How to Force DFSR SYSVOL Replication in Windows Server

Applies to: Windows Server 2025 / 2022 / 2019 / 2016 / 2012 R2 / 2012 / 2008 R2 / 2008

Sometimes SYSVOL changes need to replicate immediately between domain controllers instead of waiting for the normal DFS Replication schedule. The original version of this post used dfsrdiag SyncNow to trigger replication for the Domain System Volume replication group.

The original method is worth preserving as an operational troubleshooting step, but it is important to separate a normal replication delay from a broken SYSVOL replication state. If SYSVOL or NETLOGON is missing, or DFSR is stopped by an error such as Event ID 2213 or 4012, forcing a connection is not the same as repairing SYSVOL.

In This Article

• 1. Check SYSVOL Before Forcing Replication
• 2. Trigger DFSR SYSVOL Replication
• 3. Force DFSR to Poll Active Directory
• 4. Validate SYSVOL Replication
• 5. When SyncNow Is Not Enough
• 6. Key Takeaways

1. Check SYSVOL Before Forcing Replication

Before forcing anything, confirm that the domain controllers are healthy and that SYSVOL is already initialized. Start with Active Directory replication and the normal domain controller checks:

repadmin /replsummary

dcdiag /test:sysvolcheck /test:advertising

If Active Directory replication is already failing, fix that first. DFSR configuration is stored in Active Directory, so replication problems there can also delay or block DFSR configuration changes.

2. Trigger DFSR SYSVOL Replication

The original command used in this article is:

dfsrdiag SyncNow /RGName:"Domain System Volume" /Partner:DC02 /Time:15 /v

Replace DC02 with the actual DFSR partner. The /Time:15 value requests replication for 15 minutes, and /v enables verbose output.

Use this when SYSVOL replication is healthy but you want to trigger the DFSR connection immediately. Do not treat a successful SyncNow result as proof that SYSVOL itself is healthy.

3. Force DFSR to Poll Active Directory

If you changed DFSR-related configuration in Active Directory and do not want to wait for the normal polling interval, force DFSR to read the latest configuration:

dfsrdiag PollAD

This does not force file replication by itself. It tells the DFS Replication service to poll Active Directory for configuration changes. Microsoft also uses DFSRDIAG POLLAD in its current authoritative and non-authoritative SYSVOL recovery procedures.

4. Validate SYSVOL Replication

After triggering replication, validate the result instead of relying only on the command output.

• Confirm that SYSVOL and NETLOGON shares are present.
• Check Applications and Services Logs > DFS Replication for warnings or errors.
• Confirm Active Directory replication with repadmin /replsummary.
• Run dcdiag /test:sysvolcheck /test:advertising again.
• If you changed a Group Policy Object, confirm that both its Active Directory data and SYSVOL files have reached the expected domain controllers.

If the domain was previously migrated from FRS to DFSR, you may also find my SYSVOL migration from FRS to DFSR article useful.

5. When SyncNow Is Not Enough

If SYSVOL or NETLOGON is missing, a domain controller is stuck waiting for initial synchronization, or DFSR has stopped replication because of content freshness or dirty-shutdown protection, do not keep repeating SyncNow.

Microsoft documents separate recovery procedures for those states. Depending on the failure, the correct action may be to resume DFSR, perform a non-authoritative SYSVOL synchronization on one affected domain controller, or in a wider recovery scenario perform an authoritative synchronization from the correct source domain controller.

Important: Authoritative and non-authoritative SYSVOL recovery changes DFSR membership state and can cause data loss if the wrong domain controller is selected as the source. Use those procedures only after identifying the actual replication state.

6. Key Takeaways

• In the original scenario, dfsrdiag SyncNow was used to trigger the SYSVOL DFSR connection with a specific partner.
• dfsrdiag PollAD refreshes DFSR configuration from Active Directory; it is not the same as forcing file replication.
• Always validate SYSVOL, NETLOGON, DFSR events, Active Directory replication, and DCDiag results after the change.
• If SYSVOL replication is actually broken, follow the Microsoft recovery procedure instead of repeatedly forcing synchronization.

References

• Microsoft Learn – Force authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL
• Microsoft Learn – Troubleshoot missing SYSVOL and Netlogon shares