Replication can get broken for various reasons. One vivid symptom is when you’re unable to run gpupdate because it complains about access errors. In this case, you can check the SYSVOL share on your DCs, e.g. if there’s a mismatch between dc1\SYSVOL\domain.name\Policies and dc2\SYSVOL\domain.name\Policies, it means that replication is broken. The SYSVOL where the number of policies matches the number of GPOs in the Group Policy editor is the working one, the other shares where there are less or more policies are the broken ones.
In the old days (Windows Server 2003) you could recover from such erros with the BurFlags trick, but this is no longer relevant. Up to Windows Server 2012 you could do the same with DFSRDIAG POLLAD, but with Windows Server 2012 R2 that’s no more relevant either. There’s no DFSRDIAG anymore, but there’s a PowerShell cmdlet which can achieve the same. The problem is, this is not installed by default, so you have to install it manually (but of course this is not documented at all). Open Server Manager and install the Remote Server Administration Tools / Role Administration Tools / File Services Tools / DFS Management Tools feature.
Once ready, you can follow the 2012 procedure with DFSRDIAG, except you have to use Update-DfsrConfigurationFromAD in PowerShell instead of DFSRDIAG POLLAD from any command line (there’s a nice mapping table and a DFSR Cmdlets reference which helped to find this out).
So once you set msDFSR-Enabled to FALSE on the broken DC in ADSIEDIT and run the cmdlet (instead of the unavailable DFSRDIAG POLLAD), soon you’ll see this event in Applications and Services Logs / DFS Replication in Event Viewer:
Event ID: 2010 The DFS Replication service has detected that all replicated folders on volume C: have been disabled or deleted.
And soon another one:
Event ID: 4114 The replicated folder at local path C:\Windows\SYSVOL\domain has been disabled. The replicated folder will not participate in replication until it is enabled. All data in the replicated folder will be treated as pre-existing data when this replicated folder is enabled.
Then you can set msDFSR-Enabled to TRUE, run the cmdlet again, and soon you’ll see:
Event ID: 2002 The DFS Replication service successfully initialized replication on volume C:.
and
Event ID: 4614 The DFS Replication service initialized SYSVOL at local path C:\Windows\SYSVOL\domain and is waiting to perform initial replication. The replicated folder will remain in the initial synchronization state until it has replicated with its partner . If the server was in the process of being promoted to a domain controller, the domain controller will not advertize and function as a domain controller until this issue is resolved. This can occur if the specified partner is also in the initial synchronization state, or if sharing violations are encountered on this server or the synchronization partner. If this event occurred during the migration of SYSVOL from File Replication service (FRS) to DFS Replication, changes will not replicate out until this issue is resolved. This can cause the SYSVOL folder on this server to become out of sync with other domain controllers.
And then you’re supposed to get a 4604 event, too, which would mean the “D2” non-authoritative synchronization is done. But if you don’t receive such event (like me), you gotta proceed with the “D4” authoritative synchronization. You’ll still get the 2010, 4114 and 2002 events, but instead of 4614 + 4604 you’ll get a 4602:
Event ID: 4602 The DFS Replication service successfully initialized the SYSVOL replicated folder at local path C:\Windows\SYSVOL\domain. This member is the designated primary member for this replicated folder. No user action is required. To check for the presence of the SYSVOL share, open a command prompt window and then type “net share”.
Congratulations, you’ve just fixed your domain.