DFSR SYSVOL Stuck — Event 4012 and Backlog Not Clearing

Introduction

A GPO change goes out and applies cleanly on some domain controllers and never shows up on others. Or someone notices a SYSVOL backlog that has been climbing for days instead of draining. Or, worst case, the DFS Replication event log has an Event 4012 sitting in it and nobody is quite sure whether that means the domain controller’s SYSVOL copy can still be trusted.

DFSR is deliberately conservative about SYSVOL. Rather than silently replicating from a copy it isn’t sure is current, it stops and logs an event describing exactly what state it thinks it’s in. That is good news for troubleshooting: the fix depends entirely on which event actually fired, so read the event log before reaching for any recovery procedure.

What You’re Seeing

Event 4012 appears in Applications and Services Logs > DFS Replication, source DFSR, and reads approximately:

# Applications and Services Logs > DFS Replication, Source: DFSR, Event ID 4012
The DFS Replication service stopped replication on the folder with the following
local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other
partners for 62 days, which is longer than the time allowed by the MaxOfflineTimeInDays
parameter (60).

The backlog symptom shows up differently — not as an event, but as a number that won’t move. Get-DfsrBacklog keeps returning pending files between the same pair of servers no matter how long you wait, or the DFS Management console shows a replicated folder stuck in a state other than Normal.

What It Actually Means

Think of content freshness as an expiration date stamped on a delivery. Once a domain controller has been cut off from every partner for too long, DFSR treats its copy of SYSVOL as potentially spoiled and refuses to serve it until that’s confirmed otherwise — the data isn’t necessarily wrong, it’s just been out of contact long enough that DFSR won’t take the risk.

Event 4012 is DFSR’s content freshness protection. Every DC enabled for it (on by default from Windows Server 2012 onward) tracks how long it has gone without successfully replicating with any partner. Cross the MaxOfflineTimeInDays threshold — 60 days by default — and DFSR concludes it can no longer be sure its copy of SYSVOL reflects current reality, so it stops replicating that folder rather than risk pushing stale data out to the rest of the domain, or pulling stale data in.

A backlog that never clears is a different symptom with several possible causes — the replicated folder itself may be healthy and just slow, or it may be sitting in an error state entirely. Both symptoms point to the same next step: stop guessing and read what DFSR itself recorded.

How to Diagnose

Work from the cheapest read-only check to the deepest. None of the commands below change anything.

# 1. Check pending files between a source and destination DC
Get-DfsrBacklog -SourceComputerName DC01 -DestinationComputerName DC02 `
  -GroupName "Domain System Volume" -FolderName "SYSVOL Share"

# 2. Check the overall inbound/outbound DFSR state on a given DC
Get-DfsrState -ComputerName DC02

# 3. Confirm the underlying AD replication that carries DFSR's configuration
# is actually converging between DCs
repadmin /showrepl DC02 /errorsonly

# 4. Confirm SYSVOL is flagged ready and Netlogon is advertising correctly
dcdiag /test:sysvolcheck /test:advertising /s:DC02

# 5. Let dcdiag scan the DFSR event log itself for the last 24 hours of
# warnings and errors
dcdiag /test:DFSREvent /s:DC02

# 6. Confirm the domain has fully migrated from FRS to DFSR for SYSVOL -
# a DC stuck mid-migration behaves like a replication failure
dfsrmig /getmigrationstate

Common Causes

Working Through a Fix

Most stuck-SYSVOL cases resolve with a non-authoritative resync of the affected DC — telling it to discard its local copy and pull a fresh one from a healthy partner. DFSR has no BurFlags registry values the way FRS did; the flag lives in Active Directory, on the DC’s own DFSR subscription object.

In ADSIEdit.msc, connect to the Default naming context and locate the affected DC’s object:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,
CN=<server name>,OU=Domain Controllers,DC=<domain>

Set msDFSR-Enabled to FALSE on that object, force AD replication throughout the domain, then run DFSRDIAG POLLAD on the affected DC. Confirm Event ID 4114 appears — that’s SYSVOL stopping replication cleanly. Set msDFSR-Enabled back to TRUE, force replication again, run DFSRDIAG POLLAD once more, and watch for Event ID 4614 followed by 4604 — that pair confirms the non-authoritative resync completed.

How to Prevent It

Don’t let a domain controller sit disconnected from the replication topology for anywhere close to 60 days — a DC that’s going to be offline for an extended maintenance window is a candidate for demotion and later repromotion, not for triggering content freshness on return. Keep the DFSR service account’s environment stable: verify the built-in Administrators group retains the Manage Auditing and Security Log right, since removing it as part of a hardening pass is a common, self-inflicted cause of migration and initialization failures.

Monitor backlog proactively with Get-DfsrBacklog or a scheduled Write-DfsrHealthReport run rather than waiting for a GPO complaint to surface it — a backlog that’s merely slow and one that’s genuinely stuck look identical from the help desk ticket, and only a health report or event log check tells them apart. Confirm SYSVOL and DFSR database exclusions are in place for antivirus and backup agents; on Server 2016 and later these apply automatically once the AD DS role is installed, but verify rather than assume on older builds or third-party AV that doesn’t respect Windows’ automatic exclusion list.

Quick Reference

Final Thoughts

A stuck SYSVOL backlog feels urgent because it eventually breaks Group Policy delivery everywhere, but the DFSR event log almost always already contains the answer. Content freshness, dirty shutdown, blocked RPC, and a stalled migration each leave a distinct fingerprint, and each has a documented, low-drama fix.

Reach for an authoritative resync only when every DC’s copy is genuinely in doubt. In every other case, the non-authoritative procedure on the one affected DC — done in the right order, with AD replication forced between each step — clears the backlog without putting the rest of the domain’s SYSVOL at risk.