Active Directory Disaster Recovery: Domain Controller tot – und jetzt?
Ein Domain Controller ist ausgefallen. Jetzt entscheidet sich, ob daraus ein kurzer Ausfall oder ein echtes Active-Directory-Desaster wird. Dieser Praxisguide führt von der ersten Diagnose über FSMO, DNS und Replikation bis zu System-State-Restore, DSRM, SYSVOL, Metadata Cleanup und kompletter Forest Recovery.
1. Erst einmal tief durchatmen: Ist wirklich ein Restore nötig?
Nicht jeder tote Domain Controller muss aus einem Backup wiederhergestellt werden. Wenn noch ein oder mehrere gesunde beschreibbare DCs existieren, ist die bevorzugte Strategie häufig, den ausgefallenen DC sauber zu ersetzen und anschließend neu zu promoten. Ein Restore wird insbesondere dann relevant, wenn der DC der letzte funktionierende DC eines Domains ist, wenn bestimmte Daten auf einen früheren Stand zurück müssen oder wenn eine Forest-Recovery durchgeführt werden muss.
2. Sofortaufnahme: Was funktioniert noch?
Bevor du etwas zurücksetzt oder Rollen übernimmst, ermittle den Zustand der Umgebung. Prüfe, welche DCs erreichbar sind, wer FSMO-Rollen hält, ob DNS funktioniert und ob die Replikation gesund war. Besonders wichtig: Nicht vorschnell einen alten Backup-Stand zurückspielen, solange ein gesunder DC existiert.
3. Die wichtigsten Diagnosebefehle
Diese Befehle liefern ein schnelles Lagebild. `netdom query fsmo` zeigt die FSMO-Rollen. `repadmin /replsummary` fasst Replikationsfehler zusammen. `repadmin /showrepl` zeigt die eingehenden Replikationspartner eines DC. `dcdiag /v` führt umfangreichere DC-Tests aus. Mit `dcdiag /test:dns /v` lässt sich DNS gezielt untersuchen. `nltest /dsgetdc:example.local` zeigt, welchen DC der Locator für eine Domäne findet.
netdom query fsmo
repadmin /replsummary
repadmin /showrepl
dcdiag /v
dcdiag /test:dns /v
nltest /dsgetdc:example.local4. DNS prüfen – der oft unterschätzte Teil
AD DS ist stark von DNS abhängig. Prüfe auf einem betroffenen Server mit `ipconfig /all`, welchen DNS-Server er verwendet. Mit `nslookup` lassen sich A- und SRV-Auflösungen prüfen. Besonders interessant sind `_ldap._tcp.dc._msdcs.example.local` und `_kerberos._tcp.example.local`. Ein Client sollte für AD-DNS normalerweise die internen AD-DNS-Server verwenden und nicht direkt einen öffentlichen Resolver.
ipconfig /all
nslookup
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local
nslookup -type=SRV _kerberos._tcp.example.local5. FSMO-Rollen feststellen
Die fünf FSMO-Rollen sind Schema Master, Domain Naming Master, RID Master, PDC Emulator und Infrastructure Master. Mit `netdom query fsmo` erhältst du eine schnelle Übersicht. Alternativ kann PowerShell verwendet werden: `Get-ADForest | Select SchemaMaster,DomainNamingMaster` und `Get-ADDomain | Select PDCEmulator,RIDMaster,InfrastructureMaster`. Das ActiveDirectory-Modul muss vorhanden sein.
netdom query fsmo
Get-ADForest | Select SchemaMaster,DomainNamingMaster
Get-ADDomain | Select PDCEmulator,RIDMaster,InfrastructureMaster6. Wenn ein einzelner DC tot ist und andere DCs gesund sind
In diesem Szenario ist ein Restore des toten DC häufig nicht die beste Lösung. Prüfe zuerst `repadmin /replsummary`, sichere die Erreichbarkeit der verbleibenden DCs und entferne den alten DC nach den Microsoft-Vorgaben. Anschließend installierst du einen neuen Windows Server, bindest ihn an die Domäne an, installierst AD DS und promotest ihn als neuen DC. So vermeidest du, einen möglicherweise veralteten oder beschädigten System-State wieder in die Umgebung einzubringen.
7. Wenn der tote DC FSMO-Rollen besitzt
Kann der alte DC noch sauber gestartet werden, ist ein Transfer der Rollen vorzuziehen. Ist er dauerhaft verloren und kann nicht zurückkehren, müssen Rollen gegebenenfalls übernommen werden. In PowerShell kann `Move-ADDirectoryServerOperationMasterRole` mit `-Force` für eine Übernahme verwendet werden. Beispiel: `Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster -Force`. Für Schema Master und Domain Naming Master sind entsprechende Enterprise-/Schema-Berechtigungen erforderlich.
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster -Force8. FSMO-Seizure ist kein normaler Transfer
Eine FSMO-Übernahme sollte nur erfolgen, wenn feststeht, dass der bisherige Rolleninhaber nicht einfach wieder online kommt. Besonders beim RID Master ist Vorsicht geboten: Microsoft weist darauf hin, dass eine Seizure den RID-Pool beeinflusst. Ein alter DC, dessen Rollen übernommen wurden, sollte nicht einfach wieder mit demselben AD-Stand produktiv online gebracht werden.
9. Wenn der alte Domain Controller endgültig verloren ist: Metadata Cleanup
Nach einem dauerhaften Ausfall muss die Umgebung von Verweisen auf den alten DC bereinigt werden. Bei modernen Windows-Server-Versionen kann das Löschen des DC-Objekts über Active Directory Users and Computers bzw. Sites and Services die Metadatenbereinigung weitgehend automatisch durchführen. Für klassische Kommandozeilenverfahren steht `ntdsutil` zur Verfügung. Ein typischer Einstieg ist `ntdsutil`, danach `metadata cleanup`, `connections`, `connect to server DC02` und anschließend die Auswahl des zu entfernenden Servers. Vorher unbedingt sicherstellen, dass tatsächlich der richtige DC entfernt wird.
ntdsutil
metadata cleanup
connections
connect to server DC02
q10. System State Backup – das eigentliche AD-Notfallwerkzeug
Ein Domain Controller benötigt für eine AD-Wiederherstellung einen geeigneten System-State-Backupstand. Microsoft weist ausdrücklich darauf hin, dass ein normales Full-Server-Backup nicht automatisch dasselbe ist wie ein für die AD-System-State-Wiederherstellung geeigneter Backupstand. Mit Windows Server Backup kann beispielsweise `wbadmin start systemstatebackup -backuptarget:\\BACKUP01\AD$` verwendet werden, sofern Windows Server Backup installiert und das Ziel korrekt vorbereitet ist.
wbadmin start systemstatebackup -backuptarget:\\BACKUP01\AD$11. Backup vor dem Desaster testen
Ein Backup ist erst dann ein Recovery-Konzept, wenn du weißt, dass es wiederhergestellt werden kann. Dokumentiere Backupzeitpunkt, Backupziel, Servername, Domäne, Forest, DSRM-Passwort und die Recovery-Schritte. Idealerweise wird die Wiederherstellung regelmäßig in einem isolierten Hyper-V-Netz getestet. Ein restaurierter DC darf während einer Forest-Recovery nicht versehentlich mit einer noch laufenden produktiven AD-Umgebung kommunizieren.
12. DSRM – Directory Services Restore Mode
Für klassische System-State-Wiederherstellungen eines DC wird der Directory Services Restore Mode verwendet. Bei einer lokalen Konsole kann man beispielsweise `bcdedit /set safeboot dsrepair` setzen und danach mit `shutdown /r /t 0` neu starten. Nach Abschluss der Wiederherstellung muss der Safe-Boot-Eintrag wieder entfernt werden: `bcdedit /deletevalue safeboot` und anschließend neu starten.
bcdedit /set safeboot dsrepair
shutdown /r /t 0
# Nach dem Restore:
bcdedit /deletevalue safeboot
shutdown /r /t 013. Verfügbare System-State-Backups anzeigen
Mit `wbadmin get versions -backuptarget:\\BACKUP01\AD$` lassen sich verfügbare Backupversionen auf einem Netzwerkziel anzeigen. Wähle nicht einfach den neuesten Stand, sondern den letzten nachweislich vertrauenswürdigen Stand vor der Beschädigung oder Kompromittierung.
wbadmin get versions -backuptarget:\\BACKUP01\AD$14. Nonauthoritative System-State-Wiederherstellung
Wenn noch gesunde DCs existieren und der wiederhergestellte DC anschließend seine AD-Daten wieder von den Replikationspartnern erhalten soll, ist eine nicht-autoritativ wiederhergestellte AD-Instanz das typische Szenario. Ein beispielhafter `wbadmin`-Aufruf ist `wbadmin start systemstaterecovery -version:08/15/2026-020000 -backupTarget:\\BACKUP01\AD$`. Die genaue Version muss natürlich aus `wbadmin get versions` stammen.
wbadmin start systemstaterecovery -version:08/15/2026-020000 -backupTarget:\\BACKUP01\AD$15. Vollständige Forest-Recovery: andere Liga
Wenn kein beschreibbarer DC mehr existiert, wird aus dem einzelnen Serverproblem eine Forest-Recovery. Microsoft beschreibt dafür einen eigenen Ablauf: zunächst einen vertrauenswürdigen ersten beschreibbaren DC pro Domäne wiederherstellen, SYSVOL für den ersten DC autoritativ synchronisieren, FSMO-Rollen übernehmen, Metadaten der nicht wiederhergestellten DCs bereinigen und danach weitere DCs neu aufbauen. Die Reihenfolge und Isolation sind entscheidend.
16. Autoritatives SYSVOL – nur mit voller Absicht
Bei der vollständigen Forest-Recovery muss SYSVOL auf dem ersten wiederhergestellten DC als maßgebliche Quelle etabliert werden. Microsoft warnt ausdrücklich davor, einen autoritativen/Primary-SYSVOL-Restore auf mehreren DCs durchzuführen. Bei DFSR-basiertem SYSVOL muss die autoritative Synchronisation gezielt durchgeführt werden.
17. wbadmin mit autoritativem SYSVOL
Microsoft dokumentiert für die kombinierte Wiederherstellung von AD DS und autoritativem SYSVOL beispielsweise `wbadmin start systemstaterecovery -version:01/01/2023-130000 -authsysvol`. In einer echten Umgebung muss die Versionskennung natürlich aus dem vorhandenen Backup stammen. Dieser Schalter gehört in einen geplanten Forest-Recovery-Ablauf und nicht in einen spontanen Versuch, einen einzelnen defekten DC zu reparieren.
wbadmin start systemstaterecovery -version:01/01/2023-130000 -authsysvol18. Wenn AD kompromittiert wurde
Bei Verdacht auf einen Angriff ist ein technischer Restore allein nicht ausreichend. Zuerst muss geklärt werden, welcher Backupstand noch vertrauenswürdig ist. Microsoft empfiehlt bei Forest-Recovery nach einer möglichen Kompromittierung unter anderem die Passwörter privilegierter Konten zurückzusetzen und auch das `krbtgt`-Konto im Rahmen des vorgesehenen Verfahrens zu berücksichtigen. Auch GMSA- und Benutzerkonten können betroffen sein. Ein möglicherweise kompromittierter DC darf nicht einfach aus dem Backup restauriert und ungeprüft wieder produktiv genommen werden.
19. Nach dem Restore: Replikation beweisen
Nach jedem Restore oder DC-Neuaufbau ist `repadmin /replsummary` Pflicht. Ergänzend `repadmin /showrepl`, `dcdiag`, `dcdiag /test:dns /v` und `netdom query fsmo` ausführen. Prüfe außerdem, ob SYSVOL und NETLOGON freigegeben sind: `net share` sollte unter anderem `SYSVOL` und `NETLOGON` zeigen.
repadmin /replsummary
repadmin /showrepl
dcdiag
dcdiag /test:dns /v
netdom query fsmo
net share20. Kerberos, DNS und Anmeldung testen
Teste eine Anmeldung mit einem normalen Domänenkonto, die Auflösung des DC-Locators und den Zugriff auf SYSVOL. `nltest /dsgetdc:example.local` sollte einen erreichbaren DC liefern. `klist` kann auf einem Client vorhandene Kerberos-Tickets anzeigen. Bei Problemen lohnt ein Blick in die Ereignisprotokolle von Directory Service, DFS Replication, DNS Server und System.
nltest /dsgetdc:example.local
klist
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local21. Zeitdienst nicht vergessen
Kerberos reagiert empfindlich auf Zeitabweichungen. Der PDC Emulator hat in der Domäne eine besondere Rolle für die Zeitquelle. Mit `w32tm /query /status` und `w32tm /query /configuration` lässt sich der Zustand prüfen. Nach einer Recovery sollte die Zeitquelle bewusst kontrolliert werden.
w32tm /query /status
w32tm /query /configuration22. Hyper-V und Domain Controller Recovery
Bei virtuellen DCs darf man nicht einfach alte Snapshots zurückrollen und hoffen, dass AD das schon repariert. Moderne Windows-Versionen können mit VM-Generation-ID bestimmte Virtualisierungs-Rollback-Szenarien erkennen, aber ein Snapshot ersetzt kein AD-aware Backup. Für eine echte Forest-Recovery sollte die VM isoliert gestartet und anhand des dokumentierten Recovery-Plans behandelt werden.
# Recovery VM isolieren – kein Produktionsnetz
# Danach erst den dokumentierten Restore-Prozess durchführen23. Beispiel: Einzelnen DC ersetzen – praxisnaher Ablauf
Ein möglicher Ablauf bei zwei DCs lautet: 1. Erreichbarkeit des verbleibenden DC prüfen. 2. `repadmin /replsummary` und `dcdiag` ausführen. 3. FSMO-Rollen prüfen. 4. Rollen bei Bedarf transferieren oder übernehmen. 5. Alten DC sauber bzw. forciert entfernen und Metadaten bereinigen. 6. DNS- und Sites-and-Services-Einträge kontrollieren. 7. neuen Windows Server installieren. 8. DNS/AD DS installieren. 9. neuen DC promoten. 10. Replikation prüfen. 11. SYSVOL/NETLOGON prüfen. 12. optional FSMO-Rollen zurückverteilen.
24. Beispiel: kompletter Forest verloren – Notfallablauf
Bei einer vollständigen Forest-Recovery: produktives Netz isolieren, letzten vertrauenswürdigen Backupstand bestimmen, ersten DC pro Domäne aus einem geeigneten Backup wiederherstellen, AD DS non-authoritatively und SYSVOL autoritativ nach dem Microsoft-Verfahren wiederherstellen, FSMO-Rollen übernehmen, DNS prüfen, Metadaten der nicht wiederhergestellten DCs bereinigen, AD und SYSVOL verifizieren und erst danach weitere DCs neu aufbauen. Keine weiteren DCs aus alten Snapshots ungeprüft starten.
25. Praktische Checkliste vor dem Desaster
Dokumentiert sein sollten: Forest-Name, Domänen, DC-Namen, IP-Adressen, Sites und Subnetze, DNS-Zonen, FSMO-Rollen, Global-Catalog-Konfiguration, Backupziele, letzte erfolgreiche System-State-Backups, DSRM-Passwort, privilegierte Konten, Hyper-V-Hosts, Abhängigkeiten von DHCP/NPS/PKI/File Services und ein getesteter Recovery-Ablauf.
26. Die wichtigsten Befehle auf einen Blick
`dcdiag` – DC-Diagnose. `repadmin /replsummary` – Replikationsübersicht. `repadmin /showrepl` – Replikationspartner. `netdom query fsmo` – FSMO. `nltest /dsgetdc:example.local` – DC-Locator. `w32tm /query /status` – Zeitdienst. `wbadmin get versions` – Backupversionen. `wbadmin start systemstaterecovery` – System-State-Restore. `ntdsutil` – unter anderem Metadata Cleanup und FSMO-Seizure. `net share` – SYSVOL/NETLOGON prüfen.
dcdiag
repadmin /replsummary
repadmin /showrepl
netdom query fsmo
nltest /dsgetdc:example.local
w32tm /query /status
wbadmin get versions
net shareFazit: Recovery muss vor dem Desaster funktionieren
Der wichtigste Punkt ist nicht der einzelne Befehl. Entscheidend ist ein dokumentierter Recovery-Plan, ein vertrauenswürdiges System-State-Backup, mindestens ein realistischer Restore-Test und die klare Unterscheidung zwischen dem Ersatz eines einzelnen DC und einer vollständigen Forest-Recovery. Replikation macht AD hochverfügbar – ein Backup macht es wiederherstellbar.