Migration Server 2022 : forêt multi-domaines

Dans un article précédent, j’avais décrit la montée en niveau fonctionnel 2016 et l’audit des approbations entre mes deux domaines. Je terminais sur cette note : “Il va aussi falloir penser à upgrader l’OS de mes autres contrôleurs.”

Voilà. C’est fait.

Le contexte

L’infrastructure repose sur une forêt Active Directory à deux domaines :

Un domaine racine de forêt, dédié aux serveurs et aux hyperviseurs — deux contrôleurs de domaine assurent sa disponibilité. Le premier porte les rôles domaine (PDC Emulator, RID Master, Infrastructure Master), le second les rôles forêt (Schema Master, Domain Naming Master).
Un domaine enfant, dédié aux stations de travail et aux utilisateurs — deux contrôleurs de domaine également. Le premier concentre les rôles FSMO du domaine ainsi que le service DNS et le DHCP principal. Le second assure la continuité : Global Catalog, DNS secondaire, DHCP en failover et Autorité de Certification. Sans ces rôles, un second DC ne serait qu’un réplica passif — autant lui donner une vraie raison d’exister.

Tous tournaient sous Windows Server 2016, dont le support mainstream est terminé depuis 2022 et le support étendu se termine en janvier 2027. Le moment de migrer vers Windows Server 2022 était venu.

Méthode choisie — Démote / Re-promote

Deux approches existent pour migrer un DC vers une nouvelle version de Windows Server.

L’upgrade in-place consiste à monter l’ISO et upgrader l’OS directement sur le DC. Plus rapide, mais Microsoft ne le recommande pas pour les contrôleurs de domaine. L’expérience le confirme : lors d’une migration précédente effectuée en in-place, des problèmes de timing Kerberos au redémarrage avaient causé des erreurs de réplication et nécessité une tâche planifiée pour forcer la synchronisation après chaque reboot.

La démote / re-promote consiste à transférer les rôles FSMO vers un autre DC, démoter le DC cible, upgrader l’OS, re-promouvoir en DC, puis retransférer les rôles. Plus long, mais propre — base NTDS fraîche, pas de résidu de l’ancien OS. C’est la méthode recommandée par Microsoft, et celle qu’on va appliquer.

Prérequis avant de commencer

Backup complet

La migration implique des démotions et re-promotions. Un backup complet de tous les DCs est indispensable avant de commencer. Pas de compromis.

Vérifier la santé de la réplication

repadmin /replsummary
dcdiag /test:replications

Zéro erreur exigé. Si des problèmes de réplication existent, on les règle d’abord.

Identifier les rôles FSMO

netdom query fsmo

Il faut savoir précisément qui détient quels rôles avant de commencer à transférer quoi que ce soit.

Vérifier le SYSVOL

# L'état DFSR doit être à 4 (Normal) sur tous les DCs
Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo | Select-Object ReplicatedFolderName, State

# Comparer le nombre de GPOs entre les DCs
$dc1 = Get-ChildItem "C:\Windows\SYSVOL\sysvol\mondomaine.local\Policies" | Select-Object -ExpandProperty Name
$dc2 = Get-ChildItem "\\autredc\SYSVOL\mondomaine.local\Policies" | Select-Object -ExpandProperty Name
Compare-Object $dc1 $dc2

Dans mon cas, le dcdiag pre-migration révèle un problème DFSR sur l’un des DCs du domaine racine : neuf GPOs présents sur le DC principal sont absents du SYSVOL de l’autre DC. La réplication DFS est cassée depuis un moment, sans s’être manifestée autrement qu’en erreurs 1058 dans les logs système. Ce problème va orienter l’ordre de migration.

Migration du domaine racine de forêt

Ordre de migration : commencer par le DC avec DFSR cassé

Plutôt que de réparer DFSR puis migrer, on fait d’une pierre deux coups : on commence par le DC dont le SYSVOL est défaillant. La re-promote va reconstruire DFSR complètement depuis zéro, ce qui règle le problème à la racine.

L’autre DC du domaine racine — celui qui porte les rôles Schema Master et Domain Naming Master — devient le DC temporaire qui accueille tous les rôles pendant la migration.

Étape 1 — Transférer les rôles forêt vers le DC sain

Depuis le DC qu’on va migrer :

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

Les rôles domaine (PDC, RID, Infrastructure) étant déjà sur ce DC, il porte temporairement les 5 rôles FSMO. C’est une situation à risque — ce DC devient le point unique de défaillance pour la forêt. On travaille vite et on ne traîne pas.

Vérification :

netdom query fsmo
# Les 5 rôles doivent apparaître sur DC-SAIN

Étape 2 — Démote

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

Note : le paramètre -RemoveDnsDelegation:$true peut provoquer une erreur selon la configuration DNS. Le retirer suffit dans ce cas.

PowerShell demande de définir un mot de passe Administrateur local pour le serveur post-démote — à noter dans un gestionnaire de mots de passe avant de valider. Le serveur redémarre automatiquement en serveur membre.

Étape 3 — Upgrade OS vers Server 2022

Depuis la console de virtualisation, monter l’ISO Windows Server 2022 et lancer le setup.exe depuis Windows — pas au boot. Choisir “Upgrade : Keep files, settings, and apps” pour conserver la même édition (Standard ou Datacenter). Le serveur effectue 2 à 3 redémarrages automatiques.

Après le premier login :

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

Après une démote, les GPOs domaine ne s’appliquent plus — les règles firewall et RDP doivent être rouvertes manuellement le temps de la re-promotion.

Étape 4 — Re-promotion en DC

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

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

Le mot de passe DSRM est défini ici. Rappel : c’est le mot de passe du compte Administrateur local en mode restauration des services d’annuaire — propre à chaque DC, indépendant du domaine. À noter dans KeePass avant de valider.

Étape 5 — Résolution du problème DFSR post-promotion

Après la re-promotion, DFSR reste bloqué en State 2 (Initial Sync) pendant plusieurs heures sans progresser. Le diagnostic révèle que le DC source doit être explicitement marqué comme autoritaire pour forcer la synchronisation initiale.

Les états DFSR à connaître :

State	Signification
0	Uninitialized
2	Initial Sync — en attente de synchro initiale
4	Normal — objectif

Depuis le DC source (DC sain) :

# Marquer comme source autoritaire
Set-ADObject -Identity "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC-SOURCE,OU=Domain Controllers,DC=mondomaine,DC=local" `
  -Replace @{"msDFSR-Options"=1}

repadmin /syncall /AdeP
Restart-Service DFSR -Force

Depuis le DC re-promu :

# Marquer comme non-autoritaire
Set-ADObject -Identity "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC-REPROMOTE,OU=Domain Controllers,DC=mondomaine,DC=local" `
  -Replace @{"msDFSR-Options"=0}

Restart-Service DFSR -Force

Vérification après 2-3 minutes :

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

Get-ChildItem "C:\Windows\SYSVOL\domain"
# Policies et scripts présents ✅

Note sur le port 5722 : contrairement à une idée reçue, DFSR n’utilise pas le port fixe 5722 (c’était FRS, son prédécesseur). DFSR utilise des ports RPC dynamiques. Inutile d’ouvrir le 5722 pour résoudre des problèmes DFSR.

Étape 6 — Retransfert des rôles

Une fois le SYSVOL synchronisé et la réplication vérifiée :

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

Migration du second DC du domaine racine

Même séquence en sens inverse. Le DC fraîchement migré joue le rôle de DC temporaire.

# Transférer tous les rôles vers le DC déjà migré
Move-ADDirectoryServerOperationMasterRole -Identity "DC-DEJA-MIGRE" `
  -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, DomainNamingMaster

Démote → Upgrade → Re-promote → Retransfert des rôles domaine.

Timing FSMO post-promotion : immédiatement après une re-promotion, AD DS n’est pas encore complètement initialisé. Si le transfert PowerShell échoue avec “Le service d’annuaire n’est pas disponible”, deux options : patienter 5 à 10 minutes et réessayer, ou passer par la GUI (Active Directory Users and Computers → Maître d’opérations) qui propose un transfert forcé.

Migration du domaine enfant

Les deux DCs du domaine enfant avaient déjà été migrés en Server 2022 lors d’une opération précédente. Aucune migration OS nécessaire pour ce domaine.

Montée en niveau fonctionnel

Depuis le PDC Emulator du domaine racine :

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

Pour le domaine enfant :

Set-ADDomainMode -Identity mondomaine.lan -DomainMode Windows2016Domain
# Set-ADForestMode inutile — la forêt est partagée, déjà montée depuis le domaine racine

Si Set-ADForestMode retourne “Impossible d’abaisser le niveau fonctionnel”, c’est que c’est déjà fait — malgré le message trompeur, ce n’est pas une erreur.

Vérification :

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

Windows2016 est le niveau fonctionnel maximum pour une infrastructure en Server 2022. Microsoft n’a pas introduit de nouveau niveau avec Server 2019 ni Server 2022. En revanche, Windows Server 2025 introduit un nouveau niveau fonctionnel — le premier depuis 2016. Il apporte notamment une base de données AD en pages 32K (contre 8K depuis Windows 2000) et nécessite que tous les DCs de la forêt soient sous Server 2025. Une prochaine migration en perspective.

Vérifications finales

# Réplication — 0 erreur exigé sur tous les DCs
repadmin /replsummary

# FSMO
netdom query fsmo

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

# Nombre de GPOs cohérent entre les DCs
Get-ChildItem "C:\Windows\SYSVOL\sysvol\mondomaine.local\Policies" | Measure-Object

Points de vigilance

DFSR après re-promotion — La re-promotion ne garantit pas une synchro DFSR automatique. Si le State reste à 2 après 20-30 minutes, le Non-Authoritative Restore via msDFSR-Options est la procédure Microsoft recommandée (voir étape 5 ci-dessus).

Mot de passe DSRM — Propre à chaque DC, il doit être noté lors de chaque re-promotion. Il ne se récupère pas.

GPO firewall — Après une démote, les GPOs domaine ne s’appliquent plus. Prévoir d’ouvrir manuellement RDP et les règles firewall nécessaires avant la re-promotion.

Ordre de migration — Dans une forêt multi-domaines, commencer par le domaine racine. Les rôles forêt (Schema Master, Domain Naming Master) doivent toujours rester sur un DC opérationnel.

Bilan

Une opération qui s’est étalée sur une journée, avec une galère DFSR non anticipée qui en a occupé une bonne partie. Le diagnostic et la résolution via Non-Authoritative Restore ont finalement été plus instructifs que la migration elle-même.

La prochaine étape logique : migrer Windows LAPS legacy vers Windows LAPS natif, maintenant que le niveau fonctionnel 2016 est en place sur tous les domaines et que tous les DCs sont en Server 2022. Les prérequis sont là — plus d’excuse pour reporter.