Windows Server DFSR Replication Troubleshooting Guide

DFS Replication (DFSR) is the replication engine behind both DFS namespaces and SYSVOL replication in Active Directory. When it silently stops replicating, the symptom usually appears somewhere else entirely — GPOs applying inconsistently, one branch office seeing stale files, or a domain controller whose SYSVOL is out of step with its peers. DFSR is also unusual in that it has a built-in diagnostic toolset, so there is no need to guess. This guide walks the troubleshooting sequence from the cheapest checks to the ones that require action, and explains how to recover a member without breaking its partners.

Start With the Health Report

The health report is a scheduled task that writes an HTML report covering backlog, replication state, topology, and error conditions across all members. Run it first:

dfsrdiag.exe ReplicationState
dfsrdiag.exe Backlog /RGName:"Domain System Volume" /RFName:"SYSVOL Share" /SMem:DC01 /RMem:DC02

In PowerShell, the same information comes from the DFSR module:

Get-DfsrBacklog -GroupName "Domain System Volume" -FolderName "SYSVOL Share" -SourceComputerName DC01 -DestinationComputerName DC02
Get-DfsrMembership -GroupName "Domain System Volume" -ComputerName DC01 | Format-List
Get-DfsrState -ComputerName DC01
Get-DfsrServiceConfiguration -ComputerName DC01

Get-DfsrBacklog is the single most useful command. It lists the specific files queued from a source member to a destination member. A backlog that grows and never drains is the clearest signal of a stuck replication group.

Check Service and Replication State First

Check service and member state first

Before investigating the group, confirm the basics on every member:

Get-Service DFSR
Get-DfsReplicationGroup -GroupName "Domain System Volume" | Format-List
dfsrdiag.exe ReplicationState /member:DC01

The DFSR service must be running, and the member must show an enabled, non-disabled state inside the replication group. A member that was administratively disabled — often after a previous recovery — stays out of the topology indefinitely and generates no errors while doing so.

Diagnose by Symptom

Files exist on one member but never arrive at another. Check the backlog in the failing direction, then confirm the connection topology. A replication group with two members where one is in a different site can be governed by a site link schedule that is closed outside business hours, or by inter-site bandwidth throttling.

Replication works in one direction only. This is nearly always a membership or connection-object problem rather than a network one. Verify the connection objects, that both members are enabled, and that the read-only attribute is not set on a member that should be writable. For SYSVOL in particular, a member in read-only mode is a legitimate configuration, but it must match the design.

Replication works between some partners but not others. Verify that a two-way connection exists between every pair that needs one. Replication is not transitive: A-to-B and B-to-C does not automatically give you A-to-C.

One member has a huge backlog while the others are healthy. Look at staging area usage and disk space before anything else — DFSR refuses to replicate when the staging area quota is exhausted, and the failure is quiet:

Get-DfsrMembership -GroupName "Domain System Volume" -ComputerName DC02 | Select StagingPathQuotaInMB, StagingPath
Get-PSDrive C

Test Propagation Without Waiting

Forcing replication for a test

DFSR uses a change notification plus a poll interval, so a test file may not move for up to an hour. Force the check rather than waiting:

dfsrdiag.exe PollAD /Member:DC01
dfsrdiag.exe SyncNow /RGName:"Domain System Volume" /RFName:"SYSVOL Share" /Mem:DC02
dfsrdiag.exe PropagationTest /RGName:"Domain System Volume" /RFName:"SYSVOL Share" /SMem:DC01 /RMem:DC02

The propagation test writes a test file on the source and watches for it on the destination, which converts an ambiguous "is it replicating" question into a definite answer. Run PollAD on every member involved first, so that AD changes such as new connection objects are picked up immediately rather than at the next poll.

Read the DFSR Event Log

Get-WinEvent -LogName "DFS Replication" -MaxEvents 40 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap

Journal wrap and member recovery

Three event IDs carry most of the diagnostic value: replication errors (4004 and 4012 families), staging area and disk-space warnings, and journal wrap events. A journal wrap means the USN journal for that volume is no longer usable, and the member must resynchronise — a non-authoritative restore is the normal fix, and it should be performed on the member whose data is expendable.

Recovering a Member Safely

When a member's database is corrupt or its content is far out of date, use the standard recovery flow rather than trying to patch it: stop the DFSR service, remove the replication group membership for that member (choosing the option that does not affect other members), move the content out of the replicated folder, recreate the membership, and let it re-replicate. Before any of that, take a backup — and confirm which member holds the authoritative copy, because getting that backwards overwrites good data with stale data across the whole group.

Operational Notes

• Run the health report and backlog checks on a schedule, not only after something breaks.
• Watch staging area quota and free disk space on every member; exhaustion is the quietest failure mode.
• Replication is per-connection, not transitive — every pair that needs to exchange data needs a connection.
• Use PollAD and SyncNow to shorten test cycles instead of waiting for the poll interval.
• Identify the authoritative member before any resynchronisation, and back up first.

Related reading: our SSSD Active Directory realm join troubleshooting guide, the Windows LAPS deployment guide, and the DNS troubleshooting commands guide.

原文链接：https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/troubleshoot-dfsr-replication