Windows 365 et Autopilot Device Preparation : enfin des Cloud PCs prêts avant la première connexion

Pendant longtemps, Windows 365 avait un petit défaut assez agaçant.

Le Cloud PC était provisionné, l’utilisateur pouvait se connecter… et Intune faisait le reste en arrière-plan. Sur le papier, tout allait bien. En exploitation, c’était moins propre : application métier absente, agent de sécurité pas encore installé, script de configuration pas encore exécuté, première connexion bancale.

Bref, le Cloud PC était “provisioned”, mais pas forcément prêt.

Avec Windows Autopilot Device Preparation en mode Automatic pour Windows 365, Microsoft corrige enfin une partie du problème. L’idée est simple : rattacher une Device Preparation Policy à une Windows 365 Provisioning Policy afin d’installer les applications et scripts essentiels pendant le provisioning, avant que l’utilisateur ne commence à travailler. Microsoft indique que ce mode est actuellement en public preview et qu’il couvre notamment Windows 365 Enterprise, Windows 365 Frontline shared, Windows 365 Frontline dedicated et Windows 365 Cloud Apps.

Ce n’est pas juste une évolution de confort. Pour certains scénarios, c’est une vraie brique d’industrialisation.

Le problème initial : le « presque prêt »

Sur un poste physique, on connaît déjà le sujet : Autopilot, Enrollment Status Page, applications bloquantes, scripts, politiques Intune, etc.

Sur Windows 365, la logique était différente. Le Cloud PC est créé dans le service Windows 365, joint à Entra ID ou Hybrid Entra ID, inscrit dans Intune, puis mis à disposition. Le problème, c’est que la mise à disposition pouvait arriver avant que toutes les briques attendues soient réellement en place.

Et sur un Cloud PC, surtout en environnement partagé ou Frontline, ce n’est pas anodin.

L’utilisateur ne sait pas qu’Intune est “en train de finir”. Lui, il voit juste un poste qui n’a pas Outlook, pas l’application métier, pas le bon raccourci, pas le bon navigateur, ou pas la configuration attendue.

Dans le meilleur des cas, il attend.

Dans le pire des cas, il ouvre un ticket.

Ce que change Autopilot Device Preparation pour Windows 365

Avec Autopilot Device Preparation, Windows 365 ne se contente plus de créer le Cloud PC et de laisser Intune rattraper le reste ensuite.

La Device Preparation Policy vient s’insérer dans le provisioning. Le Cloud PC passe par un état Preparing, pendant lequel les applications et scripts suivis par la stratégie sont installés. Windows 365 termine ensuite le provisioning lorsque les éléments sont installés ou lorsque le timeout défini est atteint.

Concrètement, cela permet de passer d’une logique :

“Le Cloud PC est créé, Intune finira bien par installer ce qu’il faut.”

à une logique :

“Le Cloud PC n’est présenté comme prêt que lorsque les éléments essentiels ont été traités.”

C’est beaucoup plus sain.

Pas parfait, parce que tout n’est pas suivi de manière bloquante, mais beaucoup plus propre.

Ce n’est pas l’Autopilot classique

Le nom peut prêter à confusion.

Autopilot Device Preparation est parfois présenté comme “Autopilot v2”, mais il ne faut pas le voir comme un simple remplacement de l’Autopilot historique. Et dans le cas de Windows 365, ce n’est pas non plus exactement la même mécanique que sur un poste physique.

Sur un poste physique, l’expérience s’exécute pendant l’OOBE. L’utilisateur démarre la machine, s’authentifie, et la préparation se déroule avant l’arrivée sur le bureau.

Sur un Cloud PC, il n’y a pas le même rapport au matériel ni au premier démarrage local. Le Cloud PC est provisionné côté service, puis Intune intervient pendant ce provisioning. Le mode utilisé est donc le mode Automatic, rattaché à une Windows 365 Provisioning Policy. Microsoft décrit ce mode comme une stratégie supplémentaire pouvant être incluse dans les stratégies de provisioning Windows 365.

Autre point important : Autopilot Device Preparation ne repose pas sur l’Enrollment Status Page classique. Microsoft précise d’ailleurs que Device Preparation n’utilise pas l’ESP. Si l’ESP apparaît pendant un déploiement censé passer par Device Preparation, c’est probablement que la machine suit un autre flux, par exemple un profil Autopilot classique qui prend le dessus.

Le flux technique

Le déroulement est assez logique.

Windows 365 crée d’abord le Cloud PC. Le Cloud PC est ensuite joint à Microsoft Entra ID, puis inscrit dans Intune. À ce moment-là, l’agent Cloud PC appelle la Device Preparation Policy associée à la Provisioning Policy Windows 365. L’Intune Management Extension est installée, puis Intune synchronise les éléments nécessaires. Les applications et scripts sélectionnés dans la Device Preparation Policy sont ensuite installés ou exécutés.

Dans les grandes lignes :

Windows 365 crée le Cloud PC.
Le Cloud PC rejoint Entra ID ou Hybrid Entra ID.
Le Cloud PC s’inscrit dans Intune.
La Device Preparation Policy est appelée.
Le Cloud PC passe en état Preparing.
Les applications et scripts essentiels sont traités.
Le Cloud PC passe en Provisioned, Provisioned with warnings ou Failed selon le résultat et les options choisies.

Ce dernier point est important. Il faut décider si un échec bloque réellement l’accès utilisateur ou non.

Microsoft permet de configurer un timeout via Minutes allowed before device preparation fails. Si les applications ou scripts ne sont pas terminés dans ce délai, la préparation échoue, mais le provisioning peut continuer. Une option permet aussi d’empêcher la connexion utilisateur en cas d’échec ou de timeout. Si elle est activée, le Cloud PC est marqué Failed et l’utilisateur ne peut pas se connecter. Si elle n’est pas activée, le Cloud PC peut être marqué Provisioned with warnings et rester accessible.

Sur un environnement sensible, je préfère largement bloquer l’accès si les composants critiques ne sont pas en place.

Un Cloud PC sans agent de sécurité, sans configuration réseau ou sans application métier indispensable, ce n’est pas un poste prêt. C’est un poste à moitié livré.

Ce que l’on peut installer pendant la préparation

Le mode automatique pour Windows 365 permet aujourd’hui de suivre jusqu’à 25 applications essentielles et 10 scripts PowerShell essentiels.

C’est un point à noter, parce que plusieurs contenus publiés au lancement de la fonctionnalité parlaient encore d’une limite à 10 applications. La documentation Microsoft actuelle indique bien 25 applications et 10 scripts pour ce scénario.

Les types d’applications supportés incluent notamment :

Line-of-business apps ;
Win32 apps ;
Microsoft Store apps compatibles WinGet ;
Microsoft 365 apps ;
Enterprise App Catalog apps.

Autre point important : les applications et scripts doivent être pensés pour s’exécuter en contexte système, puisque la préparation intervient avant que l’utilisateur ne soit connecté. Microsoft précise que les apps et scripts utilisés dans ce flux doivent être configurés pour s’installer ou s’exécuter en System context.

C’est typiquement le bon endroit pour installer ou configurer :

Microsoft 365 Apps ;
l’agent EDR ;
un client VPN ou ZTNA ;
une application métier indispensable ;
un navigateur imposé ;
des certificats ;
une configuration firewall ;
des clés de registre ;
des scripts de préparation OneDrive ou environnement utilisateur ;
des composants nécessaires à l’ouverture de session ou au support.

En revanche, ce n’est pas l’endroit pour tout mettre.

Il ne faut pas transformer la DPP en image dorée déguisée. Plus on ajoute d’éléments bloquants, plus on augmente le temps de provisioning, le risque d’échec et la complexité du troubleshooting.

Mon approche serait simple : seules les briques nécessaires à une première connexion propre doivent être bloquantes. Le reste peut continuer à être déployé par Intune après coup.

La clé : Enrollment Time Grouping

Le cœur du mécanisme, c’est l’Enrollment Time Grouping.

Dans une Device Preparation Policy, on sélectionne un groupe de sécurité Entra ID. Pendant l’enrollment, le device est ajouté directement à ce groupe, ce qui permet de recevoir rapidement les applications, scripts et configurations ciblés sur ce groupe. Microsoft présente ce mécanisme comme un moyen de rendre le déploiement plus rapide et plus fiable qu’avec un groupe dynamique classique.

C’est un point fondamental.

Le groupe doit être un groupe Assigned, pas un groupe dynamique. Il sert de point d’ancrage au provisioning. Les applications et scripts doivent être :

assignés au groupe ;
sélectionnés dans la Device Preparation Policy.

Les deux sont nécessaires.

C’est probablement l’un des pièges les plus fréquents. Si une application est sélectionnée dans la DPP mais qu’elle n’est pas réellement assignée au groupe en Required, elle ne s’installe pas correctement dans ce flux. Microsoft rappelle que les applications et scripts doivent être assignés au groupe Device Preparation, et également spécifiés dans la stratégie.

Le service principal à ne pas oublier

Autre piège classique : le propriétaire du groupe.

Le groupe utilisé par la Device Preparation Policy doit permettre au service Intune d’ajouter les devices pendant le provisioning. Pour cela, le service principal Intune Provisioning Client doit être ajouté comme owner du groupe.

Son App ID est :

f1346770-5b25-470b-88bd-d5744ab7952c

Dans certains tenants, ce service principal peut apparaître sous le nom Intune Autopilot ConfidentialClient. Microsoft précise que si l’App ID correspond, c’est bien le bon service principal.

Si ce point est oublié, le résultat est assez simple : le device n’est pas ajouté correctement au groupe, donc les applications et scripts attendus ne partent pas comme prévu.

C’est le genre de détail qui fait perdre du temps alors que la configuration “semble” correcte dans la console.

Mise en place : séquence propre

La mise en place n’est pas compliquée, mais elle doit être faite dans le bon ordre.

1. Vérifier les prérequis

Avant de créer quoi que ce soit, il faut vérifier que l’environnement Windows 365 et Intune est propre : enrollment automatique, droits d’administration, stratégie de provisioning Windows 365, modèle de jointure Entra ID ou Hybrid Entra ID, et packaging applicatif déjà prêt.

Microsoft confirme que Windows 365 supporte Entra Join et Hybrid Entra Join pendant le provisioning, et que Device Preparation peut être utilisée avec ces deux modes.

En pratique, sur un Cloud PC, je privilégie Entra Join dès que possible. Hybrid Entra Join reste défendable si vous avez encore de vraies dépendances Kerberos ou des contraintes applicatives on-prem, mais il ne faut pas le garder par réflexe.

2. Créer un groupe Entra ID dédié

Créer un groupe de sécurité Entra ID dédié à la Device Preparation Policy.

Je conseille de ne pas réutiliser un groupe existant utilisé pour d’autres usages Intune. Un groupe dédié rend le troubleshooting beaucoup plus simple.

Exemple :

GRP-W365-DPP-Finance-Devices

GRP-W365-DPP-Frontline-Shared

Le nom doit permettre de comprendre immédiatement à quoi sert le groupe.

3. Ajouter Intune Provisioning Client comme owner

Dans le groupe Entra ID, ajouter le service principal comme propriétaire :

Intune Provisioning ClientApp ID : f1346770-5b25-470b-88bd-d5744ab7952c

Si le nom ne ressort pas, rechercher par App ID.

S’il apparaît sous le nom Intune Autopilot ConfidentialClient, c’est acceptable tant que l’App ID correspond.

4. Assigner les apps et scripts au groupe

Les apps doivent être assignées au groupe en Required.

Les scripts PowerShell doivent également être assignés au même groupe.

Et surtout, vérifier le contexte d’installation. Pour ce flux, les applications et scripts doivent être utilisables en contexte système.

C’est ici qu’il faut être sélectif.

Mettre 25 applications bloquantes juste parce que la limite le permet n’est pas une bonne idée. La vraie question est : “Qu’est-ce qui doit absolument être présent avant la première connexion ?”

5. Créer la Device Preparation Policy

Dans Intune :

Devices > Windows > Enrollment > Device preparation policies

Créer une nouvelle stratégie et choisir le mode Automatic.

Ensuite :

donner un nom clair ;
sélectionner le groupe Entra ID dédié ;
ajouter les applications essentielles ;
ajouter les scripts essentiels ;
appliquer les scope tags si nécessaire ;
valider.

Là aussi, le nommage compte. Dans un tenant avec plusieurs populations Windows 365, un nom flou devient vite pénible.

Exemple :

DPP-W365-Enterprise-FinanceDPP-W365-Frontline-Shared-ProductionDPP-W365-CloudApps-SAP

6. Lier la DPP à la Provisioning Policy Windows 365

C’est ici que Windows 365 et Autopilot Device Preparation se rejoignent.

Dans Intune :

Devices > Windows 365 > Provisioning policies

Créer ou modifier une provisioning policy, puis dans l’onglet Configuration, sélectionner la Device Preparation Policy.

Il faut ensuite définir :

le nombre de minutes autorisées avant échec ;
le comportement en cas d’échec ou de timeout ;
les autres paramètres habituels de provisioning.

Microsoft précise que Windows 365 termine le provisioning lorsque les apps et scripts sont installés ou lorsque le timeout expire.

Personnellement, je préfère commencer avec un timeout réaliste et mesuré sur pilote. Un timeout trop court produit de faux échecs. Un timeout trop long masque les problèmes et rend l’expérience d’attente désagréable.

7. Monitorer

Le suivi se fait dans :

Devices > Enrollment > Monitor > Windows Autopilot device preparation deployment status

Microsoft indique que ce rapport permet de suivre les déploiements Autopilot Device Preparation, notamment les statuts des applications, scripts et phases de déploiement.

Côté Windows 365, on retrouve aussi l’état global du Cloud PC : provisioning, preparing, provisioned, failed, etc.

C’est cette double lecture qui permet de comprendre rapidement si le problème vient :

du provisioning Windows 365 ;
de l’ajout au groupe ;
d’une application ;
d’un script ;
d’un timeout ;
d’une mauvaise assignation.

Cas particulier : Windows 365 Cloud Apps

La fonctionnalité devient encore plus intéressante avec Windows 365 Cloud Apps.

Windows 365 Cloud Apps permet de publier des applications individuelles hébergées sur un Cloud PC, sans exposer nécessairement un desktop complet à l’utilisateur. Microsoft précise que Cloud Apps s’appuie sur Windows 365 Frontline Cloud PCs en mode shared, et nécessite donc des licences Windows 365 Frontline.

Pour publier des applications custom non présentes dans l’image de galerie, Microsoft indique deux options : utiliser une custom image ou créer une Autopilot Device Preparation Policy. Le support d’Autopilot Device Preparation pour Cloud Apps est actuellement en public preview.

C’est intéressant parce que cela rapproche Windows 365 d’une logique de publication applicative plus fine.

On peut imaginer des scénarios où l’utilisateur n’a pas besoin d’un Cloud PC complet, mais uniquement d’une application métier publiée depuis un environnement maîtrisé. Dans ce cas, la DPP devient un moyen de préparer l’application à publier, sans forcément maintenir une image custom à chaque changement.

C’est probablement l’un des signaux les plus intéressants : Microsoft pousse Windows 365 vers des usages plus modulaires, pas uniquement vers le “poste complet dans le cloud”.

Les points d’attention

La fonctionnalité est prometteuse, mais il ne faut pas la déployer à l’aveugle.

Groupe dynamique : mauvaise idée

Le groupe utilisé par la DPP doit être un groupe Assigned. La logique repose sur l’ajout direct du device au groupe pendant l’enrollment. Un groupe dynamique ajoute de la latence, de l’incertitude, et casse l’intérêt du mécanisme.

Les apps doivent être Required

Sélectionner une application dans la DPP ne suffit pas. Elle doit aussi être assignée au groupe en Required. Microsoft le rappelle explicitement dans la documentation du flux automatique.

Le contexte système est obligatoire

Si une application dépend d’un contexte utilisateur, d’un profil utilisateur ou d’une interaction, elle n’est probablement pas un bon candidat pour ce flux.

Toutes les policies ne sont pas suivies comme les apps

Autopilot Device Preparation peut synchroniser des politiques assignées au groupe, mais Microsoft précise que l’application des policies n’est pas suivie de la même manière pendant le déploiement. Les apps et scripts, eux, sont suivis dans le rapport.

Il ne faut donc pas considérer la DPP comme une garantie absolue que toute la configuration Intune est appliquée avant l’accès utilisateur.

Attention aux known issues

Microsoft maintient une page dédiée aux known issues. Certains problèmes historiques ont été corrigés, comme le timeout à 60 minutes sur Windows 365 ou le Managed Installer qui pouvait entraîner des apps marquées comme skipped. La page reste à surveiller, surtout tant que la fonctionnalité est en preview.

Ne pas tout bloquer

La limite de 25 applications ne veut pas dire qu’il faut en mettre 25.

Dans une vraie approche projet, je sépare les éléments en trois catégories :

Bloquant avant première connexion
EDR, Microsoft 365 Apps si nécessaire, agent métier critique, configuration réseau, script de sécurité.

Important mais non bloquant
Outils bureautiques secondaires, lecteurs PDF, utilitaires, applications de confort.

À installer à la demande
Applications rares, outils métier spécifiques, logiciels lourds, applications par profil.

Le but n’est pas de reproduire une image master. Le but est d’éviter de livrer un Cloud PC inutilisable.

Ma lecture terrain

Pour moi, cette fonctionnalité répond à un vrai irritant Windows 365.

Windows 365 est souvent vendu comme un poste simple à fournir, simple à remplacer, simple à redimensionner. C’est vrai. Mais si la première connexion utilisateur donne l’impression d’un poste pas fini, l’image du service se dégrade immédiatement.

Autopilot Device Preparation améliore ce point précis.

Pas en ajoutant une couche magique, mais en remettant de l’ordre dans la séquence :

Je crée le Cloud PC.
Je l’inscris dans Intune.
Je le prépare avec les briques essentielles.
Je le rends disponible.

C’est plus propre.

C’est aussi plus proche de ce que l’on attend d’un vrai poste de travail managé.

Conclusion

Autopilot Device Preparation pour Windows 365 n’est pas une révolution spectaculaire. C’est mieux que ça : c’est une correction de trajectoire pragmatique.

Elle permet d’éviter le Cloud PC “presque prêt”, celui qui est techniquement provisionné mais fonctionnellement incomplet.

Pour Windows 365 Enterprise, Frontline et Cloud Apps, c’est une brique à tester sérieusement. Pas en production critique dès le premier jour, mais dans un pilote propre, avec peu d’applications bloquantes, des scripts maîtrisés, un timeout mesuré, et un monitoring attentif.

Mon conseil : commencez petit.

Une DPP dédiée, un groupe dédié, quelques applications essentielles, un ou deux scripts utiles, puis mesurez. Temps de provisioning, taux d’échec, causes de warning, comportement utilisateur.

Ensuite seulement, élargissez.

La bonne approche n’est pas de tout mettre dans la DPP. La bonne approche est de décider ce qui doit impérativement être prêt avant que l’utilisateur arrive sur son Cloud PC.

C’est là que la fonctionnalité prend tout son sens.