Pendant longtemps, on provisionnait un Cloud PC, l’utilisateur se connectait… et il attendait. Il attendait que Intune pousse ses apps, que les scripts PowerShell s’exécutent, que les policies s’appliquent. Résultat : une première connexion bancale, des tickets help desk en pagaille et une image un peu décevante de la solution. Microsoft vient enfin de régler ça avec la Device Preparation Policy (ou DPP pour les intimes) étendue à Windows 365 Enterprise, disponible en Public Preview. Et franchement, ça change vraiment la donne.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
- Quelle est la nouveauté ?
- Est-ce la même chose que l’Autopilot DPP pour les postes physiques ?
- J’ai Windows 365 Business, est-ce que j’y ai accès ?
- Quels sont les prérequis à respecter ?
- C’est quoi ce « Intune Provisioning Client » ?
- Combien d’apps et de scripts peut-on pousser ?
- Et si le timeout est dépassé ?
- Est-ce compatible avec Hybrid Entra Join ?
- Peut-on publier des apps Intune comme Cloud Apps via DPP ?
- Étape 0 : rappel des prérequis
- Étape 1 : créer le groupe Entra ID dédié
- Étape 2 : attribuer le service principal à ce groupe
- Étape 3 : créer la Device Preparation Policy
- Étape 4 : lier la DPP à la Provisioning Policy Windows 365
- Le test : on déroule un provisioning complet
- Monitorer le déploiement de la DPP
- Les limitations et pièges à connaître
- Conclusion
Quelle est la nouveauté ?
Comme annoncé en introduction, Microsoft étend en préversion publique l’Autopilot Device Preparation Policy (DPP) à Windows 365. L’idée est simple : vous définissez en amont les applications et les scripts qui doivent être installés sur le Cloud PC avant que l’utilisateur puisse s’y connecter. Tant que tout n’est pas prêt, le Cloud PC reste en statut Preparing et l’utilisateur est poliment mis en attente.
Pour rappel, un précédent article avait déjà écrit sur DPP et parlant de ce que l’on appelle aussi Autopilot v2. Attention, ce terme est trompeur car Autopilot v1 est à ce jour toujours en vigueur chez Microsoft.
C’est un vrai changement de philosophie par rapport à ce qu’on connaissait : historiquement, sur Windows 365, on provisionnait le Cloud PC, on laissait l’utilisateur se connecter, et Intune rattrapait son retard en arrière-plan. Forcément, entre le moment où l’utilisateur ouvrait sa session et celui où Outlook finissait enfin d’être installé, il y avait un trou dans la raquette qui faisait mauvaise impression.
Avec la DPP, ce trou disparaît : la documentation Microsoft Learn confirme que le provisioning Windows 365 ne se termine qu’une fois les apps et scripts installés (ou que le timeout soit atteint).
Est-ce la même chose que l’Autopilot DPP pour les postes physiques ?
C’est le même moteur, mais utilisé différemment. Pour un poste physique, l’Autopilot DPP s’exécute pendant l’OOBE de Windows, juste après le premier boot. Pour un Cloud PC, il n’y a pas d’OOBE côté utilisateur : la machine est provisionnée dans Azure, et la DPP s’exécute pendant cette phase de provisioning, transparente pour l’utilisateur.
Autrement dit :
- Pas besoin de hardware hash (forcément, il n’y a pas de hardware 😅)
- Pas d’Enrollment Status Page côté client
- On utilise le mode Automatic (Preview) de la DPP, pas le mode user-driven
- La DPP se « branche » sur la Provisioning Policy Windows 365 existante
Si vous avez déjà lu mes articles sur l’Autopilot DPP pour postes physiques, vous retrouverez les concepts (groupe dynamique interdit, groupe assigné obligatoire, service principal owner, 10 apps max, 10 scripts max). Seule la « sortie » change : au lieu d’un laptop qui attend sur l’OOBE, c’est un Cloud PC qui reste en Preparing.
J’ai Windows 365 Business, est-ce que j’y ai accès ?
Non. La fonctionnalité est destinée à Windows 365 Enterprise, ce qui est logique puisqu’elle s’appuie sur Intune et sur les Provisioning Policies. Windows 365 Business, qui ne s’intègre pas à Intune, n’est pas concerné.
Si vous êtes en Business et que vous voulez ce niveau d’industrialisation, c’est le bon moment pour envisager une migration vers l’offre Enterprise.
Quels sont les prérequis à respecter ?
Avant de se lancer, il faut cocher quelques cases. Microsoft liste les prérequis officiels, et je les résume ici :
| Prérequis | Détail |
|---|---|
| Licence | Windows 365 Enterprise + Intune |
| Jointure | Microsoft Entra Join (ou Hybrid Entra Join) |
| Groupe Entra | Groupe assigné (pas dynamique !) |
| Service principal | Intune Provisioning Client défini comme Owner du groupe |
| Rôle admin | Intune Administrator ou équivalent |
| Apps / scripts | Assignés en Required au même groupe Entra |
Le piège classique : oublier d’assigner les apps au groupe en « Required ». Si l’app est uniquement tracée par la DPP mais pas assignée au groupe, Intune ne la pousse jamais et la DPP boucle jusqu’au timeout. Croyez-en un MVP qui s’est fait avoir 🙃.
C’est quoi ce « Intune Provisioning Client » ?
C’est le service principal (dans certains tenants il s’appelle aussi Intune Autopilot ConfidentialClient) qui a le droit d’ajouter des devices au groupe Entra ID lié à votre DPP. Sans lui en Owner du groupe, la DPP ne peut rien faire : les Cloud PCs provisionnés ne sont jamais ajoutés au groupe, et donc les apps ne sont jamais poussées.
Si vous ne le trouvez pas par son nom dans Entra, cherchez-le par App ID :
f1346770-5b25-470b-88bd-d5744ab7952cCe GUID est documenté noir sur blanc par Microsoft dans les prérequis Autopilot DPP :
Combien d’apps et de scripts peut-on pousser ?
La limite est stricte : 25 applications et 10 scripts PowerShell. Pas plus.
Et ces 10 applications, ce sont celles qui bloquent la mise à disposition du Cloud PC. Autrement dit, il faut les choisir avec soin : votre Office, votre client VPN, votre agent EDR, éventuellement votre Teams… Les petites apps « confort » (readers PDF gratuits, utilitaires divers) peuvent parfaitement être déployées en parallèle via Intune, sans bloquer le provisioning.
Mon conseil : ne mettez dans la DPP que ce qui est réellement indispensable pour que l’utilisateur puisse travailler à la première connexion. Chaque app ajoutée allonge le temps de provisioning perçu. On ne fait pas un gold master dans la DPP.
Et si le timeout est dépassé ?
C’est vous qui décidez du comportement, et c’est paramétré directement sur la Provisioning Policy Windows 365, onglet Configuration :
- Minutes allowed before device preparation fails : le temps au bout duquel on considère que ça a échoué.
- Prevent users from connection to Cloud PC upon installation failure or time-out : la fameuse case à cocher.
Deux scénarios selon que la case est cochée ou non :
| Case cochée ? | Statut du Cloud PC | L’utilisateur peut se connecter ? |
|---|---|---|
| Oui | Failed | Non – impossible de se connecter |
| Non | Provisioned with warnings | Oui – mais certaines apps peuvent manquer |
Pour un environnement sensible (santé, finance, production industrielle), je recommande la case cochée : mieux vaut un Cloud PC refusé qu’un Cloud PC sans antivirus.
Est-ce compatible avec Hybrid Entra Join ?
Oui. Microsoft le précise explicitement : Windows 365 supporte Entra Join et Hybrid Entra Join lors du provisioning, et la DPP est compatible avec les deux modes :
Windows 365 prend en charge la jointure Entra et la jointure Entra hybride lors de l’approvisionnement. La préparation de l’appareil peut être utilisée dans les stratégies d’approvisionnement avec ces fonctionnalités activées.
Pour mémoire, mon conseil reste le même que pour les postes physiques : privilégiez toujours l’Entra Join pur quand vous le pouvez. Sur Cloud PC, il n’y a objectivement aucune bonne raison de rester en Hybrid sauf contrainte d’authentification Kerberos sur des serveurs de fichiers on-prem.
Peut-on publier des apps Intune comme Cloud Apps via DPP ?
Et voilà la bonne surprise du package ! Microsoft a annoncé en parallèle que l’Autopilot DPP peut désormais servir à publier des applications Intune comme Windows 365 Cloud Apps. En gros : une app installée via DPP peut être exposée à l’utilisateur non pas comme un raccourci sur le bureau du Cloud PC, mais comme une Cloud App dédiée dans la Windows App.
Pourquoi c’est intéressant ? Parce que ça permet, par exemple :
- De publier SAP ou un ERP maison directement comme Cloud App, sans passer par un full desktop
- De capitaliser sur les Win32 apps déjà packagées dans Intune
- De se rapprocher d’une logique type « RemoteApp » à la AVD, mais pilotée depuis Intune
C’est encore en Public Preview pour toutes les licences Windows 365, mais c’est clairement un signal : Microsoft veut transformer la DPP en point central de packaging pour Windows 365, qu’il s’agisse de full desktop ou de Cloud Apps.
La bonne nouvelle est que Microsoft a même publié un pas à pas sur le Microsoft Learn, juste ici. Et enfin, comme toujours, je vous propose dans la suite de cet article d’effectuer ensemble un pas à pas avec des copies d’écran.
Étape 0 : rappel des prérequis
Avant tout test, il est nécessaire de disposer d’une licence Windows 365, Entreprise ou Frontline, assignée à votre utilisateur de test.
La copie d’écran ci-dessous du portail Intune nous montre deux utilisateurs disposant de licences Windows 365, mais dont les Cloud PC n’ont pas encore été provisionnés :
Étape 1 : créer le groupe Entra ID dédié
On commence par créer un groupe Entra ID qui va servir de « réceptacle » pour les Cloud PCs provisionnés. Important : type d’appartenance Assigné (Microsoft ne supporte PAS les groupes dynamiques ici).
- Ouvrez le portail Microsoft Entra.
- Allez dans Groups > All groups > New group.
- Type : Security.
- Nom : quelque chose de parlant, par exemple
SG-W365-DPP-Finance. - Membership type : Assigned.
- Laissez le groupe vide, on n’a rien à ajouter manuellement : la DPP s’en chargera.
Étape 2 : attribuer le service principal à ce groupe
C’est l’étape que tout le monde oublie. Sans ça, la magie n’opère pas. Il faut que l’on donne à Intune les droits de rajouter des membres au groupe de machines.
- Ouvrez le groupe que vous venez de créer.
- Allez dans l’onglet Owners > Add owners.
- Dans la recherche, tapez Intune Provisioning Client ou collez directement l’App ID
f1346770-5b25-470b-88bd-d5744ab7952c. - Sélectionnez-le et validez.
Étape 3 : créer la Device Preparation Policy
On bascule maintenant dans le centre d’administration Intune pour créer la DPP :
- Ouvrez le Microsoft Intune admin center.
- Allez dans Devices > Windows > Enrollment > Device preparation policies.
- Cliquez sur Create, puis sélectionnez Automatic (Preview) :
- Basics : donnez un nom clair (par exemple DPP – Windows 365 Finance) et une description.
- Device group : sélectionnez le groupe créé à l’étape 1.
- Configuration settings : ajoutez jusqu’à 25 applications et jusqu’à 10 scripts. Les apps doivent être en system context pour être disponibles pour tous les utilisateurs :
- Scope tags : par défaut, sauf besoin RBAC spécifique.
- Review + create : validez :
Retournez puis vérifiez bien que votre DPP est correctement configurée :
Petit rappel important : les apps et scripts ajoutés ici doivent aussi être assignés au même groupe Entra en « Required ». Sinon Intune ne les déploie pas, et la DPP attend dans le vide :
Étape 4 : lier la DPP à la Provisioning Policy Windows 365
C’est là que les deux mondes se rencontrent.
- Dans Intune, allez dans Devices > Windows 365 > Provisioning policies.
- Créez une nouvelle Provisioning Policy ou éditez une existante :
- Sur l’onglet Configuration, descendez jusqu’à la section Autopilot device preparation policy, puis sélectionnez la DPP créée à l’étape 3 :
- Renseignez Minutes allowed before device preparation fails (je conseille entre 60 et 90 minutes selon la taille des packages).
- Cochez ou non Prevent users from connection to Cloud PC upon installation failure or time-out selon votre niveau d’exigence.
- Complétez le reste de la Provisioning Policy comme d’habitude (image, réseau, assignments) et validez.
J’ai également fait une seconde police de provisionnement DPP afin de tester le mix entre Autopilot et les Cloud Apps Frontline :
Le test : on déroule un provisioning complet
Passons à la pratique, parce qu’une doc sans test, c’est juste de la théorie. Dans mon lab, j’ai ajouté dans la DPP et j’ai suivi le déploiement :
- Adobe Acrobat Reader
- Google Chrome
- Un script PowerShell qui modifie la configuration du firewall
Mais j’ai aussi mis en obligatoire d’autres applications installées automatiquement par la suite :
- Microsoft 365 Apps (Win32 package)
- Company Portal
Voilà le déroulé observé :
- J’assigne la Provisioning Policy à mse utilisateurs de test. Les Cloud PCs apparaissent en Provisioning :
- Au bout de quelques minutes, le statut bascule en Preparing. C’est la DPP qui prend le relais.
- Le Cloud PC est rajouté au groupe géré par Intune :
- En cliquant sur Preparing, Intune me redirige vers le rapport Windows Autopilot device preparation deployment status.
- Je vois progressivement mes apps passer de Pending à Installed, puis le script en Success.
- Pareil pour le script :
- Le Cloud PC passe enfin en Provisioned.
- L’utilisateur se connecte via windows.cloud.microsoft ou via l’application Windows App :
- Acrobat bien installé, Chrome et les autres outils Office se sont installés tout seul par la suite :
- Les applications publiées via la seconde DPP s’affichent également dans l’onglet dédié :
- Enfin, les règle de Firewall ont bien été modifiées par le script :
Et c’est exactement le genre de « petite fonction sympa » qui change la vie : le script PowerShell passé en system context permet de faire tout ce qu’on veut – clés registre, certificats, création d’utilisateurs locaux, configuration OneDrive Known Folders, mise en place d’un wallpaper corporate… Tout ça sans que l’utilisateur n’ait à patienter devant un bureau à moitié configuré.
Monitorer le déploiement de la DPP
Le suivi se fait à deux endroits complémentaires :
| Emplacement | Ce qu’on y voit |
|---|---|
| Devices > Windows 365 > All Cloud PCs | Statut global : Provisioning, Preparing, Provisioned, Failed, Provisioned with warnings |
Il y est même possible de relancer le provisionnement du PC depuis le tout début :
| Emplacement | Ce qu’on y voit |
|---|---|
| Devices > Enrollment > Monitor > Windows Autopilot device preparation deployment status | Détail par device : liste des apps et scripts, statut individuel de chaque étape, codes d’erreur |
En cliquant sur un device dans le second écran, vous avez le détail ligne par ligne : chaque app avec son statut (Installed / Failed / In Progress), chaque script avec son code de sortie. C’est ce qu’il vous faut pour diagnostiquer quand un provisioning finit en Provisioned with warnings.
Et bonne nouvelle : cette vue s’articule parfaitement avec la nouvelle plateforme de monitoring Windows 365 dont j’ai parlé dans mon article précédent sur le monitoring Windows 365. Vous y gagnez une vraie vue end-to-end de la santé de vos Cloud PCs, du provisioning jusqu’à l’expérience utilisateur en run.
Les limitations et pièges à connaître
Parce que ça reste une Public Preview, il y a quelques verrues à garder en tête :
| Limitation | Impact |
|---|---|
| Groupes dynamiques non supportés | Il faut impérativement un groupe Assigned |
| 25 apps / 10 scripts max | Limite dure, à arbitrer dès la conception |
| Apps non assignées = skip silencieux | Les apps doivent aussi être en « Required » sur le groupe |
| Pas de re-provisioning automatique | Ajouter une DPP sur une Provisioning Policy existante nécessite un reprovision manuel |
| Pas de GA annoncée | Configuration à tester en pilote, pas à passer en prod critique à l’aveugle |
| Timeout trop bas = faux négatifs | Un package Win32 volumineux peut dépasser 30 min, calibrez bien |
Et comme toujours avec les previews Microsoft, la feature peut encore évoluer avant la GA (interface, nombre d’apps max, intégrations supplémentaires). À surveiller.
Conclusion
C’est clairement l’une des évolutions que j’attendais le plus pour Windows 365 Enterprise. Pas un gadget, pas un petit ajustement cosmétique : une vraie brique manquante qui arrive enfin. Jusqu’ici, on faisait du provisioning Windows 365 en croisant les doigts pour que les apps soient là au bon moment. Avec la DPP, on passe d’un modèle « best effort » à un modèle déterministe.
Ce qui me plaît particulièrement : la cohérence avec ce que les admins Intune connaissent déjà sur les postes physiques (même console, même logique de groupe, même service principal), la simplicité du branchement sur la Provisioning Policy (une case à cocher, une valeur de timeout), et la promesse tenue côté Cloud Apps qui positionne la DPP comme la pierre angulaire du packaging Windows 365 de demain.
Ce qui mérite vigilance : la limite des 25 apps / 10 scripts qui va obliger à faire des choix, le piège de l’assignment « Required » obligatoire, et le fait que la feature soit encore en Public Preview sans date de GA annoncée. Je l’intègre dès maintenant dans mes projets de déploiement, mais avec un pilote avant de la généraliser à des populations critiques.
En tout cas, si vous avez Windows 365 Enterprise, foncez tester : Devices > Windows > Enrollment > Device preparation policies, puis liez-la à votre Provisioning Policy. Et dites-moi dans les commentaires ce que vous en pensez, surtout si vous avez trouvé des cas tordus que j’aurais oubliés !
