Windows Server Summit 2024
Mar 26 2024 08:00 AM - Mar 28 2024 04:30 PM (PDT)
Microsoft Tech Community

Any potential problems with mixed OS versions for Active Directory PDC?

Copper Contributor

Hi All,


Just wanted to get people's opinions on the following:


I have a customer with multiple sites, and 3 domain controllers.  They also have a Microsoft volume license account so licensing is not an issue here.  (they are a medical facility and thus under charity pricing and if any of you have not had experience with that let's just say pricing is disgustingly cheap next to free basically.  I'm only saying this to eliminate a bunch of chaff responses of variations of make sure you got licensing)


Each DC is at a different location.  They also have an exchange server on premise running Exchange 2016 on server 2016 (bare metal).  All sites are tied together with private circuits.


The 2 "secondary" DC's are running Server 2016.   The "primary" DC (it has FMS roles etc.) on it is running Server 2008R2.


The Active Directory domain and forest functional level are all at 2008R2  (or they still could be at level 2008 I'm not sure at the moment)


The primary DC was also used as a fileserver and is running out of space.  So my thought was to setup a new DC on Server 2019, (bare metal) migrate FSMO roles to it from the old primary, demote the old primary and then setup another new fileserver (hyperv) and move all the files and shares off the old DC then shut it down.


A question was brought up, wouldn't it be better to setup the new DC with Server 2016 that way all of the DC's are the same OS version?  The target server I'm going to use is a Proliant DL380 Gen6 which I already installed 2019 on  (HP only "supports" up to server 2008R2 on these but we have Server 2019 running perfectly on several others)


My feeling is if I'm going to put time into building a server to use 2019 that way we can get the longest amount of life out of the installation.  Basically what it boils down to is Server 2022 is unable to run on any of the older CPUs so Proliants older than Gen10 are SOL - which is literally all of this customers servers - they range from Gen 6 to Gen 9)


I know Exchange 2016 can't run cannot run with anything newer than an AD Domain Functional level of 2016 so I was planning on installing the Server 2019 DC at Functional Level 2008R2 and then raising it later to 2016 level but not to 2019 domain/functional level.


Do you think I should just install Server 2016 on the new PDC?  We already have a number of Server 2019 servers in the mix just not Server 2022 yet (and probably not any for a while)

12 Replies
You can mix different versions of operating systems across the Domain Controllers, the only thing important is the Domain and Forest function level. See this article about supported operating systems when running a 2008 level domain/forest: Things start to change at 2016 level because of DFS-R requirement
Both Domain and Forest level are at 2008R2 on this domain. However they are still all using FSR for replication of SYSVOL so thank you for that tip. I will need to run a migration to DFSR first on the existing DCs since Server 2019 does not support FSR.
No problem, good luck and please mark my answer as solution to mark it as solved

It is best to avoid mixing operating systems for DC - promoting even one triggers an Active Directory migration, and having older OSes put you at risk - expect security and compatibility issues. You also need to take admin tools into account (newer OS = newer admin tools).
Also, Active Directory migration isn't always straightforward - having on-premises Exchange will add prerequisites by example (and don't try to bypass - your Exchange infrastructure may explode).
My advice : do not try to go faster than you should.
Complete your file server migration first.
Make sure your DC own only AD and DNS roles and nothing else, and there is no other server with DNS role. Make sure you build them with Server Core.
Prepare a future Active Directory migration - check prerequisites (like DFSR), AD/DNS health and backup, enable optional features already available (like AD Recycle Bin), check new features available with newer OS and domain/forest levels.
Then, migrate your 2008 R2 to 2016. Enable new features and increase domain/forest levels (you won't need to do this on you reach 2016).
Then, trigger a global AD migration to 2022 using virtual machines if possible, or 2019 if you cant do better (end of support date for 2019 is slowly closing).



Just to be clear here, there is categorically no issue with running domain controllers built on differing operating systems beyond the single requirement around migrating from FRS to DFS-R, as @Harm_Veenstra already noted.


The functional level supportability matrices can be found in the following article (though I suspect you've already seen this.) Once you migrate from FRS to DFS-R, which you can (and should) do using your existing infrastructure, you can jump directly to Windows Server 2022.


Active Directory Domain Services Functional Levels in Windows Server | Microsoft Docs


Nothing is automatically triggered with respect to new functionality simply by using a newer operating system. The most you'll find (beyond your DFS-R task) are some cryptographic suite changes - which have taken place across all platforms purely as a generational exercise and have nothing specifically to do with domain controllers or the functional levels. And 2008 R2 isn't so old that it doesn't share a good portion of these suites meaning you will not run into issues on this front (unless someone's badly customised the existing suites via GPO - which is a very, very long shot.)


As noted in that article (as one example of many), there has been no new functional levels (domain or forest) since 2016. There's been a couple of Azure-centred schema extensions but that's not the same thing, and there's quite literally zero value in discussing those here. The point is, there is no such things as Server 2022 functional levels.


Stick to what you've already discovered and what Harm has added, and you'll be fine:


  1. Migrate from FRS to DFS-R first;
  2. Make sure that completes successfully and that you have no other replication issues;
  3. Add/replace (steer clear of in-place upgrades though) the old domain controllers with Windows Server 2022 if you can, or 2019 if you have a really good reason for doing so (i.e. throwing away mainstream support duration and having to go through this whole exercise a few years sooner);
  4. Once they're all on Server 2022, consider raising your functional levels.




If you don't want to break everything you need to double check Exchange on-premises requirements - usually install the latest CU to support the latest OS, which can be a tedious process, especially if those Exchange servers are updated once in a blue moon.
Which is why it seems better imho to migrate to an Exchange-friendly OS first (2016) before making the next jump to 2019/2022 right away.
Given two of the three domain controllers are Server 2016, the only change that will occur will be when the PDC FSMO role is transferred from the 2008 R2 domain controller to one of those existing Server 2016 boxes, at which point the new PDC FSMO role holder will create two new privileged groups (Key Admins and Enterprise Key Admins). That's all.

The other new functionalities - such as PAM (Server 2016 but with forest functional level 2012 R2) or Protected Users (domain functional level 2012 R2) - have to be explicitly lit up by deliberately increasing the functional levels. Until that happens, no behavioural changes occur.

Exchange Server manages its own settings, including schema extensions and permissions on the default and configuration naming contexts.

There's no danger to Exchange Server in this scenario. There's anecdotally (as much as you can gauge such things from forums such as these) more danger to Exchange from Exchange itself when running cumulative updates.

Hello Lain, I'm not thinking about AD features or domain/forest functional levels, but Exchange supported scenarios for Active Directory environments - you just cannot mix any Exchange versions with any OS versions for domain controllers. If you do not follow precisely those requirements, Exchange breaks.



Yes, you're 100% correct about that, but that doesn't explicitly preclude mixing Active Directory operating system versions carte blanche.


While we don't know @Ted_Mittelstaedt's client's Exchange 2016 cumulative update level, if it's within the supported range of [n] to [n-1] (i.e. CU23 or 22) ) then they're supported to work against Windows Server 2019 domain controllers, which is as far as the client can go for now from what Ted said anyway.


That being the case, there's no formal (with the caveat on us not knowing the Exchange CU level) reason to limit the replacement of the 2008 R2 DC to Server 2016. The only outcome would be cutting down platform supportability by years.


So long as everything lines up within the supportability matrix (included below for Ted's benefit), mixed domain controllers is fully supported.


Exchange Server supportability matrix | Microsoft Docs




@Harm_VeenstraThat is not all.
Standard in Windows is that if an AD server is on the newest (younger than the youngest) OS all traffic with authentication will go that way.
So best practice: AD servers should always be installed as a single service on a server.
(Not combine it with anything else)
Second be aware that when using multiple domains this can become an issue when communication between DC servers goes over a firewall!
So if you install a new AD server always check network traffic first!
And replace all AD servers beginning with the Primary AD as soon as possible.
Always install latest OS with compatible latest AD.

We have experienced issues with Windows Server 2019 when all DCs in our environment were not on the same CU. With one Server on CU 2023-11 and the rest still on 2023-10, we began seeing these errors and unexpected Server reboots impacting all DCs in our environment:


Log Name: System

Source: User32

Date: 11/20/2023 4:32:19 PM

Event ID: 1074

Task Category: None

Level: Information

Keywords: Classic


Computer: [redacted]

Description: The process wininit.exe has initiated the restart of computer [redacted] on behalf of user for the following reason: No title for this reason could be found

Reason Code: 0x50006

Shutdown Type: restart

Comment: The system process 'C:\windows\system32\lsass.exe' terminated unexpectedly with status code -1073740791. The system will now shut down and restart.


This behavior was not stopped until all DCs were upgraded to the CU 2023-11.

I'm late for the party here but want to clear an important topic up for other’s awareness.
A few of the uninformed responses here will result in full blown incident response if it happens in an enterprise environment. I’ve witnessed it firsthand and have helped major corporations investigate, perform RCAs, and resolve partial, yet very large scale outages due to the encouraged actions stated within this discussion.

What some of the people have said here is completely wrong.
Yes, you can have DCs on the same domain with (reasonably) different OS versions. However, only if your DC OS versions are in Mainstream Support.
If the DC OS versions stay aligned with Mainstream Support, they’ll typically be reasonably close in OS version either way.
The concerning part, however, is the responses to whether DCs can or cannot be on different update/patch (CU) levels.
In summary, unless you want to get deep into the trenches with what configurations change, and what varying problems to expect on DCs (and therefore AD itself), consider this response to the question a big no. Strive to keep them all on the same CU at all times, regardless of OS versions.
Will they still work as expected? Maybe. Will there be issues if the CU versions are vastly different between DCs? Absolutely. Contrary to assumption here, Microsoft has been progressively "hardening" auth and security related requirements, such as requiring Kerberos PAC, Kerberos PAC Signatures, RPC sealing, NTLM, and other areas as well.
These changes, that become increasingly more “aggressive” through each update, results in, for example, unsuccessful creation of Kerberos tickets between patched DCs and DCs that are not.
Regardless of OS version, if you don't have every DC on the same, or at least very close CU (within a month or so), access and authentication will break for many of the AD objects.
For example:
If you have multiple sites, with multiple DCs and AD objects, you won't be able to authenticate via. Kerberos to/on a "computer" on a different site than you are in, as the remote site will not send the required Kerberos PAC and PAC signatures at all or in a way that the patched DC expects.
Then there's also the issue of the issues. There are a ton of known unique problems that arise with each CU version.
As of the last few years you can't simply pull the trigger, apply the latest patch on everything, and hope for the best.
In a critical production environment, prior to patching, research of each CU version is a necessity so you can determine which of the latest versions' pros exceed the cons (security vulnerability patching vs known issues that the CU causes vs configuration changes that will affect systems and/or users..)
Additionally, unless a critical need arises such as for a zero-day type patch, or substantial vulnerability remediation requirements, the CUs should be first tested in non-prod that emulates your prod environment (if budget allows).
..Of course, security is and always should be #1 priority, so always strive to be on the latest CUs for all systems either way.
Another Example:
With one of the somewhat recent CUs , if you have certain encryption attributes (Support AES 256 or 128 bit) set on any of your AD objects, you won't be able to authenticate via Kerberos for said objects against the patched DCs.
Yet another recent version can cause auth to fail in scenarios with 3-part SPNs. (Sometimes you can get lucky and hit NTLM fallback for auth, however it is substantially easier to "hack")
If you then in the above example have said CU on some of the DCs, but not on other DCs, it becomes a nightmare trying to troubleshoot issues. What is causing what undesired action? What object is communicating with what DC during the occurrence? Which is causing the issue? Potentially both or all of them.

In summary, you should always strive to be on the latest updates. If the OS is too old, demote it, and bring a new one up. Never be inconsistent with patching, most importantly with DCs in the same domain and forest (additionally consider the implications on trusts with other domains, as that is impacted as well). Keep the DC CUs consistent across the board. Strive to stay on the same CU for all DCs. Never stray more than 1-2 months of difference. Research to determine the impact each will have on your environment. Determine what commands or scripts need to be ran to check objects for atypical configurations that could/will result in failed auth after patches are applied.
Each of the updates comes with fixes, changes, and unique issues that will affect your environment. Do you research and test prior to going prod, but don’t wait too long, as the bad guys are always at your door.