DFSR SYSVOL Migration FAQ: Useful trivia that may save your follicles
Hi, Ned here again. Today I'm going to go through some well-hidden information on DFSR SYSVOL migration; hopefully this sticks in your brain and someday allows you to enjoy your weekend rather than spending it fighting issues.
As you already know, Windows Server 2008 introduced the ability to use Distributed File System Replication (DFSR) to replicate your SYSVOL folder, rather than the legacy File Replication Service (FRS). And there was much rejoicing. The step-by-steps for this process are documented here:
1: SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process
2: SYSVOL Migration Series: Part 2 – Dfsrmig.exe: The SYSVOL migration tool
3: SYSVOL Migration Series: Part 3 – Migrating to the ‘PREPARED’ state
4: SYSVOL Migration Series: Part 4 – Migrating to the ‘REDIRECTED’ state
5: SYSVOL Migration Series: Part 5 – Migrating to the ‘ELIMINATED’ state
(And before you get wound up in the Comments section - Yes, there is a TechNet Whitepaper for this coming just as soon as we can get it published! Don't hurt me!)
So let's run through some Q & A.
Q: What are the Domain Controller availability requirements during my migration?
A: There are a couple.
1. The PDC Emulator must be online any time the DFSRMIG tool is being invoked for a read or write operation. If the PDC Emulator is offline or inaccessible for LDAP, the user of DFSRMIG will receive:
“Unable to connect to the Primary DC’s AD.
Please make sure that the PDC is reachable and try the command later.”
2. All DCs must remain online until they each complete their state steps. All DCs do not need to be accessible simultaneously. But the global state will never reach the Prepared, Redirected, or Eliminated state until all DCs have been able to complete their individual phases.
The PDC Emulator requirement is because by default, administrators always edit group policy on the PDCE, so in most environments it will have the most up to date knowledge of policy. That and we need to talk to someone unique, so it might as well be him.
It is recommended that a SYSVOL migration not be attempted unless all DCs are online and available. Change control blackouts should be scheduled to prevent modification to DCs that might impact their availability. This will minimize the window of time that the migration will take.
Q: Is there some super-secret way to return to using FRS after reaching the Eliminated phase of DFSR migration?
A: Microsoft does not support returning your domain to using FRS for SYSVOL replication after a completed DFSR migration (except to rebuild the domain). This is why the steps are done in a phased approach with two checkpoints where you can revert back to FRS without any consequences. Once you trigger the ELIMINATED phase to start, there is no going back, period.
Q: When does Robocopy run during the migration and what does it do?
A: The DFSR service uses robocopy at several stages to synchronize SYSVOL directories outside of normal replication when it detects a SYSVOL migration is underway; a set of ‘pre-seeding’ and ‘save the GP admins from themselves’ operations.
1. When Prepared state (DFSRMIG /SETGLOBALSTATE 1) is invoked, all DC’s robocopy their FRS SYSVOL data locally into the new DFSR content set. This is equivalent to ‘pre-seeding’ data and ensures that minimal file replication occurs to converge the content set. This is triggered by the DFSR service itself when:
- AD replication has converged between a DC and the PDCE.
- The DFSR service on that DC has polled (this runs every 5 minutes) and picks up the state change from CN=dfsr-LocalSettings
2. When entering the Redirected state, the PDC Emulator (only) robocopies the local differences of FRS SYSVOL data into the new local DFSR content set, on itself. The other servers receive new data via replication.
3. If you undo the Redirected state back to Prepared, the reverse happens. The PDC Emulator robocopies its local DFSR content set data into its local FRS content set. FRS replication synchronizes all other servers... eventually. Allow more time for this than entering Redirected, as FRS is not as fast to synchronize as DFSR.
For sharp-eyed readers: we won’t run into any of the old pre-seeding issues (the file hash being changed by robocopy) here because DFSR correctly creates the SYSVOL_DFSR folder ACL, so there are no inheritance issues when the contents are copied in and replicated.
Q: Event 8004 says something about RODC's. I don't have any RODC's. What the frak ?
A: The following event is incorrectly written in the DFSR event log(s) on servers that are not Read-only Domain Controllers when setting elimination state using DFSRMIG.EXE:
| Log Name: DFS ReplicationSource: DFSRDate: 9/28/2007 11:53:46 AMEvent ID: 8004Task Category: NoneLevel: InformationKeywords: ClassicUser: N/AComputer: <WRITABLE DC>Description:The NTFRS member object for the Read-only Domain Controller <WRITABLE DC> was deleted successfully. |
Well, it finally happened – we had a bug. No, no, don’t try to tell me it’s not possible, it was bound to occur someday. :)
The text in the event log is completely cosmetic and benign. It is supposed be fixed in a later version of the OS. Just ignore it.
Q: What are all the AD and Registry state values that will be set at a given point in the migration?
A: Ok, you asked for it buddy.
=============
1. Prepared Phase - DFSRMIG /SETGLOBALSTATE 1
a. DFSRMIG contacts the PDC Emulator directly.
b. Global objects are created under:
CN=DFSR-GlobalSettings,CN=SYSTEM,DC=<domain>
CN=DOMAIN SYSTEM VOLUME
CN=SYSVOL SHARE
CN=CONTENT
CN=TOPOLOGYc. CN=DFSR-GlobalSettings now has msDFSR-Flags attribute set to 0.
d. As DC's pick up the globalstate change via AD replication and DFSR service polling, they create and write to registry entry:
HKLMSystemCurrentControlSetServicesDFSRParametersSysvolsMigrating Sysvols
Local State = 4 [REG_DWORD]e. The PDC Emulator creates the:
CN=dfsr-LocalSettings,CN=<servername>,DC=<domain>
objects for all DCs and sets this attribute to:
msDFSR-Flags = 80 (if RWDCs).
msDFSR-Flags = 64 (if RODCs - the RODC itself will set it to 80 later).f. The DFSR service has now started and created the new local SYSVOL_DFSR structure. Robocopy has made a local copy of the FRS SYSVOL. All AD topology data has been written in to support the content set. Initial sync of the data has started (since robocopy has locally pre-seeded the data this should involve minimal replication data on the network). The registry on all DC's is:
Local State = 5 [REG_DWORD]
g. Once initial sync is done on all DCs:
Local State = 1 [DWORD]
'msDFSR-Flags' (on CN=dfsr-LocalSettings) = 16h. If DFSRMIG /GETGLOBALSTATE returns that all DCs are prepared, 'msDFSR-Flags' on CN=dfsr- GlobalSettings has changed to 16 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with FRS being shared as SYSVOL.
=============
2. Redirected Phase - DFSRMIG /SETGLOBALSTATE 2
a. DFSRMIG contacts the PDC Emulator directly.
b. CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 96 on all DCs and this replicates out through AD.
c. As DCs pick up the attribute from AD replication, their DFSR service sets:
Local State = 6 [REG_DWORD]
d. On the PDC Emulator only, robocopy syncs any changes between the FRS and DFSR's content sets, and this is replicated out through DFSR.
e. Once SYSVOL data is in sync, SYSVOL content set is set to be the active SYSVOL share on all servers. FRS and DFSR are both still replicating data.
f. When this is complete, for each DC:
Local State = 2 [DWORD]
'msDFSR-Flags' (on CN=dfsr-LocalSettings) = 32g. If DFSRMIG /GETGLOBALSTATE returns that all DCs are redirected, 'msDFSR-Flags' on CN=dfsr- GlobalSettings has changed to 32 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with DFSR being shared as SYSVOL.
==============
3. Eliminated Phase - DFSRMIG /SETGLOBALSTATE 3
a. DFSRMIG contacts the PDC Emulator directly. At this point it is not possible to undo the changes!
b. CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 112 on all DCs and this replicates throughout AD.
c. As DCs pick up the attribute from AD replication, their DFSR service sets:
Local State = 7 [REG_DWORD]
d. On the PDC, the FRS content set information is removed and this is replicated through AD. As each DC sees this change, their FRS service stops replicating the FRS content set. The FRS service is stopped (and restarted if custom FRS sets still exist on a given server).
e. When this is complete, for each DC:
Local State = 3 [DWORD]
'msDFSR-Flags' (on CN=dfsr-LocalSettings) = 48f. If DFSRMIG /GETGLOBALSTATE returns that all DCs are eliminated, 'msDFSR-Flags' on CN=dfsr-GlobalSettings has changed to 48 because all DCs are prepared. All DCs are currently replicating DFSR only.
g. A final cleanup task on each DC will set their 'msDFSR-Flags' on CN=dfsr-LocalSettings to <NOT SET>. The same will happen from the PDC to CN=dfsr-GlobalSettings.
==============
If any 'undo' phases are entered (where an administrator has decided to go from redirected back to prepared, redirected back to start, or prepared back to start), the flow above happens in reverse, with the exception that the following two entries exist in the 'Local State' registry entries:
8 (Undo Redirecting)
9 (Undo Preparing)
Q: I'm not a huge fan of Ultrasound. Are there any other ways to validate the health of SYSVOL prior to and after migration?
A: Sure thing - already discussed in a previous blog post here.
Q: Are there any migration KBs or bugs I need to worry about?
A: One KB, with a simple solution to domains that have non-standard (and frankly, not any safer than default) security configurations: https://support.microsoft.com/kb/2567421
And that’s it. If you have any questions on DFSR SYSVOL migration not covered by this blog post or by the FileCab step-by-step guide, don’t hesitate to start swinging in the Comments section below.
- Ned “Working on Windows 7 Beta But Still Has An Unnatural Love for Win2008 DFSR” Pyle
Comments
Anonymous
January 05, 2009
Excellent Post - thank you! I want to share an experience I had recently: I had an issue at a customer site , were all the RODC computer accounts were located in a Sub-OU to the "Domain Controllers" OU(reason is they have a separate GPO for the RODCs). This caused errors in DFSRMIG Phase1. The error was "Error 87:The parameter is incorrect" - very helpful by the way :-) After digging deeper into the Migration Logs I found the reason: DFSRMIG could not create replication objects for all the RODCs, because it expected the RODC computer accounts in the "Domain Controllers" OU...so after moving all the RODC to this OU, Phase 1 completed successfully. And even after I moved the computer accounts back to the Sub-OU it works... Regards Christian SchindlerAnonymous
January 05, 2009
The comment has been removedAnonymous
January 06, 2009
The comment has been removedAnonymous
January 06, 2009
The comment has been removedAnonymous
January 06, 2009
The comment has been removedAnonymous
January 06, 2009
Ahh, cool. I figured that the new SYSVOL name in 2008 was SYSVOL_DFSR. I will demote and re-promote. And nope, it doesn't matter from a technical perspective, I am just a bit of a perfectionist and want things to be neat and tidy.Anonymous
January 06, 2009
The comment has been removedAnonymous
January 07, 2009
The comment has been removedAnonymous
January 07, 2009
The comment has been removedAnonymous
May 01, 2009
The comment has been removedAnonymous
May 14, 2009
It’s come to my attention (in a blunt object kind of way) that you’ve been waiting to migrate from WindowsAnonymous
February 26, 2015
Hey y'all, Mark, Tom and Hilde back for another mailbag. Astute readers and or those that have access