TL;DR — Quick Summary
Learn force an authoritative and non-authoritative synchronization for dfsr-replicated sysvol (like . <D4/D2 for FRS) Fixing Broken SYSVOL Replication Cons
Note: This article was originally published in 2013. Some steps, commands, or software versions may have changed. Check the current Windows Servers documentation for the latest information.
Prerequisites
Before you begin, make sure you have:
- Windows Server installed
- Administrator access
- Remote Desktop or direct console access
Forcing DFSR SYSVOL Synchronization (The Modern “D2” and “D4”)
If you are managing Active Directory Domain Services, you might encounter a scenario where the SYSVOL folder stops replicating between your Domain Controllers.
In the old days of the File Replication Service (FRS), forcing a sync was as simple as modifying the Burflags registry key and setting it to D2 (non-authoritative) or D4 (authoritative). However, Microsoft replaced FRS with Distributed File System Replication (DFSR), and Burflags no longer exist for SYSVOL.
Furthermore, unlike custom DFSR replicated folders, the SYSVOL folder is intentionally protected from editing through standard management interfaces (like the Dfsmgmt.msc snap-in or Dfsradmin.exe) to prevent accidental destruction of group policies or login scripts.
To force synchronization of a DFSR-replicated SYSVOL, you must use ADSI Edit and the DFSRDIAG command-line tool.
Method 1: Force Non-Authoritative Sync (The new “D2”)
Use this method when a single Domain Controller is out of sync and you want it to discard its corrupted SYSVOL and pull a fresh copy from a healthy partner DC.
Step 1: Open ADSIEDIT.msc on the corrupted Domain Controller.
Step 2: Connect to the Default naming context and locate the DFSR Local Settings object for this specific server:
CN=SYSVOL Subscription, CN=Domain System Volume, CN=DFSR-LocalSettings, CN=<Corrupt_Server_Name>, OU=Domain Controllers, DC=<domain>
Step 3: Edit the msDFSR-Enabled attribute and set its value to FALSE.
Step 4: Force Active Directory replication throughout your domain (you can use Active Directory Sites and Services).
Step 5: Open an elevated command prompt on the corrupted server and run:
dfsrdiag pollad
Step 6: Open Event Viewer on that server. Wait until you see Event ID 4114 in the DFS Replication event log. This confirms DFSR has stopped replicating SYSVOL.
Step 7: Go back to ADSIEDIT.msc to the exact same object from Step 2, and change msDFSR-Enabled back to TRUE.
Step 8: Force Active Directory replication again across the domain.
Step 9: Go back to the command prompt on the corrupted server and execute:
dfsrdiag pollad
Step 10: Check Event Viewer again. You will see Event ID 4614 followed by Event ID 4604. This confirms SYSVOL has been re-initialized and synced non-authoritatively.
Method 2: Force Authoritative Sync (The new “D4”)
Use this method only during a disaster recovery scenario where all SYSVOL replication is completely broken across the entire domain, and you need to declare one specific DC (preferably the PDC Emulator) as the undeniable “Master” copy that everyone else must sync from.
CRITICAL WARNING: If you set the authoritative flag on one DC, you must perform a non-authoritative synchronization on ALL OTHER DCs in the domain. Otherwise, you will experience massive file conflicts and data loss.
Phase A: Declare the Authoritative Master Server
- Open
ADSIEDIT.mscon the DC you want to make authoritative (Master). - Locate its DFSR Local Settings object:
CN=SYSVOL Subscription, CN=Domain System Volume, CN=DFSR-LocalSettings, CN=<Master_Server_Name>, OU=Domain Controllers, DC=<domain> - Edit the following two attributes:
- Set
msDFSR-EnabledtoFALSE - Set
msDFSR-optionsto1
- Set
Phase B: Set all other Servers to Non-Authoritative
4. Still in ADSIEDIT.msc, navigate to the DFSR Local Settings object for every single other Domain Controller in the domain.
5. On each of those objects, set only:
msDFSR-EnabledtoFALSE
- Force Active Directory replication throughout the domain and ensure it succeeds on all DCs.
Phase C: Restart the Master Engine 7. On the Authoritative (Master) server, open an elevated command prompt and type:
dfsrdiag pollad
- Check its Event Viewer for Event ID 4114.
- Once confirmed, go back to
ADSIEDIT.mscfor the Master server and changemsDFSR-Enabledback toTRUE. - Run
dfsrdiag polladon the master server again. - Look for Event ID 4602 in the Event Viewer. This confirms the master server has initialized itself as the primary designated member.
Phase D: Synchronize the rest of the Domain
12. For all other non-authoritative DCs, go back to ADSIEDIT.msc and change msDFSR-Enabled back to TRUE.
13. On each non-authoritative DC, open a command prompt and run:
dfsrdiag pollad
- Check the Event Viewer on each of those servers for Event ID 4604. This confirms they have successfully downloaded the fresh SYSVOL copy from the Master server.
Related Articles
- [How to: ](/change-product-key-windows-8-windows-server-2012/)
- [](/communication-with-the-underlying-transaction-manager-has-failed/)
- How to: Configure your Domain Server to sync the time over the Internet (Network Time Protocol - NTP)
- How to: Delete a DHCP Failover relationship when the partner server is unreachable