Windows Server · high · Directory & core infrastructure

DFSR event 4012 — replication stopped after exceeding MaxOfflineTimeInDays

A DFS Replication member was offline longer than the configured limit, so DFSR stopped replicating that folder rather than risk resurrecting deleted files.

What you see

Event 4012 in the DFS Replication log. Files stop syncing between servers. On SYSVOL this also means Group Policy stops replicating, which is far more serious than it first appears.

What is actually wrong

The server was down or disconnected for more than 60 days by default. DFSR deliberately refuses to resume because its change journal no longer overlaps.

Codes and articles

4012Event 4012Event 2213Event 5002

Fixes (2)

Resume replication on a data folder

Elevated PowerShell on the affected member30 minutes plus sync timemedium riskreversible

A normal replicated folder. Be aware that resuming will re-replicate deletions that happened while this member was offline.

Confirm the state and read which folder is stopped.

PowerShell

Get-WinEvent -LogName 'DFS Replication' -MaxEvents 30 | Where-Object Id -in 4012,2213,5002 | Format-List TimeCreated, Id, Message

Understand what resuming means: any file deleted on the other members while this one was offline will be deleted here too. If this server has the only copy of something, take a backup of the folder first.
DFSR does not merge — it converges. That is the whole reason it stopped rather than resuming automatically.

Resume the replicated folder using the volume GUID from the event.

PowerShell

$d = Get-WmiObject -Namespace root\microsoftdfs -Class DfsrVolumeConfig -Filter "VolumePath='\\\\.\\C:'"$d.ResumeReplication()

Watch the backlog drain.

PowerShell

dfsrdiag backlog /rgname:"Group" /rfname:"Folder" /smem:SRV01 /rmem:SRV02

Confirm it workedThe backlog reaches zero and event 4012 stops recurring.

PowerShell

dfsrdiag replicationstate /all

If you need to undo itRestore from the backup taken in step 2 if convergence removed something needed.

Rebuild SYSVOL replication with an authoritative restore

Elevated PowerShell on all DCs1–2 hourshigh risknot reversible

SYSVOL is the affected folder. Pick the DC with the SYSVOL contents you trust as authoritative — usually the PDC emulator.

Identify the PDC emulator and confirm its SYSVOL contents are correct.
PowerShell
```
Get-ADDomain | Select-Object PDCEmulator
```
Back up the SYSVOL folder on every DC before touching anything.
PowerShell
```
robocopy C:\Windows\SYSVOL_DFSR D:\sysvol-backup /E
```
This procedure overwrites SYSVOL on every non-authoritative DC from the authoritative one. If the wrong DC is chosen, every DC ends up with the wrong policies.
Stop the DFS Replication service on all DCs.
PowerShell
```
Stop-Service DFSR
```
On the authoritative DC, set msDFSR-Options to 1 on its SYSVOL Subscription object, and set msDFSR-Enabled to FALSE on all DCs' subscriptions.
Start DFSR on the authoritative DC, wait for event 4602, then set msDFSR-Enabled back to TRUE on the others and start their DFSR services.
Force AD replication so the flags propagate.
PowerShell
```
repadmin /syncall /AdeP
```

Confirm it workedEvent 4602 appears on each DC and SYSVOL contents match everywhere.

PowerShell

Get-WinEvent -LogName 'DFS Replication' -MaxEvents 10 | Where-Object Id -eq 4602

If you need to undo itRestore SYSVOL from the backup taken in step 2. There is no in-place undo once the authoritative sync has run.

Reference

DFSR event 4012 — Microsoft Learn ↗

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.