What does DFSR Event ID 4012 mean?

Event ID 4012 indicates that the DFS Replication service has stopped replicating a folder, typically SYSVOL, at the local path on the domain controller due to a database corruption, journal wrap, or dirty shutdown.

How do I fix SYSVOL replication stopped on a domain controller?

Run Get-DfsrState and dfsrdiag to diagnose the issue, then perform either an authoritative or non-authoritative sync by modifying the msDFSR-Enabled and msDFSR-Options attributes in ADSIEDIT.MSC and running DFSRDIAG POLLAD.

What is the difference between authoritative and non-authoritative DFSR sync?

An authoritative sync designates one domain controller as the master copy and overwrites all other replicas. A non-authoritative sync discards the local SYSVOL copy and re-downloads it from a partner that has a valid replica.

Can Event ID 4012 cause Group Policy failures?

Yes. When SYSVOL replication stops, the affected domain controller cannot serve updated Group Policy objects to clients, which causes GPO processing failures and inconsistent policy application across the domain.

DFSR Event ID 4012: SYSVOL Replication Stopped — Fix Guide

When you open Event Viewer on a Windows Server domain controller and find Event ID 4012 in the DFS Replication log, it means the DFS Replication service has stopped replicating a folder — most commonly SYSVOL. This is a critical issue because SYSVOL holds Group Policy objects, logon scripts, and other domain-wide resources. A domain controller that stops replicating SYSVOL will serve stale or missing Group Policy to clients, leading to inconsistent security settings and broken logon scripts across your environment. In this guide, you will learn how to diagnose Event ID 4012, understand its root causes, and resolve it using both GUI tools and PowerShell commands.

Prerequisites

Before you begin troubleshooting, ensure you have:

Domain Admin or equivalent privileges on the affected domain controller
Remote Desktop or console access to the affected server
RSAT tools installed, including Active Directory and DFS Management snap-ins
PowerShell 5.1 or later with the DFSR module available
ADSIEDIT.MSC accessible for modifying AD attributes
A second domain controller with healthy SYSVOL replication to serve as a reference partner
A recent System State backup of at least one domain controller (as a safety net)

Understanding DFSR Event ID 4012

Event ID 4012 appears in the Applications and Services Logs > DFS Replication section of Event Viewer. The full event message reads:

The DFS Replication service stopped replication on the folder at local path C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for [number] days, which is longer than the time allowed.

This event fires when one of the following conditions is met:

Journal wrap detected: The USN journal on the volume has been recycled or wrapped, meaning DFSR can no longer track which files changed since its last replication cycle.
Dirty shutdown recovery: The server experienced an unexpected shutdown (power failure, BSOD) and the DFSR database is in an inconsistent state.
Extended disconnection: The domain controller has been offline or unable to reach replication partners for longer than the configured MaxOfflineTimeInDays (default 60 days).
Database corruption: The DFSR database files in the System Volume Information folder have become corrupted.

When this event is logged, DFSR enters a stopped state for the affected replication folder. It will not automatically resume replication — you must intervene manually.

Impact on Your Environment

The consequences of unresolved Event ID 4012 are significant:

Group Policy inconsistency: Clients authenticating against the affected DC receive outdated or missing GPOs
Logon script failures: Scripts stored in SYSVOL\scripts may be missing or outdated
DFSR backlog growth: Partner DCs accumulate a growing backlog of changes waiting to replicate
Authentication issues: In severe cases, Kerberos policies and certificate auto-enrollment settings diverge

Diagnosing the Issue

Start your diagnosis by gathering information from multiple sources. Run these commands from an elevated PowerShell session on the affected domain controller.

Check DFSR Replication State

# Check the replication state across all DCs
Get-DfsReplicationGroup | Get-DfsReplicatedFolder | Get-DfsrState

# Check specifically for SYSVOL replication
Get-DfsReplicationGroup -GroupName "Domain System Volume" |
    Get-DfsReplicatedFolder |
    Get-DfsrState

The output shows each member’s replication state. Look for entries where the State column shows Stopped or In Error.

Query the Event Log with PowerShell

# Pull the last 10 DFSR Event ID 4012 entries
Get-WinEvent -FilterHashtable @{
    LogName = 'DFS Replication'
    Id = 4012
} -MaxEvents 10 | Format-List TimeCreated, Message

# Check for related events (4010, 4012, 4014)
Get-WinEvent -FilterHashtable @{
    LogName = 'DFS Replication'
    Id = 4010, 4012, 4014
} -MaxEvents 20 | Format-Table TimeCreated, Id, Message -Wrap

Run DFSRDIAG Diagnostics

# Check overall replication state
dfsrdiag ReplicationState

# Check the replication backlog between two DCs
dfsrdiag Backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /sendingmember:DC01 /receivingmember:DC02

# Force DFSR to poll Active Directory for configuration changes
dfsrdiag PollAD

# Check if the SYSVOL and NETLOGON shares exist
Get-SmbShare | Where-Object { $_.Name -match 'SYSVOL|NETLOGON' }

# Compare SYSVOL content between DCs
$dc1 = Get-ChildItem "\\DC01\SYSVOL\domain\Policies" -Recurse | Measure-Object
$dc2 = Get-ChildItem "\\DC02\SYSVOL\domain\Policies" -Recurse | Measure-Object
Write-Host "DC01 items: $($dc1.Count) | DC02 items: $($dc2.Count)"

Authoritative vs Non-Authoritative Sync Comparison

Before proceeding with the fix, you need to decide which type of synchronization to perform. The choice depends on which domain controller has the correct SYSVOL data.

Aspect	Authoritative Sync	Non-Authoritative Sync
When to use	The affected DC has the correct SYSVOL data	A healthy partner has the correct data
Data flow	Affected DC pushes its data to all partners	Affected DC pulls data from a partner
msDFSR-Options value	Set to 1 on the authoritative DC	Leave as default (no change)
Risk level	Higher — overwrites all partner replicas	Lower — only the local copy is rebuilt
Typical scenario	PDC Emulator has the correct policies	Secondary DC lost SYSVOL after crash
AD attribute changes	msDFSR-Enabled + msDFSR-Options	msDFSR-Enabled only
Recovery time	Longer (all partners re-sync from this DC)	Shorter (only local DC re-syncs)
Use on PDC Emulator	Yes, this is the most common case	Rarely — only if PDC data is corrupt

General rule: If only one or a few DCs have Event ID 4012, perform a non-authoritative sync on those DCs. If SYSVOL is broken across multiple DCs, perform an authoritative sync from the DC with the best data (usually the PDC Emulator).

Step-by-Step Resolution

Non-Authoritative Sync (Most Common)

Use this when the affected DC needs to re-download SYSVOL from a healthy partner.

Step 1: Open ADSIEDIT.MSC on the affected domain controller or a management workstation.

Step 2: Navigate to the DFSR subscription object:

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

Step 3: Set msDFSR-Enabled to FALSE.

Step 4: Force Active Directory replication across all domain controllers:

# Force replication from all partners
repadmin /syncall /APed

Step 5: Run DFSRDIAG POLLAD on the affected DC:

dfsrdiag PollAD

Verify that Event ID 4114 appears in the DFS Replication log, confirming DFSR acknowledged the configuration change.

Step 6: Set msDFSR-Enabled back to TRUE in ADSIEDIT.MSC on the same DN.

Step 7: Force AD replication again and run DFSRDIAG POLLAD:

repadmin /syncall /APed
dfsrdiag PollAD

Step 8: Verify recovery by checking for Event IDs:

4614: “The DFS Replication service initialized SYSVOL” (initial sync started)
4604: “The DFS Replication service successfully initialized SYSVOL” (sync completed)

Get-WinEvent -FilterHashtable @{
    LogName = 'DFS Replication'
    Id = 4604, 4614
} -MaxEvents 5 | Format-List TimeCreated, Message

Authoritative Sync

Use this when the affected DC has the correct data and should push it to all partners.

Follow the same steps as above, but in Step 6, before setting msDFSR-Enabled back to TRUE, also set msDFSR-Options to 1 on the authoritative DC’s SYSVOL Subscription object. This flag tells DFSR that this server’s copy is authoritative and all partners should sync from it.

After the authoritative DC recovers (Event 4602/4604), perform a non-authoritative sync on every other domain controller to pull the authoritative data.

Real-World Scenario

You manage a multi-site Active Directory environment with five domain controllers: DC01 (PDC Emulator) in the main office, DC02 and DC03 at branch offices, DC04 in a disaster recovery site, and DC05 as a read-only domain controller. After a storage failure at the branch office, DC02 was rebuilt from bare metal and rejoined to the domain. Two days later, the help desk reports that users at the branch office are not receiving the latest Group Policy settings.

You log into DC02 and find Event ID 4012 in the DFS Replication log. Running Get-DfsrState confirms that SYSVOL replication is stopped on DC02. The SYSVOL share exists but contains only a partial set of GPOs.

Your plan: perform a non-authoritative sync on DC02. You open ADSIEDIT.MSC, navigate to DC02’s DFSR-LocalSettings, set msDFSR-Enabled to FALSE, force AD replication with repadmin /syncall /APed, and run dfsrdiag PollAD. Event 4114 confirms DFSR stopped. You set msDFSR-Enabled back to TRUE, force replication again, and run PollAD. Within minutes, Event 4604 appears — SYSVOL has been reinitialized. You verify by comparing the policy count in DC02’s SYSVOL share against DC01’s, and the numbers match. Group Policy is flowing correctly again.

Gotchas and Edge Cases

Journal wrap on large volumes: If the USN journal has wrapped, you may see Event ID 4012 alongside Event ID 4010. Simply resetting msDFSR-Enabled may not be enough — you might also need to delete the DFSR database. Stop the DFSR service, delete the files in C:\System Volume Information\DFSR\ on the affected volume, then restart DFSR before performing the non-authoritative sync.

Dirty shutdown and database corruption: After a BSOD or unexpected power loss, the DFSR database may be flagged as dirty. Event ID 2213 often accompanies 4012 in this case. The recovery procedure is the same as for journal wrap — stop DFSR, clear the database, and perform a non-authoritative sync.

MaxOfflineTimeInDays exceeded: If a DC has been offline for more than 60 days (the default), DFSR refuses to replicate even after reconnecting. You can temporarily increase this value using PowerShell before performing the sync:

# Increase max offline time to 120 days temporarily
Set-DfsReplicationGroup -GroupName "Domain System Volume" -Description "Temp increase" |
    Set-DfsrMembership -MaxOfflineTimeInDays 120

Read-Only Domain Controllers (RODCs): RODCs replicate SYSVOL in a one-way direction. If an RODC shows Event 4012, the fix is always non-authoritative. Never attempt an authoritative sync from an RODC.

Multiple DCs affected simultaneously: If more than half your DCs have stopped replicating SYSVOL, start with the PDC Emulator. Perform an authoritative sync on the PDC first, then systematically perform non-authoritative syncs on the remaining DCs one at a time, waiting for Event 4604 on each before proceeding to the next.

Windows Server 2012 R2 vs 2016+: On Server 2016 and later, DFSR can recover from some journal wrap scenarios automatically. However, Event ID 4012 still requires manual intervention regardless of the OS version.

Troubleshooting

Event 4012 keeps reappearing after the fix: This usually indicates an underlying disk or volume issue. Check the System event log for disk errors (Event IDs 7, 11, 51, 153). Run chkdsk /f on the volume hosting SYSVOL. If the volume is on a virtual disk, verify the virtual storage health.

DFSRDIAG POLLAD hangs or returns an error: Ensure the DFSR service is running (Get-Service DFSR). If it is stopped, start it before running PollAD. If the service fails to start, check for DFSR database locks in System Volume Information\DFSR\.

Event 4614 appears but 4604 never follows: The initial sync has started but is not completing. Check network connectivity between the affected DC and its replication partners. Verify that TCP port 5722 (DFSR) and the ephemeral RPC ports are open in the firewall.

SYSVOL share disappears after the fix: The NETLOGON and SYSVOL shares may not reappear until DFSR finishes the initial sync and sets the SYSVOL ready flag. Wait for Event 4604 and then run net share to verify. If shares still do not appear, restart the Netlogon service:

Restart-Service Netlogon

Replication backlog remains high: After recovery, check the backlog between the fixed DC and its partners:

dfsrdiag Backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /sendingmember:DC01 /receivingmember:DC02

If the backlog does not decrease, verify that the DFSR service is running on both sides and that AD replication is healthy using repadmin /replsummary.

Summary

Event ID 4012 means DFSR has stopped replicating a folder (usually SYSVOL) and will not resume without manual intervention
Common causes include journal wrap, dirty shutdown, database corruption, and extended offline time exceeding MaxOfflineTimeInDays
Use Get-DfsrState, dfsrdiag, and Event Viewer to diagnose the scope and root cause
Choose non-authoritative sync when the affected DC should pull SYSVOL from a healthy partner (most common fix)
Choose authoritative sync when the affected DC has the correct SYSVOL data and should push it to all partners
The fix involves toggling msDFSR-Enabled in ADSIEDIT.MSC, forcing AD replication, and running DFSRDIAG POLLAD
Verify recovery by checking for Event ID 4604 in the DFS Replication log
For persistent issues, investigate disk health, network connectivity on TCP port 5722, and DFSR database integrity