Article ID: 2846759 - View products that this article applies to.
Microsoft has introduced new functionality to the DFS Replication (DFSR) service for Windows Server 2008 R2 through hotfix 2663685
(http://support.microsoft.com/kb/2663685/EN-US). After you install hotfix 2663685 or a later version of Dfsrs.exe in Windows Server 2008 R2, the DFSR Service no longer performs automatic recovery of the Extensible Storage Engine (ESE)) database after the database experiences a dirty shutdown. Instead, when the new DFSR behavior is triggered, event ID 2213 is logged in the DFSR log. A DFSR administrator must manually resume replication after a dirty shutdown is detected by DFSR.
Windows Server 2012 exhibits this behavior by default.
The DFSR service maintains one ESE database per volume on volumes that host a replicated folder. DFSR uses this database to store metadata about each file and folder in the replicated folder. The integrity of the database must be maintained to make sure that the service continues to work correctly.
When DFSR is notified that the service must shut down, it starts to commit all outstanding changes to the ESE database. Dirty shutdown in DFSR occurs when the DFSR service cannot commit all pending changes to the DSFR ESE database before the DFSR service is shut down. During startup, the DFSR service checks the integrity of the database.
Dirty shutdown recovery may cause large backlogs, and these, in turn, may cause replication conflicts. In some cases, before the fix in hotfix 2780453
(http://support.microsoft.com/kb/2780453)was released, the winning file may not be the version that the end-user wants. The update to stop replication during dirty shutdown was intended as a safeguard that lets administrators back up the data to capture deltas since the last backup was taken before replication is resumed.
After you install hotfix 2780453, you no longer have to pause replication during a dirty shutdown. The fix from hotfix 2780453
(http://support.microsoft.com/kb/2780453)is included in all Windows 2012 default media.
Best practicesBest practices for AutoRecovery based on server role, OS, and patch level
Collapse this tableExpand this table
How to disable the Stop Replication functionality in AutoRecovery
To have DFSR perform AutoRecovery when a dirty database shutdown is detected, edit the following registry value after hotfix 2780453
(http://support.microsoft.com/kb/2780453)is installed in Windows Server 2008 R2. You can deploy this change on all versions of Windows Server 2012. If the value does not exist, you must create it.
Key: HKLM\System\CurrentControlSet\Services\DFSR\ParametersHow to resume replication after event 2213 is logged
After event 2213 is logged, an administrator must run a WMIC command in order to resume replication. The command specifics are provided in the text of event ID 2213
Step 1: Event ID 2213 is logged on your DFSR server.
Event Type: Warning
Step 2: Copy the WMIC command from step 2 in event ID 2213 recovery steps, and then paste it into an elevated command prompt. When the command runs successfully, it returns the following results:
wmic /namespace:\\root\microsoftdfs pathdfsrVolumeConfig where volumeGuid="F1CF316E-6A40-11E2-A826-00155D41C919" call ResumeReplicationNote for PowerShell users: You have to add single quotation marks to the WMIC command to run it from PowerShell, as follows:
wmic /namespace:\\root\microsoftdfs pathdfsrVolumeConfig where ‘volumeGuid="F1CF316E-6A40-11E2-A826-00155D41C919"’ call ResumeReplicationStep 3: Check whether event IDs 2212 and 2214 have been logged on the server on which you ran the resume replication command:
Event Type: Warning
Event Type: Warning
Additional note on recovery If you must reinitialize a replicated folder (or perform initial synchronization) after a dirty shutdown, follow these steps:
Steps to reduce the chances of a dirty shutdown
In Windows, a service has 30 seconds to shut down after it receives a shutdown notification. After 30 seconds, the Service Control Manager forces the service to shut down. Where the DFSR service is concerned, a busy hub server may need more than 30 seconds to commit outstanding changes to the database. If the DFSR service does not commit all changes in the 30 seconds that are allotted by the Service Control Manager, the service is forcibly closed, and this triggers a dirty shutdown recovery.
Power outages or any other hard reboot of a DFSR server may also trigger a dirty shutdown recovery. To reduce the chances of a dirty shutdown, make sure that your DFSR servers are connected to an uninterruptible power supply (UPS) to allow them to gracefully shut down.
Extending service shutdown times
On DFSR servers that require more than 30 seconds to shut down, you can use the WaitToKillServiceTimeout value to extend the time period that's allowed for all services to shut down.
A DSFR server that needs more time to shut down typically logs events 2212 and 2214 on most server restarts or restarts of the service. Or if AutoRecovery from a dirty shutdown is enabled, event 2213 is logged on every server restart or restart of the DFSR service.
Note This value is in milliseconds. This example displays five minutes of shutdown time. The value can be increased or decreased as necessary. This value affects all services, not just DFSR. We recommend that you set this value to the lowest value that still gives DFSR sufficient time to shut down cleanly. Use the following process to determine how long your DFSR service needs to shut down:
Article ID: 2846759 - Last Review: June 16, 2014 - Revision: 7.0