Les deux forêts Active Directory sont maintenant en place dans mon homelab. Pour préparer les essais de migration, il me fallait un poste Windows avec une vraie session utilisateur dans le domaine source. J’ai donc créé VDI-WIN11, une VM Windows 11 Professionnel sur mon ESXi.
L’installation a rencontré un premier obstacle : le contrôle du TPM 2.0. Le programme d’installation ne détectait pas le TPM attendu. J’ai pu passer ce blocage et terminer l’installation. Avant de parler migration de profil, ce problème mérite une explication.
Le poste de test entre les deux domaines
Le premier contrôleur de domaine sous Windows Server 2025 constitue la cible durable du lab. Une deuxième forêt sert de source pour les essais.
Le rôle du poste Windows 11 est simple : ouvrir une session dans le domaine source, y créer des données et des paramètres reconnaissables, puis tester le passage vers un compte déjà existant dans le domaine cible. À ce stade, la migration du profil n’a pas encore été réalisée.
Pourquoi le contrôle TPM bloque dans une VM
Le TPM, pour Trusted Platform Module, fournit des fonctions de sécurité liées notamment aux clés cryptographiques. Windows 11 demande un TPM en version 2.0 dans sa configuration prise en charge, y compris pour une machine virtuelle. Configuration requise Microsoft.
Il faut distinguer deux niveaux : le matériel du PC qui héberge ESXi et le matériel présenté à Windows dans la VM. La présence éventuelle d’un TPM physique dans le portable ne signifie pas que Windows dispose automatiquement d’un TPM virtuel, ou vTPM.
Dans mon cas, le constat est celui de l’installateur : il ne disposait pas du TPM attendu. Cela ne permet pas, à lui seul, de conclure que le portable ne possède aucune puce TPM.
Dans une infrastructure vSphere gérée avec vCenter, l’ajout d’un vTPM passe par une configuration adaptée du fournisseur de clés. Broadcom documente notamment la mise en place d’un Native Key Provider, sa sauvegarde, puis l’ajout du périphérique TPM à la VM. Cette démarche fournit un vTPM ; elle est différente du contournement choisi ici. Procédure Broadcom pour vSphere.
Contourner le contrôle pendant l’installation
Pour ce poste de laboratoire, la méthode consiste à demander à l’installateur d’ignorer le contrôle TPM via une valeur du registre LabConfig.
Depuis l’écran du programme d’installation de Windows lancé sur l’ISO :
- Appuyer sur Maj + F10 pour ouvrir une invite de commandes.
- Créer la valeur suivante :
reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassTPMCheck /t REG_DWORD /d 1 /f
REG_DWORD définit le type de valeur ; 1 active ce contournement et /f évite une demande de confirmation si la valeur existe déjà.
Ces commandes sont à saisir pendant l’installation, et non dans une session Windows déjà installée pour tenter de corriger rétroactivement ses prérequis.
Dans ce lab, j’ai également saisi la commande suivante pour ignorer le contrôle Secure Boot :
reg add "HKLM\SYSTEM\Setup\LabConfig" /v BypassSecureBootCheck /t REG_DWORD /d 1 /f
Une fois les deux commandes saisies, fermer l’invite et reprendre l’assistant, en revenant à l’écran précédent si nécessaire. J’ai utilisé les deux commandes avant de poursuivre l’installation. Cela ne permet pas de conclure que les deux contrôles auraient bloqué séparément : TPM et Secure Boot sont deux mécanismes différents. Le guide d’installation d’un autre éditeur d’hyperviseur, acontis, documente ces deux valeurs ; il ne constitue pas une procédure de support Microsoft ou VMware. Guide acontis, section Windows 11 Installation.
Ce que le contournement ne fait pas
Ignorer un contrôle ne crée pas le périphérique manquant. Cette modification n’ajoute aucun vTPM et ne rend pas, à elle seule, la VM conforme aux prérequis de Windows 11. Elle n’active pas non plus BitLocker et ne valide pas sa configuration.
Microsoft précise qu’une installation sur du matériel ne respectant pas les exigences minimales n’est pas prise en charge et que les mises à jour, y compris de sécurité, ne sont pas garanties. Le fait d’ouvrir Windows Update après l’installation ne change pas cette limite. Position de Microsoft sur les installations hors prérequis.
Le choix est limité ici à une VM de test pour travailler sur Active Directory et les profils utilisateurs. Pour tester des fonctions dépendantes du TPM ou reproduire un déploiement Windows 11 pris en charge, je devrai disposer d’une configuration avec vTPM et des autres prérequis nécessaires.
Le résultat et la suite du lab
Après le contournement, l’installation a pu se poursuivre. La VM a redémarré et lancé une recherche de mises à jour. Cela confirme le passage du blocage initial, sans permettre d’annoncer que toutes les mises à jour sont installées.
Un deuxième problème est apparu au moment de joindre le domaine source : le poste ne trouvait pas le contrôleur de domaine. Il fallait corriger sa configuration DNS pour utiliser le DNS du domaine source. VDI-WIN11 a ensuite rejoint le domaine et une session utilisateur a été ouverte.
Le poste de départ est donc prêt. La prochaine étape sera de préparer quelques fichiers et réglages témoins, puis de tester la migration du profil vers le compte cible. Les données, les applications et les accès liés à l’ancienne identité devront être vérifiés après l’opération.