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.

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.

Start up a PowerShell prompt and type in the command Install-WindowsFeature AD-Domain-Services. This will install the binaries on your server.

Install the ADDSDeployment module by running Import-Module ADDSDeployment in order to continue to work configuring Active Directory from PowerShell.

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.

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.

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

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

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.

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.

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.

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

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.

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. ;)

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.

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

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

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 ?

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.

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 ?

@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)

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.

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?

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.

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?

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.

@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?

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

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

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?