Windows Autopilot Device Preparation (v2)

0

Contexte : Pourquoi une v2 d'Autopilot ?

😓

Problèmes d'Autopilot v1

❌ Enregistrement hardware hash complexe
❌ Groupes dynamiques lents (queries Azure AD)
❌ ESP peu lisible pour l'utilisateur
❌ Reporting limité / pas temps réel
❌ Erreurs difficiles à diagnostiquer
❌ LOB + Win32 dans le même déploiement = risqué

🚀

APDP : Objectifs v2

✓ Simple policy unique, pas de hash
✓ Rapide groupes statiques, déploiement immédiat
✓ Observable statut quasi temps réel
✓ Fiable déploiement sérialisé, moins de conflits
✓ Lisible barre de progression en % pour l'utilisateur

📍

Scénario Argos Consulting

Après avoir déployé 20 PCs en v1, Argos reçoit encore des nouveaux postes chaque mois. L'équipe IT veut une méthode encore plus simple : sans enregistrement hardware hash préalable : et un monitoring clair pour ne plus "déployer à l'aveugle". Objectif : migrer les futurs déploiements vers APDP.

⚠️ APDP et Autopilot v1 coexistent. Si un appareil est enregistré dans Autopilot v1 (hardware hash présent), le profil Autopilot v1 prend la priorité sur la policy APDP. Pour utiliser APDP, l'appareil ne doit PAS être un Autopilot device enregistré.

1

Comparatif : Autopilot v1 vs Device Preparation (v2)

APDP est une re-architecture d'Autopilot, pas un simple remplacement. Les deux solutions coexistent. Voici ce qui change fondamentalement.

🔷 Autopilot v1 (classique)

🔑Enregistrement : hardware hash (S/N + modèle + timestamp) capturé et uploadé dans le service

📋Profil assigné à un groupe d'appareils (dynamique ou statique)

👥Groupes dynamiques Entra ID pour l'assignation des apps

📺Enrollment Status Page (ESP) : 3 phases : Device prep / Device setup / Account setup

📊Rapport de déploiement (30 jours) : statut global uniquement

⚙️Plusieurs objets à configurer : profil Autopilot + ESP + groupes + apps

🖥️Supporte : Windows 10 et 11

🔗Join : Entra join + Hybrid join

📦Modes : User-driven, Self-deploying, Pre-provisioning

🐢Apps déployées via groupe dynamique : délai de traitement des règles

🟢 Autopilot Device Preparation v2 (APDP)

🆕Pas de hardware hash : policy assignée à un groupe d'utilisateurs NOUVEAU

🆕Device Preparation Policy (DPP) unique contient tout (OOBE + apps + scripts + groupe) NOUVEAU

🆕Enrollment Time Grouping : groupe statique assigné à l'enrollment, zéro délai NOUVEAU

🆕Pas d'ESP : écran "Setting up for work or school" avec % de progression NOUVEAU

🆕Reporting quasi temps réel : statut par app / script / phase NOUVEAU

🆕Configuration centralisée dans 1 seule policy Intune NOUVEAU

⚠️Windows 11 uniquement (22H2+KB5035942 minimum) LIMITÉ

⚠️Entra join UNIQUEMENT : Hybrid join non supporté LIMITÉ

⚠️User-driven GA · Windows 365 auto (preview) · Pre-prov / Self-deploying : planned LIMITÉ

⚡Apps déployées via groupe statique : traitement immédiat, plus rapide et fiable

💡 La clé de la rapidité APDP : le groupe d'appareils est un security group statique. Contrairement aux groupes dynamiques Entra ID qui doivent évaluer des règles (queries) avant de traiter les apps, le groupe statique est immédiatement opérationnel lors de l'enrollment. Apps et scripts démarrent en quelques secondes.

🔄 Mon appareil est-il éligible à la migration v1 → APDP ?

Réponds aux questions pour connaître le chemin de migration recommandé pour ton contexte Argos Consulting.

L'appareil est-il actuellement enrollé en Windows Autopilot v1 (profil de déploiement existant) ?

L'appareil est-il en Hybrid Entra Join (AD on-premise + Entra ID) ?

🚫 Migration APDP impossible pour cet appareil

APDP (Autopilot Device Preparation) ne supporte pas le Hybrid Entra Join. C'est une limitation connue de la v2 au moment de la GA.

Options :
→ Conserver Autopilot v1 pour les appareils Hybrid Join existants
→ Migrer vers Entra Join pur (Cloud-only) avant d'adopter APDP
→ Suivre les release notes Microsoft : le support Hybrid est sur la roadmap APDP

L'utilisateur assigné à l'appareil fait-il partie d'un groupe Entra ID statique (requis pour APDP) ?

✅ Parfait pour APDP directement

Cet appareil neuf peut être provisionné nativement avec APDP, sans passer par v1.

Étapes :
→ Créer une Device Preparation Policy dans Intune
→ Assigner un groupe statique d'utilisateurs
→ L'appareil se configure automatiquement à l'OOBE sans enregistrement de hash

✅ Migration v1 → APDP possible

Cet appareil est éligible à la migration.

Procédure recommandée :
→ 1. Supprimer le profil Autopilot v1 dans Intune → Devices → Enrollment → Windows Autopilot
→ 2. Créer une Device Preparation Policy et l'assigner au groupe statique de l'utilisateur
→ 3. Effectuer un reset Windows (Settings → Recovery → Reset this PC) pour déclencher l'OOBE APDP
→ 4. Vérifier dans Intune : Devices → Monitor → Device Preparation Status

⚠️ Le reset efface les données locales — prévoir une sauvegarde OneDrive au préalable.

⚠️ Action préalable requise : créer un groupe statique

APDP requiert un groupe Entra ID statique (non dynamique) pour l'Enrollment Time Grouping. Les groupes dynamiques ne sont pas supportés.

Solution :
→ Créer un groupe statique dans Entra ID (ex : GRP-APDP-Argos-Users)
→ Ajouter les utilisateurs manuellement ou via sync RH
→ Retourner à l'étape précédente et choisir "groupe statique"

Le groupe dynamique existant peut rester pour d'autres usages (Compliance, CA) — seule la Device Preparation Policy nécessite un groupe statique.

2

Enrollment Time Grouping : Le cœur d'APDP

Clique sur chaque étape pour comprendre le fonctionnement interne de l'Enrollment Time Grouping.

1

Admin configure la Device Preparation Policy

DPP créée dans Intune : contient le groupe d'appareils cible, les apps et les scripts

La DPP est assignée à un groupe d'utilisateurs (ex : "Argos-Consultants"). Elle spécifie quel groupe d'appareils statique (ex : "Argos-APDP-Devices") recevra les apps et scripts lors de l'enrollment. Les apps et scripts sont présélectionnés dans la policy : max 25 apps + 10 scripts PowerShell. Toutes les apps doivent être configurées en contexte System et assignées au groupe d'appareils cible.

↓

2

Utilisateur allume le PC et s'authentifie

Pendant l'OOBE, l'utilisateur saisit son compte M365 (membre du groupe d'utilisateurs de la DPP)

Lorsque l'utilisateur s'authentifie pendant l'OOBE, Intune vérifie si une Device Preparation Policy est assignée à cet utilisateur. Si oui, le déploiement APDP démarre. L'écran "Setting up for work or school" remplace l'ESP classique. Aucun hardware hash n'est vérifié c'est l'utilisateur qui détermine si l'appareil suit APDP.

↓

3

L'appareil est automatiquement ajouté au groupe d'appareils

Enrollment Time Grouping : ajout immédiat au security group statique

Dès l'enrollment, Intune ajoute automatiquement l'appareil au security group statique défini dans la DPP (ex : "Argos-APDP-Devices"). C'est ici que réside l'innovation : pas de règle dynamique à évaluer, pas de délai. L'appartenance au groupe est effective immédiatement. Permission RBAC requise : "Enrollment programs → Enrollment time device membership assignment".

↓

4

Apps et scripts déployés pendant l'OOBE

Uniquement les apps sélectionnées dans la DPP : les autres apps du groupe s'installent après

Seules les apps et scripts explicitement sélectionnés dans la DPP sont déployés pendant l'OOBE (bloquant). Les autres apps assignées au groupe d'appareils mais non sélectionnées dans la DPP seront déployées après que l'utilisateur accède au bureau : elles ne bloquent pas le démarrage. Les politiques Intune assignées au groupe sont synchronisées pendant le déploiement, mais leur application n'est pas obligatoirement tracée.

↓

5

Page de complétion + accès au bureau

L'utilisateur est informé que la configuration est terminée et accède au bureau

Une page de complétion informe l'utilisateur que le setup OOBE est terminé. Contrairement à l'ESP v1, cette page est claire et rassurante. Les installations non-critiques continuent en arrière-plan après accès au bureau. Le monitoring APDP enregistre le statut complet dans le rapport de déploiement accessible quasi en temps réel depuis le portail Intune.

3

Créer une Device Preparation Policy : Simulateur

Devices → Enrollment → Windows → Device preparation policies → Create

Name

Description

Device security group (Enrollment Time Grouping)

💡 Le Device security group doit être un security group statique (pas dynamique). C'est lui qui est utilisé pour l'Enrollment Time Grouping. Toutes les apps et scripts sélectionnés dans la DPP doivent être assignés à ce groupe.

Étape 1 / 5

OOBE settings

Deployment modeUser-driven

Join typeMicrosoft Entra join (seul type supporté)

User account typeStandard User ✓

Deployment timeout60 minutes

Allow users to collect diagnosticsAllow ✓

Custom error message"Contactez support@argos.fr"

⚠️ APDP n'utilise PAS l'Enrollment Status Page (ESP). Si l'ESP apparaît pendant l'OOBE, c'est qu'un profil Autopilot v1 est présent sur l'appareil (il a la priorité). Vérifier que l'appareil n'est pas enregistré en Autopilot classique.

Étape 2 / 5

Sélectionner les apps à déployer pendant l'OOBE

Ces apps seront installées AVANT que l'utilisateur accède au bureau. Max 25 apps + 10 scripts PS.

🔵 Microsoft 365 Apps (Win32 via Intune) 🔒 Microsoft Defender for Endpoint onboarding (Win32) 📋 Company Portal (Microsoft Store : WinGet) 🖨️ Pilote imprimante Argos (LOB .msi) 💬 Microsoft Teams (Win32) 📁 OneDrive client (Win32) 🔑 GlobalProtect VPN (Win32)

4 / 25 apps sélectionnées

💡 Règle critique : toutes les apps sélectionnées ici doivent être assignées en Required au groupe d'appareils Argos-APDP-Devices avec contexte d'installation System. Les apps en contexte User ne fonctionneront pas pendant l'OOBE.

Étape 3 / 5

Assignments

Assignée à (groupe d'utilisateurs)

👥 Argos-Consultants

Groupe Entra ID contenant tous les utilisateurs consultants. Quand un membre de ce groupe s'authentifie sur un nouveau PC, la DPP démarre automatiquement.

Priorité de policy

Priorité 1 (plus haute)

Si plusieurs DPPs sont assignées au même utilisateur, la priorité est définie par l'ordre dans la liste : glisser-déposer dans Intune. La plus haute (plus petit numéro) s'applique.

🎯 Contrairement à Autopilot v1, la DPP est assignée à des utilisateurs (pas des appareils). N'importe quel PC Windows 11 sur lequel un membre du groupe s'authentifie suivra le processus APDP : sans enregistrement préalable.

Étape 4 / 5

✓ Policy créée : APDP-Argos-UserDriven-EntraJoin

TypeUser-driven · Entra join

Device security groupArgos-APDP-Devices (statique)

Apps OOBE4 / 25 sélectionnées

Assigned toArgos-Consultants (groupe utilisateurs)

Priority1 (plus haute)

User account typeStandard User

🎉 Policy prête ! Les consultants Argos qui reçoivent un nouveau PC Windows 11 et s'authentifient avec leur compte M365 déclencheront automatiquement cette DPP : sans aucun enregistrement hardware hash préalable.

Étape 5 / 5 ✓

4

OOBE APDP : Expérience utilisateur v2

L'OOBE APDP est plus simple et plus claire que l'ESP d'Autopilot v1. Navigue entre les étapes.

5

Scénarios APDP : Ce qui est disponible en juin 2026

👤

User-Driven : Entra Join

L'utilisateur s'authentifie. L'appareil rejoint Entra ID et est géré par Intune. Cas Argos : consultants.

✓ Disponible (GA)

☁️

Windows 365 Frontline : Auto

Déploiement automatique pour Cloud PCs partagés Windows 365 Frontline. Aucune interaction utilisateur.

⚡ Preview (juin 2026)

🏭

Pre-Provisioning (White Glove)

Phase IT + phase utilisateur. Réduction du temps OOBE chez l'utilisateur final.

📅 Planned : pas encore disponible

🤖

Self-Deploying

Aucune interaction utilisateur, pas d'association à un compte. Kiosques, salles partagées.

📅 Planned : pas encore disponible

🏢

Hybrid Entra Join

Appareil joint à Active Directory on-premises ET à Entra ID. Nécessite connecteur Intune.

✗ Non supporté par APDP

↑ Sélectionne un scénario pour voir ses détails.

⚠️ Si tu as besoin de Pre-Provisioning, Self-Deploying ou Hybrid join aujourd'hui, reste sur Autopilot v1 classique. Microsoft investit en parallèle dans les deux solutions. La migration n'est pas forcée.

6

Rapport de déploiement : Monitoring quasi temps réel

Devices → Monitor → Device preparation deployments Statut par appareil, par app et par script.

17

Succès

2

Échecs

1

En cours

20

Total

Appareil	Utilisateur	Durée	Statut	Détails
DESKTOP-7K2P1	marie.dupont@argos.fr	14 min	✓ Success	Microsoft 365 AppsInstallé MDE onboardingInstallé Company PortalInstallé Pilote imprimanteInstallé
DESKTOP-3MT5R	jean.martin@argos.fr	19 min	✓ Success	Microsoft 365 AppsInstallé MDE onboardingInstallé Company PortalInstallé Pilote imprimanteInstallé
DESKTOP-9NQ8X	pierre.bernard@argos.fr		⟳ En cours (65%)	Microsoft 365 AppsInstallé MDE onboardingEn cours Company PortalEn attente Pilote imprimanteEn attente
DESKTOP-2WF4K	sophie.leclerc@argos.fr	72 min	✗ Échec (timeout)	Microsoft 365 AppsInstallé MDE onboardingErreur 0x87D1041C Company PortalNon installé Pilote imprimanteNon installé Logs disponibles 28 jours · Télécharger depuis "Device deployment details"

💡 Contrairement à Autopilot v1 (rapport 30 jours, statut global), le rapport APDP est quasi temps réel avec un statut par app et par script. Les logs des déploiements en erreur sont téléchargeables directement depuis le portail (disponibles 28 jours).

7

Quiz de validation : Windows Autopilot Device Preparation