You can recover a single domain controller or the complete AD domain if your Active Directory domain controller fails and you have a DC backup (made using Windows Server Backup or other backup tools). In this post, we’ll teach you how to use Windows Server Backup to accomplish a non-authoritative AD DS recovery. It’s assumed that you have a DC backup and that you’re familiar with the DSRM password (if the DSRM password is lost, you can reset it).
There are two ways to recover a domain controller:
Non-authoritative Active Directory Domain Services restore—in this mode, one of your domain controllers is presumed to be down and you don’t want to add another DC to the domain. All domain controllers recognize that your DC has been restored from the backup and deliver it all the changes that have accumulated in AD since the backup was made during non-authoritative recovery;
Authoritative restore of ADDS—performed very seldom. When the NTDS base on all DCs in a domain is deleted or corrupted, for example (or you only had one DC in the domain deployed). The AD database on the restored DC is treated as primary in this scenario, and its objects are duplicated to all other DCs. Keep in mind that erroneous authorized recovery can result in additional AD issues.
When you have many DCs in your domain, non-authoritative recovery is employed in the great majority of circumstances. You can employ non-authoritative DC recovery if you meet the following criteria:
- You want to deploy the role of the previous DC on the newly deployed server because the physical server with the ADDS role has failed.
- You need to restore a virtual DC from a snapshot, clone, or rollback. Virtualized DC guests running Windows Server 2012 and newer can use this mode. VMGID (VM-Generation ID) must be supported by the hypervisor host platform (at least Hyper-V 2012 or VMWare vSphere 5.0 Update 2).
The following procedures will be done when doing non-authoritative DC recovery:
- The OS reverts to the state it was in at the time of backup;
- The ntds.dit database receives a new DSA Invocation ID, which is a unique GUID. The domain controller notifies other DCs in the forest that it was restored from a backup by resetting this parameter.
- The current RID pool will be deleted and replaced with a new one. Security principals with the same SID will show in the forest if the RID pool is not reset and a new one is not requested. The DC with the FSMO job RID Master is asked for the RID pool.
- There will be a non-authoritative SYSVOL recovery (SYSVOL directory files are copied from other DCs).
In order to restore Active Directory, you need to boot the server into the Directory Services Restore Mode (DSRM). To do this, run the msconfig command, go to the Boot tab, select the Safe Boot > Active Directory repair option.
Or just execute the commands:
bcdedit /set safeboot dsrepair
shutdown -t 0 –rReboot the server. It should boot in DSRM mode. Run the Windows Server Backup (wbadmin) and select Recover from the action panel.
In the recovery wizard, select A backup stored on another location.
Select Local Drive as a backup location.
Choose the system state backup version, date, and time that we want to restore.
Select System State from the Select Recovery screen.
To do a non-authoritative restore, choose Original location.
Click on “Recover” button on the Confirmation step in order to start the recovery process.
Wait until the recovery of the AD domain controller is complete. The name of your new server will be changed to the previous DC’s name.
Disable Safe Boot mode via msconfig (otherwise your server will boot into DSRM mode again).
Run the Active Directory Users and Computers (ADUC) console once the server has booted up to ensure that it has successfully connected to your DC.
