Objectif
Activer Secure Boot sur un parc Windows de manière progressive, en identifiant les appareils déjà compatibles UEFI/GPT, en sécurisant la récupération BitLocker, en préparant un pilote par modèle de matériel et en séparant clairement la conversion éventuelle MBR→GPT de l’activation du paramètre firmware.
Prérequis
- Inventaire du parc : modèle, version BIOS/UEFI, mode de démarrage, partitionnement du disque système et état Secure Boot.
- Accès administrateur Windows et accès au firmware local ou via l’outil constructeur de gestion BIOS.
- Clé de récupération BitLocker sauvegardée et testée pour les machines chiffrées.
- Sauvegarde récente des postes critiques et support de récupération Windows disponible.
- Groupe pilote représentatif de chaque modèle matériel avant généralisation.
Procédure pas à pas
Inventorier le mode de démarrage et l’état Secure Boot
Commencez par mesurer l’état réel du parc au lieu de supposer que tous les postes Windows 11 sont identiques. Depuis PowerShell élevé, vérifiez Secure Boot et récupérez le style de partition du disque système. Sur une machine BIOS hérité, Confirm-SecureBootUEFI renvoie une erreur indiquant que la plateforme n’est pas prise en charge ; ce résultat doit être classé séparément d’un simple Secure Boot désactivé.
Confirm-SecureBootUEFIGet-Disk | Select Number,FriendlyName,PartitionStyle,IsBoot,IsSystemGet-CimInstance Win32_ComputerSystem | Select Manufacturer,Model- Les postes sont classés en : déjà conformes, UEFI/GPT avec Secure Boot désactivé, ou Legacy/MBR à préparer.
Contrôler BitLocker et la capacité de récupération
Avant toute modification du firmware, vérifiez si le volume système est chiffré et si la procédure de récupération est maîtrisée. Ne copiez pas la clé BitLocker dans le ticket ou dans un script. Vérifiez simplement l’état de protection et confirmez que la clé est sauvegardée dans AD DS
manage-bde -status C:Get-BitLockerVolume -MountPoint C: | Select MountPoint,VolumeStatus,ProtectionStatus,EncryptionPercentage- Chaque machine pilote possède une méthode de récupération BitLocker vérifiée avant le redémarrage firmware.
Valider la compatibilité UEFI et le firmware
Consultez la documentation du constructeur pour le modèle exact et mettez à jour le BIOS/UEFI si la version déployée contient des correctifs nécessaires. Relevez le mode UEFI, la présence éventuelle de CSM/Legacy Boot et l’état des clés Secure Boot. N’utilisez pas une procédure générique pour restaurer les clés ou modifier le boot mode : les menus et mécanismes d’automatisation diffèrent selon Dell, HP, Lenovo et autres constructeurs.
msinfo32- Le modèle pilote démarre déjà en UEFI ou dispose d’un chemin de migration constructeur documenté.
Valider MBR2GPT sur les postes Legacy/MBR
Pour les postes dont le disque système est encore en MBR, commencez uniquement par la validation MBR2GPT. Cette commande ne convertit rien et permet de vérifier la disposition des partitions. Si la validation échoue, analysez le journal avant de modifier le partitionnement. Ne forcez pas la conversion si le disque contient une disposition non supportée, un bootloader tiers ou des partitions particulières non documentées.
mbr2gpt.exe /validate /disk:0 /allowFullOS- La validation réussit sur les postes candidats à la conversion ; les échecs sont isolés et traités individuellement.
Convertir MBR vers GPT lorsque c’est nécessaire
Sur un poste pilote sauvegardé et dont la validation a réussi, suspendez BitLocker si votre procédure de changement firmware l’exige, puis lancez MBR2GPT. Après une conversion réussie, le disque ne doit plus être démarré en mode BIOS Legacy : le firmware doit être basculé en UEFI avant le prochain démarrage normal. Conservez la console locale ou un support de récupération pendant toute cette séquence.
Suspend-BitLocker -MountPoint C: -RebootCount 1mbr2gpt.exe /convert /disk:0 /allowFullOS- Le disque système est GPT et le poste est prêt à démarrer en mode UEFI.
Basculer le firmware en UEFI et activer Secure Boot
Accédez au firmware avec la méthode supportée par le constructeur. Désactivez Legacy/CSM si nécessaire, sélectionnez UEFI, puis activez Secure Boot. Si le firmware indique que les clés de plateforme ne sont pas provisionnées, utilisez uniquement l’option constructeur documentée pour charger les clés par défaut. Ne modifiez pas simultanément d’autres paramètres de sécurité ou de stockage afin de garder un rollback lisible.
- Le poste démarre Windows en mode UEFI avec Secure Boot activé.
Vérifier Windows immédiatement après redémarrage
Après le premier démarrage, contrôlez l’état Secure Boot, BitLocker, les événements de démarrage et les fonctions métier de base. Une valeur True de Confirm-SecureBootUEFI constitue un contrôle direct côté Windows. Vérifiez aussi que BitLocker a repris sa protection si vous l’aviez suspendu et que le poste rejoint normalement le domaine, le VPN, le Wi-Fi et les outils de gestion.
Confirm-SecureBootUEFIGet-BitLockerVolume -MountPoint C: | Select ProtectionStatus,VolumeStatusGet-Disk | Where-Object IsSystem | Select PartitionStyle- Secure Boot renvoie True, le disque est GPT et BitLocker est protégé.
Déployer par vagues homogènes
Construisez des vagues par modèle et version de firmware plutôt qu’une vague aléatoire. Automatisez seulement les réglages BIOS dont la syntaxe a été validée avec l’outil du constructeur. Surveillez les demandes de clé BitLocker, les échecs de démarrage et les appareils qui restent en Legacy. Arrêtez la vague si le taux d’incident dépasse le seuil fixé dans le plan de changement.
- Chaque modèle passe par un pilote puis une vague contrôlée sans augmentation anormale des incidents de boot.
Documenter les exceptions et la conformité
À la fin, exportez la liste des appareils où Secure Boot reste impossible : firmware non compatible, matériel ancien, bootloader particulier ou conversion MBR2GPT non éligible. Les exceptions doivent avoir une justification et une action prévue. Intégrez le contrôle Secure Boot à l’inventaire ou à la conformité MDM afin que les futures réinstallations ne réintroduisent pas un démarrage Legacy.
- Le parc dispose d’un état de conformité mesurable et les exceptions ont un propriétaire et une date de revue.
Validation
La procédure est validée lorsque :
- Confirm-SecureBootUEFI retourne True sur les appareils ciblés.
- Le disque système est en GPT et le firmware démarre en UEFI.
- BitLocker est de nouveau protégé et la récupération a été testée sur le pilote.
- Les applications, réseau et outils de gestion fonctionnent après redémarrage.
Retour arrière
- Si le poste ne démarre plus après la bascule UEFI, revenir au paramètre de boot précédent via la console firmware uniquement si le disque n’a pas été converti de manière incompatible.
- Après conversion MBR2GPT, ne tentez pas de revenir en Legacy comme rollback improvisé ; utilisez la sauvegarde ou la procédure de récupération prévue si le boot UEFI ne peut pas être corrigé.
- Si Secure Boot seul pose problème, le désactiver temporairement peut restaurer le démarrage pendant l’analyse, tout en conservant le mode UEFI.
- Réactiver BitLocker et vérifier la protection après tout retour arrière.
Dépannage / erreurs fréquentes
- Confirm-SecureBootUEFI indique plateforme non prise en charge : vérifier que la machine démarre réellement en UEFI et non en BIOS Legacy.
- MBR2GPT /validate échoue : lire les logs MBR2GPT et corriger la disposition plutôt que lancer /convert.
- Écran BitLocker au redémarrage : utiliser la récupération officielle, puis vérifier la mesure Secure Boot/TPM avant de poursuivre la vague.
- Windows ne démarre plus après conversion : vérifier que le firmware est bien passé en UEFI et que l’entrée Windows Boot Manager est sélectionnée.
- Secure Boot est activé dans le BIOS mais False sous Windows : vérifier les clés de plateforme et l’état Setup Mode selon la documentation constructeur.
Références officielles
À consulter : Secure Boot.