1. Change the default unexpected shutdown handling policy from auto-recovery to manual-recovery, so the default behavior requires a manual user approval to go ahead with unexpected shutdown recovery. This was done to allow a user to take a backup of existing replicated folders on the volume before the recovery operation.
2. Support manually resuming the unexpected shutdown recovery and replication of the replicated folder(s) in a volume, using a WMI method. The command(*) to do that is:
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="<volume-GUID>" call ResumeReplication
3. Support setting the default behavior back to automatic unexpected shutdown recovery, as in Windows Server 2008. The command for this:
wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE
To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command:
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="0D9806D1-AC1A-11E1-98C3-00155D4FBB00" call ResumeReplication
a. If the hash value for the local file matches the value returned by a remote replication partner for the same file, it means that the local file version is correct. In that case, DFSR clears the “Initial Sync” fence value to “Default” in the local DFSR database for that file.
b. If the hash value for the local file does not match the value returned by a remote replication partner for the same file, it means that the local file version is not correct. The remote data is always considered authoritative in this case. So DFSR moves the local file to <ReplicatedFolderPath>DfsrPrivateConflictAndDeleted folder, and installs the remote version of the file in its place.
a) The local copy of replicated folder data for the server going through unexpected shutdown recovery is never considered “authoritative”, remote data is considered more trustworthy wherever a local file version does not match that of a replication partner.
b) At the end of an unexpected shutdown recovery, a local file or a folder may end up in one of four states:
1. Left just where it was, if the local file or folder is identical to that on the remote replication partner, OR,
2. It may move to DFSR-private ‘Pre-existing’ folder, if the local file or folder does not exist on a remote replication partner, OR,
3. It may move to DFSR-private ‘Conflict And Deleted’ folder, if the local copy is different from that on the remote replication partner, OR,
4. It may move to DFSR-private ‘Conflict And Deleted’ folder and then get purged. This is due to the quota size and high watermark configured on the ‘Conflict And Deleted’ folder. The “least recently used” content in ‘Conflict And Deleted’ folder is purged when the high watermark is reached for the folder, until the folder size drops down to configured low watermark. The DFS Replication service enforces the configured size and the watermarks on this folder as a machine-local activity; this does not involve remote replication partners. You can read more about this in the TechNet article Staging folders and Conflict and Deleted folders .
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.