Helpdesk: "Branch staff say the Projects share on FS02 hasn't shown a single new file from head office since Tuesday, and DC02 is still handing out last month's drive-mapping GPO. A forum thread says to stop DFSR, delete the database under System Volume Information, and run an authoritative SYSVOL restore from the PDC. Can we just do that tonight?"
Don't delete anything yet. "DFS Replication not working" is several different stops that look the same from a file share. Microsoft's SYSVOL troubleshooting article says reinitializing replication "is unnecessary in most cases, and it may cause data loss if done incorrectly," and that deleting the DFS Replication database "shouldn't be required and is discouraged" because "It causes DFS Replication to consider all local data on the server to be nonauthoritative." An authoritative restore on the PDC rewrites SYSVOL on every other domain controller to fix what may be one paused volume. Work through it as a chain: the replicated folder, the members, the direction, and the event IDs on the ticket → each member's replicated folder state and membership (enabled, read-only, primary) → the connections in both directions and the backlog each way → initial replication: has the new member finished, and is there a primary? → a stop condition: dirty shutdown (2213), content freshness (4012), a database failure, or a restored snapshot → files that can't move: filters, locks, the staging quota, conflicts → SYSVOL's own rules: shares, events 4614 and 4604, the FRS migration state, msDFSR-Enabled → the network, RPC, AD polling, and clocks underneath. The DfsrReplicatedFolderInfo WMI class, the DFSR cmdlets (Get-DfsrMembership, Get-DfsrConnection, Get-DfsrBacklog), the DFS Replication event log, dfsrmig, and Get-ADObject are the sources for that chain. Delete the database and a disabled connection or a 4012 on the partner is still there tomorrow.
If the ticket started as a GPO that won't apply and nobody has proven it's SYSVOL yet, read Group Policy Not Applying first. If someone suggests rolling a file server or DC back to a Hyper-V checkpoint, read Hyper-V Checkpoint Operation Failed and the snapshot row in Step 5. Microsoft doesn't support restoring snapshots of DFSR members. This post covers "DFS Replication isn't working: files stop arriving, it works in one direction only, initial replication never starts or finishes, events 2213 or 4012 show up, or SYSVOL won't replicate between domain controllers, and you need a read-first path through state, membership, connections, backlog, initial sync, stop conditions, staging, SYSVOL, and the network before you delete the database, re-add members, raise MaxOfflineTimeInDays, or run an authoritative restore."
TL;DR
- Read the folder state first. Microsoft's WMI values: 0 = Uninitialized, 1 = Initialized, 2 = Initial Sync, 3 = Auto Recovery, 4 = Normal, 5 = In Error. Anything but 4 tells you which step to read.
- A backlog isn't automatically a fault. Microsoft: a backlog "is not necessarily an indication of problems. A backlog indicates latency." Compare both directions and watch the trend.
- A member still in initial sync sends nothing. Microsoft: "no outbound replication occurs from a member on which the replicated folder is in the initial-sync state." That's one common "works in one direction" cause.
-
Event 2213 means replication paused after a dirty shutdown. Microsoft's order: "Back up the files in all replicated folders on the volume," then run
ResumeReplicationfor that volume. -
Event 4012 is content freshness. Microsoft: it's enabled by default on Windows Server 2012 and later domain controllers with
MaxOfflineTimeInDays= 60, and the fix is a non-authoritative resync of that member. - Authoritative SYSVOL is for "every DC is broken." Microsoft: "If only repairing one DC, make it non-authoritative and don't touch other servers."
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Group, folder, members, direction, dates, and event IDs written down | "DFS is broken" with no server names |
| 2. State and membership | State 4 on every member; membership enabled; read-only and primary as designed | State 2, 3, or 5; a disabled membership; an unexpected read-only member |
| 3. Connections and backlog | Connections enabled both ways; backlog draining | Backlog growing in one direction; a disabled connection |
| 4. Initial replication | New member logged 4104 (SYSVOL: 4604) | 4102 with no 4104; 4614 with no 4604 |
| 5. Stop conditions | No 2213, 4012, or 2104 waiting on you | Replication stopped on a volume or a folder |
| 6. Files that can't move | Files not filtered, not locked, staging big enough | Some files never arrive; 4202 then 4208; 4302 or 4304 |
| 7. SYSVOL | SYSVOL and NETLOGON shared; migration complete; state 4 on every DC | Shares missing; a DC stuck after 4614 |
| 8. Network, RPC, AD | Partners reach each other over RPC; the DFSR configuration replicated in AD and polled | Backlog grows both ways; DFS Management changes never land |
| 9. Change | Only after Steps 1-8 agree: one layer, one change | Database deleted, members re-added, same stop next month |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Replication group and replicated folder (or SYSVOL) | SYSVOL has its own recovery rules (Step 7). DFS Management can't edit it |
| Which members, and which direction fails | "FS01 to FS02 works, FS02 to FS01 doesn't" points at one member's state or one connection |
| When it stopped | Match it to an outage, a hard reboot, a restore, a new member, a firewall change |
| How long the member was disconnected | Microsoft's content freshness limit is days offline, 60 by default (Step 5) |
| What changed? | Power loss, a VM restored from a checkpoint, a server rebuilt, a member added, staging moved, a schedule closed |
| Event IDs in the DFS Replication log | 2213, 4012, 4102, 4104, 4202, 4208, 4614, 4604 each point at a different step |
Then branch on what you see:
| What you see | What it usually means | Start at |
|---|---|---|
| New files never reach one member; the other direction works | That member, or the connection into it, stopped (our reading) | Steps 2, 3, 5 |
| A member's changes never leave it | It's still in initial sync, read-only, or its outbound connection is disabled | Steps 2, 3, 4 |
| New member never fills, state 2 for days | Initial replication waiting on an upstream partner or a primary | Step 4 |
| 2213 after a power cut or crash | Replication paused after a dirty shutdown (Microsoft) | Step 5 |
| 4012 and state 5 | Content freshness: offline longer than MaxOfflineTimeInDays (Microsoft) |
Step 5 |
| Server restored from a VM snapshot | Unsupported for DFSR; Microsoft Support case | Step 5 |
| Most files fine, some never replicate | Filters, file locks, EFS, staging, or conflicts | Step 6 |
| SYSVOL or NETLOGON share missing on a DC | The DC never finished SYSVOL initialization, or its upstream is in error (Microsoft) | Step 7 |
| Backlog grows in both directions | Service, network, RPC, or a stop on both members | Steps 5, 8 |
Step 2: Read each member's state and membership (read-only)
Microsoft's SYSVOL article queries the replicated folder state with wmic against the root\microsoftdfs namespace. The same class from PowerShell (our CIM form):
# Read-only. Replicated folder state on each member (DFSR's WMI provider)
Get-CimInstance -ComputerName 'FS01', 'FS02' -Namespace 'root\MicrosoftDFS' -ClassName DfsrReplicatedFolderInfo |
Select-Object PSComputerName, ReplicationGroupName, ReplicatedFolderName, MemberName, State |
Format-Table -AutoSize
State |
Microsoft's name | How to read it |
|---|---|---|
| 0 | Uninitialized | The folder isn't set up on this member yet (our reading) |
| 1 | Initialized | Configured, not yet replicating (our reading) |
| 2 | Initial Sync | Still syncing from a partner. Microsoft: no outbound replication from this member (Step 4) |
| 3 | Auto Recovery | Recovering its database. Our reading: often a 2213 pause (Step 5) |
| 4 | Normal | Healthy at this layer |
| 5 | In Error | Microsoft's content freshness example shows 5 after a 4012 (Step 5) |
| No instance | - | Microsoft: a member "may fail to report a state value and indicate no instance(s) available" |
Then the membership and connection settings, which DFSR reads from Active Directory:
# Read-only. Membership settings for every member of the group
Get-DfsrMembership -GroupName 'Branch-Data' -ComputerName * |
Format-Table ComputerName, FolderName, Enabled, ReadOnly, PrimaryMember, StagingPathQuotaInMB, State -AutoSize
# Read-only. Every connection in the group, both directions
Get-DfsrConnection -GroupName 'Branch-Data' |
Format-Table SourceComputerName, DestinationComputerName, Enabled, State -AutoSize
# Read-only. Service status here, then service settings and the content freshness limit on each member
Get-Service -Name DFSR
Get-DfsrServiceConfiguration -ComputerName 'FS01', 'FS02' |
Format-Table ComputerName, RPCPort, DynamicRPCPort, UnexpectedAutoRecovery -AutoSize
Get-CimInstance -ComputerName 'FS01', 'FS02' -Namespace 'root\MicrosoftDFS' -ClassName DfsrMachineConfig |
Select-Object PSComputerName, MaxOfflineTimeInDays
| Finding | What Microsoft says | Next |
|---|---|---|
Enabled is False on a membership |
Disabled membership: "DFS Replication stops replicating content on this computer" | Re-enabling triggers a non-authoritative sync (Step 9) |
ReadOnly is True
|
Read-only replicated folders replicate "through a one-way connection" (Windows Server 2008 R2 and later) | Expected one-way by design. Changes made there don't go out (our reading) |
A connection's Enabled is False
|
"You must enable a connection between the computers before the DFS Replication service can initiate replication." | Step 9, but read the one-way warning first |
| Only one connection in a pair | Microsoft's archived DFSR guidance: one-way connections hamper conflict resolution | Don't just add the missing connection (Step 9) |
MaxOfflineTimeInDays is 60 |
Content freshness is on. 0 means it's off (Microsoft) | Step 5 if any member was offline long |
Step 3: Connections and backlog in both directions (read-only)
Get-DfsrBacklog lists pending updates from a source to a destination. Microsoft: "The maximum number of files that this command displays is 100. The Verbose parameter displays a count of all backlogged updates." Run it both ways:
# Read-only. Backlog count FS01 -> FS02, then FS02 -> FS01 (the count is in the verbose stream)
$rg = 'Branch-Data'; $rf = 'Projects'
Get-DfsrBacklog -GroupName $rg -FolderName $rf -SourceComputerName 'FS01' -DestinationComputerName 'FS02' -Verbose 4>&1 |
Where-Object { $_ -is [System.Management.Automation.VerboseRecord] } | ForEach-Object Message
Get-DfsrBacklog -GroupName $rg -FolderName $rf -SourceComputerName 'FS02' -DestinationComputerName 'FS01' -Verbose 4>&1 |
Where-Object { $_ -is [System.Management.Automation.VerboseRecord] } | ForEach-Object Message
# Read-only. The oldest of the first 100 files waiting FS01 -> FS02
Get-DfsrBacklog -GroupName $rg -FolderName $rf -SourceComputerName 'FS01' -DestinationComputerName 'FS02' |
Sort-Object UpdateTime | Select-Object -First 20 FullPathName, UpdateTime
# Read-only. What FS02 is transferring right now, inbound and outbound
Get-DfsrState -ComputerName 'FS02' | Format-Table FileName, UpdateState, Inbound, SourceComputerName -AutoSize -Wrap
Microsoft's example verbose output reads The replicated folder has a backlog of files. Replicated folder: "RF01". Count: 2400. The VerboseRecord filter is ours. The older tool: dfsrdiag backlog /rgname:"Branch-Data" /rfname:"Projects" /smem:FS01 /rmem:FS02 (switches from Microsoft Q&A and the archived TechNet wiki).
For a whole group at once, the health report:
# Writes an HTML and an XML report to C:\Temp; nothing changes in replication
Write-DfsrHealthReport -GroupName 'Branch-Data' -ReferenceComputerName 'FS01' -MemberComputerName 'FS02' -Path 'C:\Temp'
Microsoft: the report "contains administrative information about replication state, efficiency, and any potential replication issues," and the backlog from the reference computer "is compared to all other members."
| What the backlog shows | What it usually means (our reading unless noted) | Next |
|---|---|---|
| FS01 → FS02 growing, FS02 → FS01 near zero | FS02 isn't receiving: its state, the FS01 → FS02 connection, a stop on FS02 | Steps 2, 5, 8 |
| FS02 → FS01 growing, FS02's changes never arrive | FS02 can't send: initial sync (state 2), its outbound connection, staging on FS02 | Steps 2, 4, 6 |
| Both directions growing | Service, network, or RPC, or a stop on both members | Steps 5, 8 |
| Count flat, the same files at the top for days | Those files are stuck: locks, staging, conflicts | Step 6 |
| Zero both ways, but a file still differs | The file was never a replicated change: filters, attributes, EFS | Step 6 |
| Large right after a bulk copy, then dropping | Latency. Microsoft: a backlog "may be expected in your environment" | Watch the trend |
Step 4: Did initial replication start and finish? (read-only)
Microsoft's DFSR replicated-folder reference explains the model. On the primary member, DFSR "automatically initializes the folder" and its content "is authoritative." A non-primary member "must first complete initial sync where its metadata (and data if necessary) is synchronized from a partner that is primary or has already completed initial sync." And two rules that explain most stuck setups:
- "no outbound replication occurs from a member on which the replicated folder is in the initial-sync state"
- "It is required that a replicated folder have a primary member before replication can occur."
The events, from Microsoft's archived AskDS walkthrough and the DFSR database article: the primary logs 4112 ("This member is the designated primary member for this replicated folder"), the downstream logs 4102 when initial replication begins, and 4104 when "The DFS Replication service successfully finished initial replication on the replicated folder."
# Read-only. Initial replication milestones on FS01 and FS02, last 30 days
foreach ($m in 'FS01', 'FS02') {
Get-WinEvent -ComputerName $m -FilterHashtable @{
LogName = 'DFS Replication'
Id = 4102, 4104, 4112, 4412
StartTime = (Get-Date).AddDays(-30)
} -ErrorAction SilentlyContinue | Select-Object MachineName, TimeCreated, Id
}
| Finding | What it means | Next |
|---|---|---|
| 4102 on FS02, no 4104, state 2 | Still in initial sync. It needs a normal upstream partner with a moving backlog | Step 3 against the upstream partner |
| Every member in state 2, no 4112 anywhere | No primary. Microsoft: then "all members of the replication group fail to replicate the folder" | Microsoft's fix: Dfsradmin membership /set /isprimary:true on the primary, "only if you're certain that the initial replication fails" |
| The upstream partner is also in state 2 | Microsoft: a request to a member in initial sync "fails." It can't feed anyone | Fan out from a member in state 4 |
| Many 4412 events | Conflicts during initial sync. Microsoft's archived post: most failed pre-seeding attempts come from "mismatched NTFS permissions" | Check ACLs on prestaged data |
| Many 4202 and 4204 events | Microsoft: normal during initial replication, but give it "as much staging area as possible" | Step 6 |
Configuration changes aren't instant. Microsoft: DFSR "queries domain controllers every five minutes by using a lightweight check for membership configuration changes," and "performs a full poll every hour." Microsoft's archived post shows how to see which DC a member reads its configuration from:
# Read-only. The DC this member last read its DFSR configuration from
Get-CimInstance -ComputerName 'FS02' -Namespace 'root\MicrosoftDFS' -ClassName DfsrReplicationGroupConfig |
Select-Object ReplicationGroupName, LastChangeSource
Microsoft defines LastChangeSource as "the name of the Active Directory server." If that DC hasn't received your change yet, the member can't see it (our reading). That's Step 8.
Step 5: Is replication stopped on purpose? (read-only)
Three stops wait for you, and one situation isn't supported at all. Look for them first:
# Read-only. Stop conditions and their follow-ups on FS02, last 90 days
Get-WinEvent -ComputerName 'FS02' -FilterHashtable @{
LogName = 'DFS Replication'
Id = 2104, 2212, 2213, 2214, 4012, 4008, 4114, 5004, 5014
StartTime = (Get-Date).AddDays(-90)
} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, Message | Format-List
Dirty shutdown (2213). Microsoft: a dirty shutdown "occurs when the DFSR service cannot commit all pending changes" to its database before the service stops. When auto-recovery is off, DFSR logs 2213 and waits: "A DFSR administrator must manually resume replication." Microsoft also notes "Windows Server 2012 exhibits this behavior by default," and "The command specifics are provided in the text of event ID 2213."
# Read-only. 1 = stop and log 2213; 0 = Microsoft's value to "have DFSR perform AutoRecovery"
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\DFSR\Parameters' -Name StopReplicationOnAutoRecovery -ErrorAction SilentlyContinue
# Read-only. Volumes DFSR tracks; match VolumeGuid to the GUID in the 2213 text
Get-CimInstance -Namespace 'root\MicrosoftDFS' -ClassName DfsrVolumeConfig | Select-Object VolumeGuid, VolumePath
Because Microsoft says 2012 stops by default, don't read a missing registry value as "auto-recovery is on" (our reading). Microsoft's best-practice table lists AutoRecovery as On for domain controllers, cluster nodes, and read-only members on every version, and for writable members on Windows Server 2012.
Content freshness (4012). Microsoft's SYSVOL article: content freshness "is enabled on Windows Server 2012 (and later versions) domain controllers by default," MaxOfflineTimeInDays "will be set to 60," and 0 means it's disabled. Microsoft's archived AskDS post explains why it exists. DFSR keeps deletion tombstones for 60 days, so a member that comes back after longer "can replicate out old deletions for files that are actually live or replicate out stale data and overwrite existing files." Its example event:
The DFS Replication service stopped replication on the replicated folder at local path c:\rf1. It has been disconnected from other partners for 76 days, which is longer than the MaxOfflineTimeInDays parameter.
The same post says the rest of that event text is wrong: "DFSR does not self-correct this situation, it does not move files into the ConflictAndDeleted folder, and you, the user, have actions you need to take." Microsoft counts these as "unable to replicate": disabled or deleted connections, a stopped DFSR service, a schedule set to no replication, or a server kept off. The value lives per server in DfsrMachineConfig.XML under %systemdrive%\System Volume Information\DFSR\Config, not in AD.
Database failure (2104). Microsoft: "The DFSR service stops replication with error Event ID 2104." Deleting the database makes the member resync "as non-master," moving files to ConflictAndDeleted or PreExisting. Microsoft's alternative makes the damaged member the primary (4112, then 4104 on the others).
Restored VM snapshot. Microsoft: "Snapshots aren't supported by the DFSR database or any other Windows multi-master databases," and "Under no circumstances should you create or restore snapshots of computers running DFSR on read-write members in a production environment." Symptoms include 5014 and 5004, then local changes that never replicate outbound. Microsoft's resolution is a support case: "Recreating the replication group or replicated folder will not fix the issue on the restored server."
| Finding | What it means | Next |
|---|---|---|
2213, StopReplicationOnAutoRecovery = 1 |
Paused after a dirty shutdown (Microsoft) | Back up, then ResumeReplication (Step 9) |
| 2212 and 2214 after a resume | Microsoft: check for both. 2214 marks the end of dirty shutdown recovery | Back to Step 3 |
4012, state 5, MaxOfflineTimeInDays 60 |
Content freshness blocked a stale member (Microsoft) | Non-authoritative resync of that member (Step 9) |
| 2104 | Database failure (Microsoft) | Microsoft's primary-member procedure, not a blind database delete |
| 5014/5004 after a VM restore | Unsupported snapshot restore (Microsoft) | Microsoft Support |
Step 6: Files that can't move (read-only)
Filters. Excluded names never replicate:
# Read-only. File and folder filters on the replicated folder
Get-DfsReplicatedFolder -GroupName 'Branch-Data' -FolderName 'Projects' |
Format-List FolderName, FileNameToExclude, DirectoryNameToExclude
Microsoft's example output shows {~*, *.bak, *.tmp}, the usual default (our note). A user saving budget.bak or ~draft.docx won't see it on the partner.
What DFSR won't replicate, from Microsoft's DFSR FAQ:
| Item | Microsoft's statement |
|---|---|
| EFS-encrypted files | "DFS Replication doesn't replicate files or folders that are encrypted using the Encrypting File System (EFS)." Encrypting a replicated file deletes it from the other members |
| Hard links and junctions | "Hard link files are ignored by DFS Replication." "Junction points also aren't replicated, and DFS Replication logs event 4406" |
| Exclusively locked files | DFSR "doesn't replicate the file until it's closed." Read-share access is fine |
| Timestamp-only changes | "DFS Replication doesn't replicate files for which the only change is a change to the timestamp." |
| Non-NTFS volumes and CSVs | NTFS only; ReFS, FAT, and Cluster Shared Volumes aren't supported |
Sharing violations. Microsoft: event 4302 is "A local sharing violation" on the receiving side, and 4304 means "The service can't stage a file for replication because of a sharing violation" on the sending side. The health report can keep listing them after the files replicate, because "no anti-events are triggered" (Microsoft). Check the backlog instead.
Staging quota. Microsoft: "The staging area quota must be as large as the 32 largest files in the Replicated Folder." Membership default: 4096 MB. Microsoft's own command, pointed at the folder:
# Read-only. Size of the 32 largest files in GB (Microsoft's calculation)
$big32 = Get-ChildItem 'D:\Data\Projects' -Recurse | Sort-Object Length -Descending | Select-Object -First 32 | Measure-Object -Property Length -Sum
$big32.Sum / 1GB
# Read-only. Staging events on FS01, last 7 days
Get-WinEvent -ComputerName 'FS01' -FilterHashtable @{ LogName = 'DFS Replication'; Id = 4202, 4204, 4206, 4208, 4212; StartTime = (Get-Date).AddDays(-7) } -ErrorAction SilentlyContinue |
Group-Object Id | Select-Object Name, Count
| Event | Microsoft's meaning | Read it as |
|---|---|---|
| 4202 | Staging "is above the high watermark. The service will attempt to delete the oldest staging files" | Normal in small numbers. Microsoft's guideline: about one per folder per day outside initial sync |
| 4204 | Old staging files deleted; "now below the high watermark" | Normal |
| 4206 | "failed to clean up old staging files" | Action needed |
| 4208 | Usage "is above the staging quota"; "might fail to replicate some large files" | Microsoft: "abnormal and requires intervention." Raise the quota (Step 9) |
| 4212 | "the staging path is invalid or inaccessible" | Fix the path or its permissions |
Conflicts. Microsoft: DFSR "uses the version of the file that was saved last" and moves the other to DfsrPrivate\ConflictandDeleted, which "isn't replicated" and is treated "as a cache." The archived AskDS post calls 4412 the conflict event. To see what was preserved:
# Read-only. Conflicted/deleted and preexisting files on FS02 (Microsoft's manifest paths)
Get-DfsrPreservedFiles -Path 'D:\Data\Projects\DfsrPrivate\ConflictAndDeletedManifest.xml' |
Select-Object Path, PreservedName, PreservedTime, PreservedReason -First 20
Get-DfsrPreservedFiles -Path 'D:\Data\Projects\DfsrPrivate\PreExistingManifest.xml' |
Select-Object Path, PreservedReason, FileCount -First 20
Step 7: SYSVOL rules (read-only)
SYSVOL replicates as the SYSVOL Share folder in the Domain System Volume group (names from Microsoft's queries and the subscription DN). Microsoft: "sysvol replication is intentionally protected from any editing through its management interfaces to prevent accidents," so DFS Management and Dfsradmin won't reset it. Read every DC:
# Read-only. SYSVOL state on every DC (our CIM form of Microsoft's wmic loop)
$dcs = (Get-ADDomainController -Filter *).HostName
foreach ($dc in $dcs) {
Get-CimInstance -ComputerName $dc -Namespace 'root\MicrosoftDFS' -ClassName DfsrReplicatedFolderInfo -Filter "ReplicatedFolderName='SYSVOL Share'" -ErrorAction SilentlyContinue |
Select-Object PSComputerName, ReplicatedFolderName, State
}
# Read-only. Content freshness limit per DC
Get-CimInstance -ComputerName $dcs -Namespace 'root\MicrosoftDFS' -ClassName DfsrMachineConfig |
Select-Object PSComputerName, MaxOfflineTimeInDays
# Read-only. On DC02: are SYSVOL and NETLOGON shared?
Get-SmbShare -Name SYSVOL, NETLOGON -ErrorAction SilentlyContinue | Select-Object Name, Path
# Read-only. On the PDC emulator: is SYSVOL on DFSR at all?
dfsrmig /getglobalstate
dfsrmig /getmigrationstate
# Read-only. DC02's SYSVOL subscription flags
Get-ADObject -Identity 'CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC02,OU=Domain Controllers,DC=corp,DC=contoso,DC=com' -Properties 'msDFSR-Enabled', 'msDFSR-Options' |
Select-Object 'msDFSR-Enabled', 'msDFSR-Options'
Microsoft's dfsrmig reference: run /getglobalstate "only" on the PDC emulator; the states are 0 Start, 1 Prepared, 2 Redirected, 3 Eliminated; and /getmigrationstate reports whether every DC reached the global state. A domain still in Start is replicating SYSVOL with FRS, and this post's DFSR steps don't apply (our note).
SYSVOL events from Microsoft's articles:
| Event | Meaning |
|---|---|
| 4614 | "DFS Replication is waiting to do initial replication" (new or reset DC) |
| 4604 | SYSVOL "has been initialized": the non-authoritative sync finished |
| 4602 | SYSVOL initialized as the authoritative or primary copy |
| 4114 | The SYSVOL membership is disabled: "sysvol replication is no longer being replicated" |
| 2213 | Paused after a dirty shutdown |
| 4012 | Content freshness stopped SYSVOL on this DC |
Microsoft's SYSVOL article ties the missing-share symptom to its cause: "Domain controllers without SYSVOL shared can't replicate inbound because of upstream (source) domain controllers being in an error state. Frequently (but not limited to), the upstream servers have stopped replication because of a dirty shutdown (event ID 2213)." Its recovery map:
| Situation | Microsoft's path |
|---|---|
| One or more DCs blocked by content freshness, others healthy | Back up SYSVOL, then non-authoritative sync of each blocked DC, fanning out from a healthy DC's direct partners |
| Every DC logged 4012 and shows state 5 | Authoritative sync on the most up-to-date DC: "the only situation to set a DFS Replication server as authoritative" |
| DCs paused by 2213, content freshness not triggered |
ResumeReplication on each, fanning out from a healthy DC. Expect 2212, 2218, then 2214 |
| New DC logged 4614 without 4604, upstream in 2213 (two DCs) | Resume the upstream (4602), then dfsrdiag pollad on the new DC to finish (4604) |
Step 8: Network, RPC, AD, and time (read-only)
Microsoft's port reference for DFSR: TCP 135 plus "Randomly allocated high TCP ports" (49152-65535). "Port 5722 is only used on a Windows Server 2008 domain controller or a Windows Server 2008 R2 domain controller," and "Port 445 is used by DFSR only when creating a new empty replicated folder." The FAQ adds that DFSR can be pinned to a static port, and its RPC "is always encrypted"; you can't turn that off.
# Read-only. From FS02 toward FS01: name, endpoint mapper, and the static port if one is set
Resolve-DnsName -Name 'fs01.corp.contoso.com'
Test-NetConnection -ComputerName 'fs01.corp.contoso.com' -Port 135 |
Select-Object ComputerName, RemotePort, TcpTestSucceeded
# Read-only. AD replication health: DFSR's configuration lives in AD
repadmin /replsummary
# Read-only. Clock offset to the PDC emulator
w32tm /stripchart /computer:dc01.corp.contoso.com /samples:3 /dataonly
Test-NetConnection proves the endpoint mapper answers, not that the dynamic port is open. A firewall that allows 135 and blocks the high range still breaks DFSR (our note). Microsoft's archived post: "DFSR stores its configuration in AD," and changes reach members "during its next poll of AD." A member reading from a DC that's behind won't see a fixed connection or schedule. Time matters too. Microsoft's FAQ: DFSR doesn't strictly require time sync, but "The server clocks must be set within five minutes of each other (by default) for Kerberos authentication to function properly," and conflict resolution uses timestamps.
| Finding | Next |
|---|---|
| Name doesn't resolve, or resolves to an old IP | DNS record for the partner |
| 135 fails, or 135 works and the backlog still grows both ways | Firewall rules for 135 and the dynamic range, or a static port (Step 9) |
repadmin /replsummary shows failures |
Fix AD replication before you touch DFSR settings |
| Clock offset of minutes | Fix time on that member before anything else |
Common false starts (read these before you change anything)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| Deleting the DFSR database | Microsoft: "shouldn't be required and is discouraged"; all local data becomes nonauthoritative | Read the stop condition (Step 5) and follow its recovery |
| Authoritative SYSVOL restore to fix one DC | Microsoft: "If only repairing one DC, make it non-authoritative and don't touch other servers" | Non-authoritative on the broken DC (Step 9) |
Raising MaxOfflineTimeInDays to clear a 4012 |
It's the check that keeps stale tombstones and old files from replicating out (our reading of Microsoft's AskDS post) | Non-authoritative resync of that member |
| Removing and re-adding the member | Microsoft's archived post calls it "a common misconception" that this triggers a fresh initial sync | Disable, poll, re-enable the membership (Step 9) |
| Recreating the group after a VM snapshot restore | Microsoft: it "will not fix the issue on the restored server" | Microsoft Support |
| Disabling a membership to "pause" replication | Microsoft: "Disabling and enabling the membership of a computer causes non-authoritative inbound replication" | Disable the connection or use Suspend-DfsReplicationGroup
|
Running ResumeReplication without a backup |
Microsoft: skipping the backup "may result in data loss from unexpected conflict resolution" | Back up every replicated folder on that volume first |
| Adding the missing reverse connection on a one-way setup | Microsoft's archived post: "That is a BAD idea"; old data can flow back | Force that member through initial sync first |
| Treating any backlog as an outage | Microsoft: a backlog "is not necessarily an indication of problems" | Compare directions and the trend (Step 3) |
| Marking a member primary after setup | Microsoft: it can become "a rogue primary server" | Only when initial replication has really failed (Step 4) |
Step 9: Change one layer, then watch (only after the read)
Pick the one change Steps 1-8 point at. Back up what you change, and test on one member first.
Disabled connection (Step 2), when it was paused recently, not a one-way design:
# Change. Re-enable FS02 -> FS01; dry-run first, then ask the members to poll AD
Set-DfsrConnection -GroupName 'Branch-Data' -SourceComputerName 'FS02' -DestinationComputerName 'FS01' -DisableConnection $false -WhatIf
Update-DfsrConfigurationFromAD -ComputerName 'FS01', 'FS02' -Verbose
Update-DfsrConfigurationFromAD lists no -WhatIf. It only triggers the poll Microsoft describes. If the connection was disabled for longer than MaxOfflineTimeInDays, expect a 4012 instead and use the non-authoritative path below (our reading).
Closed schedule: Microsoft: Sync-DfsReplicationGroup "ignores the schedule for the specified number of minutes."
# Change (temporary). Replicate FS01 -> FS02 for 15 minutes regardless of schedule; dry-run first
Sync-DfsReplicationGroup -GroupName 'Branch-Data' -SourceComputerName 'FS01' -DestinationComputerName 'FS02' -DurationInMinutes 15 -WhatIf
Dirty shutdown (2213), after a backup of every replicated folder on that volume:
# Change. Microsoft's ResumeReplication on the paused volume (GUID from the 2213 text); dry-run first
$vol = Get-CimInstance -Namespace 'root\MicrosoftDFS' -ClassName DfsrVolumeConfig -Filter "VolumeGuid='E18D8280-2379-11E2-A5A0-806E6F6E6963'"
Invoke-CimMethod -InputObject $vol -MethodName ResumeReplication -WhatIf
Microsoft's own form is wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="GUID" call ResumeReplication, and a success returns ReturnValue = 0. The CIM form is ours. Then check for 2212 and 2214. To auto-recover next time, Microsoft documents StopReplicationOnAutoRecovery = 0, or Set-DfsrServiceConfiguration -UnexpectedAutoRecovery $true -WhatIf (Microsoft: "The recommended value for this parameter is $True"). To prevent dirty shutdowns, Microsoft points to a UPS and WaitToKillServiceTimeout, sized from the gap between events 1006 and 1008.
Content freshness (4012) on a custom folder: non-authoritative resync of FS02 only. Back up FS02's folder and its partner first. Microsoft's archived post: files only on FS02 go to PreExisting, and its local changes go to ConflictAndDeleted.
# Change. Disable FS02's membership; dry-run first
Set-DfsrMembership -GroupName 'Branch-Data' -FolderName 'Projects' -ComputerName 'FS02' -DisableMembership $true -WhatIf
# After AD replication: poll, then wait for 4008 and 4114 on FS02
Update-DfsrConfigurationFromAD -ComputerName 'FS02' -Verbose
# Change. Re-enable; FS02 then logs 4102 and, when done, 4104
Set-DfsrMembership -GroupName 'Branch-Data' -FolderName 'Projects' -ComputerName 'FS02' -DisableMembership $false -WhatIf
# Change. Afterwards, copy (not move) preexisting files out for review; dry-run first
Restore-DfsrPreservedFiles -Path 'D:\Data\Projects\DfsrPrivate\PreExistingManifest.xml' -RestoreToPath 'E:\Review\Projects' -CopyFiles -WhatIf
Microsoft on re-enabling: "you will lose any private data and can lose replicated data. You may be able to recover replicated data by using the Restore-DfsrPreservedFiles cmdlet."
SYSVOL on one DC (DC02): Microsoft's non-authoritative sync. Back up DC02's SYSVOL contents first. Microsoft does this in ADSI Edit. The Set-ADObject form is ours:
# Change. Step 1: disable DC02's SYSVOL subscription; dry-run first
$sub = 'CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC02,OU=Domain Controllers,DC=corp,DC=contoso,DC=com'
Set-ADObject -Identity $sub -Replace @{ 'msDFSR-Enabled' = $false } -WhatIf
# Step 2: force AD replication (from the DC where you made the change), then on DC02: dfsrdiag pollad
repadmin /syncall DC01 /AdeP
# Step 3: wait for 4114 on DC02, then set it back and repeat the sync and poll
Set-ADObject -Identity $sub -Replace @{ 'msDFSR-Enabled' = $true } -WhatIf
DC02 then logs 4614 and 4604 (Microsoft). repadmin /syncall flags are Microsoft's: /A all naming contexts, /d distinguished names, /e across sites, /P push. The authoritative procedure is different. Microsoft sets the DFSR service to Manual and stops it on every DC, sets msDFSR-Options=1 and msDFSR-Enabled=FALSE on one DC (preferably the PDC emulator), and disables every other DC. It brings the authoritative DC back first (4602), then the rest. Follow Microsoft's article step by step, and only for the "every DC is in error" case from Step 7.
Staging quota (Step 6): Microsoft: changes "do not require a reboot or restart of the service"; they wait on AD replication and DFSR's polling.
# Change. Raise staging for both members (Microsoft's example value, 32 GB); dry-run first
Set-DfsrMembership -GroupName 'Branch-Data' -FolderName 'Projects' -ComputerName 'FS01', 'FS02' -StagingPathQuotaInMB 32768 -WhatIf
Firewall needs a fixed port (Step 8): Set-DfsrServiceConfiguration -ComputerName 'FS02' -RPCPort 40000 -WhatIf pins DFSR to one port (1024-65535). Microsoft: "Microsoft recommends a dynamic port. You might need to specify a static port to accommodate a firewall."
Read-only confirm afterwards, plus one low-risk write:
# Read-only. State 4 on both members and the backlog falling in both directions
Get-CimInstance -ComputerName 'FS01', 'FS02' -Namespace 'root\MicrosoftDFS' -ClassName DfsrReplicatedFolderInfo |
Select-Object PSComputerName, ReplicatedFolderName, State
# Low-risk write. Drops a test file into DFSR_DIAGNOSTICS_TEST_FOLDER on FS01; dry-run first
Start-DfsrPropagationTest -GroupName 'Branch-Data' -FolderName 'Projects' -ReferenceComputerName 'FS01' -WhatIf
# Later: where did the test file arrive? (writes HTML + XML to C:\Temp)
Write-DfsrPropagationReport -GroupName 'Branch-Data' -FolderName 'Projects' -ReferenceComputerName 'FS01' -Path 'C:\Temp'
Watch one full cycle. Every member shows state 4, the backlog falls in both directions, the propagation test file reaches every member, and the event you were waiting for is there: 4104 for a member, 4604 for SYSVOL, 2214 after a resume. Microsoft: use Remove-DfsrPropagationTestFile to delete old test files.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Connection recently disabled | Re-enable it, poll AD | Re-adding the member |
| One-way connection by accident, months old | Force that member through initial sync | Adding the reverse connection as-is |
| 2213 after an outage | Back up, ResumeReplication, then a UPS and shutdown timeout |
Deleting the database |
| 4012 on one member | Non-authoritative resync of that member | Raising MaxOfflineTimeInDays
|
| 4012 on every SYSVOL DC, state 5 | Authoritative sync on the most current DC, per Microsoft | Authoritative restore when one DC is broken |
| No primary member, initial sync stuck | Set the primary only when initial replication truly failed | Marking members primary after setup |
| 4208 staging events | Staging quota of at least the 32 largest files | Turning off RDC to "speed it up" |
| Files filtered or locked | Change the filter, or find the process holding the file | Disabling the filter for every folder |
| VM restored from a snapshot | Microsoft Support | Recreating the replication group |
FAQ
Why is DFS replication not working in one direction?
Compare the backlog both ways with Get-DfsrBacklog -Verbose, then read the quiet member's state. Microsoft: "no outbound replication occurs from a member on which the replicated folder is in the initial-sync state," so a member stuck in state 2 receives but never sends. Other causes: a disabled connection, a read-only membership (one-way by design), a 2213 or 4012 on one side, or an exclusive lock on the files.
What does DFSR event ID 4012 mean?
Content freshness stopped replication on that folder because the member was disconnected longer than MaxOfflineTimeInDays (60 by default on Windows Server 2012 and later DCs). Microsoft's AskDS post says DFSR "does not self-correct this situation." Back up the member and its partner, then run a non-authoritative resync: disable the membership (or msDFSR-Enabled for SYSVOL), wait for 4114, and re-enable it.
How do I check the DFS replication backlog?
Run Get-DfsrBacklog -GroupName RG -FolderName RF -SourceComputerName A -DestinationComputerName B -Verbose. It lists up to 100 files, and the verbose stream gives the full count. Run it in both directions. dfsrdiag backlog and Write-DfsrHealthReport show the same data. Microsoft: a backlog "indicates latency" and "may be expected."
How do I do a non-authoritative restore of SYSVOL with DFSR?
Microsoft's steps: set msDFSR-Enabled=FALSE on the DC's SYSVOL Subscription object, force AD replication, run DFSRDIAG POLLAD, wait for event 4114, set it back to TRUE, replicate and poll again, then wait for 4614 and 4604. Back up SYSVOL first. Only use the authoritative version when every DC is in error.
Why isn't DFS initial replication starting?
A non-primary member needs a primary member, or a partner that already finished initial sync. Microsoft: "It is required that a replicated folder have a primary member before replication can occur." Check for 4112 on the primary and 4102 on the new member, the upstream partner's state, the connection, and AD polling (Update-DfsrConfigurationFromAD). Then give it a large staging quota.
Related posts
- Group Policy Not Applying (SYSVOL's half of a GPO: when the template never reaches a DC)
- Hyper-V Checkpoint Operation Failed (why a checkpoint is the wrong undo button for a DFSR member)
- Trust Relationship Between This Workstation and the Primary Domain Failed (secure channel triage for a member server that stops talking to the domain)
Free checklist
SYSVOL replication outages are often what finally pushes device policy from GPOs to Intune, and once Intune compliance feeds Conditional Access, a bad policy blocks sign-ins instead of drive maps. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=dfs-replication-not-working
Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 favor read-only checks: the DFSR WMI classes, the `Get-Dfsr cmdlets, Write-DfsrHealthReport (writes a local report), Get-WinEvent on the DFS Replication log, Get-SmbShare, dfsrmig /getglobalstate and /getmigrationstate, Get-ADObject, Test-NetConnection, repadmin /replsummary, and w32tm /stripchart. Enabling connections, overriding schedules, ResumeReplication`, disabling and re-enabling memberships or the SYSVOL subscription, forcing AD replication, authoritative sync, restoring preserved files, changing staging quotas or the RPC port, auto-recovery settings, and propagation tests are deliberate changes. Change one layer at a time, test on one member first, and check current Microsoft Learn for version-specific behavior.*
Top comments (0)