How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like “D4/D2” for FRS)

Fixing Broken SYSVOL Replication

Consider the following scenario:

You want to force the non-authoritative synchronization of SYSVOL on a domain controller. In the File Replication Service (FRS), this was controlled through the D2 and D4 data values for the Burflags registry values, but these values do not exist for the Distributed File System Replication (DFSR) service. You cannot use the DFS Management snap-in (Dfsmgmt.msc) or the Dfsradmin.exe command-line tool to achieve this. Unlike custom DFSR replicated folders, SYSVOL is intentionally protected from any editing through its management interfaces to prevent accidents.

How to perform a non-authoritative synchronization of DFSR-replicated SYSVOL (like “D2” for FRS)

1. In the ADSIEDIT.MSC tool modify the following distinguished name (DN) value and attribute on each of the domain controllers that you want to make non-authoritative:

   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

   msDFSR-Enabled=FALSE

2. Force Active Directory replication throughout the domain.
3. Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:

   DFSRDIAG POLLAD

4. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated.
5. On the same DN from Step 1, set:

   msDFSR-Enabled=TRUE

6. Force Active Directory replication throughout the domain.
7. Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:

   DFSRDIAG POLLAD

8. You will see Event ID 4614 and 4604 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done a “D2” of SYSVOL.

How to perform an authoritative synchronization of DFSR-replicated SYSVOL (like “D4” for FRS)

1. In the ADSIEDIT.MSC tool, modify the following DN and two attributes on the domain controller you want to make authoritative (preferrably the PDC Emulator, which is usually the most up to date for SYSVOL contents):

   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

   msDFSR-Enabled=FALSE
   msDFSR-options=1

2. Modify the following DN and single attribute on all other domain controllers in that domain:

   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

   msDFSR-Enabled=FALSE

3. Force Active Directory replication throughout the domain and validate its success on all DCs.
   

   Log Name: DFS ReplicationSource: DFSRDate: 3/11/2013 9:35:38 AMEvent ID: 4012Task Category: NoneLevel: ErrorKeywords: ClassicUser: N/AComputer: computer.domain.local Description:The DFS Replication service stopped replication on the folder with the following local path: C:WindowsSYSVOLdomain. This server has been disconnected from other partners for 90 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.

4. Start the DFSR service set as authoritative:
5. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated.
6. On the same DN from Step 1, set:

   msDFSR-Enabled=TRUE
   

7. Force Active Directory replication throughout the domain and validate its success on all DCs.
8. Run the following command from an elevated command prompt on the same server that you set as authoritative:

   DFSRDIAG POLLAD

9. You will see Event ID 4602 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done a “D4” of SYSVOL.
   

   Log Name: DFS ReplicationSource: DFSRDate: 3/11/2013 10:40:35 AMEvent ID: 4602Task Category: NoneLevel: InformationKeywords: ClassicUser: N/AComputer: Description:The DFS Replication service successfully initialized the SYSVOL replicated folder at local path C:WindowsSYSVOLdomain. 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”.

10. Start the DFSR service on the other non-authoritative DCs. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on each of them.
11. Modify the following DN and single attribute on all other domain controllers in that domain:

    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<each other server name>,OU=Domain Controllers,DC=<domain>

    msDFSR-Enabled=TRUE

12. Run the following command from an elevated command prompt on all non-authoritative DCs (i.e. all but the formerly authoritative one):

    DFSRDIAG POLLAD

Log Name: DFS Replication
Source: DFSR
Date: 3/11/2013 10:42:07 AM
Event ID: 4604
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: ClientServer.Domain.Local
Description:
The DFS Replication service successfully initialized the SYSVOL replicated folder at local path C:WindowsSYSVOLdomain. This member has completed initial synchronization of SYSVOL with partner AuthorativeServer.Domain.Local. To check for the presence of the SYSVOL share, open a command prompt window and then type “net share”.

Back to the top | Give Feedback

More Information

If setting the authoritative flag on one DC, you must non-authoritatively synchronize all other DCs in the domain. Otherwise you will see conflicts on DCs, originating from any DCs where you did not set auth/non-auth and restarted the DFSR service. For example, if all logon scripts were accidentally deleted and a manual copy of them was placed back on the PDC Emulator role holder, making that server authoritative and all other servers non-authoritative would guarantee success and prevent conflicts.

If making any DC authoritative, the PDC Emulator as authoritative is preferable, since its SYSVOL contents are usually most up to date.

The use of the authoritative flag is only necessary if you need to force synchronization of all DCs. If only repairing one DC, simply make it non-authoritative and do not touch other servers.

This article is designed with a 2-DC environment in mind, for simplicity of description. If you had more than one affected DC, expand the steps to include ALL of those as well. It also assumes you have the ability to restore data that was deleted, overwritten, damaged, etc. previously if this is a disaster recovery scenario on all DCs in the domain.

See also: