Restez actif avec Windows 365 Reserve

Vous avez vu passer « Windows 365 Reserve » dans une release note, vous savez vaguement que ça dépanne quand un PC tombe en rade, mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On part d’une licence trial fraîchement activée et on déroule, capture après capture, jusqu’au Cloud PC Reserve connecté depuis la Windows App.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. C’est quoi Windows 365 Reserve, et à quoi ça sert ?
2. Le modèle de licence et l’assignation
3. Les pré-requis à poser avant de se lancer
4. Préparer le terrain : Intune, réseau, Entra
5. Créer la provisioning policy Reserve, pas-à-pas
6. Laisser l’utilisateur se servir : le self-provisioning (Preview)
7. Provisionner côté IT (depuis Intune)
8. Provisionner côté utilisateur (self-service)
9. Se connecter au Cloud PC Reserve
10. Surveiller l’usage (rapports Intune)
11. Rendre le Cloud PC (deprovision)

1. C’est quoi Windows 365 Reserve, et à quoi ça sert ?

Windows 365 Reserve, c’est une déclinaison de Windows 365 pensée pour les utilisateurs qui travaillent d’habitude sur un PC physique. L’idée : leur fournir un Cloud PC de secours, de courte durée, quand leur machine principale n’est plus disponible. On reste dans la logique de continuité d’activité, on n’achète pas une licence Cloud PC plein temps « au cas où », on garde une réserve qu’on active uniquement quand le besoin tombe.

Concrètement, ça donne quoi ? Microsoft cible cinq scénarios :

Perte, vol ou casse de l’appareil
Retards de livraison de matériel
Pannes ou incidents cyber
Besoins de staffing temporaire
Environnements de test ou d’essai (le lab, justement)

Côté gestion, tout passe par Microsoft Intune : on prépare les policies à l’avance, et le jour J on provisionne en quelques clics.

Réserve Windows 365 est une version de Windows 365 conçue pour les utilisateurs qui travaillent principalement sur des PC physiques.

Il fournit aux organisations un accès flexible et à court terme à un PC cloud pour maintenir la productivité des employés lors d’interruptions inattendues.

Cette offre prend en charge la continuité d’activité en permettant un accès rapide et sécurisé aux PC cloud lorsque les appareils physiques ne sont pas disponibles.

Source : What is Windows 365 Reserve?, Microsoft Learn

2. Le modèle de licence et l’assignation

Le principe d’abord. Windows 365 Reserve est un produit à part entière, avec une licence seulement disponible en annuel :

Attention : dans le centre d’administration Microsoft 365, vos licences Reserve s’affichent comme assignées à zéro utilisateur. C’est normal : elles s’appliquent au niveau du tenant et ne s’assignent pas comme une licence Microsoft 365 classique. Inutile de chercher à les coller sur un utilisateur depuis le portail M365.

Comme annoncé juste au dessus, on n’assigne pas cette licence dans la console d’administration Microsoft 365 :

Chaque licence ouvre droit à 10 jours d’accès au Cloud PC par an et par utilisateur :

Les pré-requis utilisateur (Windows 11 ou 10 Enterprise, Intune, Entra ID P1) sont, eux, déjà inclus dans la plupart des plans : Microsoft 365 E3, E5, F3, A3, A5, Business Premium et les abonnements Education Student Use Benefit.
La licence Reserve, elle, vient se rajouter par-dessus.

Alors comment on assigne ? Par la provisioning policy que l’on va créer sous Intune.

Quand vous créez une policy Reserve dans Intune et que vous lui affectez un groupe Entra, chaque membre du groupe reçoit une licence, tant qu’il reste assez de licences disponibles dans le tenant. Les règles à garder en tête :

Un utilisateur ne peut détenir qu’une seule licence Reserve à la fois.
Les 10 jours ne se partagent pas et ne se mutualisent pas entre utilisateurs : Microsoft conseille de prévoir une licence par utilisateur à couvrir.
Une fois son Cloud PC provisionné, sa licence ne peut plus être retirée ni réaffectée avant la fin du terme.

Le délai à anticiper : le Cloud PC d’un utilisateur ne devient éligible au provisioning que sept jours après l’affectation de sa licence. Ce délai ne s’applique que la première fois (ou après une interruption de couverture), et il se suit dans Intune sous la provisioning policy de l’utilisateur. D’où la règle d’or : on prépare et on assigne les policies bien en amont, pas le jour de l’incident.

La réaffectation, enfin : il n’y a pas de bouton « réassigner ». Tout se gère via l’appartenance au groupe Entra ou l’affectation du groupe à la policy. Et le comportement dépend de l’état du Cloud PC :

Licence non utilisée (Cloud PC jamais provisionné) : si vous retirez l’utilisateur de l’affectation, sa licence retourne au pool disponible du tenant et peut être redistribuée.
Licence utilisée (Cloud PC déjà provisionné) : si vous retirez l’utilisateur, la licence lui reste attachée jusqu’à la fin du terme et ne revient pas au pool.

Reste le piège des compteurs. Les 10 jours se décomptent dès le provisioning et se mettent en pause au deprovision. Un « jour » se mesure par tranches de 24 heures à partir de l’heure de provisioning, quel que soit le fuseau : toute fraction de journée passée provisionnée consomme la journée entière. Vous pouvez enchaîner les 10 jours d’un bloc ou les étaler sur l’année en jouant sur provisioning et deprovisioning.

Les jours non consommés expirent à la fin du terme, et à la disponibilité générale il n’y a ni cumul ni extension.

Attention : provisionnez à la demande, et déprovisionnez dès que l’utilisateur a récupéré sa machine. Chaque jour où le Cloud PC reste provisionné est décompté du crédit annuel, même s’il n’est pas utilisé.

3. Les pré-requis à poser avant de se lancer

Avant de créer quoi que ce soit, on vérifie le terrain. Voici le tableau à fixer en favori :

Brique	Ce qu’il vous faut
Licence	Windows 365 Reserve (jusqu’à 10 jours par an et par utilisateur)
Système d’exploitation	Windows 11 Enterprise ou Windows 10 Enterprise
Gestion	Microsoft Intune
Identité	Microsoft Entra ID P1
Rôle requis	Windows 365 administrator
Rôles recommandés	Intune administrator (rapports, fonctionnalités Intune), User administrator (groupes Entra)
Réseau et jonction	Pas d’Azure AD DS ni de domaine on-prem requis. Les Cloud PC Reserve sont toujours joints à Microsoft Entra, sur le Microsoft Hosted Network

Bonne nouvelle pour les setups modernes : pas de domaine Active Directory à traîner, pas de réseau Azure à câbler. Tout est Entra-joined sur le réseau hébergé par Microsoft. (Source : Managing Windows 365 Reserve, Microsoft Learn.)

4. Préparer le terrain : Intune, réseau, Entra

Quatre points à régler en amont, pour que le Cloud PC arrive déjà prêt à l’emploi le jour où on en a besoin :

Intune : appliquez vos policies et vos apps ciblées utilisateur, pour que le Cloud PC Reserve hérite des mêmes réglages que vos postes physiques.
Réseau : vérifiez que vos firewalls d’entreprise ne bloquent pas le service Windows 365 (voir les exigences réseau Windows 365).
Entra Join : assurez-vous que vos endpoints de jonction Microsoft Entra sont prêts.
Groupe Entra : créez (ou réutilisez) un groupe de sécurité qui servira à l’affectation de la provisioning policy.

Mon retour terrain : le groupe Entra dédié vaut le coup, même pour un lab. C’est lui qui pilote l’allocation des licences Reserve, et c’est tellement plus propre que de bidouiller des affectations à l’unité.

5. Créer la provisioning policy Reserve, pas-à-pas

La provisioning policy, c’est elle qui définit les réglages du Cloud PC : géographie, langue, type d’image. Et surtout, c’est en lui affectant un groupe Entra que vous allouez réellement les licences Reserve.

Attention : vous ne pouvez provisionner le Cloud PC d’un utilisateur que sept jours après lui avoir affecté sa licence. Créez et assignez vos policies bien avant le moment où vous en aurez besoin, sinon le jour de l’incident vous serez coincé par ce délai.

Dans Intune, allez dans Devices > Provision Cloud PCs et sélectionnez Create policy.

Sous Basics, saisissez un nom et une description.
Sous Experience, choisissez Access a full Cloud PC.
Sous License type, choisissez Reserve.
Choisissez la Geography des Cloud PC Reserve :

Changez l’image de la galerie si besoin :

Configurez une Device Preparation Policy (Autopilot DPP) :

Sélectionnez celle-ci dans votre police :

Sous Assignments, ajoutez vos groupes d’utilisateurs :

Vérifiez les réglages et sélectionnez Create :

Les Cloud PC de réserve apparaissent déjà, mais conservent pour le moment ce statut de non provisionnement :

Cela s’explique facilement, car c’est exactement à ce moment que le délai de sept jours commence :

Il ne nous reste plus qu’à patienter les sept jours afin de continuer nos tests. Mais avant cela, nous pouvons activer une autre option bien sympathique pour rendre les utilisateurs plus autonomes.

6. Laisser l’utilisateur se servir : le self-provisioning (Preview)

Par défaut, c’est l’IT qui provisionne les Cloud PC de réserve. Mais Microsoft propose aussi une option pour laisser l’utilisateur déclencher lui-même la création de son Cloud PC depuis la Windows App, sans attendre un ticket. De quoi accélérer la reprise quand chaque minute compte.

Attention : cette capacité est en Public Preview. Selon Microsoft, sa disponibilité future dépendra des résultats de cette préversion. Elle est désactivée par défaut et reste entièrement gouvernée par l’IT, à activer en connaissance de cause.

Côté admin, l’activation de cette option se fait ainsi. Dans Intune, allez dans Devices > Windows 365 > Settings et sélectionnez Create > Windows App settings :

Sous Basics, saisissez un nom et une description.

Sous Configuration settings, basculez Enable users to provision new Cloud PC instances sur Enabled :

Attention : petit garde-fou intégré, ce paramètre ne s’applique qu’aux groupes déjà assignés à une provisioning policy Reserve et licenciés pour Reserve. Pas de risque qu’il déborde sur le reste du parc.

Sous Assignments, ajoutez vos groupes d’utilisateurs :

Vérifiez les réglages et sélectionnez Create :

Côté utilisateur, une fois le réglage appliqué : il se connecte à la Windows App ou au web, voit une nouvelle carte d’appareil Set up my Cloud PC, la sélectionne, confirme via un message de consentement, et le provisioning démarre.

Un détail à ne pas zapper, même en self-service : la période de grâce de sept jours (le délai d’activation) s’applique toujours. Tant qu’elle n’est pas écoulée, à la première affectation de licence, l’utilisateur ne peut pas encore créer son Cloud PC, qu’il passe par l’IT ou par la Windows App.

Voici ce que ça donne côté IT, si l’on tente de provisionner avant la fin des sept jours :

Voici ce que ça donne côté utilisateur, si l’on tente de provisionner avant la fin des sept jours :

7. Provisionner côté IT (depuis Intune)

Le moment de vérité. Les Cloud PC Reserve se provisionnent toujours manuellement, à la demande.Avant toute nouvelle action, voici le même écran sept jours plus tard :

Ouvrez la provisioning policy, sélectionnez Cloud PC Users, choisissez un ou plusieurs utilisateurs, puis Provision :

Confirmez dans la boîte de dialogue :

Le processus de provisionnement se déclenche alors :

Le rapport sur Intune affiche également l’information de provisionnement :

Le Cloud PC passe alors en préparation :

Un détail des étapes de la DPP est disponible :

Une fois le provisionnement terminé, le Cloud PC de Réserve obtient le statut suivant :

Au besoin, il est même possible de comprendre et de relancer le provisionnement si ce dernier a rencontré une erreur :

8. Provisionner côté utilisateur (self-service)

Et quand c’est l’utilisateur qui provisionne lui-même (self-provisioning activé, voir la section 6), le déroulé côté Windows App ressemble à ça :

Le Cloud PC commence alors à se provisionner :

Comme lors du déclenchement par l’administrateur, le processus de provisionnement est aussi visible sur le portail Intune :

9. Se connecter au Cloud PC Reserve

Et là, magie : une fois provisionné, l’utilisateur accède à son Cloud PC depuis n’importe quel appareil.

Ouvrez la Windows App ou le client web sur n’importe quel appareil compatible (Windows, Mac, iOS, Android).
Connectez-vous avec les identifiants de l’organisation.
Filtrez par Windows 365 pour retrouver le Cloud PC Reserve une fois provisionné :

Windows App filtrée sur Windows 365 pour retrouver le Cloud PC Reserve provisionné

Depuis la carte d’appareil, lancez le Cloud PC :

Le Cloud PC de réserve s’ouvre bien, et on y trouve également les applications provisionnées par la policy Autopilot DPP :

10. Surveiller l’usage (rapports Intune)

Pour le suivi de toutes ces machines, tout est filtrable dans Intune.

Provisioning policies : filtre License Type = Reserve :

Rapports : dans la vue d’ensemble Windows 365, ouvrez le rapport Windows 365 Reserve licensing :

All Cloud PCs : filtre License Type = Reserve :

11. Rendre le Cloud PC (deprovision)

Pour rendre le Cloud PC (deprovision), côté admin depuis Intune, ou côté utilisateur via l’action Return dans la Windows App :

Allez dans Devices ou Cloud PC Users sous votre policy.
Sélectionnez un ou plusieurs Cloud PC et choisissez Deprovision now :

Confirmez dans la boîte de dialogue :

Le traitement de déprovisionnement commence alors :

Vérifiez que le statut repasse de Provisioned à Not provisioned :

Attention : le deprovision met en pause le compteur de jours, mais il supprime le Cloud PC et toutes les données non sauvegardées. Aucun snapshot, aucun délai de grâce, et il faut une action admin pour reprovisionner ensuite. Faites sauvegarder les données importantes avant de rendre la machine.

Voilà, en quelques étapes…

Voilà, en quelques étapes vous êtes passé d’une licence trial à un Cloud PC de secours connecté, prêt à dépanner un utilisateur dont le PC est out. Concrètement, ça donne quoi ? Une réserve de continuité d’activité que vous préparez une fois et que vous activez à la demande, sans gérer de PC de prêt ni de licence Cloud PC plein temps.

Les pièges à retenir :

Le délai de sept jours entre l’affectation de la licence et le premier provisioning : on prépare en avance, pas le jour de l’incident.
Le compteur de 10 jours tourne dès le provisioning : on provisionne à la demande.
Le deprovision (ou le Return côté utilisateur) supprime les données non sauvegardées, sans snapshot ni délai de grâce.
L’auto-provisioning depuis la Windows App et la Device Preparation Policy sont encore en Public Preview : à tester en lab avant de promettre quoi que ce soit en prod.

Foncez tester en lab : avec une licence trial, vous bouclez le parcours complet en une après-midi.

Pour aller plus loin

Windows 365 avec Autopilot

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

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-d5744ab7952c

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

Microsoft Learn

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.

Attention : si vous modifiez une Provisioning Policy existante pour y ajouter la DPP, les Cloud PCs déjà provisionnés ne sont PAS re-préparés automatiquement. Il faut déclencher un reprovision pour qu’ils passent par la DPP.

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 !

Upgradez facilement votre Cloud PC Windows 365

Les Cloud PC de Microsoft sont disponibles depuis quelques temps déjà, et de nouvelles fonctionnalités sont leurs rajoutées très régulièrement. Acheté sous forme de licence mensuelle, le Cloud PC initialement commandé peut ne plus suffire à l’utilisateur. Microsoft propose, encore en préversion à cette date, le redimensionnement automatique de celui-ci.

Si vous n’avez pas encore eu l’occasion d’aller plus en profondeur sur les Cloud PC de Microsoft, voici quelques liens vers des articles précédemment écrits, et une excellente vidéo :

Qu’est-ce que le redimensionnement d’un Cloud PC Windows 365 ?

La documentation de Microsoft l’explique très bien :

L’action à distance Redimensionner vous permet de mettre à niveau la RAM, le processeur virtuel et la taille de stockage d’un PC cloud Windows 365 Entreprise pour répondre aux besoins de l’utilisateur.
Microsoft Learn

Pourquoi ne pas simplement recréer un nouveau Cloud PC ?

La démarche de repartir sur un nouveau Cloud PC est tout à fait envisageable. Mais le redimensionnement du Cloud PC a pour principal avantage de conserver les données de l’utilisateurs, mais aussi ses applications et bien d’autres encore.

Peut-on redimensionner son Cloud PC à la baisse ?

La réponse est oui, dans une certaine mesure. Tant que le SKU choisi ne contient pas un disque plus petit que celui présent sur SKU de départ : aucun souci.

La taille d’un disque, et donc des partitions présentes sur celui-ci, est souvent problématique pour certains traitements automatisés.

Doit-on changer sa licence Windows 365 ?

La réponse est encore oui. Le redimensionnement d’un poste Windows 365 nécessite de disposer d’une licence vers la nouvelle taille.

Mais, à l’inverse de nombreuses licences Cloud achetées sous forme de souscription à travers le New Commerce Experience (NCE), je n’ai pas trouvé de moyen direct de migrer de licence Windows 365.

Cela est bien dommage car la licence Windows 365 peut-être prise pour une année, et il sera bien pratique de migrer sur un Cloud PC plus puissant si le besoin s’en fait sentir avant la date d’échéance.

Néanmoins, j’ai pu m’en sortir avec l’aide du Support de Microsoft. Pour cela, j’ai dû acheter une nouvelle licence Windows 365 avant que la précédente, moins puissante, soit annulée et que je sois remboursé.

Est-ce que les utilisateurs peuvent redimensionner leur propre Cloud PC ?

La réponse est non. Comme le rappelle Microsoft, il est nécessaire de disposer d’un des rôles ou combinaisons de rôles suivants pour y parvenir :

Administrateur global
Administrateur de service Intune
Rôles Administration Lecteur Intune + PC cloud

Le redimensionnement est-il disponible pour tous les SKUs Windows 365 ?

Sauf erreur, seuls les SKUs Enterprise sont concernés par cette nouveauté. En effet, un Cloud PC dont le SKU est de type Business ne pourra pas encore avoir cette fonctionnalité.

Que va-t-il se passer pour l’utilisateur durant le redimensionnement ?

Le redimensionnement d’un Cloud PC nécessite de déconnecter l’utilisateur. Il est donc nécessaire de le prévenir en amont afin que ce dernier soit au courant et qu’il ne perde aucune donnée.

Le traitement dure une trentaine de minutes environ.

Comment procède-t-on pour redimensionner ?

Le processus n’est pas bien compliqué. Voici en détail un pas à pas pour mieux vous guider. J’ai simulé la présence de fichiers à divers endroits pour vérifier l’impact du redimensionnement.

Commencez par vérifier la présence d’une nouvelle licence Windows 365 non assignée sur la console d’administration de Microsoft 365 :

Comme vous le montre la copie d’écran ci-dessous, mon utilisateur est actuellement équipé d’un Cloud PC de 2 coeurs / 4Go de mémoire vive. Mon but est de redimensionner son Cloud PC vers une configuration avec deux fois plus de mémoire vive.

Un rapide tour dans son gestionnaire des tâches montre bien les 4Go de mémoire vive :

J’ai déposé un dossier contenant des photos sur le bureau du Cloud PC de départ. L’icône vert sur celui-ci nous montre une synchronisation vers son compte OneDrive :

Le dossier est bien présent sur le bureau du Cloud PC de départ :

J’en profite pour déposer un second dossier de photos à la racine de son disque C, non synchronisé avec OneDrive :

Ce dossier est plus petit que le précédent, mais il nous permettra de vérifier la bonne récupération des données sur le Cloud PC d’arrivée :

Retournez sur la console Intune afin de lancer le redimensionnement du Cloud PC via le menu suivant :

Choisissez la taille de nouvelle configuration du Cloud PC, puis cliquez sur Redimensionner :

Confirmez votre choix :

L’ordre de redimensionnement a bien été pris en compte. Du point de vue utilisateur, il ne nous reste qu’à patienter :

Une première notification apparaît sur le Cloud PC :

On retrouve également l’action dans l’historique des actions lancées depuis la console Intune :

Quelques minutes plus tard, l’utilisateur est bien déconnecté de son Cloud PC :

Un tour dans la console Intune nous montre bien que le redimensionnement est en cours sur le Cloud PC de notre utilisateur :

Si l’utilisateur tente de s’y reconnecter avant la fin du redimensionnement, le message d’erreur suivant apparaît :

Environ 20 minutes plus tard, le statut du Cloud PC change à nouveau :

Toujours sur cette même console Intune, le journal des opérations sur le poste affiche bien le statut suivant :

Afin que l’utilisateur puisse se connecter à son nouveau Cloud PC , un rafraîchement des accès est obligatoire dans l’application :

Juste après le rafraîchement, le nouveau Cloud PC apparaît bien en dessous du précédent, qui devient alors vide de poste :

Cliquez-dessus afin d’ouvrir une nouvelle session de bureau à distance :

Retournez sur le Gestionnaire des tâches afin de vérifier la nouvelle mémoire disponible :

Comme votre utilisateur de test ne doit pas être administrateur du poste, ouvrez la fenêtre suivante en mode Administrateur, puis lancez le programme suivant :

diskmgmt.msc

Vérifiez dans le Gestionnaire des disques la nouvelle taille de la partition du disque C :

Toujours sur le Cloud PC, vérifiez bien la présence :

du dossier présent sur le bureau de l’ancien Cloud PC
du dossier présent à la racine du disque C de l’ancien Cloud PC

Sur le portail Intune, retournez sur la fonction de redimensionnement du Cloud PC afin de constater l’impossibilité de retourner sur un SKU ayant un disque plus petit :

Conclusion

Rien à dire de spécial sur cette fonctionnalité si ce n’est qu’elle marche très bien, et qu’elle pourra faciliter la vie à de nombreux techniciens IT 😎💪