
Restoring a domain controller from backup using Veeam
- Transfer
- Tutorial
We continue to publish a series of articles written by a colleague for the corporate blog and dedicated to backing up and restoring domain controllers and Active Directory itself.
A previous article in this series talked about the procedure for backing up physical and virtual domain controllers (DCs). Today we’ll talk about their recovery.
I must say right away that this post is not an Active Directory recovery guide. Its task is to talk about what you need to consider when restoring AD or a specific domain controller from a backup, and also show how you can perform these actions using Veeam solutions.

A thorough knowledge of your infrastructure is very helpful in planning your AD recovery. Here are just a few of the questions you need to know the answers to successfully recover data:
Note: Starting with Windows Server 2008, DFSR replication has become the default configuration option for SYSVOL directory replication.
When planning to restore a domain controller, you must first determine whether non-authoritative mode is sufficient or if you need to use authoritative mode .
The difference between the two modes is that in the non-authoritative recovery mode , the domain controller realizes that it has been disconnected for some time. Therefore, it allows other controllers to update its database, making it the latest changes that occurred during its absence. And during authoritative recovery, the controller believes that only it has a truly correct database, so it is he who receives the authority to update the databases of other domain controllers based on his data.
In most recovery scenarios, you will need to use non-authoritative mode , as there are several domain controllers in the environment. (In addition, authoritative recovery can lead to new problems.)
This is precisely what the Veeam Backup & Replication logic is based on: non-authoritative recovery is performed by default , since it is believed that the infrastructure is built with redundancy and includes several controllers.
In order to perform authoritative recovery using Veeam, you need to perform some additional steps, which will be described later.
UsefulAnother common option for a domain controller to fail is to distribute its roles between other controllers and clear the metadata if recovery is unlikely. In this case, you instruct other DCs to perform the functions of the failed one, and you do not need to restore it.
So, back to the backup files, the creation of which was described in the previous article. In order to restore a domain controller from a Veeam Backup & Replication backup, you need to:
The most noteworthy here is that thanks to data processing taking into account the state of applications when creating a backup, you don’t need to do anything else. Veeam recognizes the domain controller in the specified VM and carefully restores it using the following sequence of actions:
The domain controller will be aware of the recovery from the backup and take the appropriate action: the existing database will be declared invalid, and the replication partners will be able to update it, introducing the latest information.

With a high degree of probability, you do not need this recovery mode. However, let's get to know him better so that you understand why this is so.
This mode can be used, for example, when you try to restore a valid copy of a domain controller in an environment with several domain controllers, even though the entire AD structure is damaged for some reason (e.g., malware, virus, etc.). In this situation, of course, it is preferable that the damaged domain controllers receive changes from the newly restored controller.
Note: The steps taken are similar to what happens when using Veeam SureBackup to restore a domain controller in an isolated environment.
To restore a deleted object or container in modeauthoritative and force the domain controller to copy the recovered data from this DC to other controllers:
The authoritative recovery procedure for SYSVOL (when using the DFSR service) is performed as follows:

Procedure authoritative restore SYSVOL (using service FRS):
Now a little about restoring a physical machine from backup using Veeam Endpoint Backup.
You will need:
Important! Remember that in this case, the special Veeam Backup & Replication logic will not be used.
After recovery with Veeam Endpoint Backup, your domain controller boots in recovery mode. You will need to decide whether you want to change the registry keys or immediately restart the VM in normal mode. Perhaps this Veeam Knowledge Base article will be helpful.

Here you can read more about bare-metal recovery using Veeam Endpoint Backup in more detail.
So, we looked at restoring a separate domain controller. However, most often when working with AD, you need to restore an accidentally deleted object, and in this case, restoring the entire controller is not the most effective option. Therefore, in the next article I will talk about restoring individual AD directory objects using Microsoft's own tools and the Veeam Explorer utility for Active Directory.
A previous article in this series talked about the procedure for backing up physical and virtual domain controllers (DCs). Today we’ll talk about their recovery.
I must say right away that this post is not an Active Directory recovery guide. Its task is to talk about what you need to consider when restoring AD or a specific domain controller from a backup, and also show how you can perform these actions using Veeam solutions.

A thorough knowledge of your infrastructure is very helpful in planning your AD recovery. Here are just a few of the questions you need to know the answers to successfully recover data:
- How many domain controllers in your environment are one or more?
- Are these read-write domain controllers (RWDC) or read-only domain controllers (RODC)?
- Is only one controller out of order, or is the entire AD infrastructure damaged?
- If you have multiple controllers, do you use the File Replication Service (FRS) to synchronize changes between different domain controllers or switched to a distributed DFSR to synchronize changes between different domain controllers?
Note: Starting with Windows Server 2008, DFSR replication has become the default configuration option for SYSVOL directory replication.
Restoring a virtualized domain controller
When planning to restore a domain controller, you must first determine whether non-authoritative mode is sufficient or if you need to use authoritative mode .
The difference between the two modes is that in the non-authoritative recovery mode , the domain controller realizes that it has been disconnected for some time. Therefore, it allows other controllers to update its database, making it the latest changes that occurred during its absence. And during authoritative recovery, the controller believes that only it has a truly correct database, so it is he who receives the authority to update the databases of other domain controllers based on his data.
In most recovery scenarios, you will need to use non-authoritative mode , as there are several domain controllers in the environment. (In addition, authoritative recovery can lead to new problems.)
This is precisely what the Veeam Backup & Replication logic is based on: non-authoritative recovery is performed by default , since it is believed that the infrastructure is built with redundancy and includes several controllers.
In order to perform authoritative recovery using Veeam, you need to perform some additional steps, which will be described later.
UsefulAnother common option for a domain controller to fail is to distribute its roles between other controllers and clear the metadata if recovery is unlikely. In this case, you instruct other DCs to perform the functions of the failed one, and you do not need to restore it.
Non-authoritative recovery
So, back to the backup files, the creation of which was described in the previous article. In order to restore a domain controller from a Veeam Backup & Replication backup, you need to:
- Run the recovery wizard in the Veeam Backup console.
- Find the domain controller you need.
- In the recovery menu, select the option to restore the entire VM (Restore Entire VM).
- Specify a recovery point.
- Select a source or new recovery location.
- Complete the procedure.
The most noteworthy here is that thanks to data processing taking into account the state of applications when creating a backup, you don’t need to do anything else. Veeam recognizes the domain controller in the specified VM and carefully restores it using the following sequence of actions:
- Recovery of files and disks of VM.
- Boot the OS in a special mode of recovery of domain services (DSRM mode).
- Application settings.
- Restart in normal mode.
The domain controller will be aware of the recovery from the backup and take the appropriate action: the existing database will be declared invalid, and the replication partners will be able to update it, introducing the latest information.

Authoritative recovery
With a high degree of probability, you do not need this recovery mode. However, let's get to know him better so that you understand why this is so.
This mode can be used, for example, when you try to restore a valid copy of a domain controller in an environment with several domain controllers, even though the entire AD structure is damaged for some reason (e.g., malware, virus, etc.). In this situation, of course, it is preferable that the damaged domain controllers receive changes from the newly restored controller.
Note: The steps taken are similar to what happens when using Veeam SureBackup to restore a domain controller in an isolated environment.
To restore a deleted object or container in modeauthoritative and force the domain controller to copy the recovered data from this DC to other controllers:
- Select Veeam's full VM recovery operation: the program will automatically perform standard DC recovery in non-authoritative mode (see above).
- The second time you restart DC, open the boot wizard (press F8), select DSRM, and log in with the DSRM account information (the account that you specified when you assigned this computer to the domain controller).
- Open a command prompt and run the ntdsutil utility
- Use the following commands:
activate instance ntds;
- then
authoritative restore;
- then
restore object “distinguishedName”
orrestore subtree “distinguishedName”
Example:restore subtree “OU=Branch,DC=dc,DC=lab, DC=local
- Confirm authoritative recovery and restart the server after the operation is completed.
The authoritative recovery procedure for SYSVOL (when using the DFSR service) is performed as follows:
- Perform a non-authoritative restore of the domain controller (for example, restore the entire VM in Veeam Backup & Replication).
- On the second boot, go to the registry branch HKLM \ System \ CurrentControlSet \ Services \ DFSR , create the Restore key , and then create the SYSVOL line with the value authoritative .
This value will be read by the DFSR service. If not set, the default is to restore SYSVOL in non-authoritative mode . - Go to HKLM \ System \ CurrentControlSet \ Control \ BackupRestore , create a SystemStateRestore key , then create a LastRestoreId string with any GUID value, for example, 10000000-0000-0000-0000-000000000000 .
- Restart the DFSR service.

Procedure authoritative restore SYSVOL (using service FRS):
- Perform a non-authoritative restore of the domain controller (for example, restore the entire VM in Veeam Backup & Replication).
- On the second boot, go to the registry branch HKLM \ System \ CurrentControlSet \ Services \ NtFrs \ Parameters \ Backup / Restore \ Process at Startup and change the value of the Burflag key to 000000D4 (hex) or 212 (dec) .
This will force data to be copied to domain controllers using the old FRS technology in authoritative mode. Read more about restoring FRS here . - Restart the NTFRS service.
Recovering a physical domain controller with Veeam Endpoint Backup
Now a little about restoring a physical machine from backup using Veeam Endpoint Backup.
You will need:
- Pre-prepared Veeam emergency boot disk.
- Access to the backup itself (on a USB stick or network drive).
Important! Remember that in this case, the special Veeam Backup & Replication logic will not be used.
After recovery with Veeam Endpoint Backup, your domain controller boots in recovery mode. You will need to decide whether you want to change the registry keys or immediately restart the VM in normal mode. Perhaps this Veeam Knowledge Base article will be helpful.

Here you can read more about bare-metal recovery using Veeam Endpoint Backup in more detail.
So, we looked at restoring a separate domain controller. However, most often when working with AD, you need to restore an accidentally deleted object, and in this case, restoring the entire controller is not the most effective option. Therefore, in the next article I will talk about restoring individual AD directory objects using Microsoft's own tools and the Veeam Explorer utility for Active Directory.