When executing GPUPDATE from a workstation, you receive the following error:
The processing of Group Policy failed. Windows attempted to read the file <domain\policies\GUID\gpt.inf> from a domain controller and was not successful.
In addition, you may find that the file replication event logs display the following error:
Event ID 13568: The file replication service has detected that the replica set is in jrnl_wrap_error
If your SYSVOL folder is not replicating properly, you may experience inconsistencies when applying group policies to network clients. Printers, mapped drives and other object policies are either not being applied correctly or they are taking a long of time to apply; sometimes days or weeks. If this sounds familiar, one or more of your domain controllers may have a problem replicating SYSVOL folders.
Look in the SYSVOL folders by browsing \\SERVERNAME\sysvol\ on your primary domain controller. Double click on the domain name and create a text file named replication.txt inside that folder. Now browse each domain controller’s SYSVOL folder and look for the file. The file should have copied over to all your DC’s. If a DC is missing the file, it may have replication issues. This behavior is indicative of a replication issue but to be certain, it’s necessary to check the file replication logs on all replicating servers.
Open server manager and look in event viewer > application and service logs > file replication service. Look at the file replication events of all your domain controllers for replication errors.
To check for journal wrap, look for the following error in the file replication event log: Event ID 13568
The file replication service has detected that the replica set is in jrnl_wrap_error
This indicates that the service is in a journal wrap state. Once you identify the DC that is in journal wrap condition, we must re-initializing SYSVOL replication. Before we start, we need to determine whether replication is being done by FRS (also known as NTFRS) or DFS-R.
Determining Whether DFS-R or NTFRS is Being Used to Replicate SYSVOL on Your Server
If your server is running domain functionality 2008 or higher, then DFS-R is used to replicate SYSVOL. If you are running 2000 or 2003 domain functionality, then FRS is used to replicate SYSVOL.
Another way to determine whether DFSR or FRS is being used on a domain controller that is running Windows Server 2008 is to check the value of the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState registry sub key. If this registry sub key exists and its value is set to 3 (ELIMINATED), DFSR is being used. If the sub key does not exist, or if it has a different value, FRS is being used.
Before fixing the replication problem by re-initializing SYSVOL replication, it’s important to find the root cause that broke it in the first place. Otherwise, file replication may continue to stop working once again. Here are some common causes that can lead to replication problems:
- Check that the FRS or DFSR service is running on all your domain controllers without stopping.
- Check that all servers can ping each other using both their host name as well as their FQDN
- Check that RPC service is running and there are no firewalls blocking port connectivity between replicating members (ports 135, 445)
- Check if VPN links are down, very slow or highly intermittent. Check for Kerberos errors over slow VPN links.
- Check if server has unexpected shutdown problems, disk consistency problems, disk write cache problems, disk media errors or memory/ECC errors.
- Make sure that DC’s do not lose connection with each other for long periods of time.
To re-initialize a SYSVOL folder on a server that is running FRS, see Microsoft KB290762.
To re-initialize SYSVOL folder on a server running DFS-R, see Microsoft KB2218556