DFS Replication problems typically appear as files that stop synchronizing, a backlog that does not clear, replication partner errors, or SYSVOL and Group Policy inconsistencies.
This guide walks through the first checks you should perform to determine the DFS Replication status, identify where replication may be failing, and gather useful diagnostic evidence before making recovery changes.
Start with the current replication state and backlog, then verify RPC connectivity, replication group configuration, DFS Replication event logs, health reports, and staging.
Already completed the basic DFSR checks?
If replication is still delayed or stopped after checking state, backlog, connectivity and Event Logs, the issue may require deeper investigation.
Tell us you’re contacting us about a DFSR issue and include any relevant Event ID.
1. Checking DFS Replication Status(Get-DfsrState, Get-DfsrBacklog, Dfsdiag)
Start by checking the current replication activity and the backlog between DFSR partners.
Get-DfsrState shows inbound and outbound files that are currently replicating or immediately queued for replication. Get-DfsrBacklog shows pending updates that have not yet replicated from a source member to a destination member.
A backlog does not automatically mean DFS Replication is broken. A backlog represents replication latency and may be expected depending on the rate of file changes, network conditions, replication schedules and environment size.
1 | Get-DfsrState -ComputerName "ServerName" | Format-Table FileName,UpdateState,Inbound,Source* -Auto -Wrap |
How to interpret the result:
Active or queued files confirm that DFSR is processing updates at that moment. No output does not necessarily mean replication is unhealthy — there may simply be no files currently replicating or queued.
1 2 3 4 5 6 | Get-DfsrBacklog ` -GroupName "ReplicationGroupName" ` -FolderName "ReplicatedFolderName" ` -SourceComputerName "SourceServer" ` -DestinationComputerName "DestinationServer" | Select-Object FileName, FullPathName |
Replace the replication group, replicated folder and server names with the values from your environment. A small backlog that clears can be normal. A backlog that remains unchanged or continues to grow — especially when combined with repeated DFSR errors or user impact — deserves further investigation.
Optional: Check DFS Namespace Referrals:
1 | dfsdiag /testreferral /DFSPath:\\YourDomain.local\YourNamespace |
Note: A successful DFS Namespace referral test does not confirm that DFS Replication itself is healthy. DFS Namespaces (DFSN) and DFS Replication (DFSR) are related but separate components.
2. Verifying Network Connectivity
DFS Replication relies on RPC communication between replication partners. Start by verifying basic name resolution and connectivity, then test the RPC Endpoint Mapper on TCP 135.:
1 | Test-NetConnection -ComputerName "DestinationServer" -Port 135 |
DFSR initially contacts the RPC Endpoint Mapper on TCP 135 and normally continues communication over dynamically allocated RPC ports unless a static DFSR RPC port has been configured.
If DFS Namespace or SMB access is also part of the problem, test TCP 445 separately:
1 | Test-NetConnection -computername <ip, hostname or FQDN of DestinationServer> -Port 135 |
1 | Test-NetConnection -ComputerName "DestinationServer" -Port 445 |
Legacy environments: TCP 139 is associated with legacy NetBIOS-based SMB communication. TCP 5722 applies to older Windows Server 2008/2008 R2 domain controller scenarios and is not used for DFSR on modern Windows Server domain controllers.
3. Reviewing DFS Replication Configuration
Next, confirm that the expected replication groups, members and connections exist and are enabled. Start by listing the configured DFS Replication groups:
1 | Get-DfsReplicationGroup |
Review membership information:
1 | Get-DfsrMembership -GroupName * -ComputerName * |
1 | Get-DfsrConnection |
Check that:
- the expected servers are members of the replication group;
- the replicated folders are enabled;
- the expected partner connections exist;
- connections have not been disabled intentionally or accidentally.
At this stage, focus on identifying an unexpected configuration. Avoid changing replication membership or topology until you understand which member contains the correct data.
4. Inspecting Event Logs
The DFS Replication event log is often the fastest way to determine whether you are dealing with normal replication latency, a communication problem, or a DFSR recovery condition.
On both replication partners, open:
Event Viewer → Applications and Services Logs → DFS Replication
Look for repeated warnings or errors around the time the replication problem started. Pay particular attention to the following events..
DFSR Event ID 2213 — Replication Paused After Recovery
Event 2213 can indicate that DFS Replication has paused after an unexpected shutdown or database recovery condition.
Do not assume that a service restart alone will resolve the condition. Check whether DFSR subsequently recovered and whether the replicated folder returned to a normal state before taking corrective action.
DFSR Event ID 4012 — Content Freshness Protection
Event 4012 means DFS Replication has stopped replication for an affected folder because it has exceeded the configured offline period and Content Freshness protection has been triggered.
This is not a normal backlog condition. Before attempting recovery, establish which replication member contains the correct and current copy of the data.
DFSR Event ID 5002 — Partner Communication Error
Event 5002 indicates that DFS Replication encountered an error communicating with a replication partner.
A single historical event may have been transient. Repeated Event 5002 entries together with a persistent backlog or replication failure are a stronger indication that partner communication needs investigation.
Seeing 2213, 4012, 5002 or repeated DFSR errors?
If this is a production environment and replication is still delayed or stopped, avoid forcing recovery until the current replication state and correct source of data are understood.
Tell us what is affected, the Event ID you are seeing and the current business impact. Tell us you’re contacting us about a DFSR issue and include any relevant Event ID.
5. Check the Replicated Folder and Recent Configuration Changes
If the problem affects only a specific replicated folder, verify the underlying folder configuration and consider whether filesystem, security, storage or DFSR configuration changes were made shortly before replication stopped.
At this stage, document unexpected configuration differences rather than changing permissions or replication settings blindly.
6. Generating Health Reports (Write-DfsrHealthReport)
Windows Server includes a native DFSR health report that can provide additional information about replication state, efficiency and potential issues across members of a replication group.
Generate the report using:
1 2 3 4 | Write-DfsrHealthReport ` -GroupName "REPLICATION_GROUP_NAME" ` -ReferenceComputerName "SERVER_NAME" ` -Verbose |
The command generates an HTML health report together with an XML file. Review the report alongside the DFS Replication Event Log — especially when the basic state and backlog checks do not explain why replication is failing.
Health report generated but the cause still isn’t clear?
An engineer can review the symptoms and help determine the next diagnostic step. Tell us you’re contacting us about a DFSR issue and include any relevant Event ID.
7. Check the DFSR Staging Area and Quota
An undersized staging area can significantly reduce DFSR performance and, in some environments, contribute to replication delays.
Microsoft recommends that the staging quota is at least large enough to accommodate the 32 largest files in the replicated folder.
1 2 3 4 5 6 | $big32 = Get-ChildItem "D:\YourReplicatedFolder" -Recurse | Sort-Object Length -Descending | Select-Object -First 32 | Measure-Object -Property Length -Sum $big32.Sum / 1GB |
Replace D:\YourReplicatedFolder with the actual path of the replicated folder.
This calculation helps estimate the minimum staging requirement. A properly sized staging area does not, however, prove that the rest of the replication path is healthy.
8. Before Restarting the DFS Replication Service
Restarting the DFS Replication service may be appropriate in some situations, but it should not replace identifying why replication stopped.
Before restarting DFSR, capture:
- the current
Get-DfsrStateoutput; - the backlog status;
- recent DFS Replication Event IDs;
- the affected replication group and folder.
Recovery-related conditions such as Event 2213 or Content Freshness protection require investigation of the DFSR state rather than relying on a simple service restart.
1 | Restart-Service -Name DFSR |
Do not use a restart as a substitute for the recovery procedure indicated by the DFSR Event Log.
DFSR Still Not Replicating?
If replication is still delayed, stopped, or showing repeated DFSR errors after the checks above, the issue may require deeper investigation.
IT-Emergencies can review the symptoms, identify the likely failure area, and determine the appropriate next diagnostic or recovery step.
Send us the symptoms and any relevant Event ID below.
Conclusion
DFS Replication troubleshooting should start by establishing the current state, measuring backlog, verifying RPC connectivity, reviewing replication configuration and correlating the results with the DFS Replication Event Log.
A backlog alone does not prove that DFSR has failed, and not every replication problem should be approached with a service restart. When repeated errors, SYSVOL problems or recovery conditions are present, identify the failure state before making corrective changes.
If the checks in this guide do not identify the cause and replication is still affecting a production environment, request a DFSR Incident Review and we can help determine the next step.
FAQ
Use Get-DfsrState to view current inbound and outbound DFSR activity and Get-DfsrBacklog to identify pending updates between replication partners. For a broader diagnostic view, review the DFS Replication Event Log and generate a Write-DfsrHealthReport.
The DFSR backlog contains updates that have not yet replicated from the source member to the destination member. A backlog represents replication latency and is not automatically a failure. A backlog that does not clear or continues to grow, particularly when combined with DFSR errors, should be investigated.
Common causes include RPC or partner connectivity problems, incorrect or disabled DFSR configuration, replicated-folder recovery states, Content Freshness protection, staging constraints and other conditions recorded in the DFS Replication Event Log. Start by correlating the DFSR state, backlog and recent Event IDs rather than changing the configuration immediately.
No. A backlog means that updates are waiting to replicate. Depending on the environment and rate of change, some backlog can be normal. The more important questions are whether the backlog is clearing and whether DFSR is reporting repeated warnings or errors.
Suspect a stalled replication condition when the backlog remains unchanged or grows over time, files remain inconsistent between members, DFSR repeatedly logs errors, or a replicated folder is no longer progressing normally. Use the Event Log together with Get-DfsrState and Get-DfsrBacklog rather than relying on one indicator alone.
Event 2213 indicates a DFS Replication recovery condition in which replication may be paused after an unexpected shutdown. Confirm whether DFSR subsequently recovered before making additional changes.
Event 4012 indicates that Content Freshness protection has stopped replication for an affected replicated folder because it has remained offline beyond the configured threshold. Determine which copy of the replicated data is current before attempting recovery.
Event 5002 means DFS Replication encountered an error communicating with a replication partner. Review the associated error, partner availability and RPC connectivity, especially when the event repeats.
On a domain controller, review the DFS Replication Event Log and confirm that the SYSVOL Share replicated folder is in a normal state. Missing SYSVOL or NETLOGON shares, initialization events that never complete, or Content Freshness errors require additional investigation.
A restart can be appropriate in some situations, but it does not resolve every DFSR failure or recovery state. Capture the current state and recent Event IDs first, particularly when DFSR reports recovery-related errors.
Yes. IT-Emergencies can remotely investigate DFSR incidents, including persistent backlog, replication partner errors, SYSVOL problems and replication states that remain unhealthy after the basic checks above.
Request a DFSR Incident Review →
About Alexios Pappas – Alexios Pappas has worked internally in IT Departments in multi-role technical and management positions for many years. In parallel, Alexios led IT multinational projects across several countries globally as an IT Freelancer. He repeatedly got Top Rated Plus distinction and also 100% satisfaction rate for over one and a half-decade, resulting from the Client’s feedback. Since 2015 he has been focused on informing and helping Businesses that want to improve and excel in their IT Section.
© 2026 IT-Emergencies. All rights reserved.
Unauthorized copying, reproduction, or republication of this article is prohibited, except as permitted by applicable law or with prior written permission.
Original source: How to Check DFS Replication Status (DFSR Troubleshooting)
