From LedHed's Wiki
Jump to: navigation, search
(Created page with "Microsoft introduced DFS in Windows 2003 R2 (as a replacement for the old File Replication Service FRS) The default behavior for 2003 R2 - 2008 R2 was for DFS to "AutoRecover...")
 
 
(2 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
The default behavior for 2003 R2 - 2008 R2 was for DFS to "AutoRecover" from a unexpected "Dirty" shutdown.
 
The default behavior for 2003 R2 - 2008 R2 was for DFS to "AutoRecover" from a unexpected "Dirty" shutdown.
  
In true Microsoft form they changed the default behavior in a Jan/2012 [http://support.microsoft.com/kb/2663685 hotfix KB2663685]
+
In true Microsoft form they changed the default behavior in a Jan/2012 [http://support.microsoft.com/kb/2663685 Hotfix KB2663685].
 +
This hotfix disables "AutoRecovery" after a dirty shutdown. This has some major implications in that if an administrator doesn't know a system suffered a power failure, DFS will be broken which can cause SYSVOL replication to stop and thus prevent GPO propagation.
 +
Whats even worse is that Microsoft made this the default behavior in Windows 2012 (and presumably hence forth). On the bright side the MS Event ID for failed DFS replication (Event ID 2213) clearly describes the necessary steps to initiate DFS recovery.
  
 +
The command looks something like this:
 +
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="2F13E795-5EF6-12E5-92E7-876E6E0F1169" call ResumeReplication
 +
NOTE: the '''''volumeGuid''''' will be different on your system.
 +
 +
 +
If you don't want this to be the default behavior you can re-enable DFS "AutoRecovery" by running the following WMIC command:
 +
wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE
 +
 +
OR
 +
 +
You can enable this via Group Policy Preferences by setting the following Registry Key, and applying the GPP to the 'Domain Controllers' OU.
 +
Path: HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters
 +
Key:  StopReplicationOnAutoRecovery
 +
DWord: 0
 +
 +
 +
 +
== References ==
 +
http://blogs.technet.com/b/filecab/archive/2012/07/23/understanding-dfsr-dirty-unexpected-shutdown-recovery.aspx
  
 
[[Category:DFS]]
 
[[Category:DFS]]

Latest revision as of 08:15, 7 December 2013

Microsoft introduced DFS in Windows 2003 R2 (as a replacement for the old File Replication Service FRS)

The default behavior for 2003 R2 - 2008 R2 was for DFS to "AutoRecover" from a unexpected "Dirty" shutdown.

In true Microsoft form they changed the default behavior in a Jan/2012 Hotfix KB2663685. This hotfix disables "AutoRecovery" after a dirty shutdown. This has some major implications in that if an administrator doesn't know a system suffered a power failure, DFS will be broken which can cause SYSVOL replication to stop and thus prevent GPO propagation. Whats even worse is that Microsoft made this the default behavior in Windows 2012 (and presumably hence forth). On the bright side the MS Event ID for failed DFS replication (Event ID 2213) clearly describes the necessary steps to initiate DFS recovery.

The command looks something like this:

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="2F13E795-5EF6-12E5-92E7-876E6E0F1169" call ResumeReplication

NOTE: the volumeGuid will be different on your system.


If you don't want this to be the default behavior you can re-enable DFS "AutoRecovery" by running the following WMIC command:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE

OR

You can enable this via Group Policy Preferences by setting the following Registry Key, and applying the GPP to the 'Domain Controllers' OU.

Path: HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters
Key:  StopReplicationOnAutoRecovery
DWord: 0


References

http://blogs.technet.com/b/filecab/archive/2012/07/23/understanding-dfsr-dirty-unexpected-shutdown-recovery.aspx