The introduction of Windows 2008 brought us the famous Read-Only domain controller, the domain controller without passwords (unless explicitly approved) and one-way replication. That one-way replication also applied to the SYSVOL share. Sysvol is replicated by either FRS or DFSR depending on the initial setup of the domain. If you have upgraded your domain from Windows 2000 or Windows 2003 to Windows 2008 SYSVOL is still using FRS to replicate. When you have initially deployed Windows 2008 and set the forest functional level to use the Windows 2008 standards; DFSR is used. Usually the replication of Sysvol is two-way, you can change the contents on each domain controller and those changes are replicated to all domain controllers.
If you made changes to the SYSVOL folder on an RODC (2008), however, these changes are overwritten with the next replication cycle when you have DFSR. When you have a Windows 2008 R2 RODC the SYSVOL share will automatically be marked as read-only so you cannot make any changes.
When you have a mixed 2003/2008 domain, or did not start with the forest functional level at 2008; SYSVOL still replicates through the FRS method, and in that case horrible things can occur: If you change a file on the RODC SYSVOL that replicates through the FRS method the file get’s stamped placed in the queue for outbound replication (which will never occur) and if you make enough changes the FRS on the RODC will actually shutdown! In any case, the changed file will never go outbound. To circumvent this behavior some Administrators ACL’d the SYSVOL on the Read Only domain controller, but again, those changes are also marked for outbound delivery. In any case, if you are running in a mixed environment, upgrade those last domain controllers and do not forget to migrate your SYSVOL to use DFSR.
Why?
DFSR is more efficient, scalable and reliable; it uses Differential replication with compression instead of replicating the entire file. It is more flexible (scheduling/bandwidth throttling wise) and even better has a self-healing mechanism that protects is from database corruptions! No more D0, or D5’s needed.
How do you migrate?
The sysvol migration can be achieved through the DFSRMIG program. This little program requires the domain to be in forest functional level 2008. There are 4 steps in migrating the SYSVOL replication technique. These steps are 0 to 3 and are:
0 – Start
1 – Prepare
2 – Redirect
3 – Eliminate
When we give the order to prepare for the migration, each domain controller will actually create a new SYSVOL folder and fill that up with the contents of the current SYSVOL folder, replication for that folder will start automatically. The new Sysvol folder (called SYSVOL_DFSR) will be created on the same location as the current SYSVOL folder. If you have for example places SYSVOL on D:, the new folder will be D:SYSVOL_DFSR.
In the redirect state the share is swapped on each domain controller and you are actually running your sysvol with DFS Replication. In the eliminate phase the old SYSVOL is deleted and FRS is stopped for Sysvol replication.
DFSRMig /setGlobalState 0 is the starting point, to verify the global state of the migration, use the /getMigrationState command. This will tell you if all domain controllers in the domain have reached the state you wanted and if not, which ones are still out of Sync.
If you want to know the last command (and state you have ordered), use the /getGlobalState option
The process is coordinated by the PDC emulator domain controller, therefore it could take a while before all domain controllers are in sync. You can actually force the process a bit by forcing replication using the command: repadmin /syncall /AeD, then force the DFSR to poll the Active Directory for changes: dfsrdiag polladd /Member:<dc>
Well you can continue to set the Global State to 3 to finish the migration. If you want to roll-back however, please do so before state 3 by setting the previous state. After state 3 there’s no way back.
If you want more information on where the current SYSVOL is hosted, and where the new location is aswell as other info on the DFSR use the DFSRDiag DumpADCfg command
Continue all the steps above until you have completed migration state 3.
If you want more info.. go to the Storage Team Blog: