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

Résumé opérationnel

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.

Symptôme, contexte et périmètre de l’incident

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.

• Autopilot classique et Device Preparation
• user-driven Entra join et scénarios officiellement supportés
• réseau, identité, MDM, ESP, scripts et applications

Questions à résoudre et méthode de diagnostic

Pour Autopilot bloqué pendant l’OOBE, l’enquête suit le parcours Network → Identity → Enrollment → Provisioning. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur CAB MDMDiagnosticsTool, ModernDeployment-Diagnostics-Provider et DeviceManagement-Enterprise-Diagnostics-Provider/Admin. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « Profil non reçu, Enrôlement échoue et ESP reste sur Apps » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• localiser la phase bloquée
• collecter les preuves avant reset
• fournir une correction et un rollback reproductibles

Cartographie du flux à diagnostiquer

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.

État initial et prérequis de collecte

L’état initial de Autopilot bloqué pendant l’OOBE doit couvrir 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. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Network, Identity, Enrollment, Provisioning sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• 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

Collecte des preuves : journaux, registre et états

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

Investigation pas à pas

L’investigation suit l’ordre Network → Identity → Enrollment → Provisioning. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Autopilot bloqué pendant l’OOBE, les contrôles « Capturer le symptôme », « Tester le socle », « Collecter les diagnostics » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

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.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent CAB MDMDiagnosticsTool, ModernDeployment-Diagnostics-Provider, DeviceManagement-Enterprise-Diagnostics-Provider/Admin, rapport Autopilot ou Device Preparation. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Autopilot bloqué pendant l’OOBE, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

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

$ErrorActionPreference = 'Stop'
try {
  $cab = 'C:\Windows\Temp\Autopilot-Diagnostics.cab'
  mdmdiagnosticstool.exe -area Autopilot -cab $cab
  Get-Item -LiteralPath $cab | Select-Object FullName, Length, LastWriteTime
  Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 120 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[08:41:10.210] OOBE        Network=Connected TimeSync=OK
[08:42:05.882] Entra       Authentication=Success CorrelationId=<GUID>
[08:42:28.310] Enrollment  MDMCertificate=Created EnrollmentId=<GUID>
[08:43:02.771] ESP         Phase=DeviceSetup State=InProgress
[08:44:19.415] IME         AppId=<GUID> State=Failed ExitCode=1603
[08:44:20.003] ESP         BlockingApp=<GUID> State=Error

Arbre de décision : symptômes, causes et corrections

La matrice couvre notamment Profil non reçu, Enrôlement échoue, ESP reste sur Apps, IME absent. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles profil attendu reçu, Entra join et MDM sains et ESP termine dans le délai pilote sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

Validation de la correction et critères de clôture

La correction de Autopilot bloqué pendant l’OOBE est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• 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

Retour arrière, escalade et points de vigilance

Le retour arrière de Autopilot bloqué pendant l’OOBE restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à CAB MDMDiagnosticsTool, ModernDeployment-Diagnostics-Provider, DeviceManagement-Enterprise-Diagnostics-Provider/Admin, rapport Autopilot ou Device Preparation ainsi que les causes déjà écartées.