SYSVOL Not Replicating in Active Directory? How to Check and Fix DFSR

SYSVOL not replicating is one of the more confusing Active Directory failures, because normal AD replication can look completely healthy while it happens. The usual signs are inconsistent Group Policy depending on which DC a client used, missing SYSVOL or NETLOGON shares, a DFSR backlog that never drains, or DFS Replication errors on one or more domain controllers.

The key fact to start from: repadmin checks AD object replication, not DFSR SYSVOL replication. repadmin /replsum can show zero errors with SYSVOL not replicating the entire time.

SYSVOL Not Replicating vs AD Replication

AD DS object replication and SYSVOL DFSR replication are separate replication paths with different tools and failure modes. AD replication (managed by the KCC, diagnosed with repadmin) carries directory objects: GPO metadata, user accounts, group memberships, site topology. When you create a GPO, the GPO object – name, GUID, version number, links – replicates to all DCs through the AD replication engine.

DFSR carries the actual policy files. Every GPO maps to a GUID-named folder under %WINDIR%\SYSVOL\domain\Policies\. Inside each folder is GPT.INI (the version counter), the computer and user policy folders, scripts, and other policy files. Clients read these files from the SYSVOL share when applying Group Policy.

When DFSR breaks, AD replication stays healthy. The GPO object says version 7 exists, but SYSVOL on two of your three DCs still holds version 4 files. A client authenticating to DC01 gets the current policy. A client hitting DC02 gets a version three updates behind.

That is why SYSVOL replication failures produce inconsistent Group Policy behavior across machines: the metadata and the files are out of sync.

For AD object replication failures – USN rollback, lingering objects, Error 1722 – see Active Directory replication not working. The symptoms overlap, but the diagnosis is different.

Step 1: Check SYSVOL and NETLOGON Shares

The first check when SYSVOL is not replicating – run this on every DC:

Both SYSVOL and NETLOGON must appear. A missing SYSVOL or NETLOGON share means SYSVOL has not initialized or published correctly on that DC, and it needs DFSR and Netlogon diagnosis before anything else.

Netlogon publishes the shares only after DFSR reports SYSVOL as ready, which it records in the SysVolReady registry value:

A value of 0 means Netlogon is still waiting for SYSVOL. Treat that as a symptom, not the fault: check the DFS Replication log for Event 4614 (waiting for initial sync) or a DFSR error before anything else. Forcing SysVolReady to 1 while DFSR is still initializing publishes shares with incomplete content and hides the real problem. If DFSR has completed initialization but the shares still aren’t published, follow Microsoft’s procedure for that specific failure state in How to troubleshoot missing SYSVOL and Netlogon shares rather than setting the value as a generic repair.

SYSVOL Not Replicating to a New Domain Controller

A newly promoted DC with no SYSVOL or NETLOGON share is usually still waiting for its first DFSR sync from a partner. The DFS Replication log tells you where it is:

• Event 4614 – SYSVOL is initialized but waiting for initial replication. The DC has not yet received content from a partner.
• Event 4604 – initial replication completed. SYSVOL is ready and the shares should appear.

If 4614 is present and 4604 never follows, the problem is on the partner side or in between: check that DFSR is running and healthy on the source DC, that the source DC isn’t itself logging 2213 or 4012, and that the two DCs can reach each other (see Step 4). The new domain controller checklist covers the rest of what to verify after promotion.

Step 2: Check SYSVOL Replication Type and FRS Migration State

On domains upgraded from Windows Server 2003 or 2008, SYSVOL may still be replicating with FRS, the older File Replication Service. For SYSVOL not replicating on a long-running forest, this is an easy cause to miss, because DFSR tools will show nothing useful while FRS is still doing the work.

• ELIMINATED – the completed migration state expected on fully migrated domains. DFSR owns SYSVOL and FRS is gone.
• PREPARED – DFSR replicates a separate copy of SYSVOL, but FRS still serves the live SYSVOL share. DFSR diagnostics won’t show the problem clients actually see.
• REDIRECTED – the SYSVOL share points at the DFSR copy, but the FRS copy has not been removed yet.

Since Windows Server version 1709, a new DC cannot be promoted as a replica into a domain that still uses FRS. Promotion fails with: “The specified domain is still using the File Replication Service (FRS) which is deprecated. This server does not support FRS and cannot be promoted as a replica into the specified domain.”

If the state is anything other than ELIMINATED, finish the FRS-to-DFSR migration before further DFSR troubleshooting; Microsoft’s SYSVOL migration documentation covers that process. If the domain was built on Windows Server 2008 functional level or later, SYSVOL started on DFSR and you can skip this step.

Step 3: Check DFSR SYSVOL Replication Status

The backlog is the most direct way to check SYSVOL replication status between two DCs:

Run it for every DC pair, in both directions. In a three-DC environment that means six checks (DC01 to DC02, DC02 to DC01, and so on).

• 0 files – nothing pending for that checked direction at that moment. It doesn’t prove every other pair is healthy.
• Non-zero, count decreasing over time – replication is working and catching up. Recheck over 15-30 minutes.
• Non-zero, count not changing – SYSVOL is not replicating in that direction. Go to the event log.

To check SYSVOL replication status from PowerShell (requires the DFS Management tools, RSAT-DFS-Mgmt-Con):

The cmdlet returns up to 100 pending items; the -Verbose output reports the total backlog count even when it’s larger than that.

Step 4: Check the DFS Replication Event Log

This is where most operators lose time when SYSVOL is not replicating. The DFS Replication log is not in the standard Windows Logs section.

Correct path: Event Viewer > Applications and Services Logs > DFS Replication

Windows Logs > Application may show a few DFSR entries, but the events you need are in Applications and Services Logs.

Key DFSR event IDs for SYSVOL replication:

Events 5002 and 5008 both point at partner communication. DFSR on Windows Server 2012 and later uses RPC: the endpoint mapper on TCP 135, then a dynamically assigned high port (49152-65535 by default). Port 5722 was only used by DFSR on Windows Server 2008 and 2008 R2 domain controllers, per Microsoft’s service and port requirements. A quick first test:

A success only proves the endpoint mapper is reachable; a firewall that blocks the dynamic range will still break DFSR. If 135 fails, the fix is firewall or routing, not a DFSR configuration change.

Step 5: Diagnose the DFSR Error

Each event below points to a different cause of SYSVOL not replicating, and each has its own fix.

Event 2213: Dirty Shutdown

Event 2213 is a frequent cause of SYSVOL not replicating on a DC that otherwise looks healthy. It’s logged when the DFSR database was not shut down cleanly – power loss, a crash, an abrupt service stop. When DFSR logs Event 2213, replication on that volume is paused, and the event text provides the ResumeReplication command to restart it.

The event text contains the exact recovery command, including the volume GUID. Copy it from that server’s own event:

A return value of 0 means the resume was accepted. Microsoft’s Event ID 2213 article recommends backing up replicated content before resuming, since recovery can resolve conflicts unexpectedly. Then leave DFSR alone until the recovery events appear; restarting the service mid-recovery starts it over.

To make DFSR recover automatically after future dirty shutdowns, the same Microsoft article documents setting the StopReplicationOnAutoRecovery DWORD to 0 under HKLM\System\CurrentControlSet\Services\DFSR\Parameters. The default behavior exists so you can take a backup before replication resumes; change it deliberately, not as part of the fix.

Event 4012: Content-Freshness Lockout

Event 4012 means the DC has been unable to replicate for longer than MaxOfflineTimeInDays (60 days by default). DFSR treats its local SYSVOL as potentially stale and refuses to replicate it – SYSVOL not replicating to or from that DC is deliberate here, so outdated policy can’t overwrite newer content on other DCs.

The event text suggests removing the server from the replication group and re-adding it. For SYSVOL, use a non-authoritative sync instead (see below) – it achieves the same result through the supported SYSVOL procedure.

The default recovery path is simple: if a healthy DC exists, run a non-authoritative sync on the locked-out DC; if none does, run an authoritative sync.

Events 4202 and 4208: Staging Quota

Staging pressure builds up over time, especially after large script or software-deployment content lands in SYSVOL. DFSR commonly uses a 4,096 MB default staging quota. An undersized quota causes repeated staging cleanup and re-staging, and poor replication performance that can look like SYSVOL not replicating, especially when large files repeatedly exceed the available staging space. Microsoft’s staging sizing guidance is a quota at least as large as the 32 largest files in the replicated folder:

Divide by 1,048,576 to get MB. To change the quota, use DFS Management: Replication > Domain System Volume, open the member’s Properties, and set Staging > Quota (in megabytes), as described in Microsoft’s SYSVOL staging quota procedure.

Event 2104: DFSR Database Error

Event 2104 is less common but serious: DFSR couldn’t recover from an internal database error and stopped replication on the volume. Check disk health first:

If the disk reports problems, fix those before anything else. If the disk is clean and 2104 persists, recover SYSVOL on that DC with a non-authoritative sync from a healthy partner rather than editing DFSR’s database files by hand. Content that existed only on this DC ends up in DfsrPrivate\ConflictAndDeleted or PreExisting, so check those before deleting anything.

SYSVOL Not Replicating After VM Snapshot Restore

Modern virtualized DCs handle this better than they used to. On a hypervisor that supports VM-Generation ID, a DC that detects a snapshot restore applies virtualization safeguards: it resets its invocation ID, then stops DFSR, deletes the DFSR database, and replicates SYSVOL inbound non-authoritatively from a partner. Give it time to finish and check for 4614 and 4604.

Without VM-Generation ID support, or after an unsupported restore method, those safeguards don’t run and the DC risks USN rollback, not just a SYSVOL problem. See USN rollback in Active Directory before treating it as a DFSR-only issue.

SYSVOL Policies Folder Not Replicating

Sometimes the symptom is narrower: one GPO behaves differently depending on the DC, and the Policies folder on one DC is missing a GUID folder or holds an older GPT.INI. AD can show the correct GPO version in GPMC at the same time, because the GPO object replicated through AD while the files didn’t.

Compare the same GPO’s GPT.INI across DCs:

Different Version= lines, or a GUID folder present on one DC and missing on another, confirm the problem is SYSVOL not replicating that content. From there, use the backlog check and DFSR event log above. If SYSVOL is consistent across DCs and the policy still doesn’t apply, the problem is on the client side – see Group Policy troubleshooting.

How to Force SYSVOL Replication Safely

There’s no single “force SYSVOL now” command equivalent to repadmin /syncall, and mixing them up is a common source of bad advice. Three different things get called “forcing replication”:

• repadmin /syncall /AdeP forces AD object replication. It doesn’t move SYSVOL files, but it’s how changes to DFSR settings stored in AD (such as msDFSR-Enabled) reach other DCs.
• dfsrdiag pollad makes DFSR on a DC re-read its configuration from AD immediately instead of waiting for the next polling interval. Run it after an AD-side change.
• dfsrdiag syncnow (or Sync-DfsReplicationGroup in PowerShell) temporarily overrides the replication schedule with a partner. SYSVOL already replicates continuously by default, so this rarely fixes anything on its own.

With SYSVOL not replicating and the backlog stuck, forcing replication won’t help: DFSR has stopped for a reason, and that reason is in the event log. Fix the event first, then use pollad to apply configuration changes, or a non-authoritative sync to rebuild a DC’s SYSVOL.

Non-Authoritative SYSVOL Restore (D2)

“D2” is FRS-era shorthand that operators still use for a non-authoritative DFSR SYSVOL sync. Use it for SYSVOL not replicating on one or a few DCs and at least one healthy DC exists to pull from. The broken DC discards its local SYSVOL state and pulls a fresh copy from a healthy partner. The procedure follows Microsoft’s authoritative and non-authoritative synchronization guide.

Authoritative SYSVOL Restore (D4)

“D4” is the matching shorthand for an authoritative DFSR SYSVOL sync. Use it for SYSVOL not replicating on all or most DCs and there’s no healthy partner to pull from, or when you need to roll every DC back to one known-good copy.

Choosing the authoritative DC is the decision that matters most. Microsoft recommends the PDC Emulator as the default. Before committing, confirm it holds the intended GPO content: check GPMC, compare against your GPO backups, and use what the team knows about recent changes. Timestamps and GPT.INI versions help compare DCs, but the newest copy isn’t automatically the correct one:

If you make one DC authoritative but don’t reset the others to non-authoritative, DFSR generates conflicts on every DC you skipped. Check msDFSR-Options on the authoritative DC afterward.

Emergency Recovery with dcgpofix

If no DC has usable SYSVOL content, there’s no backup, and the immediate need is working default policy, dcgpofix can recreate the Default Domain Policy and Default Domain Controllers Policy:

Post-Fix Verification

Present shares aren’t proof. SYSVOL replication is confirmed only when all of the following are true:

Operators often stop at step 1. Steps 2 and 4 are what confirm DFSR is working and content is consistent across every DC. For broader DC validation, the DCDiag DFSREvent and SysVolCheck tests in the DCDiag guide are a useful second opinion.

FAQ

What is the difference between AD replication and SYSVOL replication?

AD replication carries directory objects – user accounts, GPO metadata, configuration – through the KCC-managed engine. SYSVOL replication carries the actual GPO files and scripts through DFSR. Both must work for Group Policy to apply correctly. repadmin only shows AD replication, so you can have clean AD replication and SYSVOL not replicating at the same time.

How do I check SYSVOL replication status?

Run dfsrdiag backlog (or Get-DfsrBacklog in PowerShell) between each DC pair in both directions, confirm SYSVOL and NETLOGON with net share, and read the DFS Replication event log. A backlog that stays at the same non-zero number means replication has stopped in that direction.

Why is SYSVOL not replicating to a new domain controller?

Usually because initial replication hasn’t completed. Look for Event 4614 (waiting) without a following 4604. Check that DFSR is healthy on the source DC, that the source isn’t logging 2213 or 4012 itself, and that RPC traffic between the two DCs isn’t blocked.

How do I force SYSVOL replication?

Short answer: fix why it stopped. dfsrdiag pollad makes DFSR re-read its configuration and dfsrdiag syncnow overrides the schedule, but neither restarts replication that DFSR halted because of an error. If a DC’s SYSVOL is wrong, run a non-authoritative sync on it.

What does DFSR Event 4012 mean for SYSVOL?

The DC couldn’t replicate for longer than MaxOfflineTimeInDays (60 days by default), so DFSR treats its SYSVOL as stale and won’t replicate it. Run a non-authoritative sync if at least one healthy DC exists, or an authoritative sync if every DC is affected. Ignore the event’s “remove and re-add the member” instruction for SYSVOL.

What is the difference between non-authoritative and authoritative SYSVOL restore?

Non-authoritative (D2) tells a broken DC to discard its SYSVOL state and pull from a healthy partner. Authoritative (D4) makes one DC the source of truth and forces all others to pull from it. Use non-authoritative when at least one DC has correct content; use authoritative when none do.

Is dcgpofix safe for SYSVOL recovery?

No, not as a SYSVOL fix. It recreates the two default GPOs and resets their settings; it doesn’t restore custom GPO files. It’s a last resort when no DC and no backup holds usable content.

Final Thoughts

SYSVOL not replicating is disorienting because repadmin says everything is fine. AD looks healthy while the failure sits in a separate replication path with its own service, its own event log, and its own recovery procedures.

The diagnostic path is short once you know where to look: check the shares, confirm SYSVOL is on DFSR, measure the backlog between DC pairs, and read the DFS Replication log. Recovery then comes down to one decision – non-authoritative sync when a healthy source exists, authoritative sync when it doesn’t.

The two mistakes that cost the most time: looking in the wrong event log, and restarting DFSR before reading why it stopped.

If SYSVOL replication is healthy but Group Policy still behaves inconsistently, the next layer to check is DNS and DC location. Active Directory DNS problems covers SRV record and name resolution failures that produce very similar symptoms.