GUIDE / ACTIVE DIRECTORY / DISASTER RECOVERY

Active Directory Disaster Recovery: Domain Controller dead – now what?

A domain controller has failed. The next steps determine whether this is a short outage or a real Active Directory disaster. This practical guide covers diagnosis, FSMO, DNS and replication through System State restore, DSRM, SYSVOL, metadata cleanup and complete forest recovery.

Important: Active Directory recovery commands are not “try and see” commands. Verify the backup, roles, replication state and target server before production changes. Full forest recovery should follow a documented and tested plan.
DETECT→ISOLATE→RECOVER→VERIFY

1. First: do you really need a restore?

A dead domain controller does not automatically mean that you should restore it. If one or more healthy writable DCs remain, the preferred approach is often to replace the failed DC and promote a fresh server. A restore becomes particularly relevant when the DC is the last functioning DC in a domain, when specific directory data must be recovered to an earlier point, or during forest recovery.

2. Immediate assessment: what still works?

Before changing anything, determine which DCs are reachable, which FSMO roles exist, whether DNS works and whether replication was healthy. Do not immediately restore an old backup while a healthy DC still exists.

3. Essential diagnostics

Use `netdom query fsmo` for FSMO roles, `repadmin /replsummary` for replication health, `repadmin /showrepl` for inbound replication partners, `dcdiag /v` for detailed DC diagnostics and `dcdiag /test:dns /v` for DNS. `nltest /dsgetdc:example.local` shows which DC the locator finds.

netdom query fsmo
repadmin /replsummary
repadmin /showrepl
dcdiag /v
dcdiag /test:dns /v
nltest /dsgetdc:example.local

4. DNS is critical

AD DS depends heavily on DNS. Check `ipconfig /all` and verify that the server uses internal AD DNS servers. Use `nslookup` to test records such as `_ldap._tcp.dc._msdcs.example.local` and `_kerberos._tcp.example.local`.

ipconfig /all
nslookup
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local
nslookup -type=SRV _kerberos._tcp.example.local

5. Identify FSMO roles

The five FSMO roles are Schema Master, Domain Naming Master, RID Master, PDC Emulator and Infrastructure Master. `netdom query fsmo` gives a quick overview. PowerShell can also be used with `Get-ADForest` and `Get-ADDomain`.

netdom query fsmo
Get-ADForest | Select SchemaMaster,DomainNamingMaster
Get-ADDomain | Select PDCEmulator,RIDMaster,InfrastructureMaster

6. One DC is dead, other DCs are healthy

In this scenario restoring the dead DC is often not the best option. Verify replication, remove the failed DC according to Microsoft guidance, install a fresh Windows Server and promote it as a new DC.

7. What if the failed DC held FSMO roles?

Transfer roles if the old DC can still be recovered cleanly. If it is permanently lost, roles may need to be seized. PowerShell example: `Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster -Force`.

Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster -Force

8. FSMO seizure is not a normal transfer

Seize roles only when the former role holder will not return. The RID Master deserves particular caution because seizure affects the RID pool. A former DC whose roles were seized should not simply be returned to production with its old AD state.

9. Metadata cleanup

A permanently lost DC must be removed from the directory topology. Modern Windows Server tools can perform much of the metadata cleanup automatically when the DC object is deleted. `ntdsutil` remains available for command-line procedures. Always verify the target DC before cleanup.

ntdsutil
metadata cleanup
connections
connect to server DC02
q

10. System State backup

A domain controller needs an appropriate System State backup for AD recovery. A normal full-server backup is not automatically equivalent to an AD System State recovery point. Example: `wbadmin start systemstatebackup -backuptarget:\\BACKUP01\AD$`.

wbadmin start systemstatebackup -backuptarget:\\BACKUP01\AD$

11. Test the backup before disaster strikes

A backup is only a recovery plan once you know it can be restored. Document backup time, target, server name, forest, domain, DSRM password and recovery steps. Use an isolated Hyper-V network for realistic restore tests.

12. DSRM – Directory Services Restore Mode

Classic DC System State recovery uses Directory Services Restore Mode. For a local console, `bcdedit /set safeboot dsrepair` followed by `shutdown /r /t 0` can boot into DSRM. After recovery remove the setting with `bcdedit /deletevalue safeboot` and reboot.

bcdedit /set safeboot dsrepair
shutdown /r /t 0

# Nach dem Restore:
bcdedit /deletevalue safeboot
shutdown /r /t 0

13. List available System State backups

`wbadmin get versions -backuptarget:\\BACKUP01\AD$` lists backup versions on a network target. Choose the last known trustworthy backup before corruption or compromise, not blindly the newest one.

wbadmin get versions -backuptarget:\\BACKUP01\AD$

14. Nonauthoritative System State recovery

If healthy DCs remain and the restored DC should receive current directory data through replication, a nonauthoritative AD restore is the normal pattern. Example: `wbadmin start systemstaterecovery -version:08/15/2026-020000 -backupTarget:\\BACKUP01\AD$`. Use a real version returned by `wbadmin get versions`.

wbadmin start systemstaterecovery -version:08/15/2026-020000 -backupTarget:\\BACKUP01\AD$

15. Full forest recovery is different

If no writable DC remains, the incident becomes a forest recovery. Microsoft describes a dedicated process: restore a trusted first writable DC in each domain, establish authoritative SYSVOL on the first recovered DC, seize FSMO roles, clean up metadata for unrecovered DCs and rebuild additional DCs.

16. Authoritative SYSVOL

During a full forest recovery, SYSVOL on the first recovered DC must be made authoritative. Microsoft explicitly warns against performing a primary/authoritative SYSVOL restore on multiple DCs.

17. wbadmin with authoritative SYSVOL

Microsoft documents combined AD DS and authoritative SYSVOL recovery with `wbadmin start systemstaterecovery -version:01/01/2023-130000 -authsysvol`. The version must come from the actual backup inventory.

wbadmin start systemstaterecovery -version:01/01/2023-130000 -authsysvol

18. If Active Directory was compromised

A technical restore is not enough after suspected compromise. Establish which backup is trustworthy. Microsoft recommends resetting privileged credentials during forest recovery after compromise and includes a planned `krbtgt` reset; GMSA and user credentials may also need attention. Never blindly restore a potentially compromised DC.

19. Prove replication after recovery

Run `repadmin /replsummary`, `repadmin /showrepl`, `dcdiag`, `dcdiag /test:dns /v` and `netdom query fsmo`. Verify SYSVOL and NETLOGON with `net share`.

repadmin /replsummary
repadmin /showrepl
dcdiag
dcdiag /test:dns /v
netdom query fsmo
net share

20. Test Kerberos, DNS and logon

Test a normal domain login, DC locator and SYSVOL access. `nltest /dsgetdc:example.local` should return a reachable DC. `klist` shows Kerberos tickets. Review Directory Service, DFS Replication, DNS Server and System event logs.

nltest /dsgetdc:example.local
klist
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local

21. Do not forget time synchronization

Kerberos is sensitive to time skew. The PDC Emulator has a special timekeeping role. Check `w32tm /query /status` and `w32tm /query /configuration`.

w32tm /query /status
w32tm /query /configuration

22. Hyper-V and DC recovery

Do not simply roll back an old VM snapshot and assume AD will repair itself. VM-Generation-ID helps with supported virtualization rollback scenarios, but a snapshot is not a replacement for an AD-aware backup. Isolate a recovery VM during forest recovery.

# Recovery VM isolieren – kein Produktionsnetz
# Danach erst den dokumentierten Restore-Prozess durchführen

23. Example: replace one failed DC

With two DCs: verify the remaining DC, run replication diagnostics, check FSMO roles, transfer or seize roles if necessary, remove the old DC and clean metadata, verify DNS and Sites and Services, install a new Windows Server, promote it, verify replication and SYSVOL/NETLOGON, then redistribute FSMO roles if desired.

24. Example: entire forest lost

Isolate production, identify the last trustworthy backup, restore the first DC in each domain according to the forest recovery process, establish authoritative SYSVOL where required, seize FSMO roles, verify DNS, clean up metadata and only then rebuild additional DCs. Never start multiple old DC snapshots at once.

25. Disaster-preparedness checklist

Document forest and domain names, DCs, IP addresses, sites and subnets, DNS zones, FSMO roles, Global Catalog configuration, backup targets, successful System State backups, DSRM password, privileged accounts, Hyper-V hosts, dependencies and a tested recovery sequence.

26. Command cheat sheet

`dcdiag` – DC diagnostics. `repadmin /replsummary` – replication summary. `repadmin /showrepl` – replication partners. `netdom query fsmo` – FSMO roles. `nltest /dsgetdc:example.local` – DC locator. `w32tm /query /status` – time service. `wbadmin get versions` – backup versions. `wbadmin start systemstaterecovery` – System State recovery. `ntdsutil` – metadata cleanup and other AD maintenance. `net share` – SYSVOL/NETLOGON check.

dcdiag
repadmin /replsummary
repadmin /showrepl
netdom query fsmo
nltest /dsgetdc:example.local
w32tm /query /status
wbadmin get versions
net share

Conclusion: recovery must work before the disaster

The key is not a single command. You need a documented recovery plan, a trustworthy System State backup, a realistic restore test and a clear distinction between replacing one DC and recovering an entire forest. Replication provides availability; backup provides recoverability.

Praxis-Check: Nach jeder Recovery nicht nur „Server bootet“ prüfen, sondern AD DS, DNS, Replikation, SYSVOL/NETLOGON, Kerberos, FSMO und normale Domänenanmeldung verifizieren.
About Sille-Solutions