The Sysvol and Netlogon Shares Are Missing After You Restore a Domain Controller from Backup (316790)

Important This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

SYMPTOMS

After you restore a domain controller from a backup, the Sysvol and Netlogon shares may be missing. Also, Dcdiag.exe does not pass the FsmoCheck test and generates the following error message:

Warning: DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1355

This problem generally occurs only if the domain controller that you restore is the only domain controller in the domain, or if all of the domain controllers in the domain have also been restored (for example, to duplicate a production environment in a lab).

RESOLUTION

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
You must designate one domain controller as being authoritative for the Sysvol replica set. If all of the domain controllers in the domain have been restored, select the primary domain controller emulator flexible single master operations (FSMO) role holder:

Stop the File Replication service on the domain controller.
Start Registry Editor (Regedt32.exe).
Locate and then click the BurFlags value under the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
On the Edit menu, click DWORD, click Hex, type D4, and then click OK.
Quit Registry Editor.
Move data out of the PreExisting folder.
Restart the File Replication Service.

Note This registry value marks the FRS replica as authoritative for the whole replica set. Set this value on only one replica, and only to resolve this specific issue. If you configure multiple replicas as authoritative, conflicts and collisions may occur in the replica set.

When you set the D4 registry setting on one domain controller, you must set the D2 registry setting on every other domain controller. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

315457 How to Rebuild SYSVOL and Its Content in a Domain

MORE INFORMATION

When you restore a domain controller from backup (or when you restore the System State), the FRS database is not restored because the most up-to-date state exists on a current replica instead of in the restored database. When FRS starts, it enters a "seeding" state and then tries to locate a replica with which it can synchronize. Until FRS completes replication, it cannot share Sysvol and Netlogon.

If you restore all of the domain controllers in the domain backup, all the domain controllers enter the seeding state for FRS and try to synchronize with an online replica. This replication does not occur because all of the domain controllers are in the same seeding state. Setting the primary domain controller FSMO role holder to be authoritative forces the domain controller to rebuild its database based on the current contents of the system volume. When that task is completed, the Sysvol and Netlogon shares are shared. All the other domain controllers can then start synchronizing from the online replica.