How do we upgrade an existing AD DS forest or domain to Windows Server 2022.
Well,
let me give you a six‑step path here to show you how that process
works. According to Microsoft best practice,
of course, you could do in‑place upgrade, but assuming
you're not going to do in‑place upgrade,
you're going to deploy new domain controllers, here's an approach to consider.
Add at least two, for high availability and redundancy, new member servers
running Windows Server 2022 to each of your domains.
When you're ready to start movement,
that is to start promoting some of these member servers to domain controllers,
you'll need to run adprep to prepare the forest.
You'll run that on the Windows Server 2022 boxes to
prepare both the forest and your domains.
This is adprep /forestprep, adprep /domainprep. This
prepares the schema for an upgrade.
Next, we'll want to promote those new member servers to become domain
controllers in the current down‑level environment,
whatever it is. Maybe you're currently running Windows Server 2019,
maybe you're doing 2016,
maybe you're even doing 2012 R2, I don't know. Once you've got
those member servers joined and participating as domain
controllers in the down‑level environment,
you'll want to begin the process of transferring the flexible
single master operation, or FSMO, roles from the old down‑level
domain controllers to the newer ones,
the ones that are running Windows Server 2022.
And then lastly,
you'll demote the legacy domain controllers to become member servers,
and then you can either keep them there or decommission them at that
point, and then make sure that your domain and forest functional levels
are set to Windows Server 2016.
Now note that well, that even though we're up to Windows server
2022, Microsoft hasn't made any changes to domain or forest
functional level IDs since Windows Server 2016, so that's actually
the highest that we can go as of today.
We discuss and learn all about FSMO roles in the AZ‑800 skillset, so I'll
just show you some PowerShell here to refresh your memory.
We can get a list of which domain controllers are holding domain and
forest‑scoped roles. Here we've got Get‑ADDomain to grab the domain roles,
InfrastructureMaster, RIDMaster, and PDCEmulator.
We can do a same pattern with Get‑ADForest to grab the forest‑scoped FSMO roles.
Those are DomainNamingMaster and SchemaMaster.
We want to do a gentle transfer and not a seize operation. With
PowerShell, we can invoke Move‑ADDirectoryServerOperationMasterRole
to transmit those forest‑level roles. Best practice is to keep the
forest‑level roles together on the same domain controller, and then
we can do the same thing,
Move‑ADDirectoryServerOperationsMasterRole to transfer the
domain‑specific roles to another domain controller.
Now recall that a seize is when you add the force switch parameter to this Move
command, and it would be, sieze that is, would be something you would only do
in an emergency when you don't have the ability to do a graceful transfer of
power or transfer of role, for example,
the original role holder is unavailable. As far as setting forest and
domain functional levels with PowerShell, again,
remember that there hasn't been any change here since 2016.
We can do Set‑ADDomainMode on the name of the domain, and the
label that we're looking for is Windows2016Domain.
We can do the same thing at the forest level in the forest root domain by setting ForestMode Windows2016Forest.