#1 Global Leader in Data Protection & Ransomware Recovery

Restoring Domain Controller from an Application-Aware backup

KB ID: 2119
Product: Veeam Backup & Replication
Veeam Agent for Microsoft Windows
Published: 2016-04-04
Last Modified: 2022-10-10
mailbox
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.

Cheers for trusting us with the spot in your mailbox!

Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest

error icon

Oops! Something went wrong.

Please try again later.

For Veeam Backup & Replication: Application-Aware Processing must be enabled and working to ensure proper restore of a Domain Controller.

Challenge

This article documents Domain Controller restore scenarios and steps to perform proper DC recovery. Depending on the scenario, additional steps may be required to complete a DC restore.

 

Note regarding restore of DC if VM was backed up with Veeam Backup & Replication:
All scenarios below assume that if the DC was a VM and backed up using Veeam Backup & Replication, application-aware processing was enabled during backup. When application-aware processing is enabled for a DC VM, backed up by Veeam Backup & Replication, the post-restore boot procedure is modified so that the DC will restore into a non-authoritative state.

For restores of Domain Controller backed up using Veeam Agent for Microsoft Windows:
Veeam Agent for Microsoft Windows modifies the post-restore boot procedure regardless of application-aware setting. Meaning that the restore of a DC backed up using Veeam Agent for Microsoft Windows will always result in restored DC booting into a non-authoritative state.

Solution

Whenever you’re about to restore a DC, first determine whether a non-authoritative restore is sufficient or if you need to perform additional steps for an authoritative restore. The difference between the two restore types is that when performing a non-authoritative restore, the DC understands that it was out for a while and allows the other DCs in the domain to update its database with the changes that occurred while 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 data.
Non-Authorative vs Authorative DC Restore
In a multi-DC environment where only a single DC is lost, forcing a restored DC into authoritative mode in a functioning forest can be harmful as outdated information will be forcefully replicated. To prevent this, by default, Veeam performs a non-authoritative DC restore.
For an in-depth look at Domain Controller restore Best Practices, review: How to recover a Domain Controller: Best practices for AD protection

Non-Authoritative Restore (Default)

Restore a single DC to an environment where there are other functioning DCs (or when it was the only DC)

This scenario assumes:

  • The Domain Controller is being restored to an environment where other Domain Controllers are present from which the restored Domain Controller can replicate information.

    or
  • The Domain Controller being restored is the only Domain Controller that exists in the environment.

In this scenario, a simple non-authoritative restore is sufficient to recover.

Restore the Domain Controller. The steps taken by Application-Aware Processing during the backup process will cause the Domain Controller to be restored in a non-authoritative state. The restored Domain Controller will first boot into Directory Services Restore Mode (DSRM) mode, then automatically reboot into a normal state. The Domain Controller will know that it has been recovered from backup and will allow the other DC's in the environment to update it.

When restoring a Domain Controller as the single Domain Controller in an environment, the same boot cycle will occur after restore (DSRM boot, automatic-reboot, normal boot). After the automatic reboot, the restored DC will enter an operational state.

Authoritative Restores

The scenarios below require knowing whether the Domain Controllers used DFS-R or FRS to handle the SYSVOL replication.

If you are unsure which replication technology was in use, review this Microsoft article section: 
Determining Whether a Domain Controller's SYSVOL Folder is Replicated by DFSR or FRS

Generally speaking, FRS was used with Server 2003 or Server 2008 Domain Controllers.

If the domain functional level is Windows 2008 or above, you can use the following command to check if the Domain Controller is in the ‘ELIMINATED’ state which indicates DFSR is in use:

dfsrmig.exe /getglobalstate
Restore the entire AD infrastructure (AKA “all DC’s are lost”) where DFSR SYSVOL Replication was used

After restoring a Domain Controller, the automatic recovery process performs a non-authoritative restore, causing the Domain Controller to begin seeking replication partners. However, in a scenario where all Domain Controllers are lost, and there are no partners available, replication may take quite a long time to start (e.g., 15-30 minutes). To avoid wasting time attempting to contact replication partners, it is recommended to restore two domain controllers at once. Power them on and wait for their reboot. Then, force one of them to become authoritative for SYSVOL (see below) so that they can start replicating. After that, restoring additional Domain Controllers will not require post-restore steps.

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

For Domain Controllers using the DFS-R to replicate SYSVOL, you must perform an authoritative restore of the SYSVOL on the first DC restored, by setting the following registry values as shown here:

  1. After the Domain Controller reboots, navigate to HKLM\System\CurrentControlSet\Services\DFSR registry hive, create a key named Restore and within that key create REG_SZ (string) named SYSVOL and set the value to authoritative.
  2. Then, navigate to HKLM\System\CurrentControlSet\Control\BackupRestore, create a key named SystemStateRestore and within that key create a REG_SZ (string) named LastRestoreId with any GUID value. (Example: 10000000-0000-0000-0000-000000000000).
  3. Restart the DFSR service.
DFS-R Registry Settings Authoratative
Alternatively, you can use the following commands in an Administrative Command Prompt:
REG ADD "HKLM\System\CurrentControlSet\Services\DFSR\Restore" /v SYSVOL /t REG_SZ /d authoritative /f
REG ADD "HKLM\System\CurrentControlSet\Control\BackupRestore\SystemStateRestore " /v LastRestoreId /t REG_SZ /d 10000000-0000-0000-0000-000000000000 /f
NET STOP DFSR
NET START DFSR

Note: If you’re restoring a DC without FSMO roles, you may want to transfer them to it manually after the restore, using the ntdsutil seize command.

 

If the first DC that was restored is already hosting operations master roles, set the following registry value in order to bypass initial synchronization requirements and not to wait for another partner to replicate the directory partitions:

Key Location: HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Value Name: Repl Perform Initial Synchronizations
Value Type: DWORD (32-Bit) Value
Value Data: 0

After setting the value above, restart the domain controller.

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

Restore the entire AD infrastructure (AKA “all DC’s are lost”) where FRS SYSVOL Replication was used

After restoring a Domain Controller, the automatic recovery process performs a non-authoritative restore, causing the Domain Controller to begin seeking replication partners. However, in a scenario where all Domain Controllers are lost, and there are no partners available, replication may take quite a long time to start (e.g., 15-30 minutes). To avoid wasting time attempting to contact replication partners, it is recommended to restore two domain controllers at once. Power them on and wait for their reboot. Then, force one of them to become authoritative for SYSVOL (see below) so that they can start replicating. After that, restoring additional Domain Controllers will not require post-restore steps.

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

For Domain Controllers using the FRS to replicate SYSVOL, you must perform an authoritative restore of the SYSVOL on the first Domain Controller restored using burflags, as shown here:

  1. Open Registry Editor 
  2. Navigate to HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
  3. Double-click on BurFlags
  4. Assign it a value of D4 (hex) or 212 (dec) 
  5. Open the Services Panel
  6. Stop the NTFRS Service 
  7. Start the NTFRS Service 

Alternatively, you can use the following commands in an Administrative Command Prompt:

REG ADD "HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" /v BurFlags /t REG_DWORD /d 212 /f 
NET STOP NTFRS
NET START NTFRS

You can then monitor the status of the replication by searching for the Event ID 13516 in Event Viewer (eventvwr.msc)

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.
Example of Windows Event
Restoring due to Active Directory corruption

A scenario where no Domain Controllers are actually lost, but Active Directory itself is damaged somehow (e.g., corrupt objects or schema), and you need to restore from a backup created before the corruption occurred. In this case, you need to restore one of the Domain Controllers while the others still operate in a damaged state and then force them to accept replication changes from the restored Domain Controller. To do so will require an authoritative restore of the Domain Controller.


Note: It is recommended to restore the Domain Controller with the network disconnected to prevent it from accepting changes from the other Domain Controllers after the default non-authoritative restore.
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.

To perform an authoritative restore:

  1. Restore the Domain Controller and let it complete the default non-authoritative restore (i.e., wait until it boots a second time).
  2. During this second boot, press F8 to get to DSRM mode.
  3. Log in with the DSRM account and password.
  4. Open a command prompt and run ntdsutil command.
  5. Per Microsoft Documention:
    Before you can run the authoritative restore subcommand, you need to set NTDS or an AD LDS instance as the active instance for Ntdsutil. For example, if the AD LDS instance that you want to restore is named instance 1, type the following command at the ntdsutil: prompt before you run the authoritative restore subcommand, and then press ENTER:

    activate instance instance 1
  6. Then, type "authoritative restore" and press Enter.
  7. Mark objects as authoritative:
    1. To mark a single object as authoritative, type
      restore object <distinguished_name>
      where <distinguished_name> is the DN of the object.

    2. To mark a subtree of objects as authoritative, type
      restore subtree <distinguished_name>,
      where <distinguished_name> is the DN of the subtree.
      This will mark the container object and everything it contains as authoritative. 
      Note: If the DN contains one or more spaces, enclose the entire DN in quotes.

  8. At the Authoritative Restore Confirmation dialog box, click Yes.
  9. Upon restore completion, type "quit" and press Enter to exit the ntdsutil utility.
  10. Reboot server.
  11. Perform an authoritative restore of the SYSVOL; as documented in the scenarios above, the next steps will depend on the SYSVOL replication technology in use (DFS-R or FRS). After the Domain Controller is forced into an authoritative state, reconnect the network.
     

More Information

Restore of very old Domain Controller restore points can have some side effects due to Kerberos certificate updates and related trusts (check event logs of the restored server). See also: KB2226

In situations where data from very old restore points are needed, it is advisable to use Veeam Explorer for Active Directory for granular item-level AD restore methods. Check out the "compare" feature in the Active Directory Explorer.

To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Spelling error in text

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

Oops! Something went wrong.

Please try again later.

You have selected too large block!

Please try select less.

KB Feedback/Suggestion

This form is only for KB Feedback/Suggestions, if you need help with the software open a support case

By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please try again later.