The Sysvol and Netlogon Shares Are Missing After You Restore a Domain Controller from Backup - DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1355

en definitiva si restauran un dc y el SYSVOL y NETLOGON desaparecieron, cambien el burflag a D4 y reinicien el NTFRS yo no tuve que borrar nada de archivos como dice ahí

Use Symantec system recovery 2011 en un Windows 2003 Virtual para hacerlo físico en un HP Proliant

Después de esto todos los errores de Global Catalog que tenía desaparecieron



http://support.microsoft.com/kb/316790/en-us
Article ID: 316790 - Last Review: October 31, 2006 - Revision: 3.6
The Sysvol and Netlogon Shares Are Missing After You Restore a Domain Controller from Backup

View products that this article applies to.

System Tip
This article applies to a different version of Windows than the one you are using. Content in this article may not be relevant to you. Visit the Windows 7 Solution Center
This article was previously published under Q316790
Notice

This article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center is a starting point for planning your migration strategy from Windows 2000. For more information see the Microsoft Support Lifecycle Policy.
Expand all | Collapse all
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).
Back to the top
CAUSE
This behavior occurs because the File Replication service (FRS) cannot locate a valid replication partner to synchronize the Sysvol replica set.
Back to the top
RESOLUTION
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows

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
Back to the top
STATUS
This behavior is by design.
Back to the top
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.
Back to the top