Group Policy is not replicated between domain controllers

This post provides the most appropriate solutions to the problem in which Group policies both do not apply and do not replication between domain controllers in a regular Windows Server environment.

Group Policy is not replicated between domain controllers

If GPOs are not being synchronized or replicated between domain controllers, this could be due to the following reasons:

  • Problems with Active Directory.
  • Problems with one or more domain controllers depending on the settings.
  • Lag or slow file replication service issues.
  • The Distributed File System (DFS) client is disabled.
  • Network connection to the domain controller.

Some client machines will use DC based on site membership in case you have more than one DC in the domain. Typically, if each site has multiple DCs, clients can select DCs based on “weight”, whereas normally all DCs are “equally weighted”. It is also possible that the client machines will use the DC elsewhere. Therefore, if your DCs are not properly replicated, the SYSVOLs located on those servers may not have the data accurately mapped, in which case your workstations will get different results depending on which DC the client machines point to.

Group Policy is not replicated between domain controllers

In a typical case, there are three DCs and one of them, the old DC 2012, will be decommissioned. The other two are DC 2016 which is new and currently owned by FSMO. There is now an issue with SYSVOL replication where any changes made on DC 2016 are not replicated to DC 2012 SYSVOL policies.

So, if Group Policies are not applied and replication is not working between domain controllers when installing Windows Server in an enterprise environment, if you are an IT administrator, the solutions below in no particular order should help you resolve the issue.

  1. Apply Microsoft Hotfix
  2. General troubleshooting of DC replication
  3. Synchronization of (authoritative or non-authoritative) SYSVOL data using FRS
  4. Contact Microsoft Support

Let’s take a look at the process description that applies to each of the listed solutions.

1]Microsoft fix

If you are experiencing this issue on a DC running Windows Server 2008 R2 or 2012, you must first apply Microsoft HotFix to all DCs (not required for 2012 R2) before troubleshooting. There is a known issue on DC where the servers keep files open after you edit, making it look like the edits are working, until you close and reopen the GPO and find out that it doesn’t apply at all. Similarly, replication seems to work, but some machines pick up the settings and others don’t, because the same data is not properly replicated to all DCs.

Read it: How to repair a damaged Group Policy in Windows

2]General troubleshooting with DC replication

Before continuing, you can perform the following preliminary tasks for general DC replication troubleshooting. After completing each task, check to see if the problem is resolved.

  • Force gpupdate. You can start by running gpupdate from a workstation experiencing conflicting results. If you get an output with an indication Failed to update computer policythen there is a GPO delivery problem in general.
  • Check DC for NETLOGON and SYSVOL folders. At the most basic level, a DC should have two default shared folders, the NETLOGON folder and the SYSVOL folder. If these two folders are missing on the DC, you will have problems with AD and the GPOs will not be delivered properly.
  • Force replication using a script. You can force replication using a script from Knowing that group policies consist of two parts files located in SYSVOL and the version attribute in AD, running the script is a quick way to replicate your changes to all DCs in your domain.
  • Use the troubleshooting tools. Using troubleshooting tools such as DCDIAG.exe, GPOTOOL.exeor DFSDIAG.exe, if there is a replication problem, you should be able to identify which DC or DCs are the problem. Once this is determined, you will need to restore 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 problematic DC by running DCPROMO – reboot the server – and then run DCPROMO and reboot again. If there is only one DC in the site, you can use the Burflags Windows registry entry to rebuild SYSVOL. Be aware that downgrading the only DC that resides on the site may require you to rejoin the clients to the domain.

Read it: Check the settings using the Group Policy Results Tool (GPResult.exe) in Windows 11/10

3]Synchronize (authoritative or non-authoritative) SYSVOL data using FRS

Synchronization of (authoritative or non-authoritative) SYSVOL data using FRS

The SYSVOL folder hierarchy, which is present on all Active Directory domain controllers, is primarily used to store two important sets of data replicated between DCs, but SYSVOL replication occurs separately from Active Directory replication. One can fail while the other is fully functional. In some cases, SYSVOL replication may fail and cannot be recovered without manual intervention – in which case you will need to perform an authoritative (for one DC) or non-authoritative (more than one DC) SYSVOL data synchronization using FRS.

The instructions below do not apply if the File Replication Service (FRS) is not used because the service is deprecated, although it can still be used in Active Directory domains created in Windows Server 2008 and earlier. To determine whether FRS is in use, run the following command at an elevated command prompt on the DC:

dfsrmig /getmigrationstate

If the output shows the migration status Liquidatedthen FRS is not used.

To perform authoritative or non-authoritative synchronization 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 precautions.
  • For non-authoritative synchronization, ensure that the other DC exists in the environment and that its copy of the SYSVOL data is up-to-date by going to %systemroot%\SYSVOL to check the modification dates of Group Policy template files and/or script files.

Once complete, you can do the following:

HKLM\CCS\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
  • In the right pane, double-click BurFlags entry to edit its properties.
  • In the village Vdata alu field, enter D4 (for authoritative) or D2 (for non-authoritatives) as per your requirement.
  • Click good or press Enter to save the changes.
  • Exit the registry editor.
  • Next, start the file replication service.
  • Then run Event Viewer and check the File Replication Service event log Application and service logs for info event 13516. It may take a few minutes for this event to appear.
  • After event 13516 occurs, run the following command:
net share
  • Now confirm the presence of shared SYSVOL and NETLOGON files in the output.

In a single DC domain, 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 SYSVOL synchronization on one or more other DCs after the authoritative synchronization is complete, checking the FRS event logs of the other DCs for errors or warnings. events. You can also compare the data in the SYSVOL folder hierarchy of the damaged DC with the corresponding data on the known healthy DC to confirm that the data matches.

4]Contact Microsoft Support

If Group Policy is not replicated between domain controllers If the problem persists, you may need to contact Microsoft Professional Support. They charge per incident 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 it: Group Policy processing failed because there is no network connectivity to the domain controller

Why is DFS not replicating?

If the DFS Replication service has stopped replicating on the C: volume, the failure may be because the disk is full, the disk has failed, or the quota limit has been reached. This problem can also occur if the DFS Replication service encountered errors when trying to place the files for the replicated folder on the C: volume. To see if DFS replication is working, you can run Get-DfsrState: command that shows the current state of DFS-R replication relative to the partners of a DFS replication group. DFS replication clearly does not require real-time synchronization between servers, and with a 600GB load and a 1GB link, the initial DFS replication will take a day or two at most.

How to check 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 DC. You can read the replication status at repadmin / showrepl exit Repadmin is part of Remote Server Administrator Tools (RSAT). If you change Group Policy, you might 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.