How to Migrate Windows Server 2008 R2 FSMO roles to Windows Server 2019
Published May 07 2019 12:01 AM 148K Views
Microsoft
With the "end of support" on the horizon for Windows Server 2008 R2 coming January 2020, folks are looking around for resources to help them check off some high ticket items from their "to do" list. While coming back from my last Microsoft Ignite The Tour stop - I had some time to kill waiting for my connection. I thought I would dust off some of my Active Directory admin skills and document the quick and dirty process of upgrading your Active Directory from 2008 R2 over to the latest version of Windows Server 2019.TailwindTradersBasicDiagram.png
My lab contains two domain controllers DC01 and DC02 running Windows Server 2008 R2 with the DNS and Active Directory Roles. I have also added in a Windows Server 2019 member server which will serve as my new Domain Controller once I have promote it to host Active Directory and transfer the FSMO (flexible single masters of operation) over. This is a purposely simple lab and write up. I am going to do my "Your Mileage May Very" do your research and testing on all the nuances and gotch'yas out there prior to reproducing these procedures in your own environment. I would HIGHLY recommend checking out this article where John Flores has gone though an exhaustive list of what to look out for.
 
Install Active Directory on a Windows Server 2019 member server
 

This is easy enough, login to your WS2019 server with an account that has Domain Admin rights and Enterprise Admin rights on the member server. These rights are required in order to add a domain controller into Active Directory as well as extend the schema.
 
  1. Start up a PowerShell prompt and type in the command Install-WindowsFeature AD-Domain-Services. This will install the binaries on your server.
     PowershellADServices.png
     
  2. Install the ADDSDeployment module by running Import-Module ADDSDeployment in order to continue to work configuring Active Directory from PowerShell.
     
  3. Once those additional tools have been installed run Test-ADDSDomainControllerInstallation -DomainName tailwindtraders.com to test for any prerequisites.
         -
    In this example my domain is TailwindTraders.com
         -
    You will be prompted for the Active Directory safe mode administrator password.
     
    TestDomainControllerInstall.png
     
    Note the warning regarding "Allow cryptography algorithms compatible with Windows NT 4.0" - this is a reminder that old clients and applications pre-dating Windows Vista will not be able to establish connections or logon to domain controllers running this more modern OS of windows Server 2019.
     
  4. Promote this member server into a domain controller by running Install-ADDSDomainController -CreateDnsDelegation:$false -InstallDns:$true -DatabasePath 'C:\Windows\NTDS' -DomainName 'tailwindtraders.com'
     
  5. After prompting you for an ADSafeMode password and confirming a reboot will take place - this will kick off the installation process.
         -
    It will initiate the install, while not bothering to make a new DNS delegation zone.
         -
    It will install DNS service when promoting this machine to a Active Directory domain
            controller. It will add itself (127.0.0.1) to its DNS name server list
         -
    It will place the Database (and logs) in the in C:\windows\NTDS directory
         -
    It will contact any domain controller using a standard AD query to locate one in the
            tailwindtraders.com domain in order to proceed
         -
    You COULD target a domain controller if you like by adding -ReplicationSourceDC and
            using the fully qualified domain name of a DC if you prefer

     
  6. You can see various informational messages appear in the PowerShell window as the install, schema extension and replication are Progress. 
      ADDSDomainControllerInstall.png

 

A restart will now take place once the steps are completed.

 

Transferring the FSMO (Flexible Single Masters of Operations) roles
 
If this was a real environment you would want to wait a while to allow for replication to take place around your Active Directory. You need to login to the new domain controller with Enterprise Admin rights in order to do these next steps in order to transfer FSMO roles. 
 
  • You can check for replication errors by opening up a Powershell window an running Get-ADReplicationFailure -scope SITE -target default-first-site | FT Server, FirstFailureTime, FailureClount, LastError, Partner -AUTO
NOTE: If this were a PRODUCTION migration of my Active Directory and I had NOT finished switching from SYSVOL replication to DFSR replication as of yet - I would stop everything I was doing and read NedPyle's simplified article on how to do this.
No, really... GO READ IT NOW if you have not read it yet or made the switch.
 

You could use the old school NDTSUTIL command line utility to transfer the FSMO roles to the new domain controller. Since we're using PowerShell for this blog - we'll do it all in one command. Lets figure out which domain controllers have the roles now:
 

  • To list off the two AD Forest wide roles and find out which DC currently holds them - run Get-ADForest tailwindtraders.com | Format-List SchemaMaster,DomainNamingMaster
  • To list off the three AD Domain wide roles and find out which DC currently holds them - run Get-ADDomain tailwindtraders.com | Format-List PDCEmulator,RIDMaster,InfrastructureMaster
You can see here I have them split across both DC01 and DC02.
FSMOroleLocation.png
  • To transfer all five FSMO roles from their current location to the new DC03 - run Move-ADDirectoryServerOperationMasterRole -identity DC03 -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster
It will prompt you to confirm before completing the task of transferring the roles. Once you confirm - it's all done. You can confirm with commands listed above to see that DC03 is the new owner of all the roles.
FinalFSMOTransfer.png
It should be said - the preference is to ALWAYS transfer FSMO roles between DCs instead of Seizing them. If for some reason a Domain Controller is down - you would have to seize it (by adding a -force to the command) but that DC can NEVER be added back into the Active Directory domain again without causing issues.
 
What's left?
 

If this were a production environment - I would once again wait until replication has worked it's way through all my domain controllers before proceeding. I would also do the following in order to continue this migration from 2008R2 to Windows Server 2019:
  • I would bring up an additional Windows Server 2019 Domain controller
  • I would ensure any clients I had were using the new 2019 DC as its primary DNS. I had DC01 with an address of 192.168.10.100 as the primary DNS in this lab.
  • I would run DCPROMO on both DC01 and DC02 boxes in order to demote and remove them from the Active Directory.
  • Once all downlevel domain controllers have been removed (and replicated) I would raise the Domain functional level to Windows2016Domain domain mode
    • run Set-ADDomainMode -identity tailwindtraders.com -DomainMode Windows2016Domain
  • Once all domains have been raised to Windows2016Domain mode, I would raise the Forest functional level to Windows2016Forest
    • run Set-ADForestMode -Identity tailwindtraders.com -ForestMode Windows2016Forest
That's about it. I hope you found this quick walk-through useful in learning the steps required to migrating FSMO roles from 2008R2 to 2019 while performing an upgrade of Active Directory. What do you think of this format and content - is it something you found useful and would like more of it? Feel free to reach out and share your answers below in the comment area and suggest other topics you'd like to see the team cover.
23 Comments
Copper Contributor

Has anyone done this in a production environment yet?   If so, anything to share?

Copper Contributor

Yes carried out the FSMO migration from 2008 to 2019 in production using the above process no problems at all all worked like a charm.

Microsoft

Hey @skynet051  - glad to hear it worked for ya. Even though it can be considered a major change to work with your domain controllers, this a relatively low risk task. Don't forget to have coverage for your global catalog servers as well. ;)

Copper Contributor

Hello Rick,

Thanks for this article. You mention this regarding FRS :

 

NOTE: If this were a PRODUCTION migration of my Active Directory and I had NOT finished switching from SYSVOL replication to DFSR replication as of yet - I would stop everything I was doing and read NedPyle's simplified article on how to do this.

 

I Would like to understand why this could be problematic for FSMO roles transfert.

Thanks in advance

Robert

 

Copper Contributor

@Rick Claus I removed the global catalog role from server 2008 and confirmed and my 2019 was global catalog server then demoted the 2008 and still till today it hasn’t shown my problem yet. Also my previous domain controller was 2008 first DC it didn’t had 2003 DC before that so I didn’t had to go through migrating FRS to DFS so in my case the whole process took 30 mins including demotion of 2008.

Microsoft

@diquattrobob Ensuring SYSVOL replication (FRS) to DFS is not a matter of FSMO role transfer as it is about a more modern 2019 OS not having the ability to participate in FRS replication of SYSVOL. You would end up with an empty SYSVOL on your 2019 DCs, which would become problematic if you had scripts, group policies and other critical components living in SYSVOL. 

Copper Contributor

@Rick Claus  Thanks for this.Can you answer the following:

 

1. What would be the impact of the new ip address and new server name of the primary domain controller (server 2019) in the environment.Any impact on the exchange server configured on a member server ?

2. After moving the fsmo roles, additional roles such as DHCP, DNS, RADIUS will be migrated automatically or have to be migrated manually ?

 

 

Thank you for your advise.

 

Regards

Microsoft

Hey @Bijay_George 

Regarding your questions: New IP address and computer name for the role holder should have NO impact on your environment - unless you have clients or applications who have hard coded the IP address or computer name into their authentication mechanisms. I.E. Say a user went and mapped a shared drive to the DC for some reason - that machine name (or IP address) would be different now and it would not work.  

 

All replication needs to propagate across all your DCs using your site replication process and schedule. Once that takes place - you could take over the original IP address, restart the server so that it registers all appropriate services with the new IP, and allow for replication to once again propagate. I am PERSONALLY not a big fan of changing the computer name - but that could also be done.  Because this is a NEW domain controller built from a clean member server - you are not going to be introducing DUPLICATE SIDs. 

 

As for your 2nd question - i was making the lab assumption that these additional services ARE NOT on the domain controller and are on different member servers. if that is not the case - you would have to migrate those services OFF to a different system. I have details on how to migrate DHCP, DNS is included as part of AD.

Copper Contributor

Thank you @Rick Claus  for your prompt response.That answers well!!

 

FOr my second question, yes you are right.The additional roles are co-hosted in the DC.Is it possible to backup the roles separately and restore to the new DC with a possible downtime ? or as you mentioned I need to migrate it to another member server ? which would be the best practice ?

Could you please share a link if you have procedures to migrate roles co-hosted in AD ?

 

Thanks again for your support

 

Regards

Bijay

Microsoft

@Bijay_George - DNS will be included in the migration if you so choose to during the DCPROMO process. This assumes that you are using AD integrated DNS zones. DHCP will need to be manually migrated (there are tools for that) and it is the subject of a future post. I go through what's involved in the live session i delivered in November at Microsoft Ignite (recording: https://myignite.techcommunity.microsoft.com/sessions/82966?source=sessions)

Copper Contributor

I just came on here to say I just completed a migration of our two Windows 2008 R2 Domain Controllers to Windows 2019 using these instructions in our production environment. The entire process went very well. Even moved over DHCP role as well. I don't think any employees even realized what happened.

 

These instructions were extremely helpful.

 

Thank you

 

Copper Contributor

@Rick Claus 

 

1. Does it make sense why my DC03's sysvol is already populated with files from DC01 just from doing steps 1-6?  Is it possible that it is because my Windows 2008R2 DC already is using DFSR?  Is there a way to verify this?

 

2. I am yet to run "Move-ADDirectoryServerOperationMasterRole -identity DC03 -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster".  Is there a copy option of this powershell command if I want DC01 to run simultaneously with DC03?  Should I also run this command when I build DC04 as a secondary / backup DC to DC03?

 

Thank you.

Microsoft

@G33kChiq - Your source for all things SysVol migration to DFSR is found here: https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr - The main tool dfsrmig.exe will tell you what state you are currently in and how to progress to the next state. 

 

As for the FSMO roles - only one Role Owner can exist at a time for that role. You can choose to Transfer each role independently to one server or to distribute them to multiple split servers as your needs see fit. In my example - i chose to move them all to one, as it was my demo environment and simple example of what needs to take place. 

Copper Contributor

Thank you @Rick Claus 

For the Set-ADDomainMode command and Set-ADForestMode, is it really raising the Domain functional level to Windows2016Domain domain and the forest to Windows2016Forest  despite we are using Windows 2019 OS? There's no Windows2019Forest or Windows2019Domain?

 

Also I have read somewhere to not put the Infrastructure master role on the same DC as the global catalog server. If the Infrastructure master runs on a global catalog server, it stops updating object information because it does not contain any references to objects that it does not hold. This is because a global catalog server holds a partial replica of every object in the forest.  But usually all DCs (best practice at least 2 of them) are also GC. Should or could the infrastructure master role be transferred to a server that is not a DC? 

Microsoft

@G33kChiq 

Set-addomainmode and set-adforestmode takes them to windows2016  modes as there is no 2019 specific mode. In fact I believe there was only one schema modification going from 2016 to 2019 this time around. 

Also - yes, you have brought up the residency of a fsmo that should not live together on the same DC - infrastructure master. While it is relevant in a multi-domain forest, it is not as relevant in a single domain forest - it is still recommended to not have the DC holding the role also be a GC.  As for transfering the role to a non DC - that is not possible. I assume you meant GC, not DC. 

Copper Contributor

@Rick Claus after I have transferred FSMO roles to the new domain controller, our Windows 2008R2 print server has an error upon attempting to login to it.. "the trust relationship between this workstation and the primary domain failed."

 

Then on another machine I use to manage the servers, upon running server manager against DC3 and DC4 (the new Windows 2019 DCs) it says metadata failed to be retrieved from the server due to the following error WinRM cannot process the request.  The following error with error code 0x80090322 occurred while using Kerberos authentication. An unknown security error occurred.  

 

Also Active Directory Users and Computers cannot contact the new domain controllers...  So I rolled back and moved the FSMO roles back to DC1. Then everything is fine.  What and where do you think it went wrong?

Microsoft

@G33kChiq - That is strange. by rolling back, you men that you re-made your 2008 R2 box (DC1) a domain controller?  Sorry for the delay in responding - my email notifications are not firing on this post for some reason. 

Copper Contributor

@Rick Claus  yes moved the FSMO back to DC1.  I was in the middle of demoting DC2 after I moved the FSMO to DC3 and DC4.  The print server just need rebooting since it was still authenticated against DC1.  The trust relationship was fixed after the reboot. 

 

The issue with  WinRM cannot process the request, I just ran winrm qc on the new DCs then stop and start the service. 

 

So far the only error I am getting on both DC3 and DC4 in BPA is "this domain controller must register its DNS host (A or AAAA) resource records for the domain." I have searched for this error and no luck so far for information on Windows server 2019.

 

Even though this resulted on both DC3 and DC4...

PS C:\Windows\System32\config> nltest /dsregdns
Flags: 0
Connection Status = 0 0x0 NERR_Success
The command completed successfully

Microsoft

Now it's tracking down a DNS issue! I assume can see the primary DNS server and up address has not changed? Has that DNS server been bounced to refresh it knowing what DC are around and it has a secure connection to one?

Copper Contributor

Hello, I am now finished windows2008R2 windows2019 AD migration, five windows2019 role has changed to the new server, is also a global catalog, but when I shut down the original 2008 r2 AD, all rely on AD user authentication service are inaccessible, tip password mistake, tried to move to the same new server 2008 r2 is also the same error, I feel like the migration failed, what I should do next?

Copper Contributor

Hello, I have the same scenario as this article and was hoping this article will help me. I have raised my existing domain from 2003 to 2008 but appears to be still stuck on 2003 when I user the Get-ADForest comment. When selecting "Raise Domain Functional level" in ADDT for example it shows as raised to 2008. Step 3 indicates that the funtional level has not bee raised. I cannot get past this step. Any help appreciated.

Copper Contributor

Hello, not sure how this was missed but I only raised the domain level and not the Forest level. Once I completed that I was able to promote the server 2019 to a DC. Step 3 of your article gave me the hint once I read it a second time. Thank you

Copper Contributor

You made me 2nd guess my self.

 

I do server moves regularly but they are usually closer in version number than the one I'm currently working on. When I do them, I notice the crypto message that you have as the note on

"Step 3: "Note the warning regarding "Allow cryptography algorithms compatible with Windows NT 4.0" - this is a reminder that old clients and applications pre-dating Windows Vista will not be able to establish connections or logon to domain controllers running this more modern OS of windows Server 2019." but usually pay no mind to it. However, this time I had to look at this since the current environment has a server 2003 dev box that is on its way (thank god) out but still needed for a bit longer and the current DC's are 2008r2.

 

I believe your statement about systems pre-dating vista won't work could be incorrect. I tried to follow the link you provided but its dead so I searched and found this "https://docs.microsoft.com/en-us/services-hub/health/remediation-steps-ad/disable-the-allownt4crypto...  on that page there is a video and in that video at 55 seconds in there is a slide that states the settings this is referring to has been supported since windows 2000. I very well could be misunderstanding but this link from MSFT states that systems as old as windows 2000 support this. Can you clarify your note or perhaps relink your source ?

 

Edit: Spelling and formatting

Version history
Last update:
‎May 13 2019 08:40 AM
Updated by: