Windows · DFS Replication

DFS Replication — Staging, Conflict Resolution, and Quotas

A closer look at what actually happens inside DFS Replication between a file changing and it landing on every other member — the staging folder, the conflict resolution rule, and the quotas that decide when either one starts throwing warnings.

By K Shankar R Karanth Windows Active Directory Deep Dive
Quick idea: Every file DFS Replication sends or receives passes through a staging folder first, and every file that loses a simultaneous edit gets preserved in a Conflict and Deleted folder — both are quota-governed caches, and undersizing either one is the most common cause of DFSR looking “stuck”.
Staging Folder

A local cache of files queued to send or currently being received — not a second copy of the whole replicated folder.

Conflict and Deleted

Where the “losing” version of a simultaneously edited file, or a deleted file, gets preserved instead of destroyed.

Quotas

Soft limits, not hard caps — DFSR cleans up the oldest files once a folder crosses its configured size.

What Is the Staging Folder?

DFS Replication never sends a file straight from its location in the replicated folder to a partner server. It first stages the file — copies it into a hidden DfsrPrivate\Staging folder under the replicated folder’s local path — and replicates from there. The same happens in reverse: an inbound file lands in staging before DFSR moves it into place.

Think of the staging folder as a loading dock, not a warehouse. Files pass through it on their way in or out; they don’t live there permanently, and the dock only needs to be big enough to hold what’s actively moving through it, not everything the warehouse contains.

Staging exists because DFSR needs a stable copy of a file to compute Remote Differential Compression (RDC) deltas against and to transfer without interference from whatever is still writing to the live file. Files are staged on the sending member when a receiving member requests them — skipped only if the file is 64 KB or smaller (256 KB or smaller with RDC disabled) — and staged on the receiving member as they arrive if under 64 KB, a threshold configurable between 16 KB and 1 MB.

Important: The staging quota is a soft limit, not a hard reservation. DFSR only consumes as much disk space as it currently needs; when usage crosses the configured quota, it deletes the oldest staged files to bring usage back down rather than refusing new files outright.

Why Active Directory Cares About DFSR

DFS Replication is not just a file-server convenience feature. Starting with Windows Server version 1709, a server can no longer be promoted as a domain controller into a domain that still uses the File Replication Service (FRS) to replicate SYSVOL — the promotion fails outright, with an error stating the domain must migrate to DFS Replication first.

That makes DFSR part of the authentication path, not just file sharing: SYSVOL carries Group Policy Objects and logon scripts to every domain controller, and a staging or Conflict and Deleted folder that’s badly undersized on a DC can delay GPOs reaching a site exactly the way a broken replication topology can.

In Active Directory: Replication groups, their membership, and their schedules are stored as objects in Active Directory Domain Services — the same directory backing every other AD-integrated service. Changes to a membership’s quota, described below, propagate the same way any other AD change does: replicate to a domain controller, then wait for the member’s next poll of its closest DC.

How DFSR Resolves Conflicts

A conflict happens when two members modify the same file before either change has replicated to the other. DFS Replication resolves it with one rule: the version saved most recently wins. The losing version is moved — not deleted — into the DfsrPrivate\ConflictAndDeleted folder on whichever member detects and resolves the conflict.

The same folder catches a related case: two members creating a folder with the same name at the same time. The old File Replication Service handled this by renaming one of the two folders in place — the “morphed folder name” problem, where a folder unexpectedly turns up with a suffix like _NTFRS_000add30 appended. DFSR avoids that specific failure mode: instead of renaming a folder in place, it moves the losing folder into Conflict and Deleted and leaves the winning folder under its original name.

File Conflict

Most recently saved version wins; the older version moves to Conflict and Deleted.

Name Conflict

One folder keeps its name; the other is moved into Conflict and Deleted instead of renamed in place, avoiding the old morphed-folder-name problem.

Deletions

By default, a file deleted on one member is preserved in Conflict and Deleted on every other member, not silently removed.

Every item DFSR preserves this way is logged in ConflictAndDeletedManifest.xml (for conflicts and deletions) or PreExistingManifest.xml (for files found unexpectedly during initial replication), both under the replicated folder’s DfsrPrivate folder. Files in Conflict and Deleted are renamed and are only accessible to the local Administrators group, but their ACLs are preserved, and the manifest records each file’s original name and path.

Practical rule: DFSR never merges conflicting file content. If two people genuinely need to edit the same file from different servers at the same time, DFSR is the wrong tool — it preserves the loser, it doesn’t reconcile the two versions.

Recovering a preserved file uses two PowerShell cmdlets: Get-DfsrPreservedFiles reads a manifest and lists what it contains, and Restore-DfsrPreservedFiles moves the files back out, either to their original location or to a new path. 

# List everything currently preserved in Conflict and Deleted for a replicated folder
Get-DfsrPreservedFiles -Path "D:\RF01\DfsrPrivate\ConflictAndDeletedManifest.xml"

# Restore those files to their original location, keeping every preserved version
Restore-DfsrPreservedFiles -Path "D:\RF01\DfsrPrivate\ConflictAndDeletedManifest.xml" -RestoreToOrigin -RestoreAllVersions

Configuring the Staging and Conflict and Deleted Quotas

Both quotas are set per replicated folder, per member — a member with three replicated folders has three independent staging folders and three independent Conflict and Deleted folders, each with its own quota. In DFS Management, under the Replication node, select the replication group, open the Memberships tab, right-click the replicated folder on the member to change, and choose Properties: the Staging tab holds the staging quota and path, the Advanced tab holds the Conflict and Deleted quota.

The PowerShell equivalent, Set-DfsrMembership (available since Windows Server 2012 R2), sets both in one call: 

# View current quotas and paths for a membership
Get-DfsrMembership -GroupName "RG01" -ComputerName "SRV01" |
    Select-Object ComputerName, FolderName, StagingPathQuotaInMB, ConflictAndDeletedQuotaInMB

# Raise the staging quota to 32 GB and the Conflict and Deleted quota to 4 GB
Set-DfsrMembership -GroupName "RG01" -FolderName "RF01" -ComputerName "SRV01" `
    -StagingPathQuotaInMB 32768 -ConflictAndDeletedQuotaInMB 4096
Setting Default Notes
Staging folder quota4,096 MBPer replicated folder, per member. Cleanup starts at 90% of quota, stops at 60%.
Conflict and Deleted quota660 MBSame per-folder, per-member scope. Same 90% / 60% watermark behaviour.
Key point: The 90% (start cleanup) and 60% (stop cleanup) watermark percentages are themselves configurable, via the Set-DfsrServiceConfiguration cmdlet, but the defaults are reasonable for most environments and rarely need touching.

Sizing the Staging Quota

The staging quota needs to be at least as large as the 32 largest files in the replicated folder — 16 largest for a read-only replicated folder. Below that minimum, DFSR can end up re-staging the same large files repeatedly to fit within the quota, which costs CPU and disk I/O and can stall replication rather than merely slow it. Initial replication is the worst case, since every existing file in the folder needs staging at least once. 

# Calculate the minimum staging quota, in GB, for a replicated folder
# (use 16 instead of 32 for a read-only replicated folder)
(Get-ChildItem "D:\RF01" -Recurse -Force |
    Sort-Object Length -Descending |
    Select-Object -First 32 |
    Measure-Object -Property Length -Sum).Sum / 1GB
Practical rule: Set the staging quota well above this minimum where disk space allows — as close to the size of the whole replicated folder as is practical. A generous staging quota also improves RDC and cross-file RDC performance, since more of what other members might request is already sitting in staging.

Diagnosing Replication and Backlog

A backlog — files that haven’t replicated from one member to another yet — is not automatically a problem; it reflects normal latency under a schedule or a burst of changes. It’s worth checking whenever staging events suggest a folder is under pressure, or before assuming a change simply “didn’t replicate”. 

# Count and list unreplicated changes from SRV02 (source) to SRV01 (destination)
# for a specific replication group and replicated folder
Get-DfsrBacklog -GroupName "RG01" -FolderName "RF01" -SourceComputerName "SRV02" -DestinationComputerName "SRV01" -Verbose

# Same check from the older dfsrdiag.exe utility, useful when the DFSR PowerShell
# module isn't available (e.g. checking SYSVOL from a script targeting older DCs)
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC01 /rmem:DC02

# Confirm the DFS Replication role is actually installed before troubleshooting further
Get-WindowsFeature FS-DFS-Replication

Staging Event Cheat Sheet

These events are all logged to the DFS Replication event log and describe the same underlying condition at different severities — most environments will see 4202 and 4204 regularly without anything being wrong.

Event ID Severity Meaning
4202WarningStaging space is above the high watermark; DFSR is deleting the oldest staged files. Normal under regular load.
4204InformationalCleanup from a 4202 event finished successfully; staging space is back below the watermark.
4206WarningCleanup failed to free enough space. Large files may fail to replicate. DFSR retries automatically.
4208WarningStaging usage is still above quota after cleanup ran. Abnormal — the quota is genuinely too small for current activity.
4212ErrorThe staging path itself is invalid or inaccessible; the replicated folder cannot replicate at all.
Practical note: One 4202 event per replicated folder per day is a reasonable ceiling outside of initial replication. Seeing 4208 more than occasionally is the actionable signal — increase that folder’s staging quota by roughly 20 percent and reassess.

Staging and Conflict Issues

Symptom Likely Cause Fix
Replication of large files is slow or repeatedly stalls Staging quota is below the 32-largest-files minimum, forcing DFSR to re-stage the same files. Calculate the true minimum with the sizing script above, then raise it well above that floor with Set-DfsrMembership -StagingPathQuotaInMB.
Event 4208 recurring on the same replicated folder Staging usage is exceeding quota even after automatic cleanup — sustained activity outpacing the configured size. Increase the staging quota roughly 20 percent and monitor; repeat if 4208 keeps recurring.
Event 4212 — staging path invalid or inaccessible The staging folder’s disk was removed, the path was deleted outside of DFSR, or permissions were changed on it. Confirm the path in Get-DfsrMembership‘s StagingPath property still exists and is reachable, and restore it or reset the path via Set-DfsrMembership -StagingPath.
An expected file is missing after two servers were edited independently DFSR resolved a conflict — the file now sitting in Conflict and Deleted lost because it wasn’t the most recently saved version. Use Get-DfsrPreservedFiles against that folder’s ConflictAndDeletedManifest.xml to find it, then Restore-DfsrPreservedFiles to bring it back.
Domain controller promotion fails, citing FRS The target domain is still using the File Replication Service for SYSVOL, which newer Windows Server versions cannot join. Migrate SYSVOL replication from FRS to DFSR with dfsrmig before promoting the new domain controller.

Final Thoughts

The staging folder and the Conflict and Deleted folder both look like implementation details until one of them runs out of room, and then they become the entire explanation for why replication looks broken. Neither is a bug to work around — they’re DFSR doing exactly what it’s designed to do, just against a quota that was sized for a smaller or calmer environment than the one it’s now running in.

For SYSVOL specifically, this isn’t optional plumbing. Every domain controller depends on it, and the default 4,096 MB and 660 MB quotas that work fine for a small file share can be exactly wrong once large GPO baselines or a burst of concurrent edits pass through.

Key takeaway: Size the staging quota against the 32 largest files a replicated folder actually holds, watch for event 4208 rather than 4202, and remember that a “missing” file after concurrent edits is very likely sitting in Conflict and Deleted, recoverable with Get-DfsrPreservedFiles and Restore-DfsrPreservedFiles.
Next in this series

The existing DFS Namespaces and DFS Replication post covers how namespaces and replication groups fit together at a higher level — worth reading first if replication groups and topology aren’t already familiar.