Application Aware Image Processing is required to be enabled and working as per Microsoft in order to functionally restore from a DC.

Since Active Directory implements multi-master replication, where multiple domain controllers sync changes with each other, one of the key challenges is the DC recovery process. This article outlines different DC restore scenarios and goes into some specifics of when and why this or that type of restore is required as well as gives instructions on the manual steps to perform proper DC recovery from backup created with Veeam B&R.

Before going into details, it is worth stressing that by default Veeam B&R performs automated non-authoritative restore of domain controller and in most cases when you need to recover failed DC, authoritative restore is not required.

The following situations are possible:

  • Restoring single lost DC in a multi-DC environment
  • Restoring entire AD infrastructure (AKA “all DC’s are lost”)
  • Restoring from Active Directory corruption
Depending on the scenario, different steps (or no steps at all) are required to perform DC restore. All of the scenarios assume application-aware image processing was enabled in the backup job that backed up the DC being restored.


Restoring single lost DC in a multi-DC environment or in environment with only a single DC

This scenario, actually the most common one, incurs restoring just one of the multiple DC’s when there are still other functional DC’s in the environment that the restored DC can replicate changes from.
DC recovery with Veeam B&R in this case is fully automated and does not require any user interaction. If your backup was done with application-aware image processing enabled in the backup job settings, Veeam B&R performs a non-authoritative restore of the DC, where the restored VM should first boot in Directory Services Restore Mode (DSRM) mode and then reboot automatically immediately to boot up next time normally.
The domain controller itself will understand that it has been recovered from backup and will allow normal replication to update everything that has been changed since the backup took place.
The automatic recovery should also work for environments with only a single DC.

Restoring entire AD infrastructure (AKA “all DC’s are lost”)

As mentioned above, the automatic recovery process performs a non-authoritative restore, where the DC reboots and starts looking for other DC’s to sync up. However, in a scenario where all DC’s are gone, there are no other partners available and replication may take quite long (15-30 minutes) to start. To avoid wasting the time attempting to contact replication partners, it is recommended to restore two of the domain controllers at once, power them on, wait for their reboot and force one of them to become authoritative for SYSVOL, so that they can start replicating. Then restoring other DC’s will be similar to the first scenario, i.e. will be 100% automatic.

Note: During the restore procedure, make sure the restored DC’s DNS records point to available DNS servers (e.g. to itself).

The procedure for designating DC as authoritative for SYSVOL varies based on whether FRS or DFS-R is used for SYSVOL replication. To determine if you are using FRS or DFSR for SYSVOL in the production environment check the value of the 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), DFS-R is being used. If the subkey does not exist, or if it has a different value, FRS is being used. 

If domain level is Windows 2008 or above you could also use the command dfsrmig.exe /getglobalstate to monitor if we are in the ‘ELIMINATED’ state and we are using DFSR.
If you are still using the FRS to replicate SYSVOL you need to perform an authoritative restore of the SYSVOL on first DC restored using burflags
To perform an authoritative restore of the SYSVOL when using FRS, use the following steps:

  • Start the Registry Editor 
  • Navigate to "HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" 
  • Double-click on "BurFlags" 
  • Assign it a value of D4 (hex) or 212 (dec) 
  • Stop the NTFRS Service 
  • Start the NTFRS Service 
Or you can use the following commands
  • REG ADD "HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" /v BurFlags /t REG_DWORD /d 212 /f 
You could monitor the status of the replication by searching for the Event ID 13516
“The File Replication Service is no longer preventing the computer <Computer_name> from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL.”

If you are using DFS-R as the more widely used these days the steps to implement basically consist of setting the following registry values:

Key: HKLM\System\CurrentControlSet\Services\DFSR\Restore
Value: SYSVOL (REG_SZ) = “authoritative”

Key: HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\SystemStateRestore
Value: LastRestoreId (REG_SZ) = any GUID value (e.g. 10000000-0000-0000-0000-000000000000)

If the first restored DC already hosts operations master roles, set the following registry value in order to bypass initial synchronization requirements and not to wait for another partners to replicate the directory partitions:
Key: HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Value: Repl Perform Initial Synchronizations (REG_DWORD) = 0

Note: Don’t forget to reset this value back to 1 after domain recovery is completed, so that domain controller has successful replication with its partners before starting to service client requests.

After setting the values above, restart the domain controller.

• If you’re restoring DC without FSMO roles, you might want to transfer them to it manually after the restore, using the ntdsutil seize command.
• This type of restore is similar to what Veeam B&R performs automatically when restoring DC within SureBackup isolated virtual lab.


Restoring from Active Directory corruption

Scenario where no DC’s are actually lost, however, AD itself is damaged in some way (corrupt objects or schema) and you need to restore from the backup created before corruption occurred. In this case you need to restore one of the multiple DC’s when other DC’s are still operating a damaged copy of AD and force all of them to accept replication changes from the restored DC. This is where authoritative restore of the DC is required.

Note: It is recommended to perform restore with network disabled to prevent DC from accepting changes from other controllers after the default non-authoritative restore.

To perform an authoritative restore:
1. Restore the DC and let it complete the default non-authoritative restore (wait until it reboots second time).
2. During this second boot, press F8 to get to DSRM mode.
3. Log in with DSRM account and password.
4. Open a command prompt and run ntdsutil command.
5. At the "ntdsutil:" prompt, type "authoritative restore" and press Enter.
6. At the "ntdsutil authoritative restore:" prompt, type "restore database" and press Enter.
7. At the Authoritative Restore Confirmation dialog box, click Yes.
8. Upon restore completion, type "quit" and press Enter to exit the ntdsutil utility.
9. Reboot server.
10. Perform an authoritative restore of the SYSVOL, as was already discussed above.

Note: For an easier item-level recovery of Active Directory objects (without the need to restore the domain controller itself), consider using Veeam Explorer for Active Directory.