DFS Replication Backlog: Check It with PowerShell and Fix It

Short answer: Run Get-DfsrBacklog -GroupName "RG01" -FolderName "RF01" -SourceComputerName "FS01" -DestinationComputerName "FS02" -Verbose to see what is waiting to replicate from FS01 to FS02; the verbose line gives the full count, the output lists at most 100 files. If the number keeps growing, check the DFS Replication event log for staging quota warnings (4202/4208), sharing violations (4302/4304), a dirty database shutdown (2213) or a server that was offline too long (4012), fix that cause, and watch the backlog fall to zero.

Applies to Windows Server 2016, 2019, 2022 and 2025 (DFSR PowerShell module)

Commands checked against the official documentation (linked below) on 7 October 2026; not yet run on our lab servers.

What the DFS Replication backlog means

DFS Replication (DFSR) keeps a version vector for every member. The backlog between two members is the list of updates the sending (upstream) member has that the receiving (downstream) member has not installed yet. It is directional: the backlog from FS01 to FS02 is not the same as from FS02 to FS01, so always check both directions.

A small backlog that rises during the working day and drains overnight is normal. A backlog that only grows, or that stays at the same number for hours, means replication is blocked or throttled. The fix depends on why, which is what the rest of this guide works through.

This applies to file-share replication groups and to SYSVOL on domain controllers that use DFSR. If you are still setting up namespaces and replication groups, start with our DFS Namespaces and Replication setup guide.

Check the backlog with Get-DfsrBacklog

The DFSR PowerShell module ships with the DFS Replication role and with the DFS Management tools (RSAT). First list the exact group and folder names, because the backlog cmdlet needs them:

Get-DfsReplicatedFolder | Select-Object GroupName, FolderName
Get-DfsrConnection | Select-Object GroupName, SourceComputerName, DestinationComputerName, Enabled

Then ask for the backlog in one direction. The cmdlet returns at most 100 files; add -Verbose to get the full count in the verbose stream:

Get-DfsrBacklog -GroupName "Data" -FolderName "Shared" `
  -SourceComputerName "FS01" -DestinationComputerName "FS02" -Verbose |
  Format-Table FullPathName, UpdateTime

To put just the number into a variable (useful in monitoring scripts), Microsoft documents this pattern, which redirects the verbose stream and splits the message:

$count = (Get-DfsrBacklog -GroupName "Data" -FolderName "Shared" `
  -SourceComputerName "FS01" -DestinationComputerName "FS02" -Verbose 4>&1).Message.Split(':')[2]
$count

For SYSVOL on domain controllers the replication group is Domain System Volume and the replicated folder is SYSVOL Share:

Get-DfsrBacklog -GroupName "Domain System Volume" -FolderName "SYSVOL Share" `
  -SourceComputerName "DC01" -DestinationComputerName "DC02" -Verbose

Run the same command with source and destination swapped. If only one direction is backlogged, the problem is usually on the receiving member (staging, disk, locked files, its database) or on that one connection.

dfsrdiag backlog (older tool)

Older guides use dfsrdiag backlog. It still exists on Windows Server 2016 to 2025 as part of the DFS Management tools, and the syntax is:

dfsrdiag backlog /rgname:"Data" /rfname:"Shared" /sendingmember:FS01 /receivingmember:FS02

Microsoft has not published a removal notice for dfsrdiag.exe, but current documentation leads with the DFSR PowerShell module, and the PowerShell cmdlets return objects you can filter and log. We use Get-DfsrBacklog in this guide and treat dfsrdiag as a fallback for old scripts.

See what is replicating right now with Get-DfsrState

Get-DfsrState shows the files a member is currently replicating or has queued, inbound and outbound. It is the quickest way to tell “slow but moving” from “stuck”:

Get-DfsrState -ComputerName "FS02" |
  Format-Table FileName, UpdateState, Inbound, SourceComputerName -AutoSize -Wrap

Run it a few times a minute apart. If the same files sit in Scheduled or Downloading state while the backlog does not move, look at those files first: they are often very large, locked by an application, or blocked by a file screen.

Also check the state of each replicated folder through the DFSR WMI provider. Use CIM from PowerShell, because the WMIC tool is deprecated and is no longer included in new Windows installs:

Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo |
  Select-Object ReplicationGroupName, ReplicatedFolderName, State

State values: 0 Uninitialized, 1 Initialized, 2 Initial Sync, 3 Auto Recovery, 4 Normal, 5 In Error. Anything other than 4 for a long time needs attention.

Generate a DFSR health report

Write-DfsrHealthReport produces the same HTML health report as DFS Management, including backlog counts per member, errors and warnings. Run it from a server or admin workstation with the DFS Management tools:

New-Item -ItemType Directory -Path "C:\Reports" -Force | Out-Null
Write-DfsrHealthReport -GroupName "Data" -ReferenceComputerName "FS01" `
  -MemberComputerName "FS02","FS03" -Path "C:\Reports"

Add -CountFiles if you want file counts per replicated folder, but expect the report to take much longer on large shares. Open the Health-<group>-<date>.html file and read the errors section for each member before changing anything.

Common causes of a growing backlog (and the fix for each)

Pull the relevant DFS Replication events from each member first. This one query covers the events discussed below:

Get-WinEvent -ComputerName "FS02" -FilterHashtable @{
  LogName = 'DFS Replication'; Id = 2213, 4012, 4202, 4204, 4206, 4208, 4302, 4304
} -MaxEvents 50 | Format-Table TimeCreated, Id, Message -Wrap

Staging quota too small (events 4202, 4206, 4208)

DFSR builds compressed copies of files in the staging folder before sending them. The default staging quota is 4,096 MB per replicated folder. Event 4202 (above high watermark) followed by 4204 (cleanup done) now and then is normal; many 4202s a day, or 4206/4208 (cleanup failed, quota still exceeded), means staging is too small and replication slows to a crawl.

Microsoft’s rule of thumb: the staging quota should be at least as large as the 32 largest files in the replicated folder. Measure it on the member that holds the data:

$big32 = Get-ChildItem "D:\Shares\Shared" -Recurse -File |
  Sort-Object Length -Descending | Select-Object -First 32 |
  Measure-Object -Property Length -Sum
[math]::Ceiling($big32.Sum / 1MB)

Then raise the quota on each member (value in MB). Check free space on the staging volume first. No service restart is needed:

Get-DfsrMembership -GroupName "Data" -ComputerName "FS02" |
  Select-Object FolderName, StagingPath, StagingPathQuotaInMB
Set-DfsrMembership -GroupName "Data" -FolderName "Shared" -ComputerName "FS01","FS02" `
  -StagingPathQuotaInMB 32768 -Force

Sharing violations (events 4302, 4304)

DFSR cannot replicate a file that an application holds open with an exclusive lock. Event 4302 means it has been repeatedly prevented from replicating a file because of sharing violations. Typical culprits are database files, PST files, files kept open by line-of-business applications, and antivirus scans.

• Find the file path in the 4302 event and see who has it open: Get-SmbOpenFile | Where-Object Path -like "*filename*" on the server.
• Do not replicate live databases or PST files with DFSR. Move them out of the replicated folder or add them to the file filter.
• Exclude the replicated folders and the DfsrPrivate folder from on-access antivirus scanning, following your antivirus vendor’s guidance for DFSR.

Dirty database shutdown (event 2213)

Event 2213 means the DFSR database on that volume was not shut down cleanly (power loss, crash, or the service was killed). Since Windows Server 2012, DFSR does not recover automatically: it stops replicating on that volume and waits for you. The backlog towards that member then grows forever.

Back up the replicated folders on this member before you resume replication. Microsoft warns that resuming without a backup can lose data through unexpected conflict resolution during recovery.

The event text contains the volume GUID and a wmic command to resume. Because WMIC is deprecated, use the same WMI method through CIM, replacing the GUID with the one from your event:

Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrVolumeConfig `
  -Filter "VolumeGuid='E18D8280-2379-11E2-A5A0-806E6F6E6963'" |
  Invoke-CimMethod -MethodName ResumeReplication

A ReturnValue of 0 means the call worked. DFSR then rebuilds the database and logs recovery events; on a large volume this can take hours.

Member offline too long (event 4012, content freshness)

Event 4012 says the DFS Replication service stopped replication on a folder because the server has been disconnected from its partners for longer than MaxOfflineTimeInDays (60 days by default). DFSR treats that member’s content as stale on purpose, so it cannot push old files or resurrect deleted ones.

Check the current value:

Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrMachineConfig |
  Select-Object MaxOfflineTimeInDays

The safe fix is to resync the stale member from a healthy partner rather than let it replicate its old data out:

• For SYSVOL: run a non-authoritative (D2) sync of that domain controller as described in Microsoft’s “Force synchronization for DFSR-replicated SYSVOL” article (set msDFSR-Enabled to FALSE, wait for event 4114, set it back to TRUE, wait for events 4614 and 4604).
• For file shares: back up the member’s data, remove the member from the replication group, let AD replicate, then add it back so it does an initial sync from a healthy member.
• Raising MaxOfflineTimeInDays above the number of days offline also lets replication resume, but the stale content then counts as current. Only do that if you are sure nothing on that server is older than on its partners.

Other causes worth ruling out

• Schedule or bandwidth throttling on the connection: check the group schedule in DFS Management.
• File Server Resource Manager file screens blocking file types that DFSR tries to install (access denied in the DFSR debug logs under %windir%\debug).
• Disk full on the staging or content volume of the receiving member.
• AD replication problems: DFSR reads its configuration from Active Directory, so fix AD replication errors first.

Check that it worked

1. Run Get-DfsrBacklog ... -Verbose in both directions every 10 to 15 minutes and note the count. It should fall steadily and reach zero, or near zero, outside busy hours.
2. Check DfsrReplicatedFolderInfo state is 4 (Normal) on every member.
3. Confirm no new 2213, 4012, 4206, 4208 or 4302 events appear in the DFS Replication log.
4. Run a propagation test and report: Start-DfsrPropagationTest -GroupName "Data" -FolderName "Shared" -ReferenceComputerName "FS01", wait a few minutes, then Write-DfsrPropagationReport -GroupName "Data" -FolderName "Shared" -ReferenceComputerName "FS01" -Path "C:\Reports". Every member should show the test file as arrived.
5. Generate a fresh Write-DfsrHealthReport and confirm it lists no errors for any member.

Common problems

• “Get-DfsrBacklog is not recognized”: install the DFS Management tools: Install-WindowsFeature RSAT-DFS-Mgmt-Con on a server, or the RSAT DFS feature on Windows 11.
• Backlog count is the same for hours: look at Get-DfsrState on the receiver and at the files named in 4302 events; a single huge or locked file can hold the queue.
• Backlog of hundreds of thousands after a restore: restoring files changes their metadata, so DFSR treats them as new. Let it finish, and pre-seed new members with backup or robocopy instead of letting DFSR copy everything.
• WMI errors from the cmdlets: the DFSR service must be running on the target and WMI/RPC must be reachable through the firewall from where you run the command.
• SYSVOL backlog causes Group Policy errors: clients reading a DC that has not received a GPO yet log event 1058; see our event ID 1058 guide.

If the backlog is on SYSVOL or a production share and you would rather not touch the database yourself, our Get it fixed service can take a look.

Official documentation: Get-DfsrBacklog · Write-DfsrHealthReport · DFSR event ID 2213 · Minimum DFSR staging area

Related: DFS Namespaces and Replication: Reliable File Server Setup · AD Replication Error 1722 and 8453: Fixes · AD Health Check Report: dcdiag and repadmin PowerShell Script · Group Policy Not Applying: 12 Checks with gpresult and Events · NTFS Permissions and Share Permissions: 7 Secure File Server Rules

See also: Event ID 4012 DFSR: Replicated Folder Offline Too Long (Fix) · Event ID 1058: Group Policy Failed to Read gpt.ini (Fix)

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

Windows Server 2016, 2019, 2022 and 2025 (DFSR PowerShell module)

Last full review

7 Oct 2026

Next review

5 Apr 2027

Sources

learn.microsoft.com/en-us/powershell/module/dfsr/get-dfsrbacklog?view=windowsserver2025-ps
learn.microsoft.com/en-us/powershell/module/dfsr/write-dfsrhealthreport?view=windowsserver2025-ps
learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dfsr-event-id-2213
learn.microsoft.com/en-us/windows-server/troubleshoot/how-to-determine-the-minimum-staging-area-dfsr-needs-for-a-replicated-folder