DFSR mechanics and diagnostics

DFSR moves content; DFSN directs clients

DFSR keeps copies of replicated folders in sync. DFS Namespaces gives clients referrals to shares, and SMB provides access to those shares. They can work together, but connecting to a share tells you little about replication health. A DFSR fault may still leave the local copy accessible.

DFSR uses RPC for replication. It does not carry replicated file changes through an SMB share. Port 5722 applies to Windows Server 2008/2008 R2 DCs; it is not a universal current DFSR firewall rule. Modern configurations use the endpoint mapper plus the configured RPC endpoint. See service and port requirements.

AD configuration must arrive before DFSR can consume it

DFSR global objects describe replication groups, members, connections, and replicated folders. Local settings under computer objects describe subscriptions. The service consumes configuration into its local state.

For SYSVOL, the global configuration is under:

CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,<domain DN>

Inspect the service’s local view before considering changes to its files:

dfsrdiag DumpMachineCfg /Member:DC1
dfsrdiag ReplicationState /Member:DC1

Changes when configuration is consumed: dfsrdiag PollAD /Member:DC1 asks DFSR to read configuration again. It won’t fetch missing AD changes first or synchronize every file. Check AD replication when members appear to have different topology.

Staging and RDC have a cost

DFSR stages content and can use Remote Differential Compression to reduce the amount transferred when existing data can help reconstruct a changed file. It still needs metadata, checksums, disk I/O, and processing. Replication can therefore take longer than a simple copy on a fast LAN.

Repeated staging cleanup can indicate a quota that is too small for the workload. Size and observe staging for the largest active files and concurrency rather than assuming the default fits. Keep this separate from free space for data, the database, and conflict/deleted storage. Microsoft’s staging quota guidance uses the combined size of the 32 largest files as a minimum baseline.

$largest = Get-ChildItem -LiteralPath 'D:\Data' -File -Recurse |
    Sort-Object Length -Descending | Select-Object -First 32
($largest | Measure-Object -Property Length -Sum).Sum / 1GB

This can take a while on a large tree, and it only counts files the account can enumerate. Access failures or long-path errors leave the result incomplete. Initial synchronization can also need more headroom than ordinary activity.

Preseeding needs the metadata too

Matching names and sizes aren’t enough to check preseeding. Preserve the file data, attributes, security, and other metadata required by the procedure, then compare hashes with DFSR-aware tools. An ACL change can itself cause replication work.

dfsrdiag FileHash /Path:"D:\Data\example.bin"

Use the DFSR preseeding procedure rather than transplanting old Robocopy hotfix instructions onto current Windows versions.

Replication is not a distributed file lock

If two users change copies of the same file on different members, they can conflict before the changes meet. DFSR resolves conflicts; it does not coordinate an application transaction across servers. Files held open with incompatible sharing can also delay replication.

The primary member flag matters during initial synchronization. It isn’t a permanent “this server always wins” setting or a general repair switch. Save the best copy before recovery. ConflictAndDeleted has a quota, and neither it nor PreExisting replaces a backup. Deletions replicate too. The DFSR FAQ covers these behaviors and workload limits.

Recovery can affect a whole volume

DFSR keeps one ESE metadata database per participating volume. A recovery involving that database can therefore involve several replicated folders, not only the folder whose symptom was reported.

Before resuming replication after a paused dirty-shutdown recovery, save unreplicated data from every affected folder. Conflict resolution may not keep the version the user wants. Use the volume identity in the event and the recovery procedure for that OS, rather than an old WMIC command containing someone else’s GUID. See event 2213.

Read-only replication is a folder configuration

Removing an outbound connection from a writable member does not turn its files into a supported read-only replica. Configure the supported read-only member behavior for the OS and workload, or prevent user writes through the appropriate access controls. A topology that merely suppresses outbound replication can accumulate unreplicated local changes.

For ordinary writable members, verify a connected topology with inbound and outbound paths between partners, directly or transitively. “Fully connected” does not require a full mesh. Missing outbound knowledge also compromises conflict/deletion handling, so restoring that connection after a long unsupported one-way arrangement can expose old local changes. The connection reference and Microsoft’s one-way recovery analysis explain the distinction. Do not reconnect first and discover which copy wins afterward.

Changing a normal data-folder membership between read/write and read-only can move unreplicated local changes into ConflictAndDeleted. Preserve those changes first. Use membership configuration for an ordinary replication group; SYSVOL’s service-managed membership has its own supported procedures.

Collect a useful failure record

Keep the member pair, replication group/folder, direction, last successful observation, state, backlog trend, DFSR events, free space, and recent configuration or storage changes together. “DFSR is slow” is much easier to investigate once you’ve narrowed it to one direction and one folder.

Polling is configuration work, not a file scan

When one member appears to ignore an administrative change, inspect the AD configuration it consumed:

Get-CimInstance -Namespace 'root\MicrosoftDFS' `
    -ClassName DfsrReplicationGroupConfig |
    Select-Object ReplicationGroupDn, LastChangeSource,
        LastChangeTime, LastChangeNumber

Run on that member or use an explicit remote CIM target. LastChangeSource identifies the AD server associated with the configuration change, not the human who edited it. Compare the relevant AD object’s replication metadata and audit events for that identity question. The configuration class reference defines these fields.

An open schedule permits prompt work

DFSR replication can begin soon after detecting a file change while its schedule is open. A 15-minute schedule display block is an availability/throttling unit, not a promise that DFSR sleeps for 15 minutes between files. If latency appears periodic, inspect schedule, bandwidth controls, connection errors, file locks, and staging before changing journal or database settings. The component-specific DFSR FAQ describes schedule behavior.

For a growing backlog, compare rate of change with actual delivery. A large file held open can wait while other work succeeds. Repeated metadata changes by a scanner or application can create a change storm without users visibly editing the contents. Collect the file names and responsible process when that pattern appears, rather than assuming the network alone explains the volume.

Initial authority has a limited lifetime

For an ordinary new replication group, initial synchronization needs one initial source for each replicated folder. A non-primary member must synchronize before acting as a normal source. If every available member is still waiting for initial synchronization, an apparently connected graph has no usable starting copy.

The primary designation is consumed and cleared when that member is ready; it does not stay set until every remote member finishes. A missing AD primary flag doesn’t mean the group never had one. Check initialization events and local state. If the primary loses its database before another member finishes, there may be no initialized source left. Microsoft’s primary-member explanation covers that failure and why setting primary on a working group isn’t a general repair.

A file’s identity matters more than its visible name

DFSR tracks a UID and version information for each resource. An NTFS file reference, DFSR UID, current pathname and content hash answer different questions. A same-name file independently created elsewhere is not necessarily the same replicated resource. The ID-record reference defines these fields and fence states.

Initial-primary/initial-sync fencing determines initial conflict behavior; ordinary later changes have different fences. Concurrent modifications of an established file can select a winning version without preserving both versions in the production path. Historical documentation that says an independently created older file always wins also needs its build/hotfix context: Microsoft subsequently changed that behavior. See the conflict-algorithm explanation and its update. Avoid using a single last-modified timestamp as a complete reconstruction of a conflict.

Recover a preserved file outside the live tree first

On a member with the DFSR module, inspect its actual manifest path:

Get-DfsrPreservedFiles -Path 'D:\Data\DfsrPrivate\ConflictAndDeletedManifest.xml'

Use the preserved-file listing to associate retained files with their original paths. PreExisting has a separate manifest. Quota cleanup may already have removed an entry’s content; these locations are not complete version history.

Restoration writes files: preserve the manifest/private content first, then preview a recovery into a separate directory:

Restore-DfsrPreservedFiles `
    -Path 'D:\Data\DfsrPrivate\ConflictAndDeletedManifest.xml' `
    -RestoreToPath 'E:\DFSR-Recovery-20261111' `
    -CopyFiles -RestoreAllVersions -WhatIf

Review the path, free space and retained versions before removing -WhatIf. This operates on the manifest’s contents, not just one row returned by the listing cmdlet. -CopyFiles preserves source copies; the default restoration instead moves retained files. -RestoreAllVersions recovers older retained versions too. Avoid blanket overwrite switches in an occupied recovery directory. The restoration reference documents these behaviors.

Choose the recovered file you need, then compare its content, streams and permissions before putting it back into the replicated folder. That creates a new change which will replicate to other members. Keep the manifest and recovery copy while checking delivery.