How to Restore Domain Controller From Backup?

6.4K

In this blog post, we will provide a step-by-step guide on how to restore a domain controller from backup using the Windows Server Backup feature. Whether you are an IT professional or a system administrator, this guide will equip you with the knowledge and tools needed to restore your domain controller and minimize downtime.

Supported Windows Server versions. The procedures in our guide apply to Windows Server 2025, Windows Server 2022, Windows Server 2019, and Windows Server 2016. The recovery method depends on whether you are restoring System State on the original installation, performing a full server recovery, or recovering an AD forest.

Why you may need to restore domain controller from backup?

In a Windows Server environment, domain controllers play a critical role in managing network resources and user authentication. Therefore, ensuring the availability and integrity of domain controller data is essential for maintaining network stability and security.

However, despite best efforts, domain controllers may sometimes experience hardware failures, software corruption, or malicious attacks that require you to restore domain controller from backup.

Domain Controller Recovery Considerations

Just because the title says how to restore a domain controller from backup, it doesn’t mean it is always the best path. So before going trigger-happy with DC recovery from backup, let’s talk about some considerations.

Is there one or more domain controllers still online?

If the domain controller becomes unavailable but other domain controllers remain online, consider doing a replication recovery strategy first. The high-level steps are:

1. If the failed DC had FSMO roles, transfer or seize the FSMO roles to another DC.
2. Install a new Windows Server instance, join it to the domain, and promote it to a domain controller.
3. Wait for the Active Directory replication to happen. The new DC should receive replication data from the other servers.

Note, however, that if the nearest domain controller is on another site, the replication can cause high traffic utilization in your WAN. So be mindful of the timing and workload.

Is this the only domain controller?

If the failed DC is the only one in the network, then you must do a bare-metal server recovery. We’ll cover bare-metal recovery in this tutorial.

Authoritative vs. Non-Authoritative

Another consideration is whether you will perform an authoritative or non-authoritative recovery of the domain controller. What’s the difference?

An authoritative restore will mark the restored objects as the current version. As a result, once recovered, the restored objects will replicate across all domain controllers. In short, this is called push replication.

On the other hand, a non-authoritative restore is used to restore an entire domain controller’s contents to a previous state. However, unlike an authoritative restore, the restored data is not marked as the current version. Instead, the restored data will be overwritten by more recent changes during the next replication cycle.

Restoring Virtual Domain Controllers

Keep in mind that most modern DCs run as VMs in Hyper-V, VMware, Azure, and other virtualization platforms. Before restoring a virtual DC, you need to understand how AD handles virtualization-specific recovery cases.

Why Snapshot Rollback Was Dangerous

In older versions of AD, you could face a USN rollback condition when reverting a DC to a previous VM snapshot.

AD replication relies on Update Sequence Numbers (USNs) to track changes between DCs. When a VM was reverted to an earlier snapshot, the restored DC could present outdated replication info while appearing healthy to its replication partners.

Often, such situation could result in:

• Replication failures
• Lingering objects
• Inconsistent directory data
• DC isolation

For this reason, we recommend never restoring a DC by reverting a VM snapshot.

Backup Age and Tombstone Lifetime Considerations

Before restoring a DC from backup, you need to check if the backup is not older than the AD tombstone lifetime.

The tombstone lifetime determines how long deleted AD objects are retained before permanent removal. In modern AD forests, the default tombstone lifetime is typically 180 days. However, legacy forests may use a 60-day default or a different explicitly configured value. Therefore, do not assume that the tombstone lifetime is 180 days; you should always check the actual value in the forest before performing a DC recovery.

In case you are restoring a DC from a backup that is older than the tombstone lifetime, it can introduce outdated directory information and may result in replication inconsistencies.

You can check the current tombstone lifetime with PowerShell command:

Get-ADObject `
-Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com" `
-Properties tombstoneLifetime |
Select-Object tombstoneLifetime

As a general rule, you should not restore a DC from a backup that is older than the tombstone lifetime.

In case you don’t have a recent backup and other healthy DCs exist, the safer option is to rebuild the DC and allow AD replication to restore directory data.

VM-Generation ID Protection

Starting with Windows Server 2012, AD introduced support for VM-Generation ID (VMGenID). VM-Generation ID is a special identifier provided by supported hypervisors such as:

• Hyper-V
• VMware vSphere
• Microsoft Azure

When a virtualization event occurs (for example snapshot restore, VM cloning, or certain recovery operations), the hypervisor changes the VM-Generation ID value.

AD detects this change during startup and automatically performs several safety actions:

• Discards the local RID pool
• Resets invocation IDs used for replication
• Prevents USN rollback conditions
• Initiates safe replication with partner DCs

As a result, you can safely recover modern virtualized DCs from supported virtualization operations without causing replication corruption.

Best Practices for Virtual DC Recovery

Even though VM-Generation ID significantly improves recovery safety, we still recommend you:

• Using System State/Bare Metal backups for planned recovery procedures
• Verifying AD replication health after recovery
• Avoiding unsupported hypervisor-level backup products
• Testing recovery procedures regularly

In case multiple healthy DCs are available, it is easier to rebuild the failed DC and allow AD replication to repopulate the directory than performing a full backup restoration.

In What Cases You Don’t Need Domain Controller Restore?

Before restoring a DC from backup, you need to check if the problem actually requires DC recovery.

In many cases, you can search for DC recovery procedures when the real issue is the accidental deletion of AD objects. Often it’s unnecessary to restore the entire DC because it can introduce additional complexity.

Recovering Deleted Objects with AD Recycle Bin

In case AD Recycle Bin is enabled, usually you can restore deleted objects without restoring a DC/performing an authoritative restore.

Here are the common examples:

• Deleted user accounts
• Deleted security groups
• Deleted organizational units (OUs)
• Deleted computer accounts

You can check if AD Recycle Bin is enabled using the command below:

Get-ADOptionalFeature `
'Recycle Bin Feature' |
Select-Object Name,EnabledScopes

Before restoring a deleted object, we recommend you to check that only one matching object exists. In environments where an account has been deleted and recreated multiple times, the search may return several deleted objects with the same SamAccountName. Use the command:

Get-ADObject `
-Filter 'SamAccountName -eq "jdoe"' `
-IncludeDeletedObjects |
Select-Object Name,ObjectGUID,LastKnownParent

You need to review the results and identify the correct deleted object before proceeding with the restore operation.

In order to restore a deleted user account, use the following command:

Get-ADObject `
-Identity "OBJECT-GUID" `
-IncludeDeletedObjects |
Restore-ADObject

To list recently deleted AD objects:

Get-ADObject `
-Filter 'isDeleted -eq $true' `
-IncludeDeletedObjects

When Authoritative Restore May Be Required

In case AD Recycle Bin is not enabled and deleted objects must be recovered, an authoritative restore may be necessary in such scenario.

Usually, you should use Authoritative restore when:

• A critical OU was deleted
• Multiple user accounts were removed
• Group memberships must be recovered from backup
• Recycle Bin was not enabled before the deletion occurred

In these cases, you should prefer to restore specific objects than restoring an entire DC.

Perform an Authoritative Restore with ntdsutil

In case Active Directory Recycle Bin was not enabled and you need to restore deleted AD objects from a System State backup, you should use an authoritative restore to mark the restored objects as authoritative and replicate them to other DCs.

First, you need to restore the DC System State backup in DSRM without selecting the authoritative restore option. After the System State recovery completes, keep the server in DSRM and open an elevated Command Prompt.

Start ntdsutil:

ntdsutil

Now activate the authoritative restore context:

activate instance ntds
authoritative restore

To mark a specific deleted OU and all objects below it as authoritative, use the command below:

restore subtree "OU=Sales,DC=contoso,DC=com"

Now confirm the operation when prompted, then exit ntdsutil:

quit
quit

Restart the DC normally and check if the restored OU and its objects replicate to the other DCs.

Use restore subtree only when you need to restore the entire selected OU hierarchy. Do not use an authoritative restore for a single deleted object when a more targeted recovery method is available.

Restore Domain Controller from Backup (System State)

So the domain controller goes kaput. Now you must recover it from the backup. Don’t worry; let’s walk through how it is done.

1. Install Windows Server (same version) on a new machine. Note that the replacement server should use the same Windows Server version as the original DC. Keep in mind that restoring a system state backup to a different OS version is not supported.
2. Configure the server’s network settings (IP address, DNS server, subnet, gateway, etc.) Make sure they’re the same as the failed DC.
3. Once the new server is up, do not make any changes, like changing the computer name, installing the AD Domain services role, and joining the domain.
4. Install the Windows Server Backup feature by running the below command in an elevated PowerShell session:
   

   Install-WindowsFeature -Name Windows-Server-Backup -IncludeAllSubfeature -IncludeManagementTools

   
5. Ensure that the Windows System State Backup is accessible on the server. It may be on a network share or a storage device, whether internal or external. In this example, the Windows System State Backup is in Drive E.
   

   

6. To restore from backup, we must restart the server in the Directory Services Restore Mode (DSRM). Open the System Configuration by running msconfig command. Click Boot → Safe Mode → Active Directory repair → OK.
   

   

7. On the next prompt, click Restart.
   

   

8. Once the server restarted, log in using the local Administrator account.
   

   

9. Launch the Windows Server Backup console by running wbadmin.msc.
   

   

10. Once the Windows Backup console is up, click the Recover link.
    

    

11. On the Getting Started page, select the “A backup stored on another location” option and click Next.
    

    

12. Depending on where your backup is stored, select the appropriate location option and click Next. I’ll select “Local drive” in this example.
    

    

13. Choose the backup location from the dropdown list and click Next.
    

    

14. The Recovery Wizard will scan the drive and discover the backup image. In this example, the Wizard found the backup we made of the W19DC2 Active Directory server. Select the server name and click Next.
    

    

15. If there are multiple backup instances, select the backup date and time. In this example, we only have one backup. Click Next.
    

    

16. Select “System State” as the recovery type and click Next.
    

    

17. On the Select Location for System State Recovery, choose the “Original location” option and click Next. Do not enable the “Perform an authoritative restore of Active Directory files” because we’re performing a non-authoritative recovery in this scenario.
    

    

18. You’ll see a warning that you’re restoring a backup from a different server. We know that. So click OK.
    

    

19. On the Confirmation page, enable the “Automatically reboot…” box and click Recover.
    

    

20. The Recovery Wizard reminds you that the recovery cannot be paused or canceled. When you’re sure to continue, click Yes.
    

    

21. Now wait for the recovery process to finish.
    

    

22. Once the recovery is complete, the server restarts automatically, but still in the DSRM. Log in using the DSRM admin password specified during AD DS installation.
23. You’ll see the message below saying the recovery operation was successful. Press Enter to dismiss the CMD window.
    

    

24. Now it’s time to restart the server in normal mode. Open the System Configuration utility by running the msconfig command. Click Boot, uncheck “Safe Boot”, and click OK.
    

    

25. On the confirmation prompt, click Restart.
    

    

26. Once restarted, log in using your domain account, and the domain controller has been restored from the system state backup.

Important. Before restoring a DC from backup, you need to ensure that the backup age does not exceed the AD tombstone lifetime. When restoring excessively old backups, you may face replication problems and inconsistent directory data.

Reset the krbtgt Password During Forest Recovery

In case the recovery is part of an AD forest recovery/follows a suspected domain compromise, you need to reset the krbtgt account password twice. This invalidates Kerberos keys from the previous security state and helps prevent the use of forged Kerberos tickets (such as Golden Tickets).

Do not perform the two password resets back-to-back. After the first reset, you need to allow the change to replicate to all writable DCs before performing the second reset.

Run the following command from a DC:

Set-ADAccountPassword -Identity krbtgt -Reset

After confirming that the first password change has replicated successfully, you need to reset the password again:

Set-ADAccountPassword -Identity krbtgt -Reset

Note that for a routine non-authoritative recovery of a single DC in an otherwise healthy domain, resetting krbtgt is not automatically required solely because the DC was restored from backup.

Restore Domain Controller from Backup (Bare Metal)

Doing a bare metal recovery translates to restoring the backup on a machine without an existing operating system. The supposed system drive, to begin with, is empty. This condition requires the OS installation media to access the Windows Recovery Environment (WinRE) to restore the bare-metal backup image.

1. Provision the new machine (virtual or physical).
2. Insert or attach the installation media (ISO or physical media).
3. Boot the computer into the OS installation media.
4. Once booted, click Repair your computer.
   

   

5. Click Troubleshoot.
   

   

6. Click System Image Recovery.
   

   

7. If you forgot to connect the storage containing the bare metal backup, you will get the following error message.
   

   

   So make sure to attach the storage device with the backup and click Retry.
8. Once the recovery wizard scans the device, it will detect the available backup image. In this example, I’ll choose to recover the latest backup and click Next.
   

   

9. If you wish to exclude specific drives from the recovery process, do so now. Otherwise, all disks that match the backup data will be formatted. Since I only included drive C in my previous backup, I have no other drives to exclude.
   

   

10. Finally, click Finish to start the re-imaging process.
    

    

11. As a good measure, you’ll be informed that all disks matching the backup structure will be formatted. Click Yes to confirm.
    

    

12. Wait for the restoration to finish. The duration depends on the backup size being restored.
    

    

    Once the restoration is finished, the server will restart after a 60-second countdown.
    

    

13. Once restarted, log in using your domain account, and the domain controller should be recovered.

Post-Recovery Validation

In order to verify DC health, run a full DC diagnostic:

dcdiag /v

After that, review the output for errors related to:

• DNS
• Replication
• SYSVOL
• NETLOGON
• Advertising
• FSMO roles
• Verify AD Replication

Now check the overall replication status using the following command:

repadmin /replsummary

To display detailed inbound replication info, use the command:

repadmin /showrepl

Note that all replication partners should report successful replication without failures.

Verify SYSVOL and NETLOGON Shares

You need to ensure the required DC shares are available. Run the command:

net share

Here check that the following shares exist:

• SYSVOL
• NETLOGON

Keep in mind that missing SYSVOL/NETLOGON shares may indicate DFS Replication/AD startup problems.

Note that in multi-DC environments, SYSVOL replication problems are often related to DFS Replication (DFSR). In case SYSVOL/NETLOGON shares are missing after recovery, you need to review the DFS Replication event log and check SYSVOL sync status before returning the DC to production.

Verify DNS Registration

You need to confirm that the DC has properly registered its DNS records. Use the following command:

dcdiag /test:dns

Don’t forget to also check that the server’s SRV records appear in DNS and can be resolved by clients.

Verifying DC Status

In order to list all DCs and check the restored server is visible, use the following command:

Get-ADDomainController -Filter *

Keep in mind that the restored DC should appear in the results and be reachable from other DCs.

Check Event Logs

At this step, you need to review the following Event Viewer logs for warnings and errors:

• Directory Service
• DNS Server
• DFS Replication
• System

You need to pay particular attention to replication, DNS, and SYSVOL-related events immediately after recovery.

Tip. In case the restored DC is part of a multi-DC environment, you should wait for at least one successful replication cycle and check that SYSVOL is fully synced before considering the recovery complete.

Wrapping Up

Restoring a DC from backup should generally be considered a last-resort recovery option. In environments with multiple healthy DCs, the safer approach is to rebuild the failed server and allow AD replication to restore directory data.

When a restore is required, you should always check backup age, understand the difference between authoritative and non-authoritative recovery, and validate replication, DNS, SYSVOL, and AD health after the recovery process completes.