Windows Server Summit 2024
Mar 26 2024 08:00 AM - Mar 28 2024 04:30 PM (PDT)
Microsoft Tech Community
LIVE
Streamlined Migration of FRS to DFSR SYSVOL
Published Apr 10 2019 03:48 AM 689K Views
Microsoft

First published on TECHNET on Jun 25, 2014
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!”


Update June 20, 2017: It is done; Windows Server 2016 RS1 is the last version that will allow FRS - RS3 no longer includes the binaries. https://support.microsoft.com/en-us/help/4025991/windows-server-2016-rs3-no-longer-supports-frs

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.

 

 

 

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:

 


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
78 Comments
Copper Contributor

Hi Ned,

 

After migrating to prepared state i run propagating test and see below error.

Propagation test failed.JPG

I'd suggest asking a new forums question here rather than replying to blogs.

https://techcommunity.microsoft.com/t5/Windows-Server-for-IT-Pro/bd-p/WindowsServer

 

 

 

Copper Contributor

This is AWESOME. I had been trying to migrate my DC on my home/office network and couldn't understand why I could join a new server to the domain, but couldn't get it to promote to DC. Very puzzling.

 

This worked like a charm and I've been able to complete my migration! Thanks!

Brass Contributor

Thanks for this!  That ridiculous 52 page novel was pretty bad.  You summed it up perfectly.

Copper Contributor

Hi.

 

I'm in big trouble.

 

I only have one 2008 R2 DC on this domain (domain level 2008), and, I am needing to migrate FRS to DFSR as I need to join a 2019 server to the same domain and then demote the old one.
However, I'm stuck at:
"Unable to create DFSR Migration log file. Error 5 The following Domain Controllers are not in sync with Global state ('Prepared'):
Domain Controller (Local Migration State) - DC Type
2008CSERVER ('Start') - Primary DC
Migration has not yet reached a consistent state on all Domain Controllers. State information might be stale due to AD latency."
There's enough free disk, the correct security policy for the built-in admins group is set, the AD Replication Tool shows no errors at all, nothing (not that there are any other DCs to replicate to anyway), and, Dcdiag /e /test:sysvolcheck /test:advertising is successful. (I went through all the steps in this article)


I then did Dfsrmig /setglobalstate 1 but it's been three days now and I still get the error above.
Any thoughts?
A sysvol DFSR folder has already created inside the windows/sysvol folder, shall I just try the nuclear option of Dfsrmig /setglobalstate 3 ?

(I later tried that, and, while I was now able to join my 2019 server to the domain because FRS was eliminated, my "nuclear" option is stuck at the following state: The following Domain Controllers are not in sync with Global state ('Eliminated'):
Domain Controller (Local Migration State) - DC Type
2008CSERVER ('Start') - Writable DC Migration has not yet reached a consistent state on all Domain Controllers. State information might be stale due to AD latency.)


Do I just do /deletenotntfrsmember now? Also, how do I test that this has worked, I mean, on my new DC, I've already transferred all FSMO roles to it and I can access AD and GPMC and so on but the sysvol folder is empty... Can I just manually copy everything from sysvol from the old DC (since there is only one) and then run /deletenotntfrsmember ? (that server is going to be decommissioned anyway)

 

I have a sysvol DFSR folder on the first (old) server now, and it's got all the policies in it, however, nothing replicating over to my new 2019 DC which has a sysvol folder. (it's just empty)
So do I just manually copy stuff into it, or, what do I do?

 

I think this article is missing a step about checking something, as, I checked everything and it was all fine yet I was still stuck. This was all before the 2019 server was promoted to being a DC.

 

I am decommissioning the old DC anyway, and, will have a new secondary 2019 DC that I haven't even set up yet. If I just copy stuff manually into the empty DFSR folder on the current new 2019 server, and then decommission the 2008 r2 one, will it then just work with a new secondary 2019 server?

 

(I've already transferred all the fsmo roles to the new 2019 DC, do I have to transfer them back to the old one so as to be able to fix this?

I checked on the 2019 DC, and, while I have now manually copied files over into the sysvol folder, it is not even shared on the network, if I do a \\2019dcserverhostname, there are no shares that appear at all, which is weird.)

Copper Contributor

@fgwefgyadfg need to execute at elevated command prompt, run cmd as administrator

Brass Contributor

I have a single forest tree composed of 1 root and 1 child domain.

Do I have to perform this operation 2 times?

- 1 in the root 

- 1 in the child

 

Or it is enough 1 time..... utilizing 1 enterprise domain account?

 

I'm just asking because I have performed this activity on the Root domain controller and when I run the "dfsrmig /GetMigrationState" on the Child DC's, I get DFRS migration has not yet initialized.

 

So do I have to run that command in any domain of the forest tree?

 

Kind regards

 

AP

 

Kind regards

 

AP

 

Copper Contributor

Great article - just what I needed. Thanks! My migration went off without a hitch...until I got to your Final Notes section.

 

I referred to KB2846759 as you recommended to set DFSR to always automatically resume replication. That article says it's necessary to install Hotfix 2780453 on DCs running Server 2008 R2 BEFORE making the indicated registry edit. However, it looks like Hotfix 2780453 is no longer available from Microsoft. 

 

I don't know if it has since been included in monthly roll-up updates. So I don't know whether it's safe for me to make the registry change on my lone Server 2008 R2 DC. (Honestly, it will probably be retired within the next month or so, as soon as I can safely migrate everything on it to other servers).

 

Any advice or insight on this?

Thanks again for a great write-up!

 

DR

Copper Contributor

One of the best guides I've ever come across, thanks for sharing.

 

Legend!

Copper Contributor

Does this have to be after hours work, or is this something that can be done during normal working hours?

We have 2012r2 AD Schema, only 2 DC's less than 2k users

for all practical considerations single site 20Gb connectivity between DC's.

Dcdiag /e /test:sysvolcheck /test:advertising - ALL PASSED

 Thank you!!!!

Brass Contributor

Your Quick Miagration worked great for my 2012 DCs.

Thanks!

Copper Contributor

Hello everyone,

 

I am new to the AD environment. We currently have 2 Domain Controllers running on Windows Server 2008 R2. Both servers have all the latest security patches. We have already verified Replication is working correctly between both DCs and they are using FSR. We have identified which DC has all the FSMO Roles on it. From reading this article it seems like we do all the above steps using the Quick Migration option for our environment on the server with all the FSMO Roles on it. We will be migrating our ADs over to Server 2019. Do we need to install the DFS and DFS NameSpace on the DC with all the FSMO Roles on it before doing the migration? Also, does DFS and DFS NameSpace need to be installed on the other DC too?

Copper Contributor

I ran into this problem where we had two DCs, upgraded in-place for both of them to 2019, detested the idea of reintroducing a 2016 box into the mix and demoting then re-promoting. So here is the ultimately workaround to that! Copy DFSRS.exe from a windows 2016 box to your windows 2019 boxes, take ownership and permission of the 2019 dfsrs.exe file in system32, stop the dfs service, temporarily rename the dfsrs.exe in system32 to .old, copy the 2016 version in there and start the service again. Do this on both servers...no other dlls or dependencies are necessary. Run through all the setglobalstate commands and watch till it is done. Then swap the dfsrs.exe back to the 2019 and call it gooooooood!!!!

Copper Contributor

Ned,

 

Thank you for this great article! I have a question, I need to migrate a forest with six sub domains. I assume I will need to migrate each domain one at a time and order doesn't matter?

 

Thanks,

Joe.

Brass Contributor

Myself personally I have started with the Root Domain, and only when everything was ok and fully tested I moved into the children domains.

I know people that have done the way around with no issue as well.

 

 

Kind regards

 

AP

Used it once again, it never gets old. @Ned Pyle 
:triangular_flag:So many legacy domains out there. 

Microsoft
Microsoft

@Joe_A295 sorry I missed your comment - correct, the order doesn't matter. Every domain is separate for the purposes of SYSVOL

Copper Contributor

@Ned Pyle  No worries, thank you. Yeah I figured, however just wanted to make sure to dot i's and cross t's. I completed the project without an issue because of this great article, thanks again!

Copper Contributor

@Ned Pyle Is there a recommended timeframe when going from Redirected State to Eliminated State?

Microsoft

@Chris Zoglmann Nothing specific, just when you are comfortable that DFSR appears to be working well and SYSVOL/group policy looks healthy

hello @Ned Pyle received an email that your original post has been changed but seems by design one cannot see what has changed (same with other notifications via email "

Ned Pyle (Microsoft) edited a article in Storage at Microsoft on Mar 16 2021 05:59 PM:"
If you find some time could you ask the CMS team it it is possible to highlight changes just like github - if possible at all.

 

Microsoft

@Karl_Wester-Ebbinghaus I've been asking for that for 5 years, good luck :) . I recommend directly contacting CMS about this feedback.

 

All that changed here was me deleting three dead in-page anchor links that the migration to this platform had broken. No content change here.

"I recommend directly contacting CMS about this feedback."

 

I will give it a try Ned, where to? Thanks for leaving a note on your changes.

out of my mind. How about having a DFS-R config pane and migration wizard as a WAC plugin :) ? Especially one that will honor FQDN enabled configuration by default ? I think I will drop this to uservoice. Sounds good. 

Microsoft

@Karl_Wester-Ebbinghaus feedback and support for TechCommunity itself: techcommunity@microsoft.com.

Copper Contributor

So, I followed this article.  I had a clean bill of health, and after the migration, things broke.  The new SYSVOL location is empty, and there is no NETLOGON directory.  I can see my GPOs under the GPM console, but when I go to edit them, I get an error that says "Failed to open the Group Policy Object. You might not have the appropriate rights." The error then says the following under the details "The system cannot find the path specified." I am however, able to create a new policy.  I am

 

I've looked at some of the articles about what to do if you are missing the SYSVOL and NETLOGON, but the steps outlined in those have not helped me at all.

 

I'd appreciate some help.

Microsoft

Open an MS support case immediately. This outcome has never been reported in 10 years. 

Copper Contributor

Please let me know how to do this.

 

 

Microsoft
Copper Contributor

Ned,

 

Thank you for the help.  I've tried to report the error several times, but the support page times out with a SBOX_FATAL_MEMORY_EXCEEDED error while I'm working through my write up (I noted the the system memory crawls up to 10.1GB every time before I get the error page).

Microsoft

I'm sorry to hear that. You can instead use phone to open a case, see: Global Customer Service phone numbers (microsoft.com)

Copper Contributor

Worked great. Thanks.

Microsoft

@jtechsolutionsusa glad to hear it!

Copper Contributor

Hi all, I am preparing my domain with Windows Server 2008 to migrate it to 2019, and regarding the migration of frs to dfrs, I wanted to understand what could be the problems that this could create? that is, could it interfere with the functioning of anything at the network level? I don't have applications that integrate with AD, except Exchange Server 2013.

Thanks!

Microsoft

@AnonymousForever It should cause no problems

 

  1. File replication is totally invisible to applications.
  2. The SMB shares for SYSVOL and NETLOGON will still be there when this is complete. 
  3. Any files you had stored in SYSVOL or NETLOGON that an application might have cared about will be there when this is done.
  4. Exchange doesn't know or care about FRS or DFSR (see 1)
Copper Contributor

Thanks @Ned Pyle!

Now I can proceed with a more security.

 

Grazie!

Copper Contributor

Can you run in redirected state for a validation period before moving to eliminated state and, if so, be dfsr compliant?

Microsoft

@sabshagen Yes. Yes, DFSR is working normally at that point. If you need a few weeks to make sure you're happy with the migration, you can stay in redirected state until ready to eliminate. 

Copper Contributor

Why on earth doesn't Microsoft have this migration process built into the promote to DC action?  That would be the best way to handle it, ask the user what method to use and then do it in the backend.  Seems like that would have been the best/easiest way to handle these migrations. :(

Copper Contributor

Hi,

thanks for great article. Very useful.

I'm preparing to do a migration, but have one question.

What do you mean by "PDC Emulator domain controller"?

I thought that these days all DCs are equivalent. Do you mean DC which holds FSMO roles?

Is it important that migration is started from there or can be started on any DC?

Thanks.

 

Edit: Sorry for this. I got my answer. It is a DC, which holds PDC Emulator role. Before, I didn't know each role by name. Now I do. :smile:

 

Microsoft

@Audax Hi. Yes, the PDCE FSMO role in this case. That DC in the domain will be the authoritative source of SYSVOL for the migration.

 

No worries :)

Hello @Ned Pyle

II have thought about this scenario.

 

A customer has one or several Windows Server 2008R2 Domain controllers. 

 

They are using FRS for sysvol replication.

Domain and Forest functionality levels are 2008R2. 

They plan to deploy a new domain controller running Windows Server 2022.

This requires DFS-R replication.

 

Would this be possible or would they need to IPU / migrate to 2012 R2?

 

I cannot recall whether 2008R2 would support DFS-R for sysvol yet.

 

Thank you!

Ofc I could ask the docs but believe that could be still a common scenario for readers of your guidance. 

Microsoft

@Karl_Wester-Ebbinghaus Yes, WS2008 R2 supports DFSR SYSVOL.

That's good to know so they need to migrate to DFS-R first and then deploy the new DC.

 

What's curious though. In some environments I see the Sysvol in the DFS mmc under replication as "Domain System Volume" replication item and in some other domains it does not appear in this area.

I think it's nice to have it there as it makes clear it's using regular DFS-R, too.

 

You cannot manage much at this space 

Not sure if it is worth the time, has anyone considered to bring DFS-R mig as an extension to WAC?

Maybe it could offer more than just the migration but also helps with more features like having Sites and Services / replication and diagnosis as the AD replication tool (MSI) does.

 

AFAIK DFS management is generally unavailable in WAC. 

Copper Contributor

Hi

This work perfect.

 

Thanks.

Brass Contributor

Migration has not yet reached a consistent state on all domain controllers

 

One DC is still 'Start'  What do we do?

Microsoft

@AusSupport180 Hiya. First validate that DC is replicating normally with Active Directory Replication Status Tool or REPADMIN, and that the DFSR service is running on that DC. 

Co-Authors
Version history
Last update:
‎Mar 16 2021 09:59 AM
Updated by: