DFS Replication Not Working: A Read-First Backlog, Event 4012, Dirty Shutdown, and SYSVOL Triage

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 ResumeReplication for 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 1: Capture the symptom (read-only)

Write these on the ticket first:

Then branch on what you see:

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

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

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."

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
}

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."

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:

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

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:

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:

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.

Common false starts (read these before you change anything)

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

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:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=dfs-replication-not-working

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.*