Autopilot bloqué pendant l’OOBE : reconstruire toute la chronologie

Résumé

Un blocage OOBE peut précéder Autopilot, survenir pendant l’authentification, l’Entra join, l’enrôlement MDM, l’ESP ou l’installation d’une application. Le texte affiché ne suffit pas à distinguer ces phases.

Je relève l’heure, le scénario, le profil attendu et l’identité du poste avant toute réinitialisation. Je collecte ensuite un CAB Autopilot/MDM et je corrèle événements Windows, rapport Intune et journaux IME.

La correction cible la première phase qui diverge. Réinitialiser le poste sans comprendre peut reproduire le même incident et supprimer la meilleure chronologie disponible.

Un blocage OOBE peut précéder Autopilot, survenir pendant l’authentification, l’Entra join, l’enrôlement MDM, l’ESP ou l’installation d’une application. Le texte affiché ne suffit pas à distinguer ces phases.

Contexte, objectif et périmètre

L’OOBE agrège plusieurs services et composants. DNS, proxy, heure, authentification Entra, découverte MDM, certificats, tâches de gestion, ESP et IME forment une chaîne dépendante.

L’ESP suit une liste d’éléments. Une application requise peut être ciblée sans être suivie dans la phase visible, ou arriver après le bureau. Je distingue donc attente ESP et traitement IME postérieur.

Je traite « Autopilot bloqué pendant l’OOBE » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

Ma méthode part du symptôme observable, formule plusieurs hypothèses concurrentes, puis cherche la preuve capable d’en éliminer une. Je ne commence pas par vider un cache, supprimer une clé ou réinstaller un agent : ces actions modifient précisément l’état qui permettrait de comprendre l’incident. La collecte initiale reste donc en lecture seule.

Une correction n’est proposée qu’après localisation de la phase en échec. Je distingue toujours le contournement temporaire, la correction causale et la correction structurelle. Le retour arrière est préparé avant la modification, puis le résultat est contrôlé sur un pilote représentatif avant toute généralisation.

• Objectif : localiser la phase bloquée
• Objectif : collecter les preuves avant reset
• Objectif : fournir une correction et un rollback reproductibles
• Périmètre : Autopilot classique et Device Preparation
• Périmètre : user-driven Entra join et scénarios officiellement supportés
• Périmètre : réseau, identité, MDM, ESP, scripts et applications

Architecture et fonctionnement général

Avant la sélection Autopilot, Windows doit établir le réseau et joindre les services nécessaires. Une page de connexion affichée ne prouve pas que tous les endpoints de provisioning sont accessibles.

Après authentification, l’objet Entra et l’enrôlement MDM doivent être cohérents. Le certificat et les tâches EnterpriseMgmt matérialisent le canal de gestion local.

L’ESP suit les stratégies et applications configurées. L’IME prend en charge Win32 et scripts ; son installation ou sa réception de politique peut devenir le chemin critique. La sortie de l’ESP ne signifie pas que toutes les affectations Intune sont terminées.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• heure et photo du message d’erreur
• numéro de série et scénario attendu
• accès au rapport Intune
• possibilité d’ouvrir une console de diagnostic selon le contexte
• clé USB ou chemin local protégé pour le CAB

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

Lire Device Preparation, Device ESP et User ESP

Device preparation confirme que le poste peut commencer la gestion. Device setup applique les éléments suivis en contexte appareil. Account setup concerne le contexte utilisateur lorsqu’il est utilisé. Les écrans et phases varient selon la solution Autopilot.

Une application Win32 ne doit pas être déclarée responsable sur la seule durée de l’écran. Je retrouve son AppId, son heure de policy et son état de détection dans l’IME.

Je mesure séparément téléchargement et installation. Delivery Optimization peut expliquer une attente réseau que le journal d’installation ne montre pas.

Analyser un CAB sans surinterpréter l’outil

Le CAB MDMDiagnosticsTool rassemble des données MDM et Autopilot. Un outil communautaire peut en reconstruire la chronologie et rendre l’analyse plus lisible, mais sa version, ses hypothèses et les données absentes doivent être notées.

Le script Get-AutopilotDiagnosticsCommunity ajoute la prise en charge de Device Preparation et sait lire certains ZIP de diagnostic Intune. Je vérifie sa version et son dépôt avant usage.

La conclusion reste fondée sur les événements originaux, le rapport Microsoft et les journaux locaux. La synthèse de l’outil accélère l’enquête ; elle ne remplace pas les preuves.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

MDMDiagnosticsTool.exe -area Autopilot -cab C:\Windows\Temp\Autopilot.cab

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• profil attendu reçu
• Entra join et MDM sains
• ESP termine dans le délai pilote
• applications essentielles détectées
• rapport service cohérent
• aucun reset nécessaire pour masquer l’erreur

Journaux, diagnostic et constitution des preuves

Je commence par ModernDeployment-Diagnostics-Provider et DeviceManagement-Enterprise-Diagnostics-Provider. Pour les applications Win32, j’ajoute IntuneManagementExtension.log et AppWorkload.log. Pour le joint hybride, les preuves ODJ et connecteur deviennent spécifiques.

Le rapport Intune indique la vue service, mais son horodatage doit être comparé à la tentative. Je n’associe pas un événement d’un reset précédent au blocage actuel.

• CAB MDMDiagnosticsTool
• ModernDeployment-Diagnostics-Provider
• DeviceManagement-Enterprise-Diagnostics-Provider/Admin
• rapport Autopilot ou Device Preparation
• IntuneManagementExtension.log et AppWorkload.log
• état Entra et tâches EnterpriseMgmt

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : restaurer profil et ESP précédents
• Rollback : retirer l’application fautive du groupe pilote
• Rollback : réinitialiser seulement après sauvegarde du CAB
• Vigilance : protéger les diagnostics
• Vigilance : ne pas rendre une app non essentielle bloquante
• Vigilance : ne pas utiliser un scénario HAADJ non supporté avec Device Preparation