Recommendations on Recovering Domain Controller

Product version: 11.1 and later

Last modified: 16 July 2026

Question

What are the recommendations for recovering a domain controller for Active Directory with NAKIVO Backup & Replication?

Answer

Backing Up Domain Controllers

Recommendations for backing up your domain controller:

  • Define the domain controllers that hold most Flexible Single Master Operations (FSMO) roles in your environment. From the command prompt, run the following command to get the list:

    netdom query fsmo

    The domain controller with the PDC role is the primary candidate for backing up.

  • You do not have to back up all your domain controllers (if you have multiple domain controllers) because one copy of the Active Directory database is enough. However, to avoid possible replication errors in the future, it is recommended that you back up all domain controllers.

  • Enable app-aware mode for backup jobs that contain domain controllers. With app-aware mode enabled, NAKIVO Backup & Replication recognizes the domain controller role of the machine and uses Microsoft VSS to create transactionally consistent backups of the Active Directory database.

How NAKIVO Backup & Replication Recovers a Domain Controller

When you recover a domain controller with Full VM Recovery, NAKIVO Backup & Replication creates a new virtual machine and restores the domain controller data to it. The recovered domain controller boots normally.

Note

NAKIVO Backup & Replication does not modify the boot configuration of the recovered machine. The product does not boot the domain controller into Directory Services Restore Mode (DSRM) and does not perform any Active Directory-specific actions at recovery time. The DSRM steps described below are manual steps that are only required for an authoritative restore.

Because Full VM Recovery creates a new virtual machine, the recovered virtual machine receives a new VM Generation ID. NAKIVO Backup & Replication does not preserve or transfer the VM Generation ID of the source machine and relies on the native VM Generation ID mechanism of the hypervisor. On Nutanix AHV, this behavior requires an AOS/AHV version that exposes the changed VM Generation ID to the Windows guest (AOS 7.3/AHV 10.3 or later).

Recovery Methods

There are two ways a domain controller can be recovered:

  • In a non-authoritative recovery, the domain controller is recovered first. Then the Active Directory objects are brought up to date by replicating the latest version of those objects from other domain controllers in the domain.

  • In an authoritative recovery, the data that has been recovered takes precedence over the data that exists on other domain controllers in the domain. This means that the current versions of objects in the Active Directory are overwritten by the versions of the objects that were recovered.

Non-Authoritative Recovery

In most cases, recovering a domain controller in the non-authoritative mode is enough because there are usually several domain controllers. If this is your case, proceed with a domain controller full recovery.

When the guest operating system detects a new VM Generation ID at the first boot after recovery, Active Directory Domain Services automatically applies its virtualization safeguards: the domain controller resets its InvocationID, discards its RID pool, and performs a non-authoritative resynchronization of the Active Directory database and the SYSVOL folder from the surviving domain controllers. This prevents USN rollback. No manual steps are required, provided that at least one other domain controller in the domain is online.

Authoritative Restore of Active Directory Objects

If you need your domain controllers to accept changes from a restored domain controller, the authoritative mode can be used. Proceed as follows to restore an Active Directory object or a subtree:

  1. Perform full recovery of the domain controller.

  2. Reboot the domain controller and enter its Directory Services Restore Mode with the F8 key.

  3. Open the command prompt as administrator.

  4. Run the Ntdsutil tool.

  5. Perform the following Ntdsutil commands:

    activate instance ntds

    authoritative restore

    restore object <object_name>

    restore subtree <subtree_name>

    where <object_name>/<subtree_name> is the name of the object/subtree to be restored.

  6. Confirm your commands and restart the domain controller.

Authoritative Restore of SYSVOL

Note

For a non-authoritative recovery, no manual SYSVOL actions are required: the DFS Replication database is reset automatically and SYSVOL is replicated inbound from the surviving domain controllers. The steps below are only required for an authoritative restore of SYSVOL.

If you need to restore the SYSVOL folder – the storage of important elements of AD Group Policy objects and scripts – in the authoritative mode, proceed as follows:

  1. Determine whether SYSVOL is replicated by DFSR or FRS:

    1. Open the Registry Editor.

    2. Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState registry subkey. If this registry subkey exists and its value is set to 3 (ELIMINATED), DFSR is being used. If the subkey does not exist or if it has a different value, FRS is being used.

  2. For FRS-replicated SYSVOL folder, go to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup registry subkey and enter 000000D4 (hex) or 212 (dec) to the value of the BurFlags key. For more details, refer to the Microsoft Knowledge Base topic.

  3. For DFSR-replicated SYSVOL folder, proceed as follows:

    1. Open the ADSIEdit console (adsiedit.msc), expand the default naming context and locate the SYSVOL subscription object for the DC in question:
      CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<DC_name>,OU=Domain Controllers,DC=<domain>

    2. Right-click the CN=SYSVOL Subscription object and select Properties.

    3. In the Attribute Editor tab of the properties window, set the msDFSR-Enabled attribute to FALSE and set the msDFSR-Options attribute to 1. Click OK to close the properties window.

    4. Locate the SYSVOL subscription objects for the other DCs in the domain. Refer to the DN in step 1 but substitute the names of the other DCs in the CN=<DC_name> portion.

    5. Modify the properties of each SYSVOL subscription object in step 4 and set the msDFSR-Enabled attribute to FALSE.

    6. Force AD replication throughout the domain and verify that the replication has been performed successfully.

    7. Type dfsrdiag pollad at an elevated command prompt on all DCs. Their DFS Replication event logs should contain event 4114, indicating that SYSVOL is no longer being replicated. Other informational events may also appear, but this step should not result in any warnings or errors appearing in the log.

    8. On the DC designated as authoritative, use ADSIEdit to set the msDFSR-Enabled attribute to TRUE at the location in steps 1 and 2. Click OK to close the properties window.

    9. Force AD replication throughout the domain and verify that the replication has been performed successfully.

    10. On the DC designated as authoritative, run dfsrdiag pollad from an elevated command prompt. Its DFS-R event log should now contain event ID 4602, indicating that SYSVOL has been initialized.

    11. On the SYSVOL subscription objects of the other DCs (see steps 4 and 5), set the msDFSR-Enabled attribute to TRUE.

    12. Force AD replication throughout the domain and verify that the replication has been performed successfully.

    13. On all DCs besides the authoritative one, type dfsrdiag pollad at an elevated command prompt. Their DFS-R event logs should contain event IDs 4614 and 4604, indicating that SYSVOL has been initialized and replicated from the authoritative DC. For more details on performing authoritative (non-authoritative) recovery of DFSR-replicated SYSVOL, refer to the Microsoft Knowledge Base topic.

  4. Restart FRS/DFSR service.