https://techcommunity.microsoft.com/t5/storage-at-microsoft/streamlined-migration-of-frs-to-dfsr-sysvol/ba-p/425405

Migration of FRS to DFSR SYSVOL

Assumptions

1. You already know your way around Active Directory and SYSVOL. If you are new to these technologies, stop reading this blog post and use the DFSR SYSVOL migration guide for your migration instead. It’s much more comprehensive.

2. You already deployed at least Windows Server 2008 to all domain controllers in the domain and there are no remaining Windows Server 2003 or Windows Server 2003 R2 domain controllers.

3. If using Windows Server 2008 or Windows Server 2008 R2 domain controllers, you have deployed the latest version of Robocopy.exe . The latest WS2008 version as of this writing is KB2644882 ; the latest WS2008 R2 is KB2646535 ). This is an optional but recommended step ; it ensures efficient preseeding of data during the migration, but migration still works even without them. If using Windows Server 2012 or later operating systems, there’s no need to update robocopy. For more information, review KB2567421 .

4. You already raised the domain functional level to at least Windows Server 2008, using Domain.msc or the Set-ADDomainMode Windows PowerShell cmdlet.

 

 

 

Some handy advice before you begin

For faster migration performance, be aware of how to make AD performance faster - Repadmin.exe /syncall and change notification are your friends, but like the robocopy patches above, are optional. DFSR migration only goes as fast as AD replication. For instance, this command will force push replication of all partitions while ignoring the schedules (this is a rather sledgehammer example):

 

Repadmin /syncall /force /APed

Furthermore, DFSR SYSVOL only replicates when AD has an open schedule (DFSR does not know about change notification). Ensure you have configured AD site links for continuous replication, if you want DFSR to replicate as fast as change notification.

Finally, DFSR reads and writes its new migration state every 5 minutes on each DC. You can speed this up by using Dfsrdiag.exe pollad or the new Update-DfsrConfigurationFromAD Windows PowerShell cmdlet (if all your DCs are running Windows Server 2012 R2). For the latter, a slick way to update every DC in the domain at once is to combine with the AD cmdlets (this sample is a single wrapped line):

 

Get-ADDomainController -Server corp.contoso.com -Filter * | % { Update-DfsrConfigurationFromAD -ComputerName $_.name -Verbose }

Once you start the migration, running repadmin forced syncs and dfsrdiag forced polls after each migration step will greatly speed up the processing. Or you can just wait and let things happen naturally - that’s fine too.

 

Quick Migration

In this case, the health of AD and SYSVOL on all domain controllers is not known. For instance, you are not using System Center Operations Manager to monitor your domain controllers for AD replication, SYSVOL availability, and free disk space.

The goal of the Quick Migration scenario is to test the conditions of the domain controllers, then migrate SYSVOL to DFSR, with the ability to roll back during the process.

1. Ensure free disk space - The DFSR migration process copies the contents of SYSVOL to a parallel folder called SYSVOL_DFSR, and then shares out that copy during the Redirection phase. This means that on the volume where your SYSVOL exists on domain controllers - typically the C: drive - you need at least as much free space as the size of the current SYSVOL folder, plus a 10% fudge factor. For instance., if your current SYSVOL folder is 2GB (an unusually large SYSVOL), you should ensure that at least 2.2 GB disk space is free on the same volume. Most SYSVOL are only a few hundred MB or less.

An easy way to determine the free disk space on a bunch of remote DCs is with Psinfo.exe -d . Look here for more info. The WMI Win32_LogicalDisk class is also a possibility, such as through Windows PowerShell:

 

Get-WmiObject -Class win32_logicaldisk -ComputerName srv01,srv02,srv03 | FT systemname,deviceid,freespace -auto

You can get fancier here, first looking on each computer to decide which volume hosts SYSVOL and comparing sizes and such, but this is the quick migration guide!

Note: you can greatly decrease the size of your SYSVOL by preventing legacy ADM replication using KB813338 . A hundred group policies with 50 registry settings apiece is unlikely to exceed 5MB total when creating group policies using Windows Vista or later. The ADMX central store and alternatives are available for servicing.

2. Ensure correct security policy - You must ensure that the built-in Administrators group has the “Manage Auditing and Security Log” user right on all your domain controllers. This is on by default, so if it’s not set, someone yanked it. Microsoft does not support removing that, no matter what you may have read elsewhere. To validate, examine the group policy applied to your domain controllers by using Gpresult.exe. For more info, examine KB2567421 .

 

3. Ensure AD replication is working - The DFSR migration depends entirely on each domain controller receiving and sending state changes via AD replication. There are many ways to examine AD health, but the easiest is probably the Active Directory Replication Status Tool . Install the utility and scan your domain for errors; if there are problems, fix them and then continue. Don’t attempt a DFSR migration unless all your domain controllers are replicating AD correctly.

 

Ideally, when you set “Errors Only” mode on, it looks like this:

 

Optionally, you can also verify that FRS replication is working. I wrote a piece on using FRSDiag for this years ago. I don't think it's important to do so, though. Your existing FRS not working isn't going to matter much for this migration as DFSR is going to override it and use the PDC Emulator as the source no matter what stat FRS is in. Fixing FRS issues in order to then throw it away isn't a good use of time.

4. Ensure SYSVOL is shared - DFSR migration naturally depends on SYSVOL itself; it must already be shared and the DC must be advertising and available, or migration at each stage will never complete. The simplest way to check all your domain controllers is with the Dcdiag.exe command using two specific tests:

 

Dcdiag /e /test:sysvolcheck /test:advertising

Don’t attempt a DFSR migration unless all your domain controllers are passing the connectivity, SYSVOL, and advertising tests with no errors.

They should look like this:

 

5. Migrate to Prepared State - Now you will migrate to the Prepared state, where both FRS and DFSR are replicating their own individual copies of SYSVOL, but the FRS copy mounts the SYSVOL and Netlogon shares. On the PDC Emulator domain controller, run (as an elevated domain admin):

 

Dfsrmig /setglobalstate 1

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Prepared state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. Use the following command to see progress:

 

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

 

As I mentioned in the advice section, you can speed this processing up with faster AD replication and DFSR polling.

6. Migrate to Redirected State - Now you will migrate to the Redirected state, where both FRS and DFSR are replicating their own individual copies of SYSVOL, but the DFSR copy mounts the SYSVOL and Netlogon shares. On the PDC Emulator domain controller, run (as an elevated domain admin):

 

Dfsrmig /setglobalstate 2

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Redirected state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. Use the following command to see progress:

 

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

 

7. Migrate to Eliminated State - Finally, you will migrate to the Eliminated state, where DFSR is replicating SYSVOL and FRS is removed. Unlike the Prepared and Redirected states, there is no way to go backwards from this step - once executed, FRS is permanently stopped and cannot be configured again. On the PDC Emulator domain controller, run (as an elevated domain admin):

 

Dfsrmig /setglobalstate 3

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Eliminated state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. Use the following command to see progress:

 

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

 

Your migration is complete.

 

Express Migration

In this case, the health of AD and SYSVOL on all domain controllers is known to be healthy. For instance, you are using System Center Operations Manager to monitor your domain controllers and ensure that AD replication, SYSVOL availability, and free disk space are all nominal.

The goal of the Express Migration scenario is to migrate SYSVOL to DFSR with the ability to roll back during the process.

1. Ensure correct security policy - You must ensure that the built-in Administrators group has the “Manage Auditing and Security Log” user right on all your domain controllers. This is on by default, so if it’s not set, someone yanked it. Microsoft does not support removing that, no matter what you may have read elsewhere. To validate, examine the group policy applied to your domain controllers by using Gpresult.exe . For more info, examine KB2567421 .

2. Migrate to Prepared State - Now you will migrate to the Prepared state, where both FRS and DFSR are replicating their own individual copies of SYSVOL, but the FRS copy mounts the SYSVOL and Netlogon shares. On the PDC Emulator domain controller, run (as an elevated domain admin):

 

Dfsrmig /setglobalstate 1

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Prepared state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. Use the following command to see progress:

 

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

 

As I mentioned in the advice section, you can speed this processing up with faster AD replication and polling.

3. Migrate to Redirected State - Now you will migrate to the Redirected state, where both FRS and DFSR are replicating their own individual copies of SYSVOL, but the DFSR copy mounts the SYSVOL and Netlogon shares. On the PDC Emulator domain controller, run (as an elevated domain admin):

 

Dfsrmig /setglobalstate 2

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Redirected state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. Use the following command to see progress:

 

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

 

4. Migrate to Eliminated State - Finally, you will migrate to the Eliminated state, where DFSR is replicating SYSVOL and FRS is removed. Unlike the Prepared and Redirected states, there is no way to go backwards from this step - once executed, FRS is permanently stopped and cannot be configured again. On the PDC Emulator domain controller, run (as an elevated domain admin):

Dfsrmig /setglobalstate 3

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Eliminated state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. Use the following command to see progress:

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

 

Your migration is complete.

 

Hyper Migration

In this case, the health of AD and SYSVOL on all domain controllers is known to be healthy. For instance, you are using System Center Operations Manager to monitor your domain controllers and ensure that AD replication, SYSVOL availability, and free disk space are all nominal.

The goal of the Hyper Migration scenario is to migrate SYSVOL to DFSR with the fewest steps and no ability to roll back the migration process once commenced.

1 . Ensure correct security policy - You must ensure that the built-in Administrators group has the “Manage Auditing and Security Log” user right on all your domain controllers. This is on by default, so if it’s not set, someone yanked it. Microsoft does not support removing that, no matter what you may have read elsewhere. To validate, examine the group policy applied to your domain controllers using Gpresult.exe . For more info, examine KB2567421 .

2. Migrate to Eliminated State - DFSR does not mandate that you must migrate through each stage at a time. If you wish, you can trigger migrating all the way to the Eliminated state immediately, where DFSR is replicating SYSVOL and FRS is removed. Unlike the incremental Prepared and Redirected states, there is no way to go backwards from this step - once executed, FRS is permanently stopped and cannot be configured again. On the PDC Emulator domain controller, run (as an elevated domain admin):

 

Dfsrmig /setglobalstate 3

 

Now you wait for this AD value on the PDCE to converge on all domain controllers, then for DFSR to switch to Eliminated state on each domain controller and update AD, and finally for that value to replicate back to the PDCE. This will happen for the Prepared, Redirected, and Eliminated stages sequentially, with no need to run each command. Use the following command to see progress:

 

Dfsrmig /getmigrationstate

When all DCs are ready, the output will look like this:

 

Your migration is complete.

Naturally, anything faster than Hyper Migration requires your own Schwarzschild Wormhole.

 

Final Notes

Since you are probably new to SYSVOL using DFSR - and maybe DFSR in general - I highly recommend you review these two KB articles:

• KB2846759 - DFSR event ID 2213 in Windows Server 2008 R2 or Windows Server 2012

 

• KB2958414 - DFS Replication: How to troubleshoot missing SYSVOL and Netlogon shares

They cover the scenario where DFSR may pause replication - due to a power failure or hardware problem - and wait for you to manually resume it. This initially leads to group policy not replicating, but more importantly, eventually leads to a quarantined server. With our latest hotfixes and operating systems, Microsoft recommends disabling this pausing behavior and allow DFSR to resume. If using Windows Server 2008 R2 or Windows Server 2012, use KB2846759 to always automatically resume replication (see section “How to disable the Stop Replication functionality in AutoRecovery”). It’s a simple registry entry, and you can deploy it manually or using Group Policy Preferences . Windows Server 2012 R2 and later default to auto-resuming, so there is nothing to do there.

We went from 52 pages down to a handful, and that was with plenty of screenshots and blather. Now you are running DFSR for SYSVOL and prepared for the future of Windows Server.