Add 2019 DC to Windows Server 2008 R2 AD Domain and then transfer FSMO roles

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

I want to add a 2019 DC to our production environment - which has 2 DCs - and transfer all or most roles over.

before moving to DFSR, what are your current domain controllers running? what is the functional level?

the functional levels need to be at least 2008 before you can migrate to DFSR

if you have any domain controllers older than 2008 then you need to decommission those and raise the function level before you can introduce a 2019 domain controller

ASKER

before moving to DFSR, what are your current domain controllers running? what is the functional level?
the functional levels need to be at least 2008 before you can migrate to DFSR
if you have any domain controllers older than 2008 then you need to decommission those and raise the function level before you can introduce a 2019 domain controller

Our oldest domain controllers are 2008 R2 - what I am worried about is that applications on the 2000, 2003 and maybe 2008 servers will break when tranferring roles over to the 2019 DC.

as long as the domain/forest functional levels are at least 2008 then you are ok to migrate to DFSR

applications themselves should not be affected by moving FSMO roles - would be shocked if it did

is there exchange in the environment? if so, what version? that would be the only thing that stands out that could be an issue

ASKER

We have Exchange 2013 and 2016

Support for Windows 2019 domain controllers began with Exchange 2016 CU12 so as long as that server is current, it is fine. For Exchange 2013, it doesn't support it so either move off it or manually specify domain controllers other than 2019 to use.

The 2016 AD functional level is supported for both versions so that is not an issue.

ASKER

Support for Windows 2019 domain controllers began with Exchange 2016 CU12 so as long as that server is current, it is fine. For Exchange 2013, it doesn't support it so either move off it or manually specify domain controllers other than 2019 to use.

The 2016 AD functional level is supported for both versions so that is not an issue.

Hello Seth. I am confused - will it work or not. This link here Windows 2019 says that in Windows 2019: "... latest Forest Functional Level (FFL) and Domain Functional Level (DFL) are Windows Server 2016. "

Seems like it is a non-issue?

https://learn.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019

Yes, the highest functional level is 2016 but 2019 domain controllers are not supported with Exchange 2013 in the environment. If you are at CU23 you can install a 2022 domain controller; don't know why they didn't add support for 2019.

Exchange Server supportability matrix

ASKER

I just had a few more questions:

When ready, transfer the FSMO roles (multiple ways you can choose to do this - PowerShell, NETSH, GUI tools. Once the roles are transferred, demote a DC you want to get rid of. Then run DCDIAG again and make sure things are healthy.

I have the 2 x windows 2022 DC now in the 2008R2 domain - both are GCs. Now when I demote the DCs to get rid of it I want to use the old 2008R2 DCs names and on the 2022 DCs after transferring the FSMO roles - will be able to do this without any issues.

It will be much easier for me as a lot of devices on the network are hard-coded with the static dns entries of the current fsmo role holders and also some of our applications developers in the past may have hard-coded the fqdn for the current fsmo role holders.

DO NOT RENAME DCs.

While there are certain circumstances where DC rename is supported, few if any experienced professionals would endorse such an action. If you MUST keep the same names (why?! If the DCs are DCs only, it doesn't matter, if they double as file servers, then you should take this opportunity to configure DFS Namespaces so this won't be a problem in the future.

If you INSIST on keeping the same names, then the safest way to do it is to do a swing migration - this is where you install a new dc with a new name, then remove the old DC with the old name, then install ANOTHER new DC, this time using the old name, and finally remove the newish DC with the new name that you didn't want to keep.

ASKER

Thank you Lee. Appreciate your insight on the DC renaming - does that hold true for the IP addressing also?

You have to be careful and cleanup DNS with preserving IPs. I've done it. It's far less dangerous than renaming a DC. Still not advisable, but less dangerous.

ASKER

You have to be careful and cleanup DNS with preserving IPs. I've done it. It's far less dangerous than renaming a DC.

So I am thinking remove the old entries and add in new ones with the new DC fqdns and the IP right? I just want to make sure I dont screw this up. Thank you.

ASKER

And one other question:

If I am transferring roles to the 2 new DCs what is the best way to assign roles to the 2 different DCs? E.g.

Schema master & Domain naming master on one and the rest on the other.

I also need to transfer the dhcp and ntp server roles. How do I verify all the roles that I need to transfer so that I dont miss any when I demote and remove the old DCs?

Reference https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/fsmo-placement-and-optimization-on-ad-dcs

If I am transferring roles to the 2 new DCs what is the best way to assign roles to the 2 different DCs? E.g.
Schema master & Domain naming master on one and the rest on the other.

Do you have multiple domains (not domain controllers, multiple DOMAINS)? If the answer is no, leave them all on one DC. If you have multiple domains, then breaking up the roles makes sense.

and note:

I also need to transfer the dhcp and ntp server roles. How do I verify all the roles that I need to transfer so that I dont miss any when I demote and remove the old DCs?

DHCP servers must be authorized. I would (and have) export the DHCP database from the old DHCP server, disable the DHCP service on the old server, and import it to the new server. Then authorize the new server as a DHCP server in the domain. Do this all at the same time (don't wait a day or two between steps, it doesn't have to be INSTANTLY done, but it should be one sequentially at the same time.

NTP services are handled by the PDC emulator. They should be automatically updated. You MIGHT want to use w32time to set the NTP server on the new PDC emulator to sync with a time source, but windows generally does that on it's own.

ASKER

Thank you Lee - I will start doing all the steps above and post an update here as soon as possible - may take a week; just a heads up.