Streamlined Migration of FRS to DFSR SYSVOL

Streamlined Migration of FRS to DFSR SYSVOL

  • Comments 6
  • Likes

Hi folks, Ned here again. When telling people about the coming removal of FRS from Windows Server, the main response is usually:

“Sure, I have occasional problems with FRS and know that I should upgrade to DFSR, but who has the time for a huge migration? That guide is very intimidating!”

I hear you on the guide; it is 52 pages of verbosity and completeness. This implies that migration normally takes weeks or months though, which is untrue. With smaller domains, it should take a few minutes, and with larger ones, a few hours or days at most. Migrations are staged, with no interruption to users, and can be rolled back until completed.

Today I’ll talk about how to migrate using one of three streamlined methodologies:

  • Quick Migration (where you don’t know if your domain controllers are healthy, and you want a rollback option)
  • Express Migration (where you are sure that your domain controllers are healthy, and you want a rollback option)
  • Hyper Migration (where you want to migrate with the minimum steps and are confident of domain controller health)

Before I start: we still recommend that you review the full migration guide to understand all the requirements and how DFSR SYSVOL migration works. It might add a few hours of reading, but it’s all in the name of prudence and understanding. This blog post doesn’t really explain anything; it just punches you through to the other side.

Still here? Ok, let’s get started.

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.

image

image

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_LogicalDiskclass 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.

image

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.

image

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

image

image

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:

image

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:

image

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:

image

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:

image

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:

image

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:

image

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:

image

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

image

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:

image

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:

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.

Until next time,

- Ned “Einstein–Rosen bridge” Pyle

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thanks Ned for a great article. I have a question...

    If I have multiple replication groups on a single volume, would each replication group get a separate lane when replicating? In other words, won't large backlog on replication group A impact replication group B? Based on my simple testing, looks like it doesn't.

    Also, what would be the downside of having many replication groups on single volume? It is not realistic to create a seperate volume for each replication group.

  • We have done one a few weeks ago. Everything went well. but it took ages to finish.
    We have a really small domain, but the migration ran for 5 hours or so. So be aware if it is slow, it can be normal :)

  • @ TomN - that's valid advice. Each DC can perform its movement into and out of a phase in 10 minutes (AD polling happens to read the state change with takes up to 5 min, the server changes its state, and 5 minutes later reports its change). So if you are not forcing polling with DFSRDIAG POLLAD, to go from 0 (not started) to 3 (eliminated) will take at least 30 minutes per DC. That does not factor AD replication up-to-dateness though, which is separate and with the lowest inters-site non-change notification being 15 minutes in AD, that means if there are two sites it could up to another 30 minutes (and by default that inters-site setting is 3 hours). With multiple hops, etc. it could easily be a few hours. You can greatly lower this by using repadmin or setting inter-site change notification but if you just want to wait it out, that's fine too.

    @ Jangu1206 - thanks. :) There are a few shared bottlenecks there, so a backlog on some very large/slow-replicating files can backlog other files from other folders. But there is a credit manager system in place to ensure fairness that no one can be "permanently" losing.

    No downside really, RGs are more a unit of administrative boundary and convenience.

  • Thanks Ned!

    Is there any doc explains how the credit manager system you mentioned works? To give you more realistic scenario, let's say we have two rep groups in a single volume: accounting and sales. When someone drops a large number of file to a folder in accounting rep group and then little bit later someone in sales put a small files to a folder in sales rep group. Would sales team have to wait until backlog on accounting rep group drop to certain level? We are trying to avoid situation like this where one dept impacts another.

  • thank you