Im folgenden Artikel geht es um ein Upgrade eines Domain-Controllers von Windows Server 2012 R2 zu Windows Server 2019. Das Besondere hieran ist jedoch, dass die IP-Adresse des Domain-Controllers am Ende gleichbleiben soll. Darüber kann man viel diskutieren, wie sinnvoll das ist, es hat zumindest einen großen Mehrwert für komplexe Umgebungen, dass bestehende umfangreiche Firewall-Settings (auf Host-Ebene und auf Netzwerk-Ebene) nicht angepasst werden müssen.

Im aktuellen Beispiel gibt es nur einen Domain-Controller. Grundsätzlich sollte man in Produktivumgebungen immer zwei Domain-Controller einsetzen. Häufig sieht man allerdings gerade in kleinen Umgebungen nur einen Domain-Controller.
Ebenso sieht man bei kleineren bis mittleren Umgebungen, dass auf dem Domain-Controller auch der DHCP-Server betrieben wird.

Empfehlung:
Selbst Microsoft empfiehlt, dass auf einem Domain-Controller keine weitere Software installiert sein sollte!

Ausgangslage

• Domain “DCU.local”
• 1 Domain-Controller mit “Windows Server 2012 R2”
  • Forest-Level: 2012 R2
  • Domain-Level: 2012 R2
  • IP-Adresse: 192.168.20.1
  • DHCP-Server: Range 192.168.20.10-19 (reicht für’s Beispiel)
• 1 Client mit “Windows 10 21H1”
  • IP-Adresse (via DHCP): 192.168.20.10
  • DNS-Server (via DHCP): 192.168.20.1

Zielbild

• Domain “DCU.local”
• 1 Domain-Controller mit “Windows Server 2019”
  • Forest-Level: 2016
  • Domain-Level: 2016
  • IP-Adresse: 192.168.20.1
  • DHCP-Server: Range 192.168.20.10-19 (reicht für’s Beispiel)
• 1 Client mit “Windows 10 21H1”
  • IP-Adresse (via DHCP): 192.168.20.10
  • DNS-Server (via DHCP): 192.168.20.1

Hinweis: Aktuell ist das höchste Forest-/Domain-Level auf “2016”, weder “Windows Server 2019” noch “Windows Server 2022” haben ein eigenes Level!

Literaturverweise

Bevor ich mich selbst an die Umsetzung gesetzt habe, habe ich mich im Internet über das Vorgehen informiert und bin auf folgende Artikel gestoßen:

• Migration Domain Controller zu Server 2016 – Frankys Web

Vorbereitung der Beispielumgebung

Zuerst habe ich o.g. Ausgangslage aufgebaut, also zwei VMs angelegt, diese in ein separates privates Netzwerk “vPRI-ADB-DCUpgrade” gehängt (Internet ist für das Beispiel nicht notwendig) und Windows Server 2012 R2 und Windows 10 21H1 installiert.

Tipp:
Wenn man kein Installationsmedium vorliegen hat, kann man sich aus dem Microsoft Evaluation Center einfach das passende herunterladen.

Anschließend regulär eine Domäne eingerichtet; ich habe sie “DCU” (= “Domain-Controller Upgrade” 😉 ) genannt.

Zudem wurde ein Standardbenutzer (“DCU\max.muster”), sowie ein Admin-Account (“DCU\demo.admin”) eingerichtet. Der “demo.admin” erhält entsprechende Rechte, um die spätere Migration von Domain-Controller und DHCP durchführen zu dürfen.

Es wurde zudem noch ein Windows 10 Client mit in die Domäne aufgenommen, hier wird dann getestet, ob der Client eine IP-Adresse erhält, sowie die Anmeldung an der Domäne als Benutzer (“DCU\max.muster”).

Die Installation des Betriebssystems und das Anlegen der Domäne behandle ich hier nicht, ebenso wenig das Einrichten des DHCP-Servers.
In der o.g. Ausgangslage ist also aufgebaut:

Ablauf der Migration

Wir gehen davon aus, dass der neue Server (also der, der Domain Controller werden soll) bereits mit Windows Server 2019 installiert und Mitglied der Domäne ist.

Folgende Schritte sind dann durchzuführen:

1. DC-Alt: Migrations-Account berechtigen
2. DC-Alt: DFS-R Migration prüfen
3. DC-Neu: Installation der Domain-Controller-Rolle
4. DC-Neu: Heraufstufen zum Domain-Controller
5. DC-Neu: Installation der DHCP-Rolle
6. DC-Alt: Export der DHCP-Konfiguration
7. DC-Alt/Neu: Prüfen der AD-Replizierung
8. DC-Alt: De-Autorisieren des DHCP-Servers, Stoppen & Deaktivieren des Dienstes
9. DC-Neu: Starten des DHCP-Serves & Autorisieren & Import der DHCP-Konfiguration
10. DC-Alt/Neu: Tausch der IP-Adressen (IP-DC-alt -> IP-temporär // IP-DC-neu -> IP-DC-alt)
11. DC-Alt/Neu: Übertragen der FSMO-Rollen (DC-alt -> DC-neu)
12. DC-Alt/Neu: Prüfen der AD-Replizierung
13. DC-Neu: Autorisierung des DHCP-Servers
14. DC-Alt: Herabstufen zum Member-Server
15. DC-Alt: Herunterfahren des Servers
16. DC-Neu: AD-Aufräumen

1. DC-Alt: Migrations-Account berechtigen

Für das Beispiel dient der Account “demo.admin”, welcher anfangs noch normaler Domain-Benutzer ist und entsprechend berechtigt werden muss, um die notwendigen Schritte durchführen zu dürfen.

• Benötigt werden folgende Rechte bzw. Gruppenmitgliedschaften:
  • Domain Admins
  • Enterprise Admins (= “Organisations Administratoren”)
  • Schema Admins

Achtung:
Für den Zeitraum der Migration sind technisch bedingt sehr weitreichende Rechte notwendig. Daher empfiehlt es sich diese Rechte nur kurz vor der Migration zu erteilen und kurz danach wieder zu entziehen!

2. DC-Alt: DFS-R Migration prüfen

Wenn die Domäne selbst aus einer Zeit vor “Windows Server 2012 R2” stammt oder man sich unsicher ist, dann sollte man in der PowerShell prüfen, ob die DFS-R Migration durchgeführt wurde:

dfsrmig /getmigrationstate

Hintergrund:
Vor Windows Server 2012 R2 war die DFS-R unverschlüsselt, ab Windows Server 2016 ist die DFS-R zwingend verschlüsselt. D.h. hat man eine alte Domäne (bspw. aus “Windows Server 2000”-Zeiten und hat die DFS-R Migration noch nicht durchgeführt, kann sich ein neuer Domain-Controller (“Windows Server 201[6/9]”) nicht damit den bisherigen replizieren.
Alle DFS-R Migrationsbefehle und weitere Infos gibt es auf: dfsrmig | Microsoft Docs

3. DC-Neu: Installation der Domain-Controller-Rolle

Hier gehe ich nicht sonderlich näher drauf ein, da ich das in einem früheren Artikel () bereits beschrieben habe. Daher nur zwei Zusammenfassungen:

4. DC-Neu: Heraufstufen zum Domain-Controller

Bei “Deployment Configuration” kann man auch einen bestimmten Account auswählen, falls der Account, mit dem man gerade angemeldet ist, nicht über die o.g. notwendigen Rechte verfügt.

Bei “Domain Controller Options” sollte man bedenken, dass das Passwort, welches man für den “Directory Services Restore Mode (DSRM)” bestenfalls keine seltsamen Sonderzeichen enthält, sowie alle vorherigen DSRM-Passwörter überschreibt.

Bei “Additional Options” ist hier im Beispiel egal, was im DropDown ausgewählt wird; bei größeren Umgebungen sollte man immer den ersten Domain-Controller nehmen.

Bei “Preparation Options” wird man auf die entsprechenden Vorbereitungen hingewiesen – daher muss auch ein Account verwendet werden, der die o.g. Rechte verfügt.

5. DC-Neu: Installation der DHCP-Rolle

Als nächstes wird auf dem neuen Server die DHCP-Rolle installiert. Wichtig ist aber, dass der DHCP-Server noch nicht autorisiert wird.

6. DC-Alt: Export der DHCP-Konfiguration

Im nächsten Schritt wird die DHCP-Konfiguration des alten Serves exportiert. Hierzu kann man mittels folgenden PowerShell-Befehles den Export durchführen:

Export-Dhcpserver -ComputerName "sdc2012.dcu.local" -File "C:\umzug\dhcpexport_dc2012.xml" -leases -verbose

Wichtig: Der Ordner “umzug” muss vorher angelegt werden!

Anschließend wird die exportierte Datei auf den neuen Server kopiert – am besten in den gleichen Ordner “C:\umzug\” .

7. DC-Alt/Neu: Prüfen der AD-Replizierung

Bevor es nun weiter geht, sollte erstmal sichergestellt werden, dass die AD-Replizierung zwischen beiden Domain-Controllern sauber funktioniert. Dafür gibt es mehrere Hilfmittel:

• Prüfen der DNS-Server-IPs
• AD-Tests:
  • repadmin /syncall
  • dcdiag /e >> C:\umzug\dcdiag_export.txt
  • repadmin /showrepl
  • repadmin /seplsummary
  • dfsrmig /getmigrationstate
  • dcdiag /test:dfsrevent
  • netdom query fsmo

Hinweis:
Bei dem einen oder anderen Test sind Fehler zu finden, das ist in meinem Fall in der Testumgebung, weil ich hier Evaluierungsversionen einsetze, welche keine Verbindung zum Internet haben und sich daher alle 60 Minuten herunterfahren. Dadurch kommt es zu Fehlereinträgen im Eventlog und dementsprechend werden diese auch bei den Checks angezeigt.

Prüfen der DNS-Server-IPs

Auf dem alten DC sollte als Primärer-DNS die IP-Adresse des neuen DCs stehen und umgekehrt, also:

repadmin /syncall

dcdiag /e >> C:\umzug\dcdiag_export.txt

repadmin /showrepl

repadmin /replsummary

dfsrmig /getmigrationstate

dcdiag /test:dfsrevent

netdom query fsmo

8. DC-Alt: De-Autorisieren des DHCP-Servers, Stoppen & Deaktivieren des Dienstes

Bevor der DHCP-Dienst auf dem neuen Server gestartet werden kann, müssen wir den alten deaktivieren. Der Grund dafür ist recht simple: ein DHCP-Server prüft beim Start, ob sich im selben Netzwerk bereits ein weiterer DHCP-Server befindet, der IP-Adressen verteilt. Ist dem so, fährt er erst gar nicht richtig hoch, sondern beendet sich wieder.

9. DC-Neu: Starten des DHCP-Serves & Autorisieren & Import der DHCP-Konfiguration

Da der Dienst auf dem neuen Server noch nicht gestartet ist, ist die DHCP-Konsole anfangs leer. Der Server kann einfach hinzugefügt werden. Anschließend kann der Server-Dienst gestartet werden. Sind bei den Unterpunkten kleine rote nach unten gerichtete Pfeile, dann einfach nochmal aktualisieren, dann sollten sie zu grünen Punkten mit weißen Pfeilen wechseln.

Allerdings hat der neue DHCP natürlich noch keinerlei Informationen, aber die können einfach vom Export des alten DHCP-Servers mittels folgenden PowerShell-Befehles importiert werden:

Import-DhcpServer -ComputerName "sdc2019.dcu.local" -File "C:\umzug\dhcpexport_dc2012.xml" -BackupPath "C:\dhcpbackup\" -Leases -Verbose

In

Wenn wir nun beide DHCP-Einstellungen auf einen Blick vergleichen, sehen wir, dass sie identisch sind.