How to Restore a Domain Controller from a Backup (Part 2)

Read the full series:

This is the second article from my series on Active Directory (AD) protection with Veeam. In the previous post, I reviewed physical and virtual Domain Controller (DC) backup procedures. Today, I will discuss recovery procedures.

Knowing your infrastructure 100% is a great help for AD recovery planning. Do you have a single-DC or a multi-DC environment? Read/Write Domain Controller (RWDC) or a Read-Only Domain Controller (RODC)? Have you lost just one DC or has an entire AD infrastructure been damaged or corrupted? If you have multiple DCs, do you still use File Replication Service (FRS) or have you migrated to a Distributed File System Replication (DFSR) service for syncing changes between the multiple DCs? Those are a few questions you should be able to answers if you want performing a successful recovery.

Performing a restore of a Domain Controller in non-authoritative mode

Whenever you’re about to restore a DC, first determine whether a non-authoritative restore is enough, or if should you go further and perform an authoritative restore. The difference between those two restore types is that within a non-authoritative restore, the DC understands that it was out for a while, so it lets other in site DCs update its own database with the latest changes that occurred when it was down. With an authoritative restore, the DC claims itself as the only one with correct information and a valid database, and it authoritatively updates other DCs with its own data.

In most scenarios, a non-authoritative restore is what you need because it’s usually a multi-DC environment. In addition, restoring a DC in authoritative mode can be harmful and cause further damage. Due to this, the logic of Veeam Backup & Replication was developed accordingly, and by default, it performs automated, non-authoritative DC restore, assuming that it was not the only DC in place. For an authoritative restore with Veeam, see below for some additional steps, which are required.

Let’s go back to the backup files I created when I wrote the previous article. Restoring a DC from Veeam Backup & Replication backup is quite easy. You simply:

• Select a Restore wizard in GUI
• Find a desired DC
• Choose the Restore Entire VM option from the recovery menu
• Then, select the recovery point
• Choose if the restore should happen to the original location or a new one
• Complete the procedure

The cool thing here is that, due to the application-aware image processing we used within a VM backup, you don’t have to do anything else at the moment. Veeam recognizes the DC role of this VM and gently restores it using special logic:

• Recover VM files and hard disks
• Boot it into a Directory Services Restore Mode (DSRM) mode
• Apply the settings
• Reboot it into a normal mode

The DC will be aware of the restored from the backup state and start acting accordingly, invalidating the existing database and allowing replication partners to update it with the most recent information.

Here you can read about Bare-metal restore of a backup using Veeam Endpoint Backup. You will need a Veeam recovery media prepared beforehand and the access to the backup file itself (USB disk or a network share). Keep in mind that the special logic of Veeam Backup & Replication will not be applied here. After a restore with Veeam Endpoint Backup, your DC will boot into a recovery mode and you will need to decide whether you’d like to reconfigure registry keys or reboot into a normal mode right away. This KB article will be helpful here.

Performing a restore of a Domain Controller in an authoritative mode

As a reminder, you most likely you don’t need this type of restore. But let’s dig inside anyway so you understand the reasoning. This operation might be done when you’re trying to restore a valid copy of DC in a multi-DC environment, while the entire AD is corrupted at some point (ex. ransomware, virus, etc.). You would, therefore, want to force DCs to accept changes from a restored DC.

To restore a specific deleted object or a subtree (ex. Organization Unit) in authoritative mode and force this DC to replicate it to other DCs:

1. Select full VM recovery with Veeam and let the program performing a standard, non-authoritative DC restore automatically (described above).
2. When the DC reboots the second time, open the booting wizard (press F8), select Directory Services Restore Mode (DSRM) mode and then sign in to a system using DSRM credentials (the credientials you provided when you promoted this computer to a DC).
3. Open a command line and run ntdsutil
4. Use the following commands: activate instance ntds; then authoritative restore; then restore object “distinguishedName” or restore subtree “distinguishedName”
   Example: restore subtree “OU=Branch,DC=dc,DC=lab, DC=local.
5. Confirm the authoritative restore and reboot server upon completion.

The procedure of authoritative SYSVOL restore (DFSR service used) goes this way:

1. Non-authoritative restore of a DC (Example: entire VM restore in Veeam Backup & Replication).
2. When booted the second time, navigate to HKLM\System\CurrentControlSet\Services\DFSR registry hive, create a key Restore and create SYSVOL string with the value authoritative.
   This value is read by the DFSR service. If this value is not set, the SYSVOL restore is performed non-authoritatively by default.
3. Navigate to HKLM\System\CurrentControlSet\Control\BackupRestore, create a key SystemStateRestore and create a LastRestoreId string with any GUID value. (Example: 10000000-0000-0000-0000-000000000000).
4. Restart DFSR service.

Procedure of authoritative SYSVOL restore (old FRS service used):

1. Non-authoritative restore of a DC (Example: entire VM restore in Veeam Backup & Replication).
2. When booted the second time, navigate to HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup registry hive and change the value of the key Burflag to 000000D4 (hex) or 212 (dec).
   This effectively forces the Domain Controllers still using the old FRS technology to start the replication in an authoritative mode. More details about FRS recovery.
3. Restart the NTFRS service.

While I able to go through a specific DC recovery in this article, the most frequent use cases with AD require you to recover the accidently deleted AD object, this wouldn’t be the best way to restore the whole DC for this purpose.

Helpful resources:

• Protecting the Active Directory Domain Services — Best practices for AD administration
• Read-Only Domain Controller (RODC) — Best practices for AD administration
• Recovering the Active Directory Domain Services – Best practices for AD administration
• Veeam Community Forums: Backing up Domain Controller in another AD domain issue
• Best practices for authoritative restore (TechNet)
• Recovering your Active Directory forest
• Registry keys and values for backup and restore