Recommendations on Recovering Domain Controller

Product version: 9.3

Last modified: 20 March 2020

Question

What are the recommendations for recovering a domain controller for Active Directory with NAKIVO Backup & Replication?

Answer

Recommendations for backing up your domain controller:

  • Define the domain controllers that hold most Flexible Single Master Operations (FSMO) roles in your environment. From the command prompt, run the following command to get the list:

    netdom query fsmo

    The domain controller with the PDC role is the primary candidate for backing up.

  • You do not have to backup all your domain controllers (if you have multiple domain controllers) because one copy of the Active Directory database is enough. However, to avoid possible replication errors in the future, it's recommended that you back up all domain controllers.

There are two ways a domain controller can be recovered:

  • In a non-authoritative recovery, the domain controller is recovered first. Then the Active Directory objects are brought up to date by replicating the latest version of those objects from other domain controllers in the domain.

  • In an authoritative recovery, the data that has been recovered takes precedence over the data that exists on other domain controllers in the domain. This means that the current versions of objects in the Active Directory are overwritten by the versions of the objects that were recovered.

In most cases, recovering a domain controller in the non-authoritative mode is enough because there are usually several domain controllers. If this is your case, proceed with a domain controller full recovery. Thanks to the app-aware mode, NAKIVO Backup & Replication recognizes the domain controller role of the recovering machine.

If you need your domain controllers to accept changes from a restored domain controller, the authoritative mode can be used. Proceed as follows to restore an Active Directory object or a subtree:

  1. Perform full recovery of the domain controller.

  2. Reboot the domain controller and enter its Directory Services Restore Mode with the F8 key.

  3. Open the command prompt as administrator.

  4. Run the Ntdsutil tool.

  5. Perform the following Ntdsutil commands:

    activate instance ntds

    authoritative restore

    restore object <object_name>

    restore subtree <subtree_name>

    where <object_name>/ subtree_name> is the name of the object/subtree to be restored.

  6. Confirm your commands and restart the domain controller.

If you need to restore the SYSVOL folder – the storage of important elements of AD Group Policy objects and scripts – in the authoritative mode, proceed as follows:

  1. Determine whether SYSVOL is replicated by DFSF or FRS:

    1. Open the Registry Editor.

    2. Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState registry subkey. If this registry subkey exists and its value is set to 3 (ELIMINATED), DFSR is being used. If the subkey does not exist or if it has a different value, FRS is being used.

  2. For FRS-replicated SYSVOL folder, go to HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup registry hive and enter 000000D4 (hex) or 212 (dec) to the value of the Burflag key. For more details, refer to the Microsoft Knowledge Base topic.

  3. For DFSR-replicated SYSVOL folder, proceed as follows:

    1. Open the ADSIEdit console (adsiedit.msc), expand the default naming context and locate the SYSVOL subscription object for the DC in question:
      CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<DC_name>,OU=Domain Controllers,DC=<domain>

    2. Right-click the CN=SYSVOL Subscription object and select Properties.

    3. In the Attribute Editor tab of the properties window, set the msDFSR-Enabled attribute to FALSE and set the msDFSR-Options attribute to 1. Click OK to close the properties window.

    4. Locate the SYSVOL subscription objects for the other DCs in the domain. Refer to the DN in step 1 but substitute the names of the other DCs in the CN=<DC_name> portion.

    5. Modify the properties of each SYSVOL subscription object in step 4 and set the msDFSR-Enabled attribute to FALSE.

    6. Force AD replication throughout the domain and verify that the replication has been performed successfully.

    7. Type dfsrdiag pollad at an elevated command prompt on all DCs. Their DFS Replication event logs should contain event 4114, indicating that SYSVOL is no longer being replicated. Other informational events may also appear, but this step should not result in any warnings or errors appearing in the log.

    8. On the DC designated as authoritative, use ADSIEdit to set the msDFSR-Enabled attribute to TRUE at the location in steps 1 and 2. Click OK to close the properties window.

    9. Force AD replication throughout the domain and verify that the replication has been performed successfully.

    10. On the DC designated as authoritative, run dfsrdiag pollad from an elevated command prompt. Its DFS-R event log should now contain event ID 4602, indicating that SYSVOL has been initialized.

    11. On the SYSVOL subscription objects of the other DCs (see steps 4 and 5), set the msDFSR-Enabled attribute to TRUE.

    12. Force AD replication throughout the domain and verify that the replication has been performed successfully.

    13. On all DCs besides the authoritative one, type dfsrdiag pollad at an elevated command prompt. Their DFS-R event logs should contain event IDs 4614 and 4604, indicating that SYSVOL has been initialized and replicated from the authoritative DC. For more details on performing authoritative (non-authoritative) recovery of DFSR-replicated SYSVOl, refer to the Microsoft Knowledge Base topic.

  4. Restart FRS/DFSR service.