#adreplikation

[fabian-niesen]

Domänencontroller migrieren, aber richtig

Einen Domänencontroller zu migrieren ist in vielen Umgebungen mehr als nur ein Servertausch. Spätestens wenn Name und IP-Adresse des bisherigen DC weiterverwendet werden sollen, hängen DNS, NTP, LDAP, Replikation und oft auch Drittanwendungen mit daran. Wer hier ohne Plan vorgeht, riskiert verwaiste DNS-Einträge, fehlerhafte Replikation oder Probleme bei der Authentifizierung.

Der einfachste Weg ist, einen neuen Domänencontroller mit einem neuen Namen und einer neuen IP-Adresse zu installieren. Anschließend werden bei Bedarf die FSMO-Rollen verschoben und der alte DC sauber heruntergestuft. Technisch ist das oft schnell umgesetzt. In der Praxis gehen jedoch die wenigsten Unternehmen diesen Weg.

Der Grund ist einfach: Häufig sollen Name und vor allem die IP-Adresse des bisherigen Domänencontrollers weiterverwendet werden. Das ist grundsätzlich möglich, bringt aber einige Fallstricke mit sich. Die eigentliche Frage lautet daher nicht nur, wie man einen Domänencontroller migriert, sondern wie man dies sauber, sicher und ohne Folgeschäden umsetzt.

Warum der kompliziertere Weg oft der richtige ist

Für viele Unternehmen ist der aufwendigere Weg in Wahrheit der sinnvollere. Domänencontroller werden in der Praxis nicht nur von Windows-Systemen genutzt. Oft sind ihre Dienste fest mit einer IP-Adresse oder einem Namen in anderen Systemen hinterlegt.

Typische Beispiele aus der Praxis sind:

- DNS-Server für Systeme mit fester IP-Adresse - NTP-Server für Nicht-Windows-Systeme - LDAP- oder LDAPs-Server für die Authentifizierung von Druckern, Zeiterfassungen, Telefonanlagen, Linux-Servern, VMware und anderen Anwendungen

Wenn alle Systeme ausschließlich per DHCP arbeiten würden, könnte man viele Abhängigkeiten einfach über eine Anpassung im DHCP-Server lösen. In realen Umgebungen ist das aber oft nicht möglich oder bringt mehr Nachteile mit sich, als den Domänencontroller gezielt auszutauschen und Name oder IP-Adresse wiederzuverwenden.

Was vor der Migration eines Domänencontrollers beachtet werden muss

Vor der Migration gelten einige grundlegende Regeln. Die wichtigste zuerst: Für dieses Vorgehen benötigen Sie mehr als einen Domänencontroller. Die FSMO-Rollen müssen vorübergehend auf einen Server verschoben werden, der nicht gerade migriert wird. Wenn Sie mehrere Domänencontroller nacheinander austauschen möchten, sollte zwischen den einzelnen Schritten – abhängig von der Komplexität der Umgebung – ausreichend Zeit für Replikation und Prüfung eingeplant werden.

Bei zwei DCs an einem einzelnen AD-Standort kann man in vielen Fällen einen Domänencontroller am Vormittag und den zweiten am Nachmittag migrieren. In Umgebungen mit mehreren AD-Standorten, zusätzlichen Domänen oder Vertrauensstellungen steigt die Komplexität deutlich. Auch dort ist eine Durchführung innerhalb eines Tages möglich, allerdings nur dann, wenn nach jedem Schritt die Replikation geprüft und bei Bedarf manuell angestoßen wird.

Prüfen Sie Active Directory und die gesamte Umgebung

Vor mehr als zehn Jahren habe ich mir ein eigenes Skript geschrieben, das die AD-Umgebung auswertet und seitdem kontinuierlich erweitert wurde. Wer einen Blick darauf werfen möchte, findet es hier: Get-ADInfo.ps1 auf GitHub. Das Skript listet unter anderem auch die GUIDs der Domänencontroller für die Replikation sowie die GUID- beziehungsweise InvocationId-basierten DNS-Namen auf.

Wichtig sind vor allem die Informationen darüber, welche Domänencontroller existieren, wer welche FSMO-Rollen hält, welche Vertrauensstellungen vorhanden sind und welche Replikationsverbindungen über AD-Standortgrenzen hinweg bestehen. Besonders wichtig sind dabei die Replikationszeiten. Werden Änderungen nicht sauber repliziert, kann es passieren, dass der neue Server an anderen Standorten nicht korrekt mit bestehenden Domänencontrollern repliziert. Im schlimmsten Fall wird dadurch die Replikation zwischen Standorten oder sogar zwischen vertrauten Domänen und Gesamtstrukturen unterbrochen.

Bevor Sie mit der eigentlichen Migration beginnen, sollte zuerst geprüft werden, ob die Umgebung grundsätzlich sauber arbeitet. Dazu sollten Sie die folgenden Punkte auf allen Domänencontrollern kontrollieren:

- Prüfen Sie die Funktion der Sysvol-Replikation über DFS-R. Wenn Sie noch FRS verwenden, sollten Sie zuerst auf DFS-R migrieren. FRS ist bereits seit Windows Server 2008 veraltet und wird seit Windows Server 2016 nicht mehr unterstützt. - Führen Sie idealerweise für jeden DC einen Propagation-Test über die DFS-Verwaltungskonsole durch. Der kann für das SysVol leider nicht über die PowerShell ausgeführt werden. - Zusätzlich kann ein Backlog-Test, beispielsweise mit meinem Skript Get-DFSRBacklog.ps1, weitere Hinweise liefern. - Prüfen Sie die AD-Replikation. - Für eine generelle Prüfung führen Sie repadmin /replsum in einer administrativen Eingabeaufforderung aus. Der Befehl wertet die Replikationsverbindungen aus und liefert eine Zusammenfassung.

- Für eine Detailprüfung eignet sich repadmin /showrepl auf dem jeweiligen Domänencontroller. - Prüfen Sie alle Domänencontroller mit DCDIAG. - Führen Sie dazu DcDiag.exe in einer administrativen Eingabeaufforderung aus. - Prüfen Sie das Netzwerk und alle benötigten Ports. - Ich nutze dafür Check-Network.ps1. Das Skript prüft unter anderem, ob alle für Active Directory erforderlichen Ports zu den anderen Domänencontrollern erreichbar sind. Auch die MTU kann dabei kontrolliert werden. - Der Hintergrund ist praxisnah: Ich hatte einmal über drei Firewalls hinweg ein Problem mit UDP-Fragmentierung auf der mittleren Firewall. Betroffen waren Kerberos-Pakete, die in bestimmten Situationen zu groß für TCP wurden. Ohne Zugriff auf die Firewall-Logs habe ich über eine Woche gebraucht, um die Ursache zu finden. Daraus entstand damals der CMD-Vorgänger dieses Skripts. - Prüfen Sie die eingetragenen DNS-Server. Auf jedem Domänencontroller sollte als bevorzugter DNS-Server immer ein anderer DC eingetragen sein. Idealerweise verwenden Sie IPv4. Link-Local-IPv6-Adressen, die mit FE80: beginnen, sollten hier nicht verwendet werden – es sei denn, Sie haben nur ein einziges Netzwerksegment und das wird sich auch künftig nicht ändern.

Besonderheiten bei mehreren Standorten und Vertrauensstellungen

In Active-Directory-Umgebungen mit mehreren AD-Standorten und/oder Vertrauensstellungen gelten zusätzliche Anforderungen. Bevor Sie Replikationsverbindungen manuell ändern, sollten Sie zuerst prüfen, ob der Knowledge Consistency Checker (KCC) aktiv ist. Das ist standardmäßig der Fall. Der KCC prüft in regelmäßigen Abständen die Replikation und erstellt bei Bedarf automatisch neue Replikationsverbindungen.

Wichtig ist dabei: Das geschieht nicht sofort. Änderungen an der Topologie müssen zunächst selbst repliziert werden. Deshalb ist bei Änderungen wie dem Entfernen und Hinzufügen von Domänencontrollern Geduld erforderlich. Grundsätzlich sollte der KCC seine Arbeit machen dürfen, sofern keine sehr speziellen Anforderungen in der Netzwerkarchitektur dagegensprechen. Solche Sonderfälle sind in der Praxis selten.

- Prüfen Sie bei mehreren Standorten, ob auf dem zu entfernenden Domänencontroller manuelle Replikationsverbindungen eingetragen sind. - Wenn dies der Fall ist, müssen diese Verbindungen in beide Richtungen angepasst und die erfolgreiche Replikation anschließend geprüft werden. - Wenn nötig, kann die Replikation mit repadmin beschleunigt werden. - Prüfen Sie Änderungen an der Topologie immer auf Domänencontrollern an beiden betroffenen AD-Standorten. - Aktualisieren Sie die Konsolenansicht regelmäßig, da gerade Active Directory-Standorte und -Dienste gerne veraltete, zwischengespeicherte Informationen anzeigt.

Herabstufen des alten Domänencontrollers

Wenn alle Prüfungen erfolgreich waren, kann mit der eigentlichen Migration begonnen werden. Wichtig ist dabei vor allem eines: nichts überstürzen. Domänencontroller sind das Gehirn des Active Directory. Wenn Sie die vorgeschlagenen Vorprüfungen noch nicht durchgeführt haben, holen Sie das nach. Viele Probleme, die später aufwendig analysiert werden müssen, lassen sich an dieser Stelle bereits verhindern.

Stufen Sie den auszutauschenden Domänencontroller sauber herunter. Kürzen Sie keine Neustarts ab, denn diese sind in diesem Ablauf sinnvoll und notwendig. Nach der Herabstufung zum Mitgliedsserver sollte der Server nicht einfach aus Active Directory gelöscht werden. Entfernen Sie ihn sauber aus der Domäne, indem Sie ihn in eine Arbeitsgruppe verschieben, und führen Sie danach den Neustart durch. Erst wenn der Server in der Arbeitsgruppe gestartet wurde, sollte er endgültig gelöscht, abgeschaltet oder abgebaut werden.

Prüfen Sie danach die folgenden Punkte sorgfältig in dem AD-Standort, in dem der Server zuvor betrieben wurde. Wenn dort nur ein einzelner DC vorhanden war, prüfen Sie diese Punkte auf dem PDC-Emulator.

- Wurden die Replikationsverbindungen des alten Domänencontrollers in Active Directory-Standorte und -Dienste entfernt? - Befindet sich das Computerkonto nicht mehr in der OU Domain Controllers? - Ist der alte Domänencontroller noch in der DNS-Zone _msdcs vorhanden? Das gilt auch für GUID- beziehungsweise InvocationId-basierte DNS-Namen. Prüfen Sie die komplette Zone einschließlich der standortbezogenen Einträge. Wenn Sie noch Einträge finden, löschen Sie diese manuell – aber nur dann, wenn eindeutig klar ist, dass es sich um verwaiste Einträge handelt.

Wenn Sie mehrere AD-Standorte oder Vertrauensstellungen haben, warten Sie danach, bis die Replikation des Active Directory abgeschlossen ist und der KCC gegebenenfalls die Replikationsverbindungen wiederhergestellt hat.

Passiert das nicht innerhalb der erwarteten Zeit, kann eine manuelle Wiederherstellung der Verbindungen erforderlich sein. Als Faustregel bietet sich an: Intersite-Replikationszeit × 2 + 1 Stunde. Das ist jedoch eine Maßnahme zur Fehlerbehebung und keine Abkürzung für ungeduldige Administratoren. Denken Sie daran, dass Intersite-Replikationsverbindungen immer auf einem Domänencontroller am jeweiligen AD-Standort eingerichtet werden müssen.

Wenn die Replikationsverbindungen wieder sauber aussehen, wiederholen Sie die bereits durchgeführten Prüfungen, um sicherzustellen, dass die Umgebung weiterhin konsistent ist.

Heraufstufen des neuen Domänencontrollers

Bevor der neue Domänencontroller heraufgestuft wird, sollten alle Netzwerkverbindungen noch einmal geprüft werden. Am einfachsten geht das mit Check-Network.ps1.

Wenn alle Prüfungen abgeschlossen sind, kann der neue DC heraufgestuft werden. Wichtig ist dabei, dass Name und IP-Adresse vorab korrekt vorbereitet wurden und der Server bereits in der Domäne Mitglied ist. Nach der Heraufstufung und den erforderlichen Neustarts sollten Sie mindestens die folgenden Punkte prüfen:

- Sind SysVol und NetLogon freigegeben? Am einfachsten prüfen Sie das mit Get-SmbShare. - Wurde das Computerobjekt in die OU Domain Controllers verschoben? - Wurde der Server dem richtigen AD-Standort zugeordnet? - Sind die DNS-Einträge des neuen DC in _msdcs vorhanden? - Ist DCDIAG ohne kritische Fehler? - Funktioniert die DFS-R-Replikation? - Funktioniert die AD-Replikation? - Sind die DNS-Server korrekt eingetragen? Als bevorzugter DNS muss ein anderer DC eingetragen sein. Der eigene Server sollte höchstens ergänzend eingetragen werden. Andernfalls sind Replikationsprobleme praktisch vorprogrammiert.

Im Anschluss sollten alle Dienste und Systeme geprüft werden, die bisher den alten Domänencontroller verwendet haben. Dazu gehören insbesondere DNS, NTP, LDAP, LDAPs sowie Anwendungen mit fest konfigurierten Zielsystemen.

Und wer das gerne nochmal als Plan haben möchte, bitte sehr.

Ablaufplan Domänencontroller migrieren, aber richtig

Troubleshooting

DFS-Replikation funktioniert nicht richtigWenn es Probleme mit der DFS-R-Replikation gibt, sichern Sie zuerst auf allen betroffenen Domänencontrollern den SysVol-Ordner. Prüfen Sie anschließend, ob unter „Policies“ Ordner vorhanden sind, die auf dem PDC-Emulator fehlen. Bevor Sie Dateien kopieren, sollten Sie unbedingt kontrollieren, ob die zugehörigen Gruppenrichtlinien auf dem PDC-Emulator überhaupt noch existieren. Die IDs lassen sich mit dem PowerShell-Befehl „Get-GPO -All | Format-Table -Property DisplayName,Id -AutoSize“ ermitteln. Sichern Sie im Zweifel auch die SysVol-Ordner der anderen Domänencontroller. Beachten Sie außerdem, dass bei gestörter Replikation einzelne Server ältere Versionen von Gruppenrichtlinien enthalten können. Wird die Replikation später repariert oder wechseln diese Server den Domänencontroller, kann sich das Verhalten der Systeme ändern. Wenn alles geprüft und gesichert wurde, kann eine autorisierende DFS-R-Wiederherstellung durchgeführt werden, idealerweise mit dem PDC-Emulator als Quelle. Prüfen Sie danach das Ereignisprotokoll und testen Sie die normale DFS-R-Replikation erneut.Was tun bei verwaisten DNS-Einträgen alter Domänencontroller?Vor der Bereinigung sollten Sie zuerst die GUIDs beziehungsweise InvocationIds der Domänencontroller ermitteln. Get-ADInfo.ps1 zeigt diese Werte an. Im DNS sollten nur noch Alias-Einträge beziehungsweise Registrierungen aktiver Domänencontroller vorhanden sein. Prüfen Sie dabei auch Einträge wie _kerberos, _ldap sowie weitere Dienstregistrierungen in den Unterzonen _tcp und _udp. Das gilt sowohl für die eigentliche DNS-Zone als auch für die AD-integrierte Zone _msdcs. Veraltete Einträge sollten entfernt und anschließend repliziert werden, damit alle Domänencontroller denselben Stand haben.Was tun bei fehlenden DNS-Einträgen des neuen Domänencontrollers?Prüfen Sie zuerst, ob die Replikation aktuell und fehlerfrei ist. Möglicherweise wurde der fehlende Eintrag einfach noch nicht repliziert. Ist das nicht die Ursache, sollten die auf dem Server eingetragenen DNS-Server geprüft werden. Als bevorzugter DNS sollte immer ein anderer Domänencontroller eingetragen sein. Der lokale Server sollte höchstens sekundär mit 127.0.0.1 oder einem vergleichbaren Eintrag verwendet werden. Wenn auch das nicht die Ursache ist, können Sie die DNS-Registrierung mit „ipconfig /registerdns“ als Administrator neu anstoßen. Innerhalb von etwa 15 Minuten sollten die Einträge erscheinen. Hinweise auf die Ursache finden sich häufig im Ereignisprotokoll. Wenn weder Fehlermeldungen im Eventlog noch Einträge in DNS erscheinen, kann auch eine spezielle Hub-Spoke-Konfiguration der Umgebung die Ursache sein.Probleme mit LDAP oder LDAPs nach der UmstellungGerade wenn für Domänencontroller Zertifikate ausgestellt wurden, um LDAP per TLS abzusichern, kann es nach der Migration zu Problemen kommen. In vielen Umgebungen wurden bei der Einrichtung nicht die Zertifikate der Zertifizierungsstelle, sondern direkt die Zertifikate des bisherigen Domänencontrollers verteilt oder hinterlegt. Besonders bei selbstsignierten Zertifikaten ohne eigene Zertifizierungsstelle kann das nach einem Austausch zu zusätzlichem Aufwand führen. In solchen Fällen sollten Zertifikatskette, Vertrauensstellung und Zielnamen sorgfältig geprüft werden.Gruppenrichtlinien lassen sich nach der Migration nicht anwendenGelegentlich kommt es vor, dass Gruppenrichtlinien nach der Migration nicht mehr korrekt angewendet werden. Oft taucht dann eine GUID wie „{F312195E-3D9D-447A-A3F5-08DFFA24735E}“ auf. Dabei handelt es sich um die GUID der Gruppenrichtlinienerweiterung, die das Problem verursacht. Ein typischer Kandidat in virtuellen Umgebungen ist die Erweiterung „VirtualizationBasedSecurity“, also Device Guard und/oder Credential Guard. In solchen Fällen sollte die betroffene Erweiterung identifiziert und die zugehörige Richtlinie gezielt geprüft werden.

Fazit

Einen Domänencontroller zu migrieren ist kein Hexenwerk, aber auch keine Aufgabe für Abkürzungen. Wer Name und IP-Adresse eines bestehenden DC wiederverwenden möchte, muss sauber arbeiten und vor allem die Umgebung vorab prüfen. Replikation, DFS-R, DNS, Standorttopologie und abhängige Dienste müssen vor und nach jedem Schritt kontrolliert werden.

Gerade in Umgebungen mit mehreren Standorten, Vertrauensstellungen oder fest konfigurierten Drittanwendungen zeigt sich, ob eine Migration geplant oder nur schnell durchgeführt wurde. Wenn Sie die Prüfungen konsequent durchführen, Replikationszeiten berücksichtigen und den alten Domänencontroller wirklich sauber entfernen, lässt sich auch der kompliziertere Weg stabil und ohne böse Überraschungen umsetzen.

Häufige Fragen zur Migration von Domänencontrollern

Kann ich bei der Migration eines Domänencontrollers Name und IP-Adresse wiederverwenden?Ja, das ist grundsätzlich möglich. Genau das ist in vielen produktiven Umgebungen sogar der wichtigste Grund für eine geplante Migration. Vor der Wiederverwendung müssen jedoch Replikation, DNS, DFS-R, Freigaben und abhängige Dienste sauber geprüft werden.Müssen die FSMO-Rollen vor der Migration verschoben werden?Ja. Die FSMO-Rollen sollten vorübergehend auf einen Domänencontroller verschoben werden, der nicht gerade migriert wird. Erst wenn die Umgebung stabil ist, sollte über eine spätere Rückverlagerung entschieden werden. Dazu kann mein Skript Move-FSMO.ps1 verwendet werden.Warum ist die AD-Replikation vor der Migration so wichtig?Wenn die Replikation bereits vor der Migration fehlerhaft ist, werden Änderungen wie das Entfernen oder Hinzufügen von Domänencontrollern nicht sauber in der Gesamtstruktur verteilt. Das führt häufig zu DNS-Fehlern, verwaisten Objekten, defekten Gruppenrichtlinien oder unterbrochenen Standortverbindungen.Kann ich einen neuen Domänencontroller installieren, wenn SYSVOL noch mit FRS repliziert wird?Bei aktuellen Windows-Server-Versionen ist das nicht mehr vorgesehen. Vor der Heraufstufung neuer Domänencontroller sollte SYSVOL auf DFS-R migriert sein. Bestehende FRS-Umgebungen müssen daher zuerst bereinigt und migriert werden.