Windows 10 n'était pas le dernier des Windows. Ce n'était pas non plus le plus pénible. Si Microsoft a amélioré de nombreuses choses dans Windows 11, l'éditeur semble également se donner du mal pour lui donner une mauvaise réputation à travers son attitude sur les restrictions matérielles.
En juin dernier, Microsoft dévoilait une « nouvelle » version de son système d'exploitation phare : Windows 11. L'éditeur introduisait alors des règles plus strictes concernant le matériel, notamment en matière de sécurité.
Windows 11 et compatibilité : le foutoir de Microsoft
Ainsi, activer TPM 2.0 (physique ou logiciel) devenait obligatoire, tout comme la compatibilité Secure Boot (qui n'a pas besoin d'être actif). Depuis, Microsoft s'est empêtrée dans cette situation, n'étant même pas capable de fournir un outil de test correct dans un premier temps (c'est le cas désormais), mais aussi de tenir un discours clair.
Bien que TPM 2.0 soit obligatoire sur les machines vendues dans le commerce depuis 2016, la société a pris tout l'écosystème de court avec cette histoire. Elle a également changé les règles en cours de route et ne semble pas en mesure de rassurer quant au bien-fondé de ses motivations. Dernier exemple en date, les machines virtuelles (VM).
Dans un document publié en juin dernier, il était clairement indiqué que celles-ci étaient particulières et n'auraient pas à subir les mêmes restrictions qu'un PC classique :
En juin, tout va bien
Puis il y a quelques jours, changement de ton : finalement, une VM doit aussi respecter les restrictions depuis la build 22000.194. Pourquoi cette décision subite ? Cela n'a pas été précisé. Microsoft décide, l'écosystème fait avec. Un choix d'autant plus difficile à comprendre que fin août, l'éditeur disait ne plus vouloir imposer de règles strictes à l'installation, se réservant tout de même le droit de bloquer les mises à jour sur les machines non compatibles.
Quelles restrictions en pratique ?
Bien que Microsoft ait indiqué qu'il n'y a pas de critères « durs » et d'autres plus « légers », en pratique, on distingue bien deux cas différents : ceux qui mènent à une erreur bloquante lors de l'installation et les autres. Pour les détecter, nous avons monté une machine virtuelle en faisant varier CPU, GPU, mémoire, stockage, etc.
Nous avons ainsi détecté 4 critères pouvant réellement poser problème :
- CPU à moins de deux cœurs
- Mémoire de moins de 4 Go
- Machine sans TPM 2.0 actif
- Machine sans gestion du Secure Boot (actif ou non)
Si la capacité de stockage n'est pas de 64 Go, que la partie graphique n'a pas de pilote WDDM 2.x ou que le processeur n'est pas dans la liste de compatibilité, ce n'est pas un problème. Cela pourra par contre en être un dans le cadre d'une procédure de mise à jour depuis Windows 10, nous y reviendrons dans un prochain article. Ce sont aussi des critères à prendre en compte par les constructeurs pour la certification de leurs machines.
Selon nos constatations, les blocages ont été introduits pour les machines virtuelles à partir de l'image ISO de la build 22000.194 et sur Windows 11 « Next » à partir de la build 22458 (la 22454 ne nous a pas posé de problèmes).
Installer Windows 11 sur un périphérique de stockage de 32 Go : une alerte est affichée, mais rien de bloquant
Certains hyperviseurs pris de court
Bonne nouvelle pour les adeptes de Microsoft Hyper-V : il est prêt avec ses machines virtuelles de seconde génération. Ces dernières proposent la gestion de l'UEFI et l'on peut activer un TPM virtuel (vTPM) dans les paramètres. C'est aussi le cas d'autres hyperviseurs, comme la version professionnelle de VMWare Workstation.
Mais sa version gratuite Player ne gère pas Secure Boot par exemple. Lorsque nous avons installé sa version 16 gratuite, elle ne proposait pas d'ajouter de TPM à une machine virtuelle, ce qui menait donc à une erreur lors de l'installation des dernières builds de Windows 11. Sur d'autres hyperviseurs, de telles options n'existent pas encore.
Hyper-V est déjà paré pour Windows 11, VMWare Player 16... c'est plus compliqué
C'est le cas de VirtualBox dont la dernière version date de fin juillet. Si un travail autour de TPM a commencé fin août, il n'est pas finalisé. Pour d'autres comme QEMU, ce n'est pas forcément simples d'accès et des systèmes qui l'exploitent n'ont pas forcément les options adéquates, comme Proxmox VE 7.0.
Et ce n'est pas l'annonce faite le 16 septembre qui a laissé le temps suffisant à l'équipe pour s'assurer une compatibilité avec Windows 11. Elle dit néanmoins y travailler activement et espère aboutir rapidement.
Contournez via la base de registre
Heureusement il reste pour le moment possible de contourner les restrictions sur TPM 2.0 et Secure Boot. Dans le cas de Proxmox VE 7.0, un utilisateur a publié un script officieux. À ne pas utiliser en production, donc.
Sinon, vous pouvez suivre la procédure de modification du registre que nous avions évoqué dans un précédent article. Lorsque l'installation est lancée, tapez sur les touches MAJ+F10 puis lancez l'éditeur de registre (regedit.exe). Il suffit alors d'enchaîner les actions suivantes :
- HKEY_LOCAL_MACHINE\SYSTEM\Setup > Créez la clé (dossier) LabConfig
- Créez le DWORD (32-bits) BypassTPMCheck avec la valeur 1
- Créez le DWORD (32-bits) BypassSecureBootCheck avec la valeur 1
Une fois que c'est fait, Windows 11 s'installera de manière classique. Attention, ce n'est qu'une solution de court terme, qui peut disparaître dans une prochaine build ou qui peut limiter l'accès à des mises à jour à l'avenir, comme cela a été annoncé par Microsoft. Mais si vous devez pouvoir tester une build récente dans votre hyperviseur, cela peut vous sauver la mise... en attendant une mise à jour (ou que Microsoft revienne à la raison).
L'erreur affichée dans une machine virtualisée via Proxmox VE 7.0 avant modification du registre (à gauche) puis après (à droite)
