Every domain administrator should be able to answer one question without hesitation: if a DC died right now, or someone deleted the wrong OU, could you get it back? For Active Directory, the answer comes down to whether you have a working system state backup and know how to restore from it.
System state is the supported way to protect a domain controller. It captures the AD database, SYSVOL, the registry, and the other pieces that define the DC — not as a pile of files, but in a form the restore process understands. And restoring isn’t a single action: there’s a meaningful difference between bringing a DC back to life and forcing deleted objects back into a healthy domain.
This guide covers taking the backup with wbadmin, the two restore types and when each applies,
booting into DSRM, and why reaching for a VM snapshot instead will eventually bite you.
What a system state backup actually contains
On a domain controller, “system state” is a specific set of components, not the whole disk:
System state contents on a DC
| Active Directory database | NTDS.dit and its transaction logs — the directory itself |
|---|---|
| SYSVOL | Group Policy templates and logon scripts |
| Registry | The full system registry |
| Boot files | Files needed to start Windows |
| COM+ class registration DB | Component services registration data |
| Certificate Services | CA database — only if AD CS is installed on the DC |
Because these components are interdependent, you back them up and restore them together. You can’t
cleanly pull just NTDS.dit out of a system state backup and drop it onto a running DC.
Install the backup feature and take a backup
Windows Server Backup isn’t installed by default. Add it once per DC:
Install-WindowsFeature Windows-Server-BackupThen take a system state backup with wbadmin. Send it to a dedicated volume — ideally a separate
disk, not the system volume:
# Back up system state to the E: volume
wbadmin start systemstatebackup -backupTarget:E: -quietTo confirm what backups exist and grab their version identifiers (you’ll need these for a restore):
wbadmin get versionsFor a hands-off schedule, you can drive it with a scheduled task or use the Windows Server Backup console to set a recurring system state job.
Backup hygiene checklist
- Windows-Server-Backup feature installed on key DCs
- Daily system state backup scheduled on at least two DCs
- Backups written to a separate disk or network target, not the C: volume
- Backups stored well inside the tombstone lifetime (default 180 days)
- DSRM administrator password known and documented securely
- A test restore performed at least once so you trust the process
The two kinds of restore
This is the part people get wrong, so it’s worth being precise. There are two restore types and they solve different problems.
A non-authoritative restore brings a domain controller’s data back to the point of the backup, then lets normal replication update it with everything that’s changed since. This is what you use when a DC failed and you’re rebuilding it — you want it to catch up to the rest of the domain, not override it.
An authoritative restore goes a step further. After restoring, you explicitly mark certain objects — say, an OU full of users someone deleted — so they’re treated as newer than anything replication has. Those objects then replicate out to every other DC, undoing the deletion across the domain. You only use authoritative restore to bring back objects that were deleted, and only on the objects you actually want back.
flowchart TD
A["Need to restore AD"] --> B{"What happened?"}
B -->|"A DC failed /<br/>got corrupted"| C["Non-authoritative restore<br/>let replication update it"]
B -->|"Objects were<br/>deleted by mistake"| D{"Is AD Recycle Bin<br/>enabled?"}
D -->|Yes| E["Recover from Recycle Bin<br/>(no DSRM needed)"]
D -->|No| F["Authoritative restore in DSRM<br/>mark just the deleted objects"] Restoring through DSRM
Both repair and authoritative restores happen from Directory Services Restore Mode (DSRM) — a boot mode where AD is offline so the database can be worked on safely. You log in with the DSRM administrator account and password set when the DC was promoted (you did record that, right?).
To boot a DC into DSRM, set the safe boot flag and reboot:
bcdedit /set safeboot dsrepair
shutdown /r /t 0At the logon screen, sign in as .\Administrator using the DSRM password, not the domain
admin password.
Non-authoritative restore (rebuild a DC)
In DSRM, restore the system state from your backup. First find the version, then restore it:
wbadmin get versions
wbadmin start systemstaterecovery -version:<MM/DD/YYYY-HH:MM> -quietWhen it finishes, take the DC out of DSRM and reboot back to normal:
bcdedit /deletevalue safeboot
shutdown /r /t 0Once it’s up, normal replication brings it current with the rest of the domain. Confirm with
repadmin /replsummary.
Authoritative restore (recover deleted objects)
Do the non-authoritative system state recovery exactly as above, but before rebooting out of
DSRM, use ntdsutil to mark the objects you want to win. Get the distinguished name of the
deleted OU or object first.
ntdsutil
authoritative restore
restore subtree "OU=Sales,DC=corp,DC=local"
quit
quitFor a single object use restore object instead of restore subtree. ntdsutil bumps the
version numbers on those objects so they out-replicate everything else. Then exit DSRM and reboot;
the restored objects replicate out to every other DC.
Why VM snapshots are not a substitute
It’s tempting to treat a hypervisor snapshot as a backup — they’re fast, easy, and right there in the console. For a domain controller, that’s a trap.
AD tracks every change with Update Sequence Numbers (USNs), and DCs trust that a given DC’s USN only ever moves forward. If you revert a DC to an older snapshot, its USN counter jumps backward and it starts handing out numbers other DCs have already seen attached to different changes. The result is a USN rollback: the reverted DC gets quarantined, its Netlogon service pauses replication, and the directory ends up inconsistent.
Modern hypervisors (Hyper-V on Server 2012+, current VMware and others) added the VM-Generation
ID, which lets a DC detect that it was reverted and reset its InvocationID safely instead of
rolling back. That genuinely helps — but it depends on the host, guest, and configuration all
supporting it, and it doesn’t make snapshots a complete backup strategy.
System state backup vs VM snapshot
| Recover a failed DC | System state: yes (supported). Snapshot: risky without VM-GenID. |
|---|---|
| Recover a deleted OU/user | System state: yes (authoritative). Snapshot: no, all-or-nothing revert. |
| USN rollback risk | System state: none. Snapshot: real if VM-GenID unsupported. |
| Supported by Microsoft as primary backup | System state: yes. Snapshot: no. |
Wrapping up
A working system state backup is the difference between a tense afternoon and a genuine disaster. Install Windows Server Backup, schedule daily system state backups on at least two DCs, keep them inside your tombstone lifetime, and store a copy off the box.
When you restore, match the method to the problem. Rebuilding a dead DC is a non-authoritative restore — let replication catch it up. Undoing a deletion is an authoritative restore in DSRM, marking only the objects you actually want back (or the AD Recycle Bin if it’s enabled). And keep VM snapshots in their lane: handy for a quick rollback, never a replacement for a real backup.
If your recovery plan involves standing up a replacement DC and retiring the old one, pair this with how to decommission an old domain controller safely and transferring or seizing FSMO roles.
