Migrer un contrôleur de domaine Windows Server 2016 vers 2025

Remplacer le contrôleur plutôt que mettre son système à niveau

La migration la plus prévisible d'un contrôleur de domaine Windows Server 2016 consiste à installer un nouveau serveur Windows Server 2025, le promouvoir dans le domaine existant, valider sa réplication, transférer les rôles nécessaires puis rétrograder proprement l'ancien serveur. Microsoft recommande cette approche avec une nouvelle installation plutôt qu'une mise à niveau sur place d'AD DS.

Ce guide traite précisément des contrôleurs de domaine. Il complète le plan général de sortie de Windows Server 2016 sans prétendre migrer automatiquement les autres rôles que l'ancien serveur pourrait héberger : DNS, DHCP, NPS, autorité de certification, connecteur Microsoft Entra, partage de fichiers ou logiciel d'un fournisseur doivent chacun avoir leur propre procédure.

Ne commencez pas par transférer les rôles FSMO. Le point de départ est un annuaire sain, une sauvegarde restaurable et un inventaire des dépendances. Ajouter un contrôleur 2025 à une forêt déjà en erreur ne corrige pas la réplication; cela ajoute une nouvelle copie des mêmes problèmes.

• Microsoft — Mettre à niveau les contrôleurs de domaine ↗
• Microsoft — Planifier le parcours de mise à niveau Windows Server ↗

Architecture cible et critères de réussite

Évitez de placer tous les nouveaux DC sur le même hôte, la même baie ou le même domaine de panne. Pour un petit environnement, deux DC bien séparés et correctement sauvegardés valent mieux qu'une multiplication de copies identiques sans plan de récupération.

1. Vérifier les niveaux fonctionnels et SYSVOL

Un contrôleur Windows Server 2025 est pris en charge avec les niveaux fonctionnels de forêt et de domaine Windows Server 2016 ou Windows Server 2025. Si l'environnement est encore au niveau 2012 R2, il faut d'abord retirer les DC incompatibles et élever les niveaux jusqu'à 2016. Le niveau 2025 n'est pas requis pour introduire un DC 2025.

Conservez le niveau fonctionnel 2016 pendant la coexistence : il accepte les DC 2016, 2019, 2022 et 2025. Le niveau 2025 exige que tous les contrôleurs du domaine et de la forêt soient sous Windows Server 2025. Son activation doit être un changement séparé, après la fin de la migration et une période d'observation.

SYSVOL doit utiliser DFS Replication. La promotion est bloquée dans les anciens domaines qui utilisent encore FRS. La valeur attendue de dfsrmig /getglobalstate est Eliminated et tous les DC doivent avoir atteint cet état. Une migration FRS vers DFSR est un projet préalable, pas une étape improvisée pendant la promotion.

Import-Module ActiveDirectory
Get-ADForest | Select-Object Name,ForestMode,SchemaMaster,DomainNamingMaster
Get-ADDomain | Select-Object DNSRoot,DomainMode,PDCEmulator,RIDMaster,InfrastructureMaster

$schema = (Get-ADRootDSE).schemaNamingContext
Get-ADObject $schema -Property objectVersion | Select-Object objectVersion

dfsrmig /getglobalstate
dfsrmig /getmigrationstate
Get-SmbShare -Name SYSVOL,NETLOGON

• Microsoft — Niveaux fonctionnels AD DS ↗
• Microsoft — Migrer SYSVOL de FRS vers DFSR ↗

2. Produire une référence de santé avant le changement

Exécutez les contrôles depuis un poste d'administration ou un DC sain et conservez les sorties avant et après la migration. Un avertissement ancien et compris peut être acceptable; une erreur de réplication, de DNS, de SYSVOL ou de publicité du DC doit être résolue avant d'ajouter le serveur.

Repadmin expose les partenaires et erreurs de réplication. Dcdiag teste les services de contrôleur, DNS, les partages SYSVOL et NETLOGON ainsi que plusieurs dépendances. Complétez avec les journaux Directory Service, DNS Server, DFS Replication et System et avec les alertes de votre supervision.

New-Item C:\Temp\AD-Migration -ItemType Directory -Force
repadmin /replsummary > C:\Temp\AD-Migration\replication-summary.txt
repadmin /showrepl * /csv > C:\Temp\AD-Migration\showrepl.csv
dcdiag /e /c /v /f:C:\Temp\AD-Migration\dcdiag-all.txt
dcdiag /e /test:DNS /v /f:C:\Temp\AD-Migration\dcdiag-dns.txt

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.<domaine.example>
Resolve-DnsName -Type SRV _kerberos._tcp.<domaine.example>

Get-ADDomainController -Filter * | Sort-Object Site,HostName |
  Select-Object HostName,IPv4Address,Site,OperatingSystem,
    IsGlobalCatalog,IsReadOnly | Format-Table -AutoSize

Get-ADReplicationFailure -Target * -Scope Forest |
  Select-Object Server,FirstFailureTime,FailureCount,LastError

• Microsoft — Diagnostiquer les échecs de réplication AD ↗
• Microsoft — Vérifier DNS pour la réplication ↗
• Microsoft — Référence dcdiag ↗

3. Inventorier ce qui dépend de l'ancien DC

Ne réutilisez pas immédiatement le même nom ou la même adresse IP pour masquer les dépendances. Cette tactique rend le retour arrière plus difficile et peut cacher des références obsolètes. Corriger les consommateurs pour utiliser le domaine, les enregistrements SRV ou plusieurs serveurs produit une architecture plus résiliente.

Si l'ancien DC héberge une autorité de certification, NPS, DHCP ou Entra Connect, migrez ce rôle avec sa documentation officielle avant la rétrogradation. La réplication AD DS ne déplace pas automatiquement ces configurations.

• Applications, imprimantes, NAS et pare-feu qui pointent vers son adresse IP pour LDAP, LDAPS, Kerberos ou DNS.
• Certificats LDAPS, noms alternatifs, chaîne de confiance et renouvellement automatique.
• Étendues DHCP et options DNS, cartes réseau configurées statiquement et redirecteurs conditionnels.
• NPS/RADIUS, DHCP, AD CS, Microsoft Entra Connect, agents de sauvegarde, EDR, supervision et collecte de journaux.
• Scripts, tâches planifiées, partages administratifs ou applications installées directement sur le DC.
• Règles de pare-feu entre sites pour DNS, Kerberos, LDAP, SMB, RPC Endpoint Mapper et ports RPC dynamiques.
• Rôles FSMO, catalogue global, sites/sous-réseaux, objets de connexion et source de temps.

4. Sauvegarder avant de modifier le schéma

Prenez une sauvegarde récente de l'état du système d'au moins un DC inscriptible sain par domaine, conformément au plan de récupération de forêt. Vérifiez la destination, la rétention et la capacité réelle de restauration. Un instantané d'hyperviseur n'est pas un substitut à une sauvegarde AD DS et à une procédure de récupération testée.

La première promotion d'un DC 2025 prépare le schéma et le domaine automatiquement lorsque le compte possède les droits nécessaires. Pour la première instance dans la forêt, Microsoft exige les autorisations Enterprise Admins, Schema Admins et Domain Admins du domaine du maître de schéma. Utilisez un compte privilégié temporaire et retirez ces adhésions après l'opération.

wbadmin start systemstatebackup -backuptarget:E: -quiet
wbadmin get versions

• Microsoft — Sauvegarder l'état du système d'un DC ↗
• Microsoft — Installer AD DS et droits requis pour Adprep ↗

5. Préparer le nouveau serveur Windows Server 2025

Joignez d'abord le serveur comme membre et redémarrez-le. Sa carte réseau doit interroger un DNS Active Directory existant, pas un DNS public. Après la promotion et la validation de la réplication DNS, configurez une combinaison cohérente de DNS local et de pair selon votre standard; évitez qu'un nouveau DC dépende uniquement de lui-même avant d'être sain.

• Installer les mises à jour cumulatives et les pilotes ou outils d'intégration pris en charge.
• Attribuer un nom définitif, une adresse IP fixe et le bon VLAN; utiliser un DNS AD existant pendant l'adhésion.
• Créer ou vérifier le sous-réseau et son site dans Active Directory Sites and Services avant la promotion.
• Appliquer les politiques de sécurité, EDR, sauvegarde et supervision compatibles avec un contrôleur de domaine.
• Éviter d'installer des applications d'affaires ou des rôles non nécessaires sur le nouveau DC.
• Confirmer la connectivité bidirectionnelle avec les partenaires de réplication prévus.

6. Installer AD DS et promouvoir le nouveau contrôleur

Le serveur peut être promu par Server Manager ou avec le module ADDSDeployment. Indiquez explicitement le site, DNS et le catalogue global. Choisissez un partenaire de réplication sain lorsque la topologie ou la bande passante le justifie. Le mot de passe DSRM doit être unique, protégé dans un coffre et récupérable pendant un incident.

Test-ADDSDomainControllerInstallation effectue les vérifications sans promouvoir. Lisez chaque avertissement au lieu de convertir mécaniquement la commande en déploiement. La promotion redémarre le serveur.

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

$domain = 'corp.example'
$site = 'Montreal-HQ'
$dsrm = Read-Host 'Mot de passe DSRM' -AsSecureString

Test-ADDSDomainControllerInstallation `
  -DomainName $domain -InstallDns -SiteName $site `
  -Credential (Get-Credential)

Install-ADDSDomainController `
  -DomainName $domain -InstallDns:$true -SiteName $site `
  -NoGlobalCatalog:$false -Credential (Get-Credential) `
  -SafeModeAdministratorPassword $dsrm

• Microsoft — Installer Active Directory Domain Services ↗

7. Valider le nouveau DC avant de lui transférer quoi que ce soit

Attendez la réplication initiale complète. Vérifiez toutes les partitions : domaine, configuration, schéma et partitions DNS. SYSVOL et NETLOGON doivent être partagés, le DC doit se publier dans DNS et le journal DFS Replication ne doit pas signaler une initialisation incomplète.

Testez depuis plusieurs sous-réseaux : ouverture de session, application d'une GPO, résolution DNS, changement de mot de passe, authentification Kerberos et LDAP/LDAPS si utilisé. Un test local réussi sur le DC ne prouve pas que les pare-feu intersites et le DC Locator fonctionnent.

repadmin /showrepl <DC2025>
repadmin /replsummary
dcdiag /s:<DC2025> /test:Advertising /test:Services /test:Replications /v
dcdiag /s:<DC2025> /test:SysVolCheck /test:NetLogons /test:DNS /v

Get-SmbShare -CimSession <DC2025> -Name SYSVOL,NETLOGON
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.<domaine.example>
Get-ADDomainController -Identity <DC2025> |
  Select-Object HostName,Site,IsGlobalCatalog,OperationMasterRoles

$since = (Get-Date).AddHours(-24)
'Directory Service','DNS Server','DFS Replication','System' | ForEach-Object {
  Get-WinEvent -ComputerName <DC2025> -FilterHashtable @{
    LogName=$_; StartTime=$since; Level=1,2
  } -ErrorAction SilentlyContinue
} | Select-Object TimeCreated,LogName,Id,LevelDisplayName,Message

8. Transférer les rôles FSMO et vérifier le service de temps

Transférez les rôles seulement après plusieurs cycles de réplication réussis. Les cinq rôles peuvent résider sur un même DC dans un petit domaine ou être répartis selon l'architecture. Une migration planifiée utilise un transfert normal; le paramètre Force sert à saisir un rôle lorsque l'ancien détenteur est définitivement indisponible et ne doit pas revenir en ligne.

Si le rôle PDC Emulator de la racine de forêt change de serveur, vérifiez immédiatement W32Time. Le PDC racine doit utiliser la source NTP autorisée; les autres DC et membres suivent normalement la hiérarchie du domaine. Ne copiez pas aveuglément une ancienne configuration de registre sans la comparer au standard actuel.

$target = '<DC2025>'
Move-ADDirectoryServerOperationMasterRole -Identity $target `
  -OperationMasterRole SchemaMaster,DomainNamingMaster,`
    PDCEmulator,RIDMaster,InfrastructureMaster

Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
w32tm /query /source
w32tm /query /status
w32tm /query /configuration

• Microsoft — Transférer les rôles FSMO ↗
• Microsoft — Fonctionnement du service de temps Windows ↗

9. Rediriger les dépendances et observer

Mettez à jour les options DHCP, configurations DNS statiques, applications LDAP, certificats, règles de pare-feu, sauvegardes, supervision et collecteurs de journaux. Confirmez que les clients découvrent le nouveau DC par les enregistrements SRV et qu'aucun flux critique ne dépend encore de l'ancienne adresse.

Conservez l'ancien DC en service pendant une période d'observation adaptée aux cycles métiers : traitements nocturnes, paie, sauvegardes, applications mensuelles et basculement de site. Une semaine peut suffire dans un petit environnement simple; elle est insuffisante si des intégrations ne s'exécutent qu'en fin de mois.

• Surveiller les erreurs Kerberos, Netlogon, LDAP, DNS et réplication.
• Comparer les requêtes DNS et authentifications reçues par l'ancien et le nouveau DC.
• Tester un redémarrage contrôlé ou une indisponibilité temporaire de l'ancien DC si le risque le permet.
• Faire approuver les tests métiers et conserver les résultats.

10. Rétrograder proprement Windows Server 2016

Avant la rétrogradation, confirmez que l'ancien DC ne porte plus de rôle FSMO requis, que d'autres serveurs hébergent DNS et le catalogue global, que les dépendances ont été déplacées et que la réplication est saine. Utilisez Server Manager ou Uninstall-ADDSDomainController; ne retirez jamais le rôle AD DS avec DISM sur un serveur encore contrôleur de domaine.

La rétrogradation forcée est un dernier recours lorsque le DC ne peut plus joindre les autres contrôleurs. Elle laisse des métadonnées orphelines et perd les changements non répliqués; un nettoyage de métadonnées immédiat est alors obligatoire. Dans une migration normale, toute nécessité de forcer est un signal d'arrêt et d'investigation.

Get-ADDomainController -Identity <DC2016> |
  Select-Object HostName,IsGlobalCatalog,OperationMasterRoles
repadmin /showrepl <DC2016>
repadmin /replsummary

# Invite pour le mot de passe Administrateur local et les validations.
Uninstall-ADDSDomainController

• Microsoft — Rétrograder un contrôleur de domaine ↗
• Microsoft — Uninstall-ADDSDomainController ↗

11. Nettoyer, valider et séparer le niveau fonctionnel 2025

N'élevez pas le niveau fonctionnel 2025 dans la même fenêtre que la dernière rétrogradation. Cette étape exclut les DC 2016, 2019 et 2022 et active des capacités propres à 2025, dont l'option de pages de base de données 32 K. Elle mérite un changement séparé, une vérification de tous les domaines et une décision fondée sur un besoin réel.

La migration est terminée lorsque l'environnement est exploitable et récupérable, pas lorsque l'ancien serveur est éteint. Conservez les rapports avant/après, les preuves de sauvegarde, les résultats des tests et la décision de retrait.

• Vérifier la disparition de l'ancien objet NTDS Settings et de l'objet serveur attendu dans Sites and Services.
• Retirer les anciens enregistrements DNS seulement après avoir confirmé qu'ils sont réellement obsolètes.
• Relancer repadmin, dcdiag et les tests DNS et SYSVOL sur tous les DC.
• Mettre à jour la documentation, la CMDB, les diagrammes, les sauvegardes et les procédures d'urgence.
• Retirer les groupes privilégiés temporaires utilisés pour Adprep et la promotion.
• Conserver une période de stabilité avant d'envisager le niveau fonctionnel Windows Server 2025.

• Microsoft — Élever les niveaux fonctionnels AD DS ↗

Plan de retour arrière réaliste

Le meilleur retour arrière est la coexistence temporaire : tant que l'ancien DC est sain, répliqué et non rétrogradé, les rôles et dépendances peuvent être replacés proprement. Une fois sa rétrogradation terminée, la récupération relève des autres contrôleurs et du plan de restauration de forêt, pas d'un instantané improvisé.

Une migration de DC est aussi un test de maturité AD

Le chemin technique est court; l'inventaire et les validations font la qualité du projet. Les échecs viennent souvent d'une zone DNS oubliée, d'un appareil qui utilise une IP codée en dur, d'un SYSVOL encore en FRS ou d'un rôle secondaire installé sur le DC sans propriétaire.

Cette procédure constitue un guide d'exécution, pas un remplacement d'un audit Active Directory. Un audit remet aussi en contexte les délégations, comptes privilégiés, protocoles hérités, AD CS, sauvegardes, chemins d'attaque et capacité réelle de récupération.

• Service — Audit de sécurité Active Directory →
• Article — Plan de migration Windows Server 2016 →
• Article — Plan de récupération de forêt Active Directory →