Windows Autopilot Device Preparation face à Autopilot classique

Résumé

Autopilot classique identifie généralement le poste avant l’OOBE grâce à son enregistrement dans le service Autopilot et lui attribue un profil de déploiement. Device Preparation s’appuie sur l’identité de l’utilisateur, une politique dédiée et un groupe de sécurité auquel le service de provisioning ajoute le poste pendant le parcours.

Device Preparation simplifie l’onboarding Entra join, apporte un suivi proche du temps réel et contrôle un ensemble limité d’applications et de scripts essentiels. Autopilot classique conserve davantage de modes, de personnalisation et de scénarios, notamment le pré-provisioning, le self-deploying, les appareils existants et le joint hybride.

Les deux solutions peuvent exister dans le même tenant, mais un poste ne suit qu’un parcours. Un appareil encore enregistré dans Autopilot classique reçoit prioritairement son profil classique ; je retire donc cet enregistrement avant un test Device Preparation.

Autopilot classique identifie généralement le poste avant l’OOBE grâce à son enregistrement dans le service Autopilot et lui attribue un profil de déploiement. Device Preparation s’appuie sur l’identité de l’utilisateur, une politique dédiée et un groupe de sécurité auquel le service de provisioning ajoute le poste pendant le parcours.

Contexte, objectif et périmètre

Le terme Autopilot v2 est fréquemment utilisé sur le terrain pour Device Preparation, mais je conserve le nom produit officiel. Cette précision évite de laisser entendre qu’il s’agit d’une simple nouvelle version remplaçant toutes les fonctions historiques.

Le choix dépend du type de jointure, du nombre d’applications indispensables pendant l’OOBE, du besoin de pré-provisioning, des appareils concernés et du niveau de personnalisation attendu.

Je traite « Device Preparation ou Autopilot classique » 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.

Pour expliquer la technologie, je sépare le plan de contrôle, le transport, les composants locaux et les données de résultat. Cette lecture évite d’attribuer au portail une décision prise par Windows, ou à un agent local une limitation qui appartient en réalité au service cloud, à la licence ou au modèle d’affectation.

Les détails internes observés dans les journaux ou le registre servent à établir une hypothèse de diagnostic. Ils ne deviennent pas pour autant une interface publique stable. Toute automatisation durable doit s’appuyer sur une API ou une configuration officiellement supportée, puis être revalidée quand la version du service ou du client change.

• Objectif : expliquer les deux plans de provisioning
• Objectif : fournir une matrice de décision supportée
• Objectif : préparer une coexistence et une migration contrôlées
• Périmètre : postes Windows 11 gérés avec Intune
• Périmètre : user-driven, automatic, self-deploying et pre-provisioned selon support
• Périmètre : applications, scripts, reporting et identité du device

Architecture et fonctionnement général

Dans Autopilot classique, l’identité matérielle est associée au tenant avant le déploiement. Le service délivre le profil pendant l’OOBE, puis l’Entra join, l’enrôlement MDM et l’Enrollment Status Page orchestrent la configuration.

Dans Device Preparation, le poste n’a pas besoin d’être préenregistré dans Autopilot. Après authentification, le service de provisioning identifie la politique, ajoute le device au groupe prévu et suit les applications et scripts sélectionnés.

La comparaison officielle fixe des limites distinctes : Device Preparation est centré sur Entra join et un nombre borné d’éléments essentiels ; Autopilot classique offre davantage de modes et peut suivre plus d’applications. Ces nombres et versions doivent être revalidés avant publication ou conception finale.

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.

• licences Intune, Entra et Windows confirmées
• versions Windows supportées et média à jour
• rôles RBAC et groupe de sécurité Device Preparation correctement propriétaires
• réseau OOBE autorisant les endpoints Microsoft
• applications et scripts compatibles avec le contexte device

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.

Différences qui changent réellement le design

Device Preparation ne prend pas en charge le joint hybride comme architecture officielle. Une démonstration communautaire ne transforme pas ce scénario en option de production. Lorsque le joint hybride reste obligatoire, Autopilot classique ou une autre méthode supportée demeure nécessaire.

Le pré-provisioning, le self-deploying, Autopilot Reset et certains types d’appareils restent associés au modèle classique. Device Preparation apporte en revanche une politique plus simple, un regroupement au moment du provisioning et un rapport plus réactif.

Je limite les applications OOBE à celles qui rendent le poste utilisable et sécurisé. Les autres sont livrées après l’arrivée au bureau afin de réduire la durée et la surface d’échec.

Coexistence dans un même tenant

La coexistence permet de migrer par population sans bascule globale. Je sépare les groupes, les politiques et les appareils de test, puis je documente le propriétaire du parcours.

Un appareil enregistré dans Autopilot classique ne constitue pas un bon test Device Preparation : le profil classique est prioritaire. Sa suppression du service doit être contrôlée et accompagnée du nettoyage des objets conformément au processus de cycle de vie.

Le rollback consiste à restaurer le modèle d’enregistrement et les affectations précédents, pas seulement à réinitialiser Windows. Le prochain OOBE doit à nouveau sélectionner le parcours attendu.

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.

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é.

• un seul parcours par device
• versions et licences supportées
• identité et groupe corrects
• applications essentielles terminées
• rapport cohérent
• rollback testé

Journaux, diagnostic et constitution des preuves

Je collecte le rapport correspondant à la solution utilisée, le CAB MDM Autopilot, les événements ModernDeployment-Diagnostics-Provider et DeviceManagement-Enterprise-Diagnostics-Provider, puis les journaux IME pour les applications Win32.

Les libellés communautaires APv1/APv2 sont utiles pour rechercher des retours terrain, mais le dossier de preuve conserve les noms officiels et la version de l’outil utilisé.

• profil ou politique effectivement sélectionné
• état Entra join et enrôlement Intune
• liste des applications/scripts suivis
• chronologie OOBE/ESP
• rapport de déploiement
• logs IME pour les charges Win32

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 l’enregistrement Autopilot classique si nécessaire
• Rollback : réaffecter le profil et l’ESP précédents
• Rollback : réinitialiser uniquement après sauvegarde des preuves
• Vigilance : ne pas présenter Device Preparation comme remplacement fonctionnel total
• Vigilance : ne pas utiliser HAADJ hors support
• Vigilance : revalider limites et versions Microsoft