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

Andrew Zhelezko

Read the full series:

Ch.1 — Backing up Domain Controller
Ch.2 — How to recover a Domain Controller
Ch.3 — Reanimating Active Directory tombstone objects
Ch.4 — Leveraging Active Directory Recycle Bin

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.

Disclaimer:
This post is not intended to be a comprehensive AD Domain Services recovery guide. Instead, it will give you important information to consideration when recovering AD or a particular DC, as well as explain how Veeam can accomplish this process. If you’re interested in granular recovery of a deleted AD object, navigate to the next article.

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.

NOTE:
FRS is a service for distributing shared files and Group Policy Objects (GPO) in Windows Server 2000 and Windows Server 2003. It was replaced by the DFSR in later Windows Server OS (operating system) versions. Since Windows Server 2008, DFSR has been a default option for SYSVOL replication. If the first domain controller of the domain was promoted to Windows Server 2008 functional level or higher, then you’re using DFSR. Refer to this article to determine whether FRS or DFSR is used in your domain. Here are the benefits of using DFSR over FRS.

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.

NOTE:
Another important practice is to leave a failed DC out of scope and seize its roles, as well as perform metadata cleanup if it is not likely to be coming back. This way, you allow other DC(s) to take over and you don’t need to fix a broken DC.

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:

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:

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.

Figure 1. Veeam Backup & Replication: Entire VM recovery

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.

Figure 2. Veeam Endpoint Backup: bare-metal recovery

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.

NOTE:
Follow procedures that are similar to what Veeam SureBackup job performs when restoring a DC in an isolated environment.

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.
Figure 3. Authoritative SYSVOL restore (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:

Exit mobile version