Windows Server 2016/2019 auf 2025 migrieren: Side-by-Side statt In-Place (DC-Migration)
Warum Microsoft für Domain Controller kein In-Place-Upgrade empfiehlt und wie du mit Side-by-Side-Migration sicher auf Windows Server 2025 umsteigst – mit vollständiger Schritt-für-Schritt-Anleitung, Pre-Flight-Checkliste und Rollback-Strategie.

Wer seinen Domain Controller von Windows Server 2016 oder 2019 auf Windows Server 2025 umstellen will, steht vor einer wichtigen Entscheidung: In-Place-Upgrade oder Neuinstallation? Microsoft beantwortet diese Frage für DCs eindeutig: Ein In-Place-Upgrade ist technisch möglich, aber ausdrücklich nicht empfohlen. Der empfohlene Weg ist die Side-by-Side-Migration – also einen neuen Server mit Windows Server 2025 frisch installieren, als DC promoten, FSMO-Rollen übertragen und den alten DC danach sauber demoten. Diese Anleitung führt dich durch die vollständige Vorgehensweise für KMU-Produktionsumgebungen, inklusive Pre-Flight-Checkliste, kritischer Fallstricke und einem klaren Rollback-Pfad per Hyper-V-Checkpoint.
Voraussetzungen
- Bestehende AD-Umgebung mit mindestens Forest Functional Level Windows Server 2016 (Umgebungen mit FFL 2012 R2 oder älter müssen erst alle DCs auf WS2016 aktualisieren und das FFL anheben)
- SYSVOL-Replikation per DFSR – nicht FRS. FRS ist in Windows Server 2025 vollständig entfernt. Prüfung:
dfsrmig /GetMigrationStatemuss „Eliminated" zurückgeben - Windows Server 2025 Lizenz (Standard oder Datacenter) + Installationsmedium/ISO
- Neuer Server oder VM: mindestens 2 vCPUs, 4 GB RAM, 40 GB Systemlaufwerk (Microsoft-Mindestanforderung WS2025). Bei Hyper-V: VM-Konfigurationsversion mindestens 9.0
- Konto mit Mitgliedschaft in Schema Admins + Enterprise Admins + Domain Admins für adprep und DC-Promote
- Konto mit Domain Admins für FSMO-Transfer und Demote
- AD System State Backup des bestehenden DCs (
wbadmin start systemstatebackup) vor Migrationsbeginn - Hyper-V-Host mit ausreichend freiem Speicher für Checkpoint des alten DCs
- Netzwerkverbindung zwischen altem und neuem DC: TCP/UDP 389 (LDAP), 636 (LDAPS), 3268 (GC), 88 (Kerberos), 53 (DNS), 445 (SMB), 49152–65535 (dynamische RPC-Ports)
- DSRM-Passwort des bestehenden DCs dokumentiert und sicher verwahrt
Schritt 1: Pre-Flight – Umgebung analysieren und absichern
Bevor du irgendetwas an der Produktionsumgebung änderst, verschaffst du dir ein vollständiges Bild des aktuellen Zustands. Führe alle folgenden Befehle auf dem bestehenden DC aus:
# Forest- und Domain-Functional-Level prüfen
Get-ADDomain | FL Name, DomainMode
Get-ADForest | FL Name, ForestMode
# Mindestanforderung: beide mindestens 'Windows2016Domain' / 'Windows2016Forest'
# Aktuellen AD-Schema-Stand prüfen
(Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion).objectVersion
# Erwartet: 87 (WS2016), 88 (WS2019/2022), 91 (WS2025 bereits deployed)
# SYSVOL-Replikationsmethode prüfen (FRS vs. DFSR)
dfsrmig /GetMigrationState
# Ausgabe 'Eliminated' = DFSR aktiv. Alles andere = FRS noch aktiv!
# FSMO-Inhaber ermitteln
Get-ADDomain | FL InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | FL DomainNamingMaster, SchemaMaster
netdom query fsmo
Dokumentiere alle Ausgaben. Falls das Functional Level unter 2016 liegt oder DFSR nicht aktiv ist, musst du diese Punkte erst beheben – die Migration ist andernfalls zum Scheitern verurteilt.
Erstelle jetzt den Hyper-V-Checkpoint des alten DCs. Dies ist dein einziger vollständiger Rollback-Pfad:
# Auf dem Hyper-V-Host ausführen, BEVOR adprep oder Promote startet
Checkpoint-VM -Name 'DC01-WS2016' -SnapshotName "Pre-WS2025-Migration-$(Get-Date -Format yyyyMMdd)"
# WARNUNG: Diesen Snapshot NUR bei vollständigem Migrationsabbruch einspielen!
# Nach erfolgtem Schema-Upgrade ist der Checkpoint wertlos (USN-Rollback-Risiko)
Erstelle außerdem ein AD System State Backup:
wbadmin start systemstatebackup -backuptarget:E: -quiet
Schritt 2: Windows Server 2025 installieren und vorbereiten
Installiere Windows Server 2025 auf dem neuen Server oder der neuen VM als saubere Neuinstallation (kein Upgrade eines bestehenden Systems). Konfiguriere anschließend folgende Punkte, bevor du mit dem DC-Promote beginnst:
- Statische IP-Adresse vergeben und als primären DNS-Server die IP des bestehenden DCs eintragen
- Computernamen setzen (z. B.
DC-WS2025) und Server in die Domain aufnehmen – noch nicht als DC promoten - Windows Updates vollständig einspielen und neu starten
- Bei Hyper-V: VM-Konfigurationsversion prüfen (
Get-VM | FL Name,Version) – bei Version unter 9.0 ggf.Update-VMVersionausführen, sofern der Hyper-V-Host das unterstützt
Schritt 3: AD DS Rolle installieren und DC promoten
Der entscheidende Vorteil der Side-by-Side-Methode: adprep läuft automatisch im Hintergrund, wenn du den Promote-Assistenten im Server Manager oder die PowerShell-Cmdlets verwendest. Du musst adprep nicht manuell aufrufen.
# AD DS Rolle installieren (löst beim anschließenden Promote automatisch adprep aus)
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Nach der Installation erscheint im Server Manager der Link „Promote this server to a domain controller". Wähle dort „Add a domain controller to an existing domain" und gib die Domäne sowie deine Credentials an. Alternativ per PowerShell:
# DC-Promote per PowerShell (adprep läuft automatisch)
Install-ADDSDomainController `
-DomainName 'contoso.local' `
-InstallDns:$true `
-Credential (Get-Credential) `
-SafeModeAdministratorPassword (Read-Host -AsSecureString 'DSRM Password') `
-Force:$true
Vergib beim Promote ein sicheres DSRM-Passwort und verwahre es dokumentiert in deinem Passwort-Manager – ohne dieses Passwort ist eine AD-Offline-Reparatur unmöglich. Der Server startet nach dem Promote automatisch neu.
Beim ersten WS2025-DC in der Umgebung hebt adprep das AD-Schema automatisch von Version 87/88 auf Version 91 an. Die drei neuen LDF-Dateien heißen sch89.ldf, sch90.ldf und sch91.ldf. Schemaänderungen sind irreversibel – ein eingespielter Checkpoint nach diesem Zeitpunkt würde zu einem USN-Rollback führen und die AD-Datenbank-Korruption führen.
Schritt 4: Replikation und Global Catalog prüfen
Nach dem Neustart des neuen DCs wartest du einige Minuten auf die initiale AD-Replikation und prüfst dann deren Zustand:
# Replikationszusammenfassung prüfen
repadmin /replsummary
# Alle Replikationspartner müssen 0 Failures zeigen
# Detaillierte Replikationsübersicht
repadmin /showrepl
# DC-Diagnose durchführen
dcdiag /test:replications /v
Prüfe außerdem, ob der neue DC als Global Catalog konfiguriert ist. Öffne dazu „Active Directory Sites and Services" → Dein Standort → Servers → DC-WS2025 → NTDS Settings → rechte Maustaste → Properties → Haken bei „Global Catalog" setzen, falls nicht bereits aktiv. Das ist besonders wichtig, wenn der alte DC der einzige GC war.
Schritt 5: FSMO-Rollen auf den neuen DC transferieren
Alle fünf FSMO-Rollen müssen auf den neuen DC übertragen werden, bevor du den alten DC demotierst. Ein Abschalten des alten DCs ohne vorherigen Transfer erzwingt ein „Seize" der Rollen – das ist ein Notfallverfahren mit Nachfolgerisiken, kein normaler Betrieb.
# Alle 5 FSMO-Rollen auf den neuen DC transferieren
# 0=PDCEmulator, 1=RIDMaster, 2=InfrastructureMaster, 3=DomainNamingMaster, 4=SchemaMaster
Move-ADDirectoryServerOperationMasterRole -Identity 'DC-WS2025' -OperationMasterRole 0,1,2,3,4
# Verifikation: alle Rollen müssen jetzt auf DC-WS2025 zeigen
Get-ADDomain | FL InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | FL DomainNamingMaster, SchemaMaster
netdom query fsmo
Eine Übersicht der FSMO-Rollen und ihrer Reichweite:
| FSMO-Rolle | Reichweite | Auswirkung bei Ausfall |
|---|---|---|
| Schema Master | Forest (1×) | Keine Schemaänderungen möglich |
| Domain Naming Master | Forest (1×) | Keine Domains hinzufügen/entfernen |
| PDC Emulator | Domain (1×) | Zeitsynchro, Kennwortänderungen, GPO-Updates beeinträchtigt |
| RID Master | Domain (1×) | Keine neuen SIDs/Objekte nach RID-Pool-Erschöpfung |
| Infrastructure Master | Domain (1×) | Cross-Domain-Gruppenreferenzen veralten |
Schritt 6: DNS umstellen
Bevor du den alten DC demotierst, müssen alle Clients und Server den neuen DC als primären DNS-Server verwenden. Vergisst du diesen Schritt oder führst ihn zu spät durch, bricht nach dem Demote die gesamte Namensauflösung und damit die AD-Authentifizierung zusammen.
# Auf dem neuen DC selbst: eigene IP als ersten DNS-Server eintragen
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('192.168.1.10','127.0.0.1')
# DHCP-Server: Option 006 (DNS-Server) auf die IP des neuen DCs aktualisieren
# Danach mindestens eine DHCP-Lease-Time abwarten, bevor du den alten DC demotierst
Prüfe nach der DNS-Umstellung, dass der neue DC die DNS-Zonen korrekt repliziert hat und alle A-Records sowie NS-Einträge der Domäne korrekt auflöst. Weitere Details zur DNS-Konfiguration findest du in der Anleitung zur DHCP- und DNS-Rolle auf Windows Server.
Schritt 7: Alten DC demoten
Jetzt, da alle FSMO-Rollen transferiert und die DNS-Umstellung abgeschlossen ist, kannst du den alten DC sauber demoten. Der Demote-Vorgang entfernt die AD DS-Rolle und stuft den Server zum normalen Mitgliedsserver herab:
# Alten DC demoten (auf dem alten DC ausführen)
Uninstall-ADDSDomainController `
-LocalAdministratorPassword (Read-Host -AsSecureString 'Local Admin Password') `
-DemoteOperationMasterRole:$true `
-RemoveApplicationPartitions:$true `
-Force:$true
# -DemoteOperationMasterRole:$true greift ggf. verbliebene FSMO-Rollen automatisch auf
Der Server startet nach dem Demote neu. Er ist danach ein normaler Mitgliedsserver der Domäne und kann weiterverwendet oder dekommissioniert werden.
Schritt 8: AD bereinigen und Functional Level anheben (optional)
Nach dem Demote verbleiben Reste des alten DCs in Active Directory, die manuell bereinigt werden müssen:
# Computerobjekt des alten DCs löschen (auf neuem DC ausführen)
Get-ADComputer -Identity 'OLDDC01' | Remove-ADObject -Recursive
# DNS: Veraltete A-Records und NS-Einträge des alten DCs im DNS Manager löschen
# AD Sites and Services: Serverobjekt des alten DCs manuell über die GUI entfernen
# Pfad: Sites > [Dein Standort] > Servers > OLDDC01 > rechte Maustaste > Delete
Das Anheben des Forest/Domain Functional Levels auf Windows Server 2025 ist optional. WS2025-DCs laufen problemlos im FFL/DFL Windows Server 2016. Das neue WS2025-Functional-Level bietet lediglich das optionale Feature „Database 32k pages". Da der Anhebungsvorgang irreversibel ist, sollte er nur nach sorgfältiger Planung und Applikationskompatibilitätsprüfung erfolgen:
# Domain Functional Level anheben (optional, NICHT umkehrbar!)
Set-ADDomainMode -Identity 'contoso.local' -DomainMode Windows2025Domain
# Forest Functional Level anheben (optional, NICHT umkehrbar!)
Set-ADForestMode -Identity 'contoso.local' -ForestMode Windows2025Forest
Vergleich: In-Place-Upgrade vs. Side-by-Side
| Kriterium | In-Place-Upgrade | Side-by-Side (empfohlen) |
|---|---|---|
| Microsoft-Empfehlung für DCs | Ausdrücklich nicht empfohlen | Empfohlener Standard |
| AD-Datenbank-Risiko | Hoch (Altlasten, Korruptionsrisiko) | Niedrig (saubere NTDS.dit) |
| AD-Performance-Verbesserungen | Nicht vollständig verfügbar | Vollständig verfügbar |
| Rollback-Möglichkeit | Sehr eingeschränkt | Hyper-V-Checkpoint vor Promote |
| Downtime | Länger (Upgrade-Prozess) | Nahezu null bei korrekter Ausführung |
| adprep | Manuell erforderlich | Automatisch beim Promote |
Troubleshooting / Typische Fehler
- „The forest functional level of the domain in which you are trying to install is not compatible with this version of Windows Server." – Das Forest Functional Level liegt unter Windows Server 2016. Lösung: Erst alle DCs auf mindestens WS2016 aktualisieren, dann FFL auf 2016 anheben, danach erneut versuchen.
- SYSVOL-Replikation funktioniert nicht nach Promote, GPOs werden nicht angewendet – SYSVOL wird noch per FRS repliziert. FRS ist in WS2025 entfernt. Prüfung:
dfsrmig /GetMigrationState. Lösung: DFSR-Migration vollständig abschließen, bevor der erste WS2025-DC promoted wird. - „Adprep could not contact a replica for partition" – adprep wurde manuell auf dem falschen DC ausgeführt oder die Netzwerkkonnektivität zum Schema Master bzw. Infrastructure Master fehlt.
adprep /forestprepmuss auf dem Schema-Master-DC (oder mit Konnektivität dazu) ausgeführt werden. - Authentifizierungsausfall nach Demote des alten DCs – Clients verwenden noch die IP des alten DCs als DNS-Server. Lösung: DHCP-Option 006 korrigieren, ggf.
ipconfig /flushdnsundipconfig /renewauf Clients erzwingen. - Replikationswarnungen nach Demote (Event 1308, 1311, 2023) – Das Serverobjekt des alten DCs wurde nicht aus AD Sites and Services entfernt. Lösung: Manuell über die MMC-Konsole löschen.
- Authentifizierungsprobleme mit Universal Groups in Multi-Domain-Forest – Der neue DC wurde nicht als Global Catalog konfiguriert. Lösung: In AD Sites and Services → NTDS Settings des neuen DCs → Haken bei „Global Catalog" setzen.
- Performance-Probleme oder falsche Hardwareinformationen nach WS2025-Installation auf Hyper-V – VM-Konfigurationsversion ist veraltet (z. B. 5.0 von Hyper-V 2012 R2). Prüfung:
Get-VM | FL Name,Version. Lösung:Update-VMVersion -VMName 'DC-WS2025'auf dem Hyper-V-Host ausführen. - FSMO-Rollen nach Demote des alten DCs nicht verfügbar – Alten DC demoted, ohne vorher alle Rollen zu transferieren. Lösung: Rollen per
ntdsutilseizen (Notfallverfahren) und anschließend die AD-Gesundheit mitdcdiagprüfen.
Häufige Fragen
Kann ich meinen bestehenden WS2016/2019-DC direkt per In-Place-Upgrade auf WS2025 hochrüsten?
Technisch unterstützt Microsoft In-Place-Upgrades für Domain Controller, empfiehlt es aber ausdrücklich nicht. Der Grund: Ein sauberes OS-Install gewährleistet alle AD-Performance-Verbesserungen, während ein In-Place-Upgrade Altlasten aus dem vorherigen Betriebssystem mitschleppt und bei DCs ein deutlich höheres Risiko für AD-Datenbank-Korruption trägt. Für KMU-Produktionsumgebungen ist Side-by-Side (Neuinstallation + Promote/Demote) der sichere Standard.
Muss ich adprep manuell ausführen, bevor ich den neuen DC promote?
Nein – nicht bei der Side-by-Side-Methode. Wenn du die AD DS-Rolle per Server Manager oder PowerShell (Install-WindowsFeature) installierst und dann den Promote-Assistenten verwendest, läuft adprep /forestprep und adprep /domainprep automatisch im Hintergrund. Manuelles adprep ist nur beim In-Place-Upgrade eines bestehenden DCs notwendig oder wenn du das Schemaupgrade ausdrücklich vorab durchführen möchtest.
Was passiert, wenn mein Forest noch auf Functional Level 2012 R2 ist?
Die Promotion eines WS2025-DCs wird hart geblockt. Voraussetzung ist mindestens Forest Functional Level Windows Server 2016. Das bedeutet in der Praxis: Erst alle DCs im Forest auf mindestens WS2016 aktualisieren (ebenfalls per Side-by-Side-Migration), dann das FFL auf 2016 anheben, und erst danach kann ein WS2025-DC eingeführt werden.
Wie sieht ein sicherer Rollback-Pfad für KMU aus?
Der Hyper-V-Checkpoint des alten DCs, erstellt vor jedem Migrationsschritt, ist der einzige praktische Rollback-Pfad. Dieser Checkpoint darf aber nur eingespielt werden, wenn die gesamte Migration vollständig abgebrochen wird. Nach einem erfolgten Schema-Upgrade würde das Einspielen des Checkpoints zu einem USN-Rollback führen und die AD-Datenbank korrumpieren. Zusätzlich sollte ein regelmäßiges AD-Backup per wbadmin start systemstatebackup als dauerhafter Schutz bestehen.
Muss ich den Domain/Forest Functional Level nach der Migration auf 2025 anheben?
Nein, das ist optional. WS2025-DCs laufen problemlos im FFL/DFL Windows Server 2016 – es gibt keine Funktionseinschränkungen im täglichen Betrieb. Das neue WS2025-Functional-Level bietet lediglich das optionale Feature „Database 32k pages". Da der Anhebungsvorgang irreversibel ist, sollte er nur nach sorgfältiger Planung und Anwendungskompatibilitätsprüfung durchgeführt werden.
Was ist das DSRM-Passwort und warum ist es so wichtig?
Das Directory Services Restore Mode (DSRM)-Passwort wird beim DC-Promote vergeben. Es ist der einzige Zugang zum DC, wenn Active Directory im Reparaturmodus gestartet wird – zum Beispiel nach einer Datenbank-Korruption oder wenn AD selbst nicht startet. Ohne dieses Passwort ist eine Offline-Reparatur unmöglich. Es muss sicher verwahrt werden (Passwort-Manager, dokumentiertes Notfallkonzept), unabhängig vom normalen Domain-Admin-Kennwort.
Fazit
Die Side-by-Side-Migration auf Windows Server 2025 ist für KMU der einzig empfohlene Weg, wenn es um Domain Controller geht. Der Mehraufwand gegenüber einem In-Place-Upgrade ist überschaubar und wird durch einen saubereren AD-Zustand, vollständige Performance-Verbesserungen und einen klaren Rollback-Pfad per Hyper-V-Checkpoint mehr als aufgewogen. Die wichtigsten Pflichtpunkte: Forest Functional Level mindestens Windows Server 2016 sicherstellen, SYSVOL auf DFSR umstellen (FRS ist in WS2025 entfernt), alle fünf FSMO-Rollen ordentlich transferieren und DNS-Umstellung vor dem Demote des alten DCs abschließen. Wer diese Reihenfolge einhält, kann den Migrate-Prozess in einer Produktionsumgebung mit nahezu null Downtime durchführen. Für die weitere Absicherung der neuen Umgebung empfehlen sich anschließend ein Review der Active-Directory-Grundkonfiguration und Benutzer-/OU-Struktur sowie eine Überprüfung der Gruppenrichtlinien und GPO-Struktur auf dem neuen DC.
Weiterführende Anleitungen und Quellen
- Active Directory Domäne einrichten – Benutzer und OU-Struktur
- Gruppenrichtlinien (GPO) – Grundlagen und Praxis
- Hyper-V virtuelle Maschinen erstellen und Checkpoints verwalten
- DHCP und DNS Rolle auf Windows Server konfigurieren
Quellen: Microsoft Learn: Upgrade domain controllers to a newer version of Windows Server · Microsoft Learn: Active Directory Domain Services Functional Levels · Microsoft Learn: Windows Server Active Directory schema updates · CheckYourLogs.Net: Zero-Downtime AD DS Migration from Windows Server 2016 to 2025 · blog.rmilne.ca: Windows Server 2025 DC Requires AD DS FFL 2016 Minimum