Troubleshooting DFSR Sysvol Replication: Forced Synchronization in Windows Server

Table of Contents

This article details the procedures for initiating both authoritative and non-authoritative synchronization for Sysvol replication when utilizing Distributed File System Replication (DFSR). Understanding these processes is crucial for administrators managing Windows Server environments, particularly domain controllers, to ensure consistent and reliable replication of critical system volume data. Unlike the legacy File Replication Service (FRS), DFSR does not employ the Bur Flags registry values (D2 and D4) for controlling synchronization behavior, necessitating alternative methods. Furthermore, direct manipulation of Sysvol replication through the DFS Management snap-in or Dfsradmin.exe is intentionally restricted to safeguard against accidental misconfigurations. This guide provides step-by-step instructions to effectively manage DFSR Sysvol synchronization.

How to Perform a Non-Authoritative Synchronization of DFSR-Replicated Sysvol Replication (like D2 for FRS)¶

A non-authoritative synchronization, analogous to the D2 setting in FRS, is used when you need a domain controller to synchronize its Sysvol folder from a healthy partner. This is typically employed when a domain controller’s Sysvol data is corrupted or out of sync and you want it to replicate from another domain controller assumed to have the correct data. The following steps outline the process to perform a non-authoritative synchronization:

1. Modify msDFSR-Enabled Attribute via ADSI Edit:
   Begin by opening ADSI Edit (ADSIEDIT.MSC) on each domain controller that you intend to make non-authoritative. Navigate to the following Distinguished Name (DN) path:

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

Within this DN, locate the attribute named msDFSR-Enabled. Modify this attribute and set its value to FALSE. This action effectively disables DFSR replication for Sysvol on the targeted domain controller.

2. Force Active Directory Replication:
   After modifying the msDFSR-Enabled attribute, it’s essential to ensure that this change is replicated across the entire Active Directory domain. Force Active Directory replication to propagate these changes to all domain controllers. This can be achieved using tools like Active Directory Sites and Services or command-line utilities such as repadmin /syncall /AdeP. Successful replication is critical for the subsequent steps to function correctly.

3. Initiate AD Polling on Non-Authoritative DCs:
   On each domain controller where you disabled DFSR in Step 1, open an elevated command prompt and execute the following command:

DFSRDIAG POLLAD

The DFSRDIAG POLLAD command instructs the DFSR service to immediately poll Active Directory for configuration changes. This ensures that the DFSR service on these domain controllers promptly recognizes the change made to the msDFSR-Enabled attribute.

4. Verify Event ID 4114 in DFSR Event Log:
   Check the DFSR event log on each non-authoritative domain controller. You should observe Event ID 4114. This event confirms that DFSR replication for Sysvol has been successfully stopped on these servers, as indicated by the change in Active Directory configuration. This event is a crucial indicator that the non-authoritative synchronization process is proceeding as expected.

5. Re-enable DFSR Replication:
   Return to ADSI Edit and the same DN path identified in Step 1. Locate the msDFSR-Enabled attribute again. This time, set the value of msDFSR-Enabled back to TRUE. This action re-enables DFSR replication for Sysvol on the domain controllers previously configured as non-authoritative.

6. Force Active Directory Replication (Again):
   Similar to Step 2, force Active Directory replication throughout the domain once more. This step is crucial to propagate the re-enablement of DFSR replication (msDFSR-Enabled=TRUE) to all domain controllers, ensuring that all DCs are aware of the configuration change.

7. Initiate AD Polling Again:
   On the same domain controllers where you re-enabled DFSR in Step 5, execute the DFSRDIAG POLLAD command in an elevated command prompt once more:

DFSRDIAG POLLAD

This command prompts the DFSR service to poll Active Directory and recognize the re-enablement of Sysvol replication.

8. Verify Event IDs 4614 and 4604 in DFSR Event Log:
   Examine the DFSR event log on these domain controllers again. This time, you should see Event IDs 4614 and 4604. Event ID 4614 indicates that DFSR replication for Sysvol has been initialized, and Event ID 4604 confirms that Sysvol replication has been successfully initialized. These events collectively signify that the domain controller has performed a D2-equivalent non-authoritative synchronization of Sysvol replication, pulling the latest Sysvol data from its replication partners.

By completing these eight steps, you have successfully performed a non-authoritative synchronization of DFSR-replicated Sysvol, ensuring that the designated domain controllers have refreshed their Sysvol content from their partners.

How to Perform an Authoritative Synchronization of DFSR-Replicated Sysvol Replication (like D4 for FRS)¶

An authoritative synchronization, similar to the D4 setting in FRS, is employed when you need to designate a specific domain controller as the source of truth for Sysvol data. This is typically required in disaster recovery scenarios or when you are confident that a particular domain controller holds the most accurate and up-to-date version of the Sysvol folder. It is critical to perform this procedure carefully, as an incorrect authoritative synchronization can lead to data loss or inconsistencies across the domain. The following steps outline the process for performing an authoritative synchronization:

1. Stop DFSR Service on All Domain Controllers:
   On all domain controllers within the domain, including the one you intend to make authoritative, change the DFS Replication service Startup Type to Manual. After changing the startup type, stop the DFS Replication service on each domain controller. This step is crucial to prevent any replication activity during the configuration changes and ensure a clean authoritative synchronization.

2. Configure Authoritative DC in ADSI Edit:
   Identify the domain controller you want to make authoritative for Sysvol replication. It is generally recommended to choose the PDC Emulator role holder, as it is typically the most up-to-date domain controller within the domain. On this authoritative domain controller, open ADSI Edit (ADSIEDIT.MSC) and navigate to the following DN path:

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

Within this DN, modify two attributes:
- Set msDFSR-Enabled to FALSE.
- Set msDFSR-options to 1. This attribute, when set to 1, designates the domain controller as authoritative upon the next startup of the DFSR service.

3. Configure Non-Authoritative DCs in ADSI Edit:
   On all other domain controllers in the domain (excluding the one configured as authoritative in Step 2), open ADSI Edit and navigate to the same DN path:

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

On each of these non-authoritative domain controllers, modify one attribute:
- Set msDFSR-Enabled to FALSE. It is crucial not to modify the msDFSR-options attribute on these domain controllers.

4. Force and Validate Active Directory Replication:
   Force Active Directory replication throughout the domain. It is critical to validate the success of Active Directory replication on all domain controllers. Ensure that the changes made to the msDFSR-Enabled and msDFSR-options attributes have replicated successfully to every domain controller in the domain. Failure to ensure successful AD replication before proceeding can lead to inconsistencies and replication problems.

5. Start DFSR Service on Authoritative DC:
   On the domain controller designated as authoritative in Step 2, start the DFS Replication service. Only start the service on the authoritative DC at this stage. Leave the DFSR service stopped on all other domain controllers for now.

6. Verify Event ID 4114 on Authoritative DC:
   Check the DFSR event log on the authoritative domain controller. You should see Event ID 4114, indicating that Sysvol replication has stopped. This is expected as part of the authoritative synchronization process.

7. Re-enable DFSR on Authoritative DC:
   Return to ADSI Edit on the authoritative domain controller and the same DN path as in Step 2. Set the msDFSR-Enabled attribute back to TRUE. Leave the msDFSR-options attribute set to 1; it will automatically reset after the authoritative synchronization is complete.

8. Force and Validate Active Directory Replication (Again):
   Force Active Directory replication throughout the domain once more and again, validate its success on all DCs. Ensure that the re-enablement of DFSR (msDFSR-Enabled=TRUE) on the authoritative DC has replicated properly.

9. Initiate AD Polling on Authoritative DC:
   On the authoritative domain controller, open an elevated command prompt and execute the DFSRDIAG POLLAD command:

DFSRDIAG POLLAD

This command prompts the authoritative DC to poll Active Directory and recognize the configuration changes.

10. Verify Event ID 4602 on Authoritative DC:
    Examine the DFSR event log on the authoritative domain controller. You should see Event ID 4602. This event confirms that Sysvol replication has been initialized authoritatively. This signifies that the domain controller has performed a D4-equivalent authoritative synchronization and is now the authoritative source for Sysvol data.

11. Start DFSR Service on Non-Authoritative DCs:
    Now, start the DFS Replication service on all other domain controllers (the non-authoritative DCs). As you start the service on each of these DCs, check their DFSR event logs and you will likely see Event ID 4114, indicating that Sysvol replication is initially stopped on them as well.

12. Re-enable DFSR on Non-Authoritative DCs:
    On all other domain controllers (non-authoritative DCs), return to ADSI Edit and the same DN path as in Step 3. Set the msDFSR-Enabled attribute back to TRUE.

13. Initiate AD Polling on Non-Authoritative DCs:
    On all non-authoritative domain controllers, execute the DFSRDIAG POLLAD command in an elevated command prompt:

    DFSRDIAG POLLAD
    

14. Return DFSR Service Startup Type to Automatic:
    Finally, on all domain controllers, revert the DFS Replication service Startup Type back to its original setting, which is typically Automatic.

By diligently following these fourteen steps, you have successfully performed an authoritative synchronization of DFSR-replicated Sysvol. The designated authoritative domain controller has become the source of truth, and all other domain controllers will non-authoritatively synchronize their Sysvol content from it.

More Information¶

When performing an authoritative synchronization on one domain controller, it is imperative to ensure that all other domain controllers in the domain are configured for non-authoritative synchronization. Failing to do so can lead to conflicts on domain controllers that were not explicitly configured, particularly if the DFSR service on those DCs is restarted without proper configuration. These conflicts can arise from DCs attempting to replicate changes against the authoritative source without being properly set to non-authoritative mode.

For example, in a scenario where logon scripts have been accidentally deleted and then manually restored to the PDC Emulator, designating the PDC Emulator as authoritative and all other domain controllers as non-authoritative ensures a successful recovery and prevents potential conflicts. This approach guarantees that the restored scripts on the PDC Emulator are propagated authoritatively to all other domain controllers.

While making any domain controller authoritative is possible, prioritizing the PDC Emulator as the authoritative source is generally recommended. The PDC Emulator often holds the most current and consistent Sysvol replication content due to its role in domain operations and password changes, making it a reliable source for authoritative synchronization.

The use of the authoritative flag should be reserved for situations where forcing synchronization across all domain controllers is necessary. For scenarios involving the repair of a single domain controller, performing a non-authoritative synchronization on that specific DC, without affecting other servers, is usually sufficient and less disruptive.

This guide is simplified for a 2-domain controller environment for clarity. In environments with more domain controllers, the outlined steps must be extended to encompass all DCs in the domain. Furthermore, it is assumed that administrators have a contingency plan for data recovery in disaster scenarios where data may have been deleted, overwritten, or corrupted before undertaking these synchronization procedures. Always ensure backups are in place and understood before performing authoritative or non-authoritative synchronization.

If you have further questions or require assistance with DFSR Sysvol replication troubleshooting, please feel free to leave a comment below. Your experiences and questions can help others in the community.