PatchFactoryVeille
Menu
← Retour à la veille
Autopilot · Intune6 min de lecture

Windows Autopilot : tester les améliorations ESP et Device Preparation du 14 septembre

Microsoft a documenté le 14 septembre 2026 des améliorations de performance et de fiabilité pour Windows Autopilot et Windows Autopilot device preparation pendant l'OOBE. Les équipes qui mesurent les échecs ESP, les délais d'installation applicative ou les écarts BitLocker doivent les valider sur leurs scénarios de provisioning avant d'en tirer des conclusions de production.

Impact
Déploiements Autopilot avec ESP et scénarios Device Preparation Windows 11
Action
rejouer des scénarios OOBE représentatifs et comparer provisioning, IME, réseau et BitLocker
Statut
À tester

Classement : À tester

Résumé : Microsoft a documenté le 14 septembre 2026 des améliorations de performance et de fiabilité pour Windows Autopilot et Windows Autopilot device preparation pendant l'OOBE. Les équipes qui mesurent les échecs ESP, les délais d'installation applicative ou les écarts BitLocker doivent les valider sur leurs scénarios de provisioning avant d'en tirer des conclusions de production.

Impact : déploiements Windows Autopilot avec Enrollment Status Page, et scénarios Windows Autopilot device preparation sur Windows 11 gérés par Intune.

Action : rejouer un petit lot de scénarios OOBE représentatifs et comparer le temps de provisioning, les échecs applicatifs, la reprise après coupure réseau et la méthode BitLocker obtenue.

Statut : À tester.

Ce qui change

Microsoft a ajouté le 14 septembre 2026 une note aux nouveautés Windows Autopilot : l'Enrollment Status Page bénéficie de trois améliorations pendant l'OOBE. Le nombre de tentatives de réinstallation d'applications pendant l'ESP augmente, l'Intune Management Extension lance une synchronisation dès la fin de l'ESP, et le check-in de l'appareil devient plus résilient après une perte de connectivité réseau pendant l'OOBE.

La page des nouveautés Windows Autopilot device preparation, datée du même jour, reprend les deux derniers points et ajoute un changement propre à Device Preparation : la stratégie BitLocker 128 bits par défaut n'est plus appliquée pendant l'OOBE, afin de laisser la priorité aux politiques BitLocker configurées par l'administrateur. C'est une différence importante pour les organisations qui imposent une méthode de chiffrement précise et qui contrôlent l'écart entre la politique attendue et l'état réellement appliqué après provisioning.

Microsoft ne présente pas ces changements comme de nouveaux boutons à activer dans Intune. La recommandation utile n'est donc pas de modifier massivement les profils, mais de vérifier si les flux existants se comportent mieux et si les indicateurs de support évoluent.

Qui est concerné

Le premier périmètre est celui des déploiements Windows Autopilot qui utilisent l'Enrollment Status Page pour bloquer ou suivre l'installation des applications et politiques. La documentation Intune rappelle que l'ESP s'applique pendant l'OOBE pour Microsoft Entra join et les scénarios Windows Autopilot, et qu'elle peut bloquer l'utilisation du poste jusqu'à l'installation des applications et profils requis.

Le second périmètre est plus restreint : Windows Autopilot device preparation. Microsoft le décrit comme un flux Windows 11 avec Entra join, groupe d'appareils à l'enrôlement, installation d'applications et de scripts pendant l'OOBE, et supervision quasi temps réel dans le rapport dédié. Il ne faut pas étendre le changement BitLocker à tous les scénarios ESP classiques sans confirmation : la note BitLocker est publiée dans la page Device Preparation, pas dans la page Autopilot générale.

Actions recommandées

Recommandation PatchFactory : classer ce signal À tester sur les tenants qui utilisent déjà Autopilot ou Device Preparation de façon régulière. Le test doit chercher à mesurer un résultat, pas seulement constater que la documentation a changé.

Sur un lot réduit de modèles représentatifs, relancer des enrollments OOBE avec les profils existants. Pour Autopilot avec ESP, comparer les échecs d'applications bloquantes, le temps total jusqu'au bureau, puis l'arrivée des applications ou politiques dépendantes de l'IME après la sortie de l'ESP. Si des incidents historiques étaient liés à une latence de sync IME, le critère de poursuite est une baisse observable des postes qui arrivent au bureau sans les composants attendus.

Ajouter un scénario réseau contrôlé si l'environnement a déjà vu des pertes de Wi-Fi, de proxy ou de VPN pendant OOBE. Le résultat attendu n'est pas une tolérance à toutes les coupures, mais une meilleure reprise du check-in lorsque la connectivité revient. En cas d'écart, isoler le problème par chemin réseau de staging, type d'authentification Wi-Fi/proxy et modèle matériel avant de conclure à une régression Autopilot.

Pour Windows Autopilot device preparation, inclure au moins un appareil avec politique BitLocker administrateur ciblée. Après provisioning et synchronisation, vérifier que la méthode de chiffrement obtenue correspond à la politique de l'organisation, et non à une valeur par défaut inattendue. La documentation de reporting Device Preparation permet aussi de contrôler le statut des applications et scripts, le temps de déploiement, la policy reçue et la phase en échec si le scénario ne va pas au bout.

Ce changement ne remplace pas l'article publié sur l'association d'appareils Autopilot device preparation. L'association traite l'identité et le cycle de vie du poste avant enrôlement ; le signal du 14 septembre concerne le comportement de provisioning pendant l'OOBE et les mesures à reprendre dans les pilotes.

Sources