If GPOs are not syncing or replicating between domain controllers, it could be due to the following reasons:
Active Directory issues.Issues with one or more of the Domain Controllers depending on setup.Latency or slow File Replication Service issues.The Distributed File System (DFS) client is disabled.Network Connectivity to the Domain Controller.
Some client machines will use a DC based on site membership in the scenario where you have more than one domain controller in a domain. Typically, if each site has multiple DCs, clients can choose a DC based on “weight,” whereas usually all DCs are “weighted equally.” It’s also possible that the client machines will use a DC at another location. So, if your DCs aren’t replicating correctly, the SYSVOL directories hosted on these servers may not have precisely mirrored data, in which case your workstations will get different results depending on which DC the client machines point to.
Group Policy not replicating between Domain Controllers
In a typical case scenario, there are three DCs and one of them which is an old DC 2012 will be subject to decommissioning. The other two are DC 2016 which is the new one and is currently the FSMO holder. Now, there’s the issue with SYSVOL replication where any changes created on the DC 2016 are not replicating on the SYSVOL policies of the DC 2012. So, if Group Policies are not applying and replication isn’t working between domain controllers on Windows Server setup in an Enterprise environment, if you’re an IT admin, then the solutions provided below in no particular order should help you resolve the issue. Let’s look at the description of the process as it relates to each of the listed solutions.
1] Appy Microsoft Hotfix
If you’re experiencing this issue on DCs running Windows server 2008 R2 or 2012, before going into any troubleshooting, you first need to apply the Microsoft Hotfix to all DCs (not required for 2012 R2). There is a known problem on DCs where the servers hold files open after you edit, which appears that the edits are working, until you close and reopen the GPO and find out that they aren’t applying at all. Similarly, replication appears to work, but some machines pick up the settings while others do not because the same data is not properly replicated to all DCs. Read: How to repair a corrupt Group Policy in Windows
2] General troubleshooting for DC replications issues
Before you proceed, you can carry out the following preliminary tasks on general troubleshooting for DC replications issues. On completion of each task, check to see if the issue is resolved.
Force gpupdate. You can begin by running gpupdate from the workstation that is experiencing inconsistent results. If you get an output stating Computer policy could not be updated successfully, then there is a GPO delivery problem at large.Check the DCs for the NETLOGON and SYSVOL folders. At the most basic level, a DC should have two shared folders by default, the NETLOGON, and the SYSVOL folder. If these two folders are not present on a DC, you will have an AD problem and GPOs will not be delivered properly.Force replication using a script. You can force replication with the script from GitHub.com. Knowing that group policies consist of two parts files located in the SYSVOL and a version attribute in AD, running the script is a quick way of replicating your changes to all DCs within your domain.Use troubleshooting tools. Using troubleshooting tools like DCDIAG.exe, GPOTOOL.exe, or DFSDIAG.exe, if there is a replication problem, you should be able to determine which DC or DCs are the problems. Once this is determined you will have to rebuild the system volume (SYSVOL) on these designated servers. If you have more than one DC at a site, an easy way to do this is to simply demote the problem DC by running DCPROMO – reboot the server – and then run DCPROMO and reboot once more. If just one DC resides at a site, you can use the Burflags Windows registry entry to rebuild the SYSVOL. Keep in mind that demoting the only DC residing on a site may require you to rejoin the clients to the domain again.
Read: Verify Settings with Group Policy Results Tool (GPResult.exe) in Windows 11/10
3] Sync (Authoritative or non-Authoritative) SYSVOL data using FRS
The SYSVOL folder hierarchy, present on all Active Directory domain controllers, is mainly used to store two important sets of data replicated among DCs, but SYSVOL replication takes place separately from Active Directory replication. One can fail while the other is fully functional. In some cases, SYSVOL replication may fail and be unable to resume without manual intervention – in which case, you will need to perform an Authoritative (for one DC) or non-Authoritative (more than one DC) sync of SYSVOL data using FRS. The instructions below are not applicable if the File Replication Service (FRS) is not in use because the service has been deprecated – although, it may still be in use in Active Directory domains that were created in Windows Server 2008 and earlier. To determine whether FRS is in use, run the command below in an elevated command prompt on a DC: If the output shows the migration state is Eliminated, then FRS is not in use. To perform an Authoritative or non-Authoritative sync of SYSVOL data using FRS, follow these steps:
Since this is a registry operation, it is recommended that you back up the registry or create a system restore point as necessary precautionary measures.For the non-authoritative sync, make sure another DC exists in the environment and that its copy of the SYSVOL data is up to date by navigating to %systemroot%\SYSVOL to check the modified dates of Group Policy template files and/or script files.
Once done, you can proceed as follows:
Stop the File Replication Service.Press the Windows key + R to invoke the Run dialog.In the Run dialog box, type regedit and hit Enter to open Registry Editor.Navigate or jump to the registry key path below:
At the location, on the right pane, double-click the BurFlags entry to edit its properties.In the Value data field, type in D4 (for authoritative) or D2 (for non-authoritative) per your requirement.Click OK or hit Enter to save the change.Exit Registry Editor.Next, start the File Replication Service.Next, launch Event Viewer and check the File Replication Service event log in the Applications and Services Logs for informational event 13516. It may take a few minutes for this event to appear.Once event 13516 has appeared, run the command below:
Now, confirm the presence of the SYSVOL and NETLOGON shares in the output.
In a domain with one DC, the SYSVOL data itself should not have changed during this procedure. In a domain with more than one DC, you may need to perform a non-authoritative sync of SYSVOL on one or more of the other DCs after the authoritative sync has been completed by checking the FRS event logs of the other DCs for error or warning events. You can also compare the data in the SYSVOL folder hierarchy of the affected DC to the corresponding data on a known good DC to confirm that the data match.
4] Contact Microsoft Support
If the Group Policy not replicating between Domain Controllers issue persists, then you may need to contact Microsoft Professional Support. They charge on a per-incident basis and tickets must be initiated online only as they do not accept phone calls to create a ticket. I hope this post helps you! Read: The processing of Group Policy failed because of a lack of network connectivity to a domain controller
How do you fix replication issues between domain controllers?
First, you can use Microsoft Hotfix, which works pretty well in most cases. Following that, you can force update the changes using the Command Prompt. On the other hand, you can use synchronize SYSVOL settings using FRS as well. If you want to learn them in detail, you need to go through the aforementioned guides.
How do I check my replication status?
To view and diagnose AD replication errors or issues, you can either run the Microsoft Support and Recovery Assistant Tool OR run the AD Status Replication Tool on the DCs. You can read the replication status in the repadmin /showrepl output. Repadmin is part of Remote Server Administrator Tools (RSAT). When you change a group policy, you may have to wait two hours (90 minutes plus a 30-minute offset) before you see any changes on client computers. In some cases, some changes will not take effect until the machine is rebooted.
