Restore Domain Controller Backups: System State and DSRM Steps

To back up and restore domain controller data correctly you need three things: a recent system state backup, the Directory Services Restore Mode (DSRM) password, and a clear decision about whether the restore should be non-authoritative or authoritative. This guide covers Windows Server Backup and wbadmin on Windows Server 2016 to 2025, booting into DSRM, marking objects authoritative with ntdsutil, handling SYSVOL on DFS Replication, and when the AD Recycle Bin is the better tool.

Applies to Windows Server 2016 to 2025 domain controllers

Short answer: Install the Windows Server Backup feature and run wbadmin start systemstatebackup -backupTarget:E: -quiet on at least one domain controller per domain, every day. To restore, boot the DC into DSRM (bcdedit /set safeboot dsrepair), run wbadmin get versions, then wbadmin start systemstaterecovery -version:<version>. Restart normally for a non-authoritative restore, or run ntdsutil “authoritative restore” before restarting if you need deleted objects back.

Which restore method to use

Most restore domain controller jobs are not full disasters. Pick the least invasive method that solves the actual problem.

Situation	Method	Downtime	Notes
A user, group or OU was deleted and the Recycle Bin is enabled	AD Recycle Bin (Restore-ADObject)	None	Object returns with all attributes and group memberships; no DSRM needed
One DC has a corrupt database or failed hardware, other DCs are healthy	Non-authoritative restore, or demote and re-promote	That DC only	Replication brings the DC up to date after the restore
Objects were deleted and the Recycle Bin is not enabled	Non-authoritative restore plus ntdsutil authoritative restore of the object or subtree	One DC	Restored objects replicate out to all other DCs
SYSVOL content (GPOs, scripts) was damaged on every DC	Authoritative SYSVOL restore (-authsysvol) or DFSR authoritative sync	Brief SYSVOL outage	All other DCs must resynchronise non-authoritatively
Every DC in the forest is unusable	Forest recovery	Full outage	Follow Microsoft’s forest recovery guide; outside this article’s scope

If a single DC fails and you have other healthy DCs in the same domain, demoting it (or cleaning up its metadata) and promoting a fresh server is often faster than any restore. Restores are most valuable for recovering deleted data.

Prerequisites

Check these before you need to restore domain controller data in a hurry:

• Windows Server 2016, 2019, 2022 or 2025 domain controllers. The commands are identical across these versions.
• The Windows Server Backup feature on each DC you back up: Install-WindowsFeature Windows-Server-Backup.
• Membership in Backup Operators or Administrators, and an elevated prompt, for wbadmin.
• A backup target: a dedicated local volume, an attached disk or a network share (\\backupsrv\dc-backups\). A network share keeps only the latest backup.
• The DSRM administrator password for every DC. Store it in your password vault; without it you cannot log on in DSRM. You can reset it with ntdsutil "set dsrm password" "reset password on server null" q q.
• Your forest’s tombstone lifetime (see below). A backup older than the tombstone lifetime must not be restored.

Back up a domain controller

What to back up

For Active Directory, the unit of backup is the system state. On a DC it includes the AD database (NTDS.dit) and logs, SYSVOL, the registry, boot files, COM+ database and, where installed, the certificate services database. A bare metal recovery (BMR) backup adds all critical volumes, so you can rebuild the server on new hardware. Microsoft’s forest recovery guidance recommends BMR backups for that reason, but a restore domain controller operation for AD data only needs the system state.

Back up at least two DCs per domain, on different hosts, and always include the DC that holds the most FSMO roles. Keep backups off the DC itself as well, because a backup stored on the same server is lost with it.

Run a system state backup

From an elevated Command Prompt:

wbadmin start systemstatebackup -backupTarget:E: -quiet
wbadmin get versions -backupTarget:E:

For a bare metal recovery backup instead:

wbadmin start backup -allCritical -systemState -backupTarget:E: -quiet

Windows Server Backup does not include user registry hives (HKEY_CURRENT_USER) in a system state backup or restore. That does not matter for AD, but do not treat it as a profile backup.

Schedule it

The Windows Server Backup console (wbadmin.msc) offers a Backup Schedule wizard for full or custom backups. For a daily system state job, a scheduled task is simpler and works on Server Core:

schtasks /create /tn "DC System State Backup" /sc daily /st 22:30 /ru SYSTEM /rl HIGHEST /tr "wbadmin start systemstatebackup -backupTarget:E: -quiet"

Check the result in Event Viewer » Applications and Services Logs » Microsoft » Windows » Backup » Operational, or list the stored versions with wbadmin get versions.

Tombstone lifetime and backup age

Deleted objects stay in the database as tombstones (or recycled objects) for the tombstone lifetime, then garbage collection removes them. A backup older than that period would reintroduce objects that other DCs have already purged, so Microsoft states that the backup you use must not be older than the tombstone lifetime. The default is 180 days for forests created on Windows Server 2003 SP1 and later; forests created on Windows 2000 or Windows Server 2003 RTM default to 60 days. Check your value:

$cfg = (Get-ADRootDSE).configurationNamingContext
Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,$cfg" -Properties tombstoneLifetime |
  Select-Object tombstoneLifetime

An empty value means the forest still uses the old 60-day default. In practice you want backups that are days old, not months: every day between the backup and the restore is data you must recover some other way.

Virtual machine snapshots are not backups

On a VM-GenerationID aware hypervisor (Hyper-V, current VMware and most modern platforms), Windows Server detects when a DC is reverted to a snapshot. It resets the DC’s invocation ID, discards its RID pool and resynchronises SYSVOL non-authoritatively, which prevents USN rollback. Even so, Microsoft does not recommend snapshot restores as an alternative to backups: use Windows Server Backup or another VSS-based backup product. Never copy a DC’s virtual disk to another host and start both copies, and never revert a DC snapshot on a platform that does not pass VM-GenerationID to the guest.

Boot into Directory Services Restore Mode

Every restore domain controller procedure for AD data runs while AD DS is offline, which means DSRM. From an elevated prompt on the DC:

bcdedit /set safeboot dsrepair
shutdown /r /t 0

The server restarts in DSRM. Log on as .\Administrator (or SERVERNAME\Administrator) with the DSRM password, not a domain account. Remote Desktop still works in DSRM on most builds, but have console access (iLO, iDRAC, hypervisor console) ready in case it does not. When you finish, clear the flag so the next restart is normal:

bcdedit /deletevalue safeboot
shutdown /r /t 0

On a physical server you can also press F8 during boot and pick Directory Services Repair Mode, but the bcdedit method is more reliable on modern hardware and VMs.

Non-authoritative restore

A non-authoritative restore is the default way to restore domain controller data: it puts the DC back to the state of the backup. When it restarts, normal replication updates it with every change made since, including deletions. Use it to recover a DC whose database is damaged, or as the first half of an authoritative restore.

1. Boot into DSRM as above and log on with the DSRM password.
2. List the available backups. If they are on a share or another volume, add -backupTarget:
   

   wbadmin get versions
   wbadmin get versions -backupTarget:\\backupsrv\dc-backups\ -machine:DC01

3. Start the system state recovery with the version identifier from the output (format MM/DD/YYYY-HH:MM):
   

   wbadmin start systemstaterecovery -version:09/28/2026-22:30
   wbadmin start systemstaterecovery -version:09/28/2026-22:30 -backupTarget:\\backupsrv\dc-backups\ -machine:DC01

4. Confirm the prompt. The recovery takes several minutes. Do not add -autoReboot if you still need to run an authoritative restore.
5. Clear the DSRM flag with bcdedit /deletevalue safeboot and restart normally.
6. After the restart, check the result with wbadmin start systemstaterecovery -showsummary, then let replication catch up (see “Verify the restore”).

The Windows Server Backup console offers the same operation through Recover » System state. Its checkbox “Perform an authoritative restore of Active Directory files” only makes SYSVOL authoritative; it does not mark any AD objects authoritative.

Authoritative restore of deleted objects

If you only run a non-authoritative restore after an accidental deletion, the deletion replicates back from the other DCs and the objects disappear again. An authoritative restore raises the version numbers on the restored objects so that they win against the tombstones and replicate out to every DC. Use this restore domain controller method only when the AD Recycle Bin is not enabled or the deleted objects have already passed the deleted-object lifetime.

1. Disconnect the DC from the network, or stop replication, if the deleted objects might otherwise be purged before you finish. On a short job this is usually not needed.
2. Boot into DSRM and run the non-authoritative restore above with a backup taken before the deletion. Do not restart.
3. Open an elevated prompt and start ntdsutil:
   

   ntdsutil
   activate instance ntds
   authoritative restore
   restore subtree "OU=Finance,DC=contoso,DC=com"
   quit
   quit

   
   For a single object, use restore object "CN=Jane Smith,OU=Finance,DC=contoso,DC=com" instead of restore subtree.
4. Confirm the dialog. ntdsutil writes two files in the current directory: ar_<date-time>_objects.txt (the list of restored objects) and, when back-links exist, ar_<date-time>_links_<domain>.ldf.
5. Clear the DSRM flag (bcdedit /deletevalue safeboot) and restart normally. The authoritative objects replicate out to the other DCs.
6. Restore group memberships: run the generated LDIF file on the same DC once replication is working:
   

   ldifde -i -k -f ar_20260929-101500_links_contoso.com.ldf

Group membership is stored on the group (the forward link member), not on the user (memberOf is a back-link). If you restore a user but not the groups, the LDIF file puts the links back. Memberships in groups in other domains need the objects.txt file processed in those domains as well. The verinc option (restore object "DN" verinc 100000) is only needed when you must override an earlier authoritative restore.

AD Recycle Bin vs authoritative restore

With the Recycle Bin enabled (forest functional level Windows Server 2008 R2 or later), deleted objects keep all attributes, including group memberships, for the deleted-object lifetime. Restoring them takes one command with no DSRM, no downtime and no LDIF files:

Get-ADObject -Filter 'isDeleted -eq $true -and Name -like "*Jane Smith*"' -IncludeDeletedObjects |
  Restore-ADObject

Enable it now if you have not: it is the single biggest improvement to your restore domain controller options. Authoritative restore remains necessary for changes that are not deletions, such as a script that overwrote attributes on thousands of objects.

Restore SYSVOL authoritatively

SYSVOL holds Group Policy templates and logon scripts. On Windows Server 2016 and later it must replicate with DFS Replication (DFSR); FRS is no longer supported. You have two options.

Option 1: restore with -authsysvol

When restoring the system state in DSRM, add -authsysvol. The restored SYSVOL becomes the authoritative copy and the other DCs replicate it:

wbadmin start systemstaterecovery -version:09/28/2026-22:30 -authsysvol

Option 2: DFSR authoritative synchronisation without a restore

If one DC still has a good SYSVOL and the others are damaged, force an authoritative sync from that DC instead. Each DC has a subscription object at CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<DC name>,OU=Domain Controllers,DC=contoso,DC=com; edit it with ADSI Edit or Active Directory Users and Computers » View » Advanced Features » Attribute Editor.

1. On every DC, set the DFS Replication service to Manual and stop it.
2. On the good (authoritative) DC’s subscription object, set msDFSR-Enabled to FALSE and msDFSR-options to 1.
3. On every other DC’s subscription object, set msDFSR-Enabled to FALSE.
4. Force AD replication (repadmin /syncall /AdeP) and confirm it succeeded on all DCs.
5. Start DFSR on the authoritative DC and wait for event 4114 in the DFS Replication log.
6. Set msDFSR-Enabled to TRUE on the authoritative DC, force AD replication, run dfsrdiag pollad and wait for event 4602.
7. Start DFSR on the other DCs (event 4114 on each), set their msDFSR-Enabled to TRUE, force replication and run dfsrdiag pollad on each. They log 4614 and then 4604 when the initial sync completes.
8. Set the DFS Replication service back to Automatic on every DC.

Only one DC may be authoritative. Every other DC must go through the non-authoritative steps, or SYSVOL conflicts follow. For a single DC with a broken SYSVOL, the non-authoritative sync alone is enough: set its msDFSR-Enabled to FALSE, replicate, dfsrdiag pollad, wait for 4114, set it back to TRUE, replicate, dfsrdiag pollad, and wait for 4614 and 4604.

Verify the restore

After any restore domain controller procedure, confirm that the DC is healthy before you call the job finished:

wbadmin start systemstaterecovery -showsummary
repadmin /replsummary
repadmin /showrepl DC01
dcdiag /s:DC01 /v
Get-SmbShare -Name SYSVOL, NETLOGON
Get-ADUser -Identity jsmith -Properties memberOf, whenChanged

• repadmin /replsummary should show no failures for the restored DC after a few replication cycles.
• The Directory Service event log should show event 1109 (the invocation ID changed after a restore) and no USN rollback errors such as 2095.
• SYSVOL and NETLOGON must be shared; dcdiag reports this in its NetLogons and SysVolCheck tests.
• For an authoritative restore, check the restored objects on a different DC to prove they replicated.

Build a test restore plan

An untested backup is a hope, not a plan. Practise the full restore domain controller sequence at least twice a year:

1. Create an isolated network (a private virtual switch with no route to production).
2. Restore a DC’s BMR backup into it, or promote nothing and restore the system state onto a freshly installed server of the same version and name.
3. Boot into DSRM with the stored DSRM password. If nobody can find it, you have found the first problem.
4. Run a non-authoritative restore, then an authoritative restore of a test OU, and time both steps.
5. Verify with dcdiag and by querying restored objects. Destroy the lab afterwards; never connect it to production.
6. Write the timings and any surprises into your runbook, including where the backups live and who holds the DSRM passwords.

Troubleshooting

Symptom	Cause	Fix
wbadmin is not recognised	Windows Server Backup feature not installed	Install-WindowsFeature Windows-Server-Backup
Cannot log on in DSRM	Wrong or unknown DSRM password	Reset it from normal mode with ntdsutil "set dsrm password", then boot into DSRM again
Restored objects disappear again after restart	Only a non-authoritative restore was performed	Repeat the restore and mark the objects with ntdsutil before restarting
Restored user has no group memberships	Back-links not restored	Import the ar_*_links_*.ldf file with ldifde -i -k -f
wbadmin get versions shows nothing	Backup stored elsewhere	Add -backupTarget: and -machine:
Event 2095 or replication stopped after reverting a VM	USN rollback on a platform without VM-GenerationID	Demote the DC (forced if needed), clean up metadata and promote a new one
SYSVOL not shared after restore	DFSR initial sync not complete	Check DFS Replication events 4614/4604; run a non-authoritative DFSR sync

Roll back or undo

A non-authoritative restore cannot be undone, but it is safe: replication brings the DC forward to the current state. An authoritative restore overwrites later changes to the marked objects everywhere in the domain, so restore the smallest subtree possible, and never mark a whole domain naming context authoritative to fix a few objects. If you marked the wrong subtree, recover the correct values from a newer backup with a second authoritative restore (using verinc if needed), or fix them manually. If the DC is stuck in DSRM, run bcdedit /deletevalue safeboot and restart.

Restore domain controller at a glance

Official documentation: wbadmin start systemstaterecovery, AD forest recovery: perform a nonauthoritative restore, Force authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL.

Related guides: Enable and use the Active Directory Recycle Bin to restore deleted objects · dcdiag repadmin Health Check: 7 Critical Tests Explained · Back up and restore GPOs with PowerShell.

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

Windows Server 2016 to 2025 domain controllers

Last full review

3 Oct 2026

Next review

1 Apr 2027

Sources

learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-start-systemstaterecovery
learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-perform-nonauthoritative-restore
learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization