Après l’installation d’ESXi et d’une VM Linux pour l’accès VPN, mon lab accueille son premier contrôleur de domaine. L’objectif : disposer d’un AD durable, puis reproduire une migration entre deux domaines avec des comptes utilisateurs déjà présents dans la cible.
Dans cette première partie, je prépare Windows Server 2025, crée la forêt lab.auditms.fr et vérifie les services AD et DNS. La migration des postes et des profils viendra ensuite : elle n’est pas encore réalisée à ce stade.
Une cible de migration qui restera dans le lab
Le premier serveur, LAB-DC01, héberge le domaine qui sera conservé. Une deuxième forêt temporaire servira plus tard de source pour les essais. Deux DC dans le même domaine ne reproduiraient pas ce scénario : ils partageraient le même annuaire.
Le futur test comportera donc deux forêts distinctes et un poste client. Un utilisateur existera dans chaque forêt, et le poste possédera déjà un profil associé au compte source. Le but sera de tester le passage vers le compte cible existant, puis de vérifier ce qui est réellement conservé.
Configuration de la VM
| Paramètre | Configuration retenue |
|---|---|
| Nom du serveur | LAB-DC01 |
| Système | Windows Server 2025 avec interface graphique |
| Processeur | 2 vCPU |
| Mémoire | 4 Go |
| Disque virtuel | 60 Go, provisionnement dynamique (Thin) |
| Rôles | AD DS et DNS |
| Domaine | lab.auditms.fr |
Cette configuration est celle de mon lab, pas un dimensionnement de production. Le datastore étant limité, le Thin évite de réserver immédiatement les 60 Go. Il faut toutefois surveiller sa capacité réelle : les disques et les snapshots peuvent grandir.
L’ISO a été transféré dans le datastore avant la création de la VM. Dans mon essai à travers le VPN, la copie SCP s’est montrée plus rapide que l’envoi depuis le navigateur. Cela reste une observation locale, pas une règle générale sur les performances d’ESXi.
Choisir le nom du domaine
J’ai retenu lab.auditms.fr, un sous-domaine du nom public AuditMS. Utiliser directement auditms.fr aurait été possible, mais aurait nécessité de gérer la coexistence des noms internes et publics dans le DNS AD.
Avec un espace dédié au lab, je sépare plus simplement l’annuaire du site web. Un suffixe UPN auditms.fr pourra être ajouté ensuite pour obtenir des identifiants comme utilisateur@auditms.fr ; cet ajout n’a pas encore été effectué dans cette étape.
Fixer l’adresse IP avant la promotion
Le serveur disposait initialement d’une configuration DHCP. Avant de terminer sa promotion, j’ai fixé son adresse et conservé la passerelle du réseau.
| Paramètre | Valeur du lab |
|---|---|
| Interface | Ethernet0 |
| Index d’interface | 4 |
| Adresse IPv4 | 192.168.1.26 |
| Préfixe | /24, soit 255.255.255.0 |
| Passerelle | 192.168.1.1 |
| DNS client retenu | 192.168.1.26 |
Ces adresses sont propres à mon environnement. Avant de réutiliser une adresse DHCP en statique, il faut la réserver à la VM ou l’exclure de la plage distribuée par le routeur.
Pour identifier la configuration, dans PowerShell administrateur :
Get-NetIPConfiguration
Get-NetIPAddress -InterfaceIndex 4 -AddressFamily IPv4 |
Select-Object IPAddress, PrefixLength, PrefixOrigin
Puis, depuis la console de la VM, les commandes utilisées pour ce réseau :
netsh interface ipv4 set address name="Ethernet0" source=static address=192.168.1.26 mask=255.255.255.0 gateway=192.168.1.1
Set-DnsClientServerAddress -InterfaceIndex 4 -ServerAddresses 192.168.1.26
Get-NetIPConfiguration -InterfaceIndex 4
Le premier et unique DC hébergeant DNS utilise sa propre adresse comme DNS client, conformément à la recommandation Microsoft [2]. Le service DNS doit ensuite pouvoir résoudre les noms externes, via des redirecteurs ou les indications de racine. Pointer vers soi ne suffit donc pas à valider la résolution Internet.
Cette capture montre l’état initial, pas la configuration finale.
Installer le rôle AD DS
Dans le Gestionnaire de serveur, ouvrir Gérer → Ajouter des rôles et fonctionnalités, choisir une installation basée sur un rôle, puis sélectionner LAB-DC01.
Cocher Services de domaine Active Directory et accepter les fonctionnalités requises, en conservant les outils de gestion. Continuer l’assistant et lancer l’installation [1].
Une fois le rôle installé, sélectionner Promouvoir ce serveur en contrôleur de domaine. Installer le rôle et créer l’annuaire sont deux étapes distinctes.
Créer la nouvelle forêt
Dans l’assistant de configuration, sélectionner Ajouter une nouvelle forêt, puis saisir lab.auditms.fr comme domaine racine [1].
Sur la page suivante, les options retenues sont :
- niveau fonctionnel de forêt et de domaine : Windows Server 2025 ;
- Serveur DNS et Catalogue global activés ;
- contrôleur en lecture seule RODC désactivé ;
- mot de passe de restauration DSRM renseigné et conservé de manière sûre.
Ce choix de niveau fonctionnel concerne les DC de cette forêt. Le deuxième AD temporaire sera indépendant : il ne sera pas un DC supplémentaire de lab.auditms.fr.
Comprendre l’avertissement de délégation DNS
L’assistant affiche un avertissement indiquant qu’il ne peut pas créer de délégation dans la zone parente.
Dans ce lab, aucune délégation publique vers le DC interne n’est nécessaire. L’option reste décochée. Les futurs clients devront interroger un DNS capable de résoudre la zone AD ; ici, celui de LAB-DC01.
L’assistant permet ensuite de vérifier le nom NetBIOS, les chemins de stockage et le récapitulatif. Après la vérification des prérequis, lancer l’installation. La promotion entraîne le redémarrage du serveur.
Vérifier le résultat
Après redémarrage, la console Utilisateurs et ordinateurs Active Directory affiche le domaine lab.auditms.fr et ses conteneurs.
Pour contrôler les principaux services, j’ai exécuté :
dcdiag /test:Advertising /test:SysVolCheck /test:Services /test:DNS
Les tests Advertising, SysVolCheck, Services et DNS ont réussi sur LAB-DC01. Le test DNS au niveau du domaine a également réussi.
Ces résultats valident les contrôles exécutés à cet instant. Ils ne remplacent pas une vérification complète des sauvegardes, de la résolution externe ou du fonctionnement d’un poste joint au domaine.
La suite : reproduire une migration de profil
Le domaine cible est maintenant créé. La prochaine étape sera de préparer une forêt source temporaire et un poste Windows avec un profil utilisateur de test.
Le point à valider sera précis : ouvrir la session avec un compte cible déjà existant tout en retrouvant les données et les paramètres attendus du profil source. Les accès aux partages, les applications et les éléments protégés liés à l’ancienne identité devront être testés séparément. Aucune conservation intégrale du profil ne peut être annoncée avant ces essais.
Références
- Microsoft Learn — Installer les services de domaine Active Directory
- Microsoft Learn — Recommandations de configuration du client DNS
Retour d’expérience du 27 octobre 2026. Les captures proviennent du lab ; les caractéristiques du réseau et les ressources doivent être adaptées à chaque environnement.