Forum Discussion
Any potential problems with mixed OS versions for Active Directory PDC?
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...
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: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels#windows-server-2008-functional-levels. Things start to change at 2016 level because of DFS-R requirement https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels#windows-server-2016-functional-levels
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.
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:
- Migrate from FRS to DFS-R first;
- Make sure that completes successfully and that you have no other replication issues;
- 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);
- Once they're all on Server 2022, consider raising your functional levels.
Cheers,
Lain
- 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.
Cheers,
Lain
- No problem, good luck and please mark my answer as solution to mark it as solved
