Le migliori pratiche per la disattivazione di un controller di dominio che è anche un server DNS?


9

Esistono due scuole di pensiero per il processo di disattivazione dei controller di dominio di Active Directory che sono ampiamente utilizzati come server DNS.

  1. Aggiungere l'indirizzo IP del controller di dominio in uscita a un nuovo controller di dominio e assicurarsi che DNS sia in ascolto su quell'indirizzo.

  2. Diminuisci il vecchio controller di dominio, lascia il ruolo DNS su di esso e configura un server di inoltro DNS globale sul tuo nuovo server.

Ovviamente, entrambi sono punti di interruzione fino a quando tutti i server e i dispositivi non sono stati configurati per utilizzare l'indirizzo IP primario di un nuovo server, ma a volte quel periodo di transizione può essere relativamente lungo a seconda delle dimensioni dell'ambiente.

C'è una buona pratica ben definita qui?


2
O un terzo, modificare qualsiasi / tutti i riferimenti al vecchio server DNS attraverso la rete?
Gravyface,

1
Naturalmente questo è l'obiettivo finale, motivo per cui l'ho definito un punto fermo. Ma in alcuni ambienti molto grandi questa non è un'opzione se vuoi che sia fatta in modo tempestivo. Ho detto: Obviously, both are stopgaps until all servers and devices have been configured to use the primary IP address of a new server, but sometimes that transition period can be relatively long depending on the size of the environment.giusto?
MDMarra,

semantica ... hai ragione, ma preferirei semplicemente cambiare sistematicamente la configurazione DNS dei dispositivi, monitorare l'attività, iniziando con gli ambiti DHCP, quindi lavorare attraverso i server in ordine da meno importante a importante (dai server membri ad altri controller di dominio) ) che impersonare il vecchio server e / o lasciarlo indugiare più a lungo del necessario.
Gravyface,

Naturalmente questa è l'opzione migliore, ma quando dico ambiente "molto grande", sto parlando di un'infrastruttura distribuita a livello globale con oltre 300 controller di dominio e molti team IT diversi che gestiscono diversi componenti dell'infrastruttura. A volte, in realtà non è possibile assicurarsi di avere tutti i dispositivi nel primo swing durante un aggiornamento.
MDMarra,

1
@gravyface Non ti sbagli, ma in ambienti ampi e geograficamente dispersi con la gestione decentralizzata di diversi componenti, non è sempre possibile concordare un piano di gioco, mettere tutti in linea e lavorare verso un obiettivo comune. A volte devi solo prendere una decisione per andare avanti e trovare una soluzione o una soluzione alternativa per assicurarti che abbia il minor numero di implicazioni per gli altri
Mathias R. Jessen,

Risposte:


5

Sono titubante nel rispondere perché penso che questa sia più una domanda di "discussione" che una domanda strettamente di domande e risposte ... ma è un sabato mattina pigro, quindi lo farò comunque.

C'è una buona pratica ben definita qui?

No. (Accidenti, forse questa è stata una risposta facile a tutti ...)

Microsoft fornisce indicazioni su Bingable molto generiche e facilmente googleabili su come degradare i controller di dominio ed eseguire migrazioni di AD e DNS, ma non mi preoccuperò di collegarle a loro né farò finta che rispondano alla tua domanda specifica, perché ovviamente Microsoft non può documentare ogni caso specifico per l'ambiente di ogni diversa organizzazione.

Quindi gli amministratori di sistema / ingegneri come noi sono lasciati colmare le lacune con la nostra competenza ed esperienza in cui Microsoft non ha scritto uno script speciale solo per noi, ed è ciò che ci rende preziosi.

Posso darti un esempio di qualcosa che abbiamo fatto per risolvere questo stesso problema, dal momento che lavoro anche in ambienti sparsi in tutto il mondo con dozzine o più controller di dominio, foreste AD diverse che convivono sulle stesse reti, anche i dispositivi non Windows consumano Servizi DNS dagli stessi controller di dominio, ecc. Spostarsi in nuovi datacenter e uscire da quelli vecchi, necessità di migrare a nuovo hardware o nuove versioni del sistema operativo e semplici vecchi criteri aziendali sono tutte le possibili ragioni per cui dovremmo rimuovere i controller di dominio che erano potenzialmente ancora in uso. E quando hai più organizzazioni eterogenee che attualmente utilizzano quei server DC / DNS, di solito è un processo estenuante ed elaborato di riconfigurazione di ogni client (molti dei quali potrebbero non essere sotto il tuo controllo) prima di mettere fuori servizio il controller di dominio, coinvolgendo i project manager,

Ecco perché dico che non penso che nessuno possa darti la risposta a questa domanda. Ci sono mille modi in cui potresti farlo e alcuni saranno migliori di altri a seconda della struttura e delle esigenze della tua organizzazione.

Qualcosa che abbiamo fatto per affrontare questo problema è creare un VIP per ciascun datacenter e raggruppare tutti i controller di dominio in quel datacenter dietro quel VIP. (Questo VIP è per il servizio DNS solo per ovvi motivi, sto non parlando di bilanciamento Kerberos e LDAP carico.) In questo modo, i clienti può essere configurato per utilizzare tale VIP per la loro resolver DNS, e noi siamo liberi di aggiungere e togliere controller di dominio dietro quel VIP ogni volta e comunque per favore.

Ma non sei di fronte al problema ... quindi date le opzioni che hai fornito:

  1. Aggiungere l'indirizzo IP del controller di dominio in uscita a un nuovo controller di dominio e assicurarsi che DNS sia in ascolto su quell'indirizzo.

  2. Diminuisci il vecchio controller di dominio, lascia il ruolo DNS su di esso e configura un server di inoltro DNS globale sul tuo nuovo server.

Vorrei scegliere l'opzione n. 1, poiché il tuo obiettivo è rimuovere le autorizzazioni dal vecchio server il più rapidamente possibile e l'opzione n. 2 non ti aiuta a sbarazzarti del vecchio server. Con l'opzione n. 2 l'esistenza del server è ancora necessaria. Né andrei con il suggerimento di Mathias R. Jessen di zone stub, perché di nuovo, devi ancora lasciare il vecchio server sul posto e in servizio, il che non è favorevole al tuo obiettivo finale.

Con l'opzione n. 1, per quanto brutta possa essere, puoi ritirare il vecchio server, richiedere risparmi sui costi per la tua azienda, evitare di dover pagare un altro mese di affitto su quel datacenter e ricevere un premio per essere un bravo impiegato.

Modifica: pensando alla nostra chat un po 'di più, penso che potrei aver proiettato i miei requisiti su di te, perché ho requisiti pull-the-plug-ASAP su alcune cose in questo momento, quindi era fresco nella mia mente. Sembra che non si abbia la necessità immediata di spegnere il server al più presto.

Detto questo, non sto cambiando il mio suggerimento, poiché lo preferirei ancora. Applicare l'IP aggiuntivo su un controller di dominio esistente ha funzionato bene per me in scenari molto simili, e preferirei piuttosto che avere una strana appendice vestigiale di un server seduto lì per un periodo di tempo indeterminato.


1
Penso che questo rientri good subjectivenel post Buono soggettivo, Cattivo soggettivo che ha definito la regola delle "domande di discussione". Almeno lo spero.
MDMarra,

@MDMarra Sono d'accordo. +1 per una domanda stimolante e interessante. :)
Ryan Ries,

Inoltre, solo per la cronaca, in genere faccio l'opposto del tuo suggerimento: D
MDMarra

5

La strada per l'inferno di Active Directory è pavimentata con bende temporanee. L'assegnazione dell'indirizzo IP di un server DNS decomposto o da decomprimere al nuovo server DC e DNS è una fasciatura temporanea.

Come notato da @gravyface nei commenti, nello scenario ideale è necessario modificare tutti gli ambiti DHCP e le configurazioni statiche per aggiornare la preferenza DNS del client al nuovo IP anziché a quello precedente, prima di decomprimere completamente il vecchio controller di dominio.

Comprendo che assicurarsi che tutti i client siano stati riconfigurati non è necessariamente possibile in tempo, ma certamente considero l'opzione numero 2 (inoltro dell'intero spazio dei nomi) come l'opzione meno discutibile qui.

Oltre a consentire al vecchio server di inoltrare le richieste anche dopo averlo declassato, consiglierei di abilitare la registrazione debug per le richieste in arrivo sul server DNS - questo rende un po 'più semplice valutare non solo se i client puntano ancora al vecchio server DNS ma identificare detti clienti.

Detto questo, penso che ti sia sfuggita l'ovvia terza opzione: Stub Zones !

  • Diminuisci il controller di dominio, mantieni il ruolo DNS e aggiungi tutte le zone precedentemente ricoperte come zone di stub - inoltra tutto il resto. In questo modo, si impone ai client di contattare effettivamente i controller di dominio che dovrebbero utilizzare, invece di fare il lavoro per loro
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.