Windows Autopilot Device Preparation face à Autopilot classique

L’essentiel

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.

Pourquoi cette technologie existe

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.

Device Preparation ou Autopilot classique s’appuie sur la chaîne Identité → OOBE → Policy → Intune. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont 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. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Mauvais parcours, Policy Device Preparation absente et Apps bloquées. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Identité ouvre la séquence: Hash et objet Autopilot classique, ou découverte au moment du Device Preparation. OOBE prend ensuite le relais: Authentifie l’utilisateur et sélectionne un seul parcours. Le traitement se poursuit avec Policy, où Profil+ESP classique ou politique Device Preparation. Enfin, Intune ferme la boucle: Livre les applications, scripts et configurations autorisés. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Mauvais parcours » conduit d’abord à vérifier Objet Autopilot et profil assigné, car la cause possible est Device toujours enregistré en classique. Pour « Policy Device Preparation absente », la preuve utile devient Configuration et audit Entra. Les cas « Apps bloquées » et « HAADJ tenté » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Device Preparation ou Autopilot classique expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions 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 doivent être réunies en même temps. La validation porte ensuite sur un seul parcours par device, versions et licences supportées, identité et groupe corrects et applications essentielles terminées. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

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, compatibilité et limites de support

Le fonctionnement décrit suppose 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. Ces conditions permettent de distinguer une limite de Device Preparation ou Autopilot classique d’un scénario simplement non éligible.

• 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

Cycle de fonctionnement, étape par étape

Le cycle de Device Preparation ou Autopilot classique traverse Identité → OOBE → Policy → Intune. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Device Preparation ou Autopilot classique, les étapes « Définir le scénario cible », « Créer deux pilotes séparés », « Mesurer le parcours », « Décider et documenter » séparent l’intention, son transport, son traitement et le résultat final.

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.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles profil ou politique effectivement sélectionné, état Entra join et enrôlement Intune, liste des applications/scripts suivis, chronologie OOBE/ESP. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Device Preparation ou Autopilot classique, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

Observabilité : où lire l’état réel

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

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque un seul parcours par device, versions et licences supportées, identité et groupe corrects et applications essentielles terminées. Ces contrôles relient la configuration du service au résultat réellement observé.

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

Limites, modes de panne et lecture des erreurs

Les écarts connus de Device Preparation ou Autopilot classique incluent Mauvais parcours, Policy Device Preparation absente, Apps bloquées, HAADJ tenté. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Device Preparation ou Autopilot classique commence sur le périmètre postes Windows 11 gérés avec Intune, user-driven, automatic, self-deploying et pre-provisioned selon support, applications, scripts, reporting et identité du device. Les limites et actions de réversibilité ci-dessous cadrent la progression.