Windows Autopilot pre-provisioning : concevoir le parcours technicien et utilisateur

Position recommandée

Le technicien déclenche le parcours depuis l’OOBE, généralement avec cinq pressions sur la touche Windows. L’appareil s’authentifie par attestation TPM, s’enrôle, applique la phase device de l’ESP puis est resealed avant livraison.

Le succès du technicien ne prouve pas que le parcours utilisateur est terminé. Les applications et policies ciblées sur l’utilisateur restent à traiter lors de la première connexion, et un ESP désactivé peut afficher le reseal avant la fin réelle du traitement.

Je recommande Microsoft Entra join pour les nouveaux appareils, une liste courte d’applications bloquantes, des contrôles logistiques après reseal et un délai opérationnel avant le user flow. Hybrid join reste possible mais ajoute connectivité DC, connecteur ODJ et risques.

Le technicien déclenche le parcours depuis l’OOBE, généralement avec cinq pressions sur la touche Windows. L’appareil s’authentifie par attestation TPM, s’enrôle, applique la phase device de l’ESP puis est resealed avant livraison.

Besoin, cas d’usage et périmètre de la recommandation

Le scénario reprend un profil Autopilot user-driven avec l’option de pré-provisionnement. Il prend en charge Entra join et hybrid join, mais le choix cloud-native réduit les dépendances de domaine lors de la remise.

L’attestation TPM authentifie le matériel pendant le technician flow. Les machines virtuelles ne sont pas prises en charge pour qualifier ce scénario, même avec un TPM virtuel; le pilote doit utiliser le matériel réellement livré.

Les applications, certificats et stratégies device ciblés avant l’OOBE peuvent être traités pendant la phase technicien. Les éléments ciblés utilisateur attendent la connexion de l’utilisateur et doivent être comptés dans le temps restant.

Critères de décision et options possibles

Pour Autopilot pre-provisioning, je commence par trois résultats concrets: Valider registration, profil et groupe, Tester l’attestation TPM sur chaque famille matérielle et Mesurer la phase device ESP. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Registration → Technician → Reseal → User. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment Valider registration, profil et groupe, Tester l’attestation TPM sur chaque famille matérielle et Mesurer la phase device ESP. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont Valider registration, profil et groupe, Tester l’attestation TPM sur chaque famille matérielle et Mesurer la phase device ESP. Les responsabilités se répartissent ainsi: Registration: Hash, profil et affectations préparés. Technician: Attestation TPM et phase device ESP. Reseal: État préparé, éteint et tracé. User: Identité, phase user et validation finale. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Écran rouge avant enrôlement », « Reseal trop rapide », « User flow encore très long » et « Hybrid join bloqué » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: ne pas tester sur VM, protéger QR codes et diagnostics, ne pas surcharger l’ESP et documenter l’attente avant user flow. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

Le scénario reprend un profil Autopilot user-driven avec l’option de pré-provisionnement. Il prend en charge Entra join et hybrid join, mais le choix cloud-native réduit les dépendances de domaine lors de la remise.

L’attestation TPM authentifie le matériel pendant le technician flow. Les machines virtuelles ne sont pas prises en charge pour qualifier ce scénario, même avec un TPM virtuel; le pilote doit utiliser le matériel réellement livré.

Les applications, certificats et stratégies device ciblés avant l’OOBE peuvent être traités pendant la phase technicien. Les éléments ciblés utilisateur attendent la connexion de l’utilisateur et doivent être comptés dans le temps restant.

Prérequis, gouvernance et préparation

La préparation de Autopilot pre-provisioning couvre matériel physique avec TPM supporté, appareil Autopilot enregistré, profil pré-provisioning affecté, ESP et applications device maîtrisés, réseau atelier vers endpoints Microsoft. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec Valider registration, profil et groupe. Tester l’attestation TPM sur chaque famille matérielle. Mesurer la phase device ESP. Reseal et tracer l’appareil. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• matériel physique avec TPM supporté
• appareil Autopilot enregistré
• profil pré-provisioning affecté
• ESP et applications device maîtrisés
• réseau atelier vers endpoints Microsoft
• processus de reseal et inventaire
• support et procédure de reset

Fonctionnement détaillé de Autopilot pre-provisioning

Le scénario reprend un profil Autopilot user-driven avec l’option de pré-provisionnement. Il prend en charge Entra join et hybrid join, mais le choix cloud-native réduit les dépendances de domaine lors de la remise.

L’attestation TPM authentifie le matériel pendant le technician flow. Les machines virtuelles ne sont pas prises en charge pour qualifier ce scénario, même avec un TPM virtuel; le pilote doit utiliser le matériel réellement livré.

Les applications, certificats et stratégies device ciblés avant l’OOBE peuvent être traités pendant la phase technicien. Les éléments ciblés utilisateur attendent la connexion de l’utilisateur et doivent être comptés dans le temps restant.

• matériel physique avec TPM supporté
• appareil Autopilot enregistré
• profil pré-provisioning affecté
• ESP et applications device maîtrisés

Traitement, exploitation et cas limites de Autopilot pre-provisioning

L’ESP contrôle la visibilité et le blocage. La liste bloquante doit contenir les composants indispensables à l’accès et au support, pas l’intégralité du catalogue. Les dépendances Win32 et redémarrages sont testés dans l’ordre réel.

Après succès, le reseal remet l’appareil dans un état destiné à l’utilisateur. Le numéro de série, l’heure, le profil, le résultat, la version de l’image et le colis doivent être rapprochés afin d’éviter échange de machines ou nouvelle mise sous tension.

Microsoft recommande d’attendre avant d’exécuter le user flow après la phase technicien. Je l’intègre au SLA logistique et je vérifie la documentation courante, car le comportement d’identité et de réplication évolue.

• Attendre la fenêtre définie avant user flow
• Tester première connexion et applications user
• Contrôler conformité et support à J+1

Lire les états propres à Autopilot pre-provisioning

En hybrid join, le connecteur Intune pour Active Directory, l’ODJ blob, le domaine et le réseau deviennent des dépendances supplémentaires. Le technicien externe doit disposer du chemin réseau attendu si le scénario le requiert.

Le diagnostic s’appuie sur MDMDiagnostics, les événements Autopilot/DM-EDP, l’ESP, les journaux IME et le rapport Autopilot. Les QR codes et identifiants affichés sur l’écran d’erreur doivent être protégés.

Le pilote mesure le temps technicien, le taux de reseal, le temps user flow, les erreurs d’applications et la conformité à J+1. Un gain apparent pour l’utilisateur qui déplace une charge excessive vers l’atelier n’est pas automatiquement un succès.

• Écran rouge avant enrôlement — QR code, TPM et rapport
• Reseal trop rapide — Applications device et ESP
• User flow encore très long — ESP user et journaux IME
• Hybrid join bloqué — ODJConnector et événements

Pilote et suivi opérationnel de Autopilot pre-provisioning

Le pilote couvre le périmètre Windows Autopilot, Pre-provisioning, Technician flow, ESP et contrôle Valider registration, profil et groupe. Tester l’attestation TPM sur chaque famille matérielle. Mesurer la phase device ESP. Les résultats sont segmentés selon les populations réellement concernées par Autopilot pre-provisioning.

Les cas d’échec « Écran rouge avant enrôlement », « Reseal trop rapide », « User flow encore très long » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve ne pas tester sur VM, protéger QR codes et diagnostics, ne pas surcharger l’ESP, documenter l’attente avant user flow. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Autopilot pre-provisioning se déploie par les étapes « Mesurer l’état de départ », « Configurer la population pilote », « Observer les indicateurs », « Décider la généralisation ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier Valider registration, profil et groupe. Tester l’attestation TPM sur chaque famille matérielle. Mesurer la phase device ESP. Reseal et tracer l’appareil. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Registration, Technician, Reseal, User doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  $zip = Join-Path $env:PUBLIC 'Documents\Autopilot-PreProvisioning.zip'
  mdmdiagnosticstool.exe -area 'DeviceEnrollment;DeviceProvisioning;Autopilot' -zip $zip
  Get-Tpm | Select-Object TpmPresent,TpmReady,ManufacturerIdTxt,ManufacturerVersion
  Write-Output "Archive créée : $zip"
} catch { Write-Error "Collecte Autopilot impossible : $($_.Exception.Message)"; exit 1 }

Validation, indicateurs et critères GO / NO-GO

La décision repose sur Valider registration, profil et groupe, Tester l’attestation TPM sur chaque famille matérielle, Mesurer la phase device ESP et Reseal et tracer l’appareil. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• Valider registration, profil et groupe.
• Tester l’attestation TPM sur chaque famille matérielle.
• Mesurer la phase device ESP.
• Reseal et tracer l’appareil.
• Attendre la fenêtre définie avant user flow
• Tester première connexion et applications user
• Contrôler conformité et support à J+1

Exploitation, journaux et contrôle continu

La chronologie de Autopilot pre-provisioning relie Registration, Technician, Reseal, User. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Valider registration, profil et groupe. Tester l’attestation TPM sur chaque famille matérielle. Mesurer la phase device ESP. Reseal et tracer l’appareil. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Attestation TPM ou profil », « ESP désactivé ou blocage incomplet », « Trop de contenu user » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Valider registration, profil et groupe.
• Tester l’attestation TPM sur chaque famille matérielle.
• Mesurer la phase device ESP.
• Reseal et tracer l’appareil.
• Attendre la fenêtre définie avant user flow
• Tester première connexion et applications user
• Contrôler conformité et support à J+1

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Autopilot pre-provisioning apparaissent notamment sous la forme Écran rouge avant enrôlement, Reseal trop rapide, User flow encore très long, Hybrid join bloqué. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Autopilot pre-provisioning crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Autopilot pre-provisioning restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.