# Restore Domain Controller Backups: System State and DSRM Steps Source: https://srvscripts.com/guides/backup-restore-domain-controller/ Updated: 2026-10-03 Publisher: srvScripts (https://srvscripts.com/) 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. **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:`. Restart normally for a non-authoritative restore, or run `ntdsutil` “authoritative restore” before restarting if you need deleted objects back. In short: Install the Windows Server Backup feature and run wbadmin start systemstatebackup -backupTarget:E: -quiet on at least one domain controller per domain, every day. ## 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. - Boot into DSRM as above and log on with the DSRM password. - List the available backups. If they are on a share or another volume, add `-backupTarget`: ``` wbadmin get versionswbadmin get versions -backupTarget:\\backupsrv\dc-backups\ -machine:DC01 ``` - 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:30wbadmin start systemstaterecovery -version:09/28/2026-22:30 -backupTarget:\\backupsrv\dc-backups\ -machine:DC01 ``` - Confirm the prompt. The recovery takes several minutes. Do not add `-autoReboot` if you still need to run an authoritative restore. - Clear the DSRM flag with `bcdedit /deletevalue safeboot` and restart normally. - 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. - 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. - Boot into DSRM and run the non-authoritative restore above with a backup taken before the deletion. Do not restart. - Open an elevated prompt and start `ntdsutil`: ``` ntdsutilactivate instance ntdsauthoritative restorerestore subtree "OU=Finance,DC=contoso,DC=com"quitquit ``` For a single object, use `restore object "CN=Jane Smith,OU=Finance,DC=contoso,DC=com"` instead of `restore subtree`. - Confirm the dialog. `ntdsutil` writes two files in the current directory: `ar__objects.txt` (the list of restored objects) and, when back-links exist, `ar__links_.ldf`. - Clear the DSRM flag (`bcdedit /deletevalue safeboot`) and restart normally. The authoritative objects replicate out to the other DCs. - 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=,OU=Domain Controllers,DC=contoso,DC=com`; edit it with ADSI Edit or **Active Directory Users and Computers » View » Advanced Features » Attribute Editor**. - On every DC, set the **DFS Replication** service to Manual and stop it. - On the good (authoritative) DC’s subscription object, set `msDFSR-Enabled` to `FALSE` and `msDFSR-options` to `1`. - On every other DC’s subscription object, set `msDFSR-Enabled` to `FALSE`. - Force AD replication (`repadmin /syncall /AdeP`) and confirm it succeeded on all DCs. - Start DFSR on the authoritative DC and wait for event **4114** in the DFS Replication log. - Set `msDFSR-Enabled` to `TRUE` on the authoritative DC, force AD replication, run `dfsrdiag pollad` and wait for event **4602**. - 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. - 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: - Create an isolated network (a private virtual switch with no route to production). - 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. - Boot into DSRM with the stored DSRM password. If nobody can find it, you have found the first problem. - Run a non-authoritative restore, then an authoritative restore of a test OU, and time both steps. - Verify with `dcdiag` and by querying restored objects. Destroy the lab afterwards; never connect it to production. - 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](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-start-systemstaterecovery), [AD forest recovery: perform a nonauthoritative restore](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-perform-nonauthoritative-restore), [Force authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization). **Related guides:** [Enable and use the Active Directory Recycle Bin to restore deleted objects](/guides/enable-active-directory-recycle-bin/) · [dcdiag repadmin Health Check: 7 Critical Tests Explained](/guides/dcdiag-repadmin-dc-health-check/) · [Back up and restore GPOs with PowerShell](/guides/backup-restore-gpo-powershell/). ## Frequently asked questions ### How often should I back up a domain controller? Back up the system state of at least two domain controllers per domain every day. Keep several versions, store them off the DC, and never use a backup older than the forest’s tombstone lifetime. ### What is the difference between non-authoritative and authoritative restore? A non-authoritative restore returns the DC to the backup state and then accepts all newer changes through replication. An authoritative restore marks chosen objects with higher version numbers so the restored copies replicate out and override the deletion on every other DC. ### Do I still need authoritative restore if the AD Recycle Bin is enabled? Usually not for deletions: Restore-ADObject brings deleted objects back with their attributes and memberships within the deleted-object lifetime. Authoritative restore is still useful when objects were modified rather than deleted, or when the lifetime has passed. ### Can I use a VM snapshot to restore a domain controller? Microsoft does not recommend snapshots as a replacement for backups. VM-GenerationID protects against USN rollback on supported hypervisors, but you should still back up DCs with Windows Server Backup or another VSS-based product. ### What does -authsysvol do? It makes the restored SYSVOL folder authoritative during a wbadmin system state recovery, so the other domain controllers replicate the restored Group Policy files and scripts from this DC.