In a previous post, I described the 2016 functional upgrade and the approvals audit between my two domains. I ended on this note: "I’ll also need to think about upgrading the OS on my other controllers."

Well, that’s done.

Background

The infrastructure is based on a two-domain Active Directory forest:

  • A forest root domain, dedicated to servers and hypervisors—two domain controllers ensure its availability. The first holds the domain roles (PDC Emulator, RID Master, Infrastructure Master), while the second holds the forest roles (Schema Master, Domain Naming Master).
  • A child domain, dedicated to workstations and users—also with two domain controllers. The first holds the domain’s FSMO roles as well as the DNS service and the primary DHCP. The second ensures continuity: Global Catalog, secondary DNS, failover DHCP, and Certificate Authority. Without these roles, a second DC would be nothing more than a passive replica—so we might as well give it a real reason to exist.

All were running on Windows Server 2016, for which mainstream support ended in 2022 and extended support ends in January 2027. The time had come to migrate to Windows Server 2022.

Chosen Method — Demote / Re-promote

There are two approaches to migrating a DC to a new version of Windows Server.

In-place upgrade involves mounting the ISO and upgrading the OS directly on the DC. It’s faster, but Microsoft does not recommend it for domain controllers. Experience confirms this: during a previous in-place migration, Kerberos timing issues upon reboot caused replication errors and required a scheduled task to force synchronization after each reboot.

The demote/re-promote involves transferring the FSMO roles to another DC, demoting the target DC, upgrading the OS, re-promoting it as a DC, and then transferring the roles back. It takes longer, but it’s cleaner—a fresh NTDS database, no remnants of the old OS. This is the method recommended by Microsoft, and the one we’ll be using.

Prerequisites Before Starting

Full Backup

The migration involves demotions and re-promotions. A full backup of all DCs is essential before starting. No compromises.

Check Replication Health

repadmin /replsummary
dcdiag /test:replications

Zero errors required. If replication issues exist, resolve them first.

Identify FSMO roles

netdom query fsmo

You must know exactly who holds which roles before beginning to transfer anything.

Check SYSVOL

# The DFSR state must be 4 (Normal) on all DCs
Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo | Select-Object ReplicatedFolderName, State

# Compare the number of GPOs between DCs
$dc1 = Get-ChildItem "C:\Windows\SYSVOL\sysvol\mydomain.local\Policies" | Select-Object -ExpandProperty Name
$dc2 = Get-ChildItem "\\otherdc\SYSVOL\mydomain.local\Policies" | Select-Object -ExpandProperty Name
Compare-Object $dc1 $dc2

In my case, the pre-migration dcdiag reveals a DFSR issue on one of the root domain DCs: nine GPOs present on the primary DC are missing from the SYSVOL on the other DC. DFS replication has been broken for some time, without manifesting itself other than as 1058 errors in the system logs. This issue will determine the migration order.

Migration of the forest root domain

Migration order: start with the DC with broken DFSR

Rather than repairing DFSR and then migrating, we kill two birds with one stone: we start with the DC whose SYSVOL is failing. The re-promotion will rebuild DFSR completely from scratch, which solves the problem at its root.

The other DC in the root domain—the one holding the Schema Master and Domain Naming Master roles—becomes the temporary DC that hosts all roles during the migration.

Step 1 — Transfer the forest roles to the healthy DC

From the DC we are migrating:

Move-ADDirectoryServerOperationMasterRole -Identity "DC-SAIN" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster

Since the domain roles (PDC, RID, Infrastructure) are already on this DC, it temporarily holds all 5 FSMO roles. This is a risky situation—this DC becomes the single point of failure for the forest. Work quickly and don’t linger.

Verification:

netdom query fsmo
# All 5 roles should appear on DC-HEALTHY

Step 2 — Demote

Uninstall-ADDSDomainController `
  -RemoveApplicationPartitions:$true `
  -Force:$true

> Note: The -RemoveDnsDelegation:$true parameter may cause an error depending on the DNS configuration. Simply remove it in this case.

PowerShell prompts you to set a local Administrator password for the server after demotion — make a note of it in a password manager before confirming. The server automatically restarts as a member server.

Step 3 — Upgrade OS to Server 2022

From the virtualization console, mount the Windows Server 2022 ISO and run setup.exe from within Windows — not at boot. Select "Upgrade: Keep files, settings, and apps" to retain the same edition (Standard or Datacenter). The server will perform 2 to 3 automatic reboots.

After the first login:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion
# WindowsProductName : Windows Server 2022 Standard
# WindowsVersion     : 2009

> After a demotion, domain GPOs no longer apply — firewall and RDP rules must be manually re-enabled until re-promotion.

Step 4 — Re-promotion to DC

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Install-ADDSDomainController `
  -DomainName "mydomain.local" `
  -InstallDns:$true `
  -Credential (Get-Credential) `
  -Force:$true

The DSRM password is set here. Reminder: this is the password for the local Administrator account in Directory Services Restore Mode — specific to each DC, independent of the domain. Make a note of it in KeePass before confirming.

Step 5 — Resolving the Post-Promotion DFSR Issue

After re-promotion, DFSR remains stuck in State 2 (Initial Sync) for several hours without progressing. Diagnostics reveal that the source DC must be explicitly marked as authoritative to force the initial synchronization.

DFSR states to be aware of:

State Meaning
0 Uninitialized
2 Initial Sync — waiting for initial sync
4 Normal — target

From the source DC (healthy DC):

# Mark as authoritative source
Set-ADObject -Identity "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC-SOURCE,OU=Domain Controllers,DC=mydomain,DC=local" `
  -Replace @{"msDFSR-Options"=1}

repadmin /syncall /AdeP
Restart-Service DFSR -Force

From the re-promoted DC:

# Mark as non-authoritative
Set-ADObject -Identity "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC-REPROMOTE,OU=Domain Controllers,DC=mydomain,DC=local" `
  -Replace @{"msDFSR-Options"=0}

Restart-Service DFSR -Force

Verification after 2-3 minutes:

Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo | Select-Object ReplicatedFolderName, State
# State: 4 ✅

Get-ChildItem "C:\Windows\SYSVOL\domain"
# Policies and scripts present ✅

> Note on port 5722: contrary to popular belief, DFSR does not use the fixed port 5722 (that was FRS, its predecessor). DFSR uses dynamic RPC ports. There is no need to open port 5722 to resolve DFSR issues.

Step 6 — Role Reassignment

Once SYSVOL is synchronized and replication is verified:

Move-ADDirectoryServerOperationMasterRole -Identity "DC-REPROMOTE" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster

Migration of the second DC in the root domain

Same sequence in reverse. The newly migrated DC acts as a temporary DC.

# Transfer all roles to the already migrated DC
Move-ADDirectoryServerOperationMasterRole -Identity "DC-ALREADY-MIGRATED" `
  -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, DomainNamingMaster

Demote → Upgrade → Re-promote → Re-transfer domain roles.

> Post-promotion FSMO timing: Immediately after a re-promotion, AD DS is not yet fully initialized. If the PowerShell transfer fails with "The directory service is not available," there are two options: wait 5 to 10 minutes and try again, or use the GUI (Active Directory Users and Computers → Operation Masters) which offers a forced transfer.

Child Domain Migration

The two DCs in the child domain had already been migrated to Server 2022 during a previous operation. No OS migration is required for this domain.

Functional Level Upgrade

From the PDC Emulator of the root domain:

Set-ADDomainMode -Identity mydomain.local -DomainMode Windows2016Domain
Set-ADForestMode -Identity mydomain.local -ForestMode Windows2016Forest

For the child domain:

Set-ADDomainMode -Identity mydomain.lan -DomainMode Windows2016Domain
# Set-ADForestMode is unnecessary — the forest is shared and has already been joined from the root domain

If Set-ADForestMode returns "Unable to lower the functional level," it means it has already been done — despite the misleading message, this is not an error.

Verification:

Get-ADDomain | Select-Object DomainMode   # Windows2016Domain
Get-ADForest | Select-Object ForestMode   # Windows2016Forest

> Windows2016 is the maximum functional level for a Server 2022 infrastructure. Microsoft did not introduce a new level with Server 2019 or Server 2022. However, Windows Server 2025 introduces a new functional level—the first since 2016. Notably, it features a 32K-page AD database (compared to 8K since Windows 2000) and requires that all DCs in the forest be running Server 2025. A future migration is on the horizon.

Final Checks

# Replication — 0 errors required on all DCs
repadmin /replsummary

# FSMO
netdom query fsmo

# DFSR
Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo | Select-Object ReplicatedFolderName, State

# Number of GPOs consistent across DCs
Get-ChildItem "C:\Windows\SYSVOL\sysvol\mydomain.local\Policies" | Measure-Object

Points to Watch

DFSR after re-promotion — Re-promotion does not guarantee automatic DFSR synchronization. If the State remains at 2 after 20–30 minutes, Non-Authoritative Restore via msDFSR-Options is the recommended Microsoft procedure (see step 5 above).

DSRM password — Unique to each DC, it must be noted during each re-promotion. It cannot be recovered.

GPO firewall — After a demotion, domain GPOs no longer apply. Plan to manually open RDP and the necessary firewall rules before re-promotion.

Migration Order — In a multi-domain forest, start with the root domain. Forest roles (Schema Master, Domain Naming Master) must always remain on an operational DC.

Summary

An operation that spanned a full day, with an unexpected DFSR issue that took up a significant portion of it. The diagnosis and resolution via Non-Authoritative Restore were ultimately more instructive than the migration itself.

The next logical step: migrate legacy Windows LAPS to native Windows LAPS, now that the 2016 functional level is in place on all domains and all DCs are running Server 2022. The prerequisites are in place—no more excuses to delay.