DFSR Event ID 2213 Leaves SYSVOL Replication Suspended After Unexpected Shutdown

Isabella Brown 20 Reputation points
2026-09-12T01:48:38.2666667+00:00

We experienced an unplanned power outage that caused several Domain Controllers to shut down without a clean shutdown. After the servers came back online, DFSR Event ID 2213 was logged and SYSVOL replication remained suspended.

The affected DCs are operational, but changes to SYSVOL are no longer replicating between domain controllers. We want to recover the DFSR database and resume replication without performing an authoritative SYSVOL recovery or unnecessarily forcing a full synchronization.

What is the safest procedure to recover the affected DFSR databases and resume SYSVOL replication using the ResumeReplication WMI method? What validation steps should we perform first to make sure the recovery does not introduce SYSVOL or replication inconsistencies?

Windows for business | Windows Server | Directory services | Active Directory
0 comments

2 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Chen Tran 12,770 Reputation points Independent Advisor
    2026-09-12T03:07:19.23+00:00

    Hello Isabella Brown,

    Thank you for posting question on Microsoft Windows Forum!

    Well! When a Domain Controller experiences a dirty shutdown, the DFS Replication service intentionally pauses replication on the affected volume and logs Event ID 2213. This is a built-in protection mechanism to prevent potential Jet database corruption from propagating across your domain.

    Before instructing DFSR to resume, it is recommended to verify the following points to make sure that the underlying infrastructure is healthy and secure a rollback point.

    • Since SYSVOL replication relies heavily on a healthy AD topology. Run repadmin /showrepl and repadmin /replsummary in an elevated command prompt. Ensure there are no inbound or outbound AD replication failures.
    • Backup the Local SYSVOL Folder by creating a flat-file copy of the C:\Windows\SYSVOL directory on the affected DCs to a temporary location. If the recovery process encounters fatal database corruption and forces a non-authoritative synchronization that drops files into the DfsrPrivate\ConflictAndDeleted folder, you will have a pristine backup of your GPOs and logon scripts.
    • To identify the Volume GUID by opening the DFS Replication event log on the affected DC and locate Event ID 2213. The description will explicitly list the VolumeGuid. Copy this exact string.

    Once the pre-checks are clear, you can instruct the DFSR service to perform a consistency check, rebuild the database if necessary, and resume replication. Please note: It is very important not to restart the DFSR service or the server during this phase. DFSR is verifying the database against the file system, which takes time depending on the size of your SYSVOL directory. it is advised to monitor consistently the DFS Replication Event Log for the Event ID 2212 which indicates that the DFSR service has started the database recovery/rebuild process, event ID 2214 which confirms the database recovery has completed successfully and event ID 4602 (or 4614) which confirms the SYSVOL replicated folder has successfully initialized and is now actively participating in replication.

    Please note: If several DCs received 2213 from the same power outage, treat each affected volume/DC independently. Don't assume that because one DC successfully resumes, every other DC is safe to resume without checking its own 2213, SYSVOL state, and DFSR errors.

    You can consult the following article for further reference.

    Hope the above information is helpful!

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-09-12T01:49:00.8+00:00

    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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.