Dieser Eintrag gehört zu meiner Serie „Migration zu Windows Server 2025„. In dieser möchte ich euch die Aktualisierung meiner Server-Infrastruktur von 2019 auf 2025 dokumentieren. Es ist eine lebendige Welt von Systemen, die mir wichtig sind. Mit realen Anforderungen und Bedingungen werde ich alle Arbeitsschritte erläutern.
Hier zeige ich euch, wie ich meine beiden DHCP-Server von Windows Server 2019 auf Windows Server 2025 im laufenden Betrieb umstelle.
Inhaltsverzeichnis
Zielsetzung
IST-Situation
Ich nutze 2 Windows Server 2019 mit der Rolle DHCP-Server für meine automatische IP-Adressvergabe. Beide laufen als VM auf je einem meiner Hyper-V-Server. Alle DHCP-Scopes sind durch DHCP-Failover ausfallsicher gestaltet. Meine geclusterte PFSense nutzt DHCP-Relay, um in den angeschlossenen Netzen die Lease-Requests der Clients anzunehmen und an beide DHCP-Server weiter zu leiten.

Ich nutze fast ausschließlich DHCP-Reservierungen, da mein Smarthome mit über 100 Aktoren und Sensoren unabhängig von einer Namensauflösung funktionieren muss:

SOLL-Situation
Die aktuelle Konfiguration hat sich gut bewährt. Daher möchte ich einen 1:1 Austausch als Ziel definieren.
Die Migration auf Windows Server 2025 darf keine Störung verursachen. Die automatische Adressvergabe muss zu jeder Zeit gewährleistet sein.
Die Namen und die IPs der aktuellen Server sollen wiederverwendet werden. In meiner kleinen Umgebung wäre ein Wechsel kein Problem. In großen Umgebungen müssten aber etliche Router neue DHCP-Helper/DHCP-Relay-Konfigurationen erhalten. Da ist mein Szenario so wahrscheinlicher.
Migrationsszenario
Damit die Namen und IPs wiederverwendet werden können, nutze ich Wipe & Load als Szenario. Für alle Interessierten habe ich hier noch einen älteren Post von einer Side-By-Side-Migration: WS IT-Solutions · Blog: Migration eines DHCP-Services
Vorbereitung
Berechtigungen
Für die Arbeiten sind verschiedene Rechte erforderlich. Meine T1-Kennung benötigt diese hier:

Review
Beide Server sollten gleich konfiguriert sein. Daher beschreibe ich hier nur den Review eines Servers.
Die Namen und IPs habe ich bereits ermittelt. Folgende Rollen und Features sind installiert:

Zusätzlich ist noch ein Wireshark installiert: Ich nutze die Server auch gerne für interne Netzwerkmitschnitte im Servernetz.
Im DHCP gibt es je Server entsprechende Serveroptionen. DNS ist unterschiedlich konfiguriert:


Das Logging für DHCP ist aktiviert und wurde auf c:\admin\DHCP\Logs umgelenkt:

So schauen die DNS-Optionen aus:

Ich habe einen DHCP-Failover im Modus Lastenausgleich konfiguriert:

Alle DNS-Records werden mit diesem Service-Account angelegt:

Es existiert ein Sicherungsjob für die DHCP-Konfiguration. Damit schneide ich die Transaktionsprotkolle der DHCP-Datenbank ab. Den Sicherungsjob exportiere ich in ein Migrationsverzeichnis:

Damit habe ich alles erfasst. Damit auch alle Optionen im DHCP synchron sind, starte ich eine Replikation von WS-NET1 auf WS-NET2. Bei mir

Man erkennt gut je Scope, dass diese synchron sind. Aber sicher ist eben sicher:

Aufbau der neuen VMs
Die neuen VMs baue ich je Hyper-V-Server auf:

Dann kopiere ich meine VHDX als Basefile in das Verzeichnis der VM und binde diese ein. Dabei ändere ich noch einige Parameter der VM:

Dann starte ich die beiden VMs und schließe das OOBE-Setup ab. Danach melde ich mich auf beiden Servern an und ändere den Computernamen und trage die IP-Konfiguration ein. Das funktioniert, weil beide VMs noch keinen Netzwerkanschluss haben 😉

Dann installiere ich die Rollen und Features, die ich später benötige:


Beide VMs sind damit vorbereitet.
Migration von WS-NET1
Maintenance aktivieren
In meinem PRTG aktiviere ich die Maintenance für die alte VM und deren Services. Danach schalte ich den Service in den Wartungsmodus. Ab jetzt antwortet er nicht mehr auf Anfragen!

Das kann man auch gut im Wireshark beobachten. Das ACK hat er vor der Wartung gesendet. Danach kommen Anfragen rein aber der DHCP antwortet nicht mehr. Das ist aber kein Problem, denn Clients ohne DHCP werden nun einfach vom anderen DHCP bedient und Clients, die ihre Lease nur verlängern wollen, probieren es später noch einmal. Und dann ist die Migration schon durch.

Austritt aus dem DHCP-Failover
Nun sichere ich noch einmal den aktuellen Stand in mein Migrationsverzeichnis. Dafür nutze ich die PowerShell. Der Datenstand ist jetzt unveränderbar, da der Service in Wartung steht:

Jetzt nehme ich den Server aus dem DHCP-Failover heraus. Dabei werden alle seine Scopes entfernt. Diese existieren nun nur noch auf dem anderen DHCP-Server:

Für diese Aktionen auf dem ersten Server habe ich folgenden PowerShell-Code verwendet:
$DHCPServer1 = "WS-NET1"
$DHCPServer2 = "WS-NET2"
$MigrationDir = "M:\AdminArea\Services\DHCP\Migration 2025"
$LogDir = "C:\Admin\DHCP\Logs"
Export-DhcpServer -ComputerName $DHCPServer1 -File "$MigrationDir\Config-$DHCPServer1.cfg" -Force -Leases
New-Item -Path "C:\Backup-$DHCPServer1" -ItemType "Directory"
Backup-DhcpServer -ComputerName $DHCPServer1 -Path "C:\Backup-$DHCPServer1"
Copy-Item -Path "C:\Backup-$DHCPServer1" -Destination "$MigrationDir" -Recurse -Force
Copy-Item -Path "$LogDir" -Destination "$MigrationDir" -Recurse -Force
$FailoverName = (Get-DhcpServerv4Failover -ComputerName $DHCPServer1).name
Get-DhcpServerv4Scope -ComputerName $DHCPServer1 |
ForEach-Object { Remove-DhcpServerv4FailoverScope `
-ComputerName $DHCPServer2 `
-Name $FailoverName `
-ScopeId $_.scopeid
}
Austausch des Servers
Nun kann ich den alten Server herunterfahren und den anderen ans Netzwerk anschließen:

Der neue Server muss nun in das Active Directory aufgenommen werden. Dafür privilegiere ich kurzzeitig meine T3-Kennung:

Damit klappt der Domain Join. Der Server braucht einen Neustart:

Nach der Neuanmeldung als T1-Admin schließe ich die DHCP-Konfiguration im Server Manager ab:

Die DHCP-Autorisierung überspringe ich, denn ich habe ja den AD-Computer durch den gleichen Namen wiederverwendet und der alte DHCP war bereits autorisiert:

Das bestätigt mir auch die DHCP-Konsole. Hier konfiguriere ich die Server-Optionen:


Dann passe ich die weiteren Optionen an. Die Logfiles des alten Servers kopiere ich von dem Migrationsverzeichnis in einen lokalen Ordner und lasse den neuen DHCP dort weiter protokollieren:

Das Passwort für den DNS-ServiceAccount habe ich mir nie aufgeschrieben. Das ist also ein guter Zeitpunkt, um es mal zu ändern. Ich generiere ein neues Passwort und trage dies im Active Directory Benutzerobjekt und beiden DHCP-Servern ein:


Eintritt in den DHCP-Failover
Der nächste Schritt ist die Einbindung in die DHCP-Failover-Beziehung. Diese führe ich vom alten WS-NET2 aus, der aktuell alle DHCP-Scopes alleine bereitstellt. Ich versuche mal, ob ich die alte Beziehung wiederbeleben kann:





Leider funktioniert das nicht. Ich erhalte als Ergebnis eine Fehlermeldung. Wahrscheinlich liegt das an der Authentifizierung mit dem geheimen Passwort…

Also lösche ich die alte Verbindung zwischen beiden Servern raus und erstelle dann eine neue. Das geht schneller als weitere Versuche:


Nun lege ich die Beziehung neu an:




Das hat geklappt:


Testphase
Ich installiere mir noch schnell meinen Wireshark und starte dann die Überwachung der DHCP-Pakete. Hier sehe ich die Antworten vom neuen DHCP:

Damit ist der erste Server einsatzbereit.
Migration von WS-NET2
Maintenance aktivieren
In meinem PRTG aktiviere ich die Maintenance für die alte VM und deren Services. Danach schalte ich den Service wie beim ersten Server in den Wartungsmodus. Ab jetzt antwortet er nicht mehr auf Anfragen!
Austritt aus dem DHCP-Failover
Wie beim ersten Server sichere ich die Konfiguration in mein Migrationsverzeichnis. Da unterstützt mich wieder die PowerShell. Achtung. Das Script ist nicht mit dem vom WS-NET1 identisch!
$DHCPServer1 = "WS-NET1"
$DHCPServer2 = "WS-NET2"
$MigrationDir = "M:\AdminArea\Services\DHCP\Migration 2025"
$LogDir = "C:\Admin\DHCP\Logs"
Export-DhcpServer -ComputerName $DHCPServer2 -File "$MigrationDir\Config-$DHCPServer2.cfg" -Force -Leases
New-Item -Path "C:\Backup-$DHCPServer2" -ItemType "Directory"
Backup-DhcpServer -ComputerName $DHCPServer2 -Path "C:\Backup-$DHCPServer2"
Copy-Item -Path "C:\Backup-$DHCPServer2" -Destination "$MigrationDir" -Recurse -Force
Copy-Item -Path "$LogDir" -Destination "$MigrationDir" -Recurse -Force
$FailoverName = (Get-DhcpServerv4Failover -ComputerName $DHCPServer2).name
Get-DhcpServerv4Scope -ComputerName $DHCPServer1 |
ForEach-Object { Remove-DhcpServerv4FailoverScope `
-ComputerName $DHCPServer1 `
-Name $FailoverName `
-ScopeId $_.scopeid
}
Austausch des Servers
Nun kann ich auch den 2. alten Server herunterfahren und den neuen an seiner Stelle in das Active Directory aufnehmen. Auch dafür nutze ich kurzfristig meine T3-Adminkennung als Domain Admin.
Eintritt in den DHCP-Failover
Wie beim ersten Server schließe ich zunächst die DHCP-Bereitstellung im Server Manager ab. Dann konfiguriere ich die Server-Optionen und passe die DNS-Optionen in den Eigenschaften des DHCP-Servers an. Als nächstes löse ich erneut die DHCP-Failover-Beziehung auf und erstelle sie neu. Dabei werden nun die Scopes vom neuen WS-NET1 auf den neuen WS-NET2 synchronisiert:

Testphase
Mit dem fix installierten Wireshart sehe ich auch auf dem zweiten Server wieder die DHCP-Antworten:

Damit ist auch der zweite Server wieder einsatzbereit.
Nacharbeiten
Monitoring konfigurieren
Auf beiden Servern installiere ich meine Scripte für PRTG:

Jetzt kann ich die Maintenance im PRTG beenden. Von den neuen Servern kommen Informationen rein:

Konfiguration der Datensicherung
Auf beiden Servern importiere ich meine geplante Aufgabe für die Windows Server Backup-Datensicherung und für die Sicherung der DHCP-Datenbank:

Die Datensicherung vom DHCP starte ich einmal als Test. Vorher lege ich noch den Sicherungsordner lokal an. Das funktioniert:

Die Anbindung des Sicherungs-Accounts nehme ich wie beim PKI-Server später vor. Aktuell habe ich für die nicht funktionierenden gMSA-Konten unter Windows Server 2025 keine Lösung.
Nachtrag vom 02.02.2025: Das TroubleShooting und die Lösung des Problems habe ich hier dokumentiert: WS IT-Solutions · Blog: gMSA TroubleShooting unter Windows Server 2025
Updatekonfiguration
Auch diese beiden neuen Server haben im WSUS die Identität und die Konfiguration der Vorgänger angenommen. Damit ist hier nichts zu tun:

Bereinigung im Hyper-V
Hier kann ich nun beide VMs und deren Festplattendateien löschen:


Abschluss
Diese Migration war keine große Sache. Das liegt aber zum einen an der Einfachheit des Services DHCP und zum anderen daran, dass ich bereits eine hochverfügbare DHCP-Lösung implementiert hatte. So konnte ich den Austausch der Server im laufenden Betrieb vornehmen. Dabei konnte ich die alten IPs wiederverwenden und sparte mir so die Anpassungen in der PFSense.
Stay tuned
Die Übersichtsseite zum meinem Migrationsprojekt findet ihr hier: Migration zu Windows Server 2025