DFSR Event ID 2213 Leaves SYSVOL Replication Suspended After Unexpected Shutdown

The safest recovery path is to let DFS Replication recover gracefully from the dirty shutdown state logged as event ID 2213, and avoid deleting the DFSR database or forcing authoritative/non-authoritative SYSVOL recovery unless other error states require it.

1. Validate the current DFSR state on all domain controllers first.
   • Check whether SYSVOL is shared on each DC.
   • Query DFSR state for the SYSVOL Share replicated folder:

      For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state
   

   • Interpret the state values:
     • 0 = Uninitialized
     • 1 = Initialized
     • 2 = Initial Sync
     • 3 = Auto Recovery
     • 4 = Normal
     • 5 = In Error
   • Review the DFS Replication event log on any DC not reporting state 4, especially for event ID 2213.
2. Check whether content freshness protection is also blocking replication.
   • On each affected DC, check MaxOfflineTimeInDays:

      wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
   

   • 60 means content freshness is enabled.
   • 0 means content freshness is disabled.
   • If event ID 4012 is present, that is a different recovery path and requires reinitialization guidance rather than only resuming replication.
3. Back up the files in all replicated folders on the affected volume before resuming replication.
   • This is the key safety step because dirty shutdown recovery can create backlogs and replication conflicts.
   • Failure to back up first may result in data loss from unexpected conflict resolution.
4. Resume replication only on the volumes that logged event ID 2213.
   • Use the exact ResumeReplication WMI command shown in the text of event ID 2213 for that volume.
   • From an elevated command prompt, the documented form is:

      wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="E18D8280-2379-11E2-A5A0-806E6F6E6963" call ResumeReplication
   

   • In PowerShell, add single quotation marks around the where clause, as shown in the event guidance.
   • A successful execution returns ReturnValue = 0.
5. Validate recovery after running ResumeReplication.
   • Check for DFSR event IDs 2212 and 2214 on the server where the command was run.
   • Event ID 2214 indicates completion of dirty shutdown recovery.
   • For SYSVOL scenarios where another DC was waiting on initialization, completion of recovery allows replication to continue and SYSVOL to finish initialization.
6. Recheck SYSVOL replication health across all DCs.
   • Confirm affected DCs move out of paused/error states.
   • Re-run the WMI state query and verify SYSVOL Share reaches state 4 where appropriate.
   • Confirm SYSVOL is shared on each DC.

Important cautions:

• Do not delete the DFS Replication database as a first response. This is discouraged because it makes DFS Replication treat local data as nonauthoritative.
• Do not jump to authoritative or non-authoritative SYSVOL recovery unless the environment is in a different failure state such as content freshness blocking or broader initialization failure.
• If a replicated folder must be reinitialized after dirty shutdown, the documented order is: disable the replicated folder, run the 2213 recovery steps, then enable the replicated folder. If the folder is disabled before the WMIC recovery step, initial synchronization does not occur because the volume manager is offline.

To reduce recurrence, protect DFSR servers with a UPS so the DFSR service has time to shut down cleanly. A forced shutdown can leave the DFSR ESE database in a dirty shutdown state and suspend replication again.

References:

• How to troubleshoot missing SYSVOL and Netlogon shares
• DFSR event ID 2213 in Windows Server 2008 R2