May 09 2022 05:33 AM
May 09 2022 05:33 AM
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)
May 09 2022 06:27 AM
May 09 2022 10:54 PM
May 09 2022 11:08 PM
May 10 2022 12:21 AM - edited May 10 2022 12:22 AM
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).
May 10 2022 12:57 AM
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.
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:
May 10 2022 01:59 AM
May 10 2022 06:26 AM
May 12 2022 12:53 AM
May 12 2022 02:12 AM
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.