But de la manoeuvre : transformer travail.domaine.com en work.ville.nouveaudomaine.fr, ainsi que les noms NetBIOS de TRAVAIL vers WORK.

Sources : Pour du Server 2003
Pour du Server 2008
Une synthèse
Une autre synthèse

Note préalables

• Les serveurs Exchange ne supportent pas le changement de nom (sauf Exchange 2003, et uniquement le nom DNS, pas le nom NetBIOS)
• Je n’aborde pas ici la mise à jour des relations de confiance entre domaines, elle est détailée dans l’article de chez Microsoft
• Il est très fortement conseillé de backuper les données, ainsi que l’état du système, pour pouvoir le restaurer si besoin
• Il faut faire les opérations depuis un serveur intégré au domaine, mais qui n’est pas un contrôleur de domaine. Celui-ci devra avoir la fonctionnalité “Administration de serveur distants” (qui donne notamment accès à la commande rendom)
• Si une relation de basculement entre 2 serveurs DHCP existe, elle ne fonctionnera (peut-être) plus après renommage du domaine ; il me semble que le plus simple est d’identifier 1 serveur DHCP principal, à jour, de déconfigurer le basculement, d’effectuer le renommage, puis de reconfigurer e basculement avec le nouveau nom.

Création de la nouvelle zone DNS

Il faut au préalable créer une nouvelle zone DNS. Pour ceci, Gestionnaire DNS -> nouvelle zone
Dans un cas simple, laisser les choix par défaut (zone principale, intégrée à l’AD, vers tous les serveurs DNS executés sur des DC dans ce domaine). Adapter si besoin.
Nom de la zone à créer : work.ville.nouveaudomaine.fr

Changement du nom de domaine

Depuis la station de contrôle, on lance une invite de commande en administrateur. Je conseille de dédier un répertoire à la migration

mkdir C:\migration_domaine
cd C:\migration_domaine

Puis

rendom /list

Ceci crée un fichier domainList.xml dans le répertoire courant, qu’il faut éditer en remplaçant l’ancien nom de domaine par le nouveau (il est sage de le backuper avant modification).
On remplace dedans les occurences de travail.domaine.com par work.ville.nouveaudomaine.fr.

On lance ensuite

rendom /showforest

Ceci affiche les infos updatées selon le fichier DomainList.xml modifié. Il ne modifie rien, mais permet de vérifier que la nouvelle organisation est bien celle attendue.

Ensuite,

rendom /upload

Ceci crée le fichier Dclist.xml et l’envoie sur les controlleurs de domaine. Cette étape freeze la foret pour éviter les interactions indésirables entre la migration de domaine, et d’éventuelles modifications sur la forêt.

Microsoft conseille ensuite de répliquer les infos de configuration depuis le serveur Domain Naming Master (mettre son hostname à la place dans la commande suivante) :

repadmin /syncall /d /e /P /q DomainNamingMaster

Si besoin de le connaitre le serveur qui joue le rôle de DNM, on a la commande

dsquery server -forest -hasfsmo Name

Vérifier dans le serveur DNS que nous avons IMPÉRATIVEMENT toutes les entrées définies dans cet article

On peut ensuite lancer la commande

rendom /prepare

qui va vérifier que tous les DCs sont aptes à être mis à jour. Ceci se vérifie sur le fichier Dclist.xml (les DC doivent être en état Prepared).

Enfin,

rendom /execute

qui lance effectivement la mise à jour. Les DCs vont rebooter automatiquement.

Penser à vérifier après reboot que le login se fait bien en utilisant le nouveau domaine, ainsi que les panneau de conf Système.
Vérifier le fichier Dclist.xml, les DCs doivent être à l’état Done.
Si il subsiste un état “Error”, il est possible de compléter la ligne <Retry><Retry> en <Retry>yes<Retry>, puis de réaplliquer cette étape (les DCs à l’état Done ne seront pas réaffectés par la manipulation).
Si un DC reste malgré tout à l’état Error, il faut lui enlever (puis remettre) les rôles AD-DS.

Puis sur un (chaque?) DC après redémarrage :

gpfixup /olddns:travail.domaine.fr /newdns:work.ville.nouveaudomaine.fr

qui met à jour et répare les dépendances de nom de domaine dans le stratégies de groupe après changement.

De même,

gpfixup /oldnb:TRAVAIL /newnb:WORK

qui met à jour le nom NetBIOS du domaine.
À ce stade, il faut redémarrer 2 fois chaque poste client, puis vérifier que son FQDN prend bien en compte le nouveau domaine.

On peut enfin lancer la commande

rendom /clean

qui supprime les références à l’ancien domaine.
Attention, les postes non rebootés 2 fois après cette étape devront être manuellement retirés de l’ancien domaine, puis réintégrés dans le nouveau domaine.

Enfin,

rendom /end

qui finalise la procédure et dévérouille la forêt.

Après connexion d’un client, on peut vérifier que celui-ci est bien présent dans la zone récemment créée des serveurs DNS.

Actions manuelles pour finaliser le changement

Vérifier/updater les chemins du DFSN, des partages réseaux déployés et des imprimantes déployées

• Les FQDN des clients intègrent automatiquement le nouveau nom de domaine, mais pas les serveurs. Pour les renommer correctement, il faut ajouter le FQDN du nouveau domaine, puis le mettre en principal. Pour ceci,

  netdom computername DC1.travail.domaine.com /add:DC1.work.ville.nouveaudomaine.fr netdom computername DC1.travail.domaine.com /makeprimary:DC1.work.ville.nouveaudomaine.fr

• Les partages réseaux déployés par les GPO ne sont pas mis à jour automatiquement pour utiliser le nouveau domaine/nom d’hôte, il faut le faire à la main

• De même pour les imprimantes déployées par GPO. Si le serveur les hébergeant a changé de nom d’hôte, il faut les mettre à jour

• si un espace de nom DFS (DFSN) est utilisé, il ne sera pas non plus mis à jour automatiquement

• lorsque tout fonctionnait bien j’ai backupé (exporté) puis supprimé la zone DNS de l’ancien domaine des serveur DNS pour en effacer les traces et m’assurer que tout reposait bien sur le nouveau domaine

• la synchronisation user/password avec Azure AD Connect ne fonctionnait plus, il a fallu la réinitialiser selon ce post

Dcdiag /test:DNS /DnsRecordRegistration /s:domaincontroller

Vérifier le serveur DHCP et le validité du basculement de l’étendue, s’il existe.