Facilitez-vous la vie avec WVDAdmin

Combien de clics faut-il réellement pour capturer proprement une image AVD, la versionner dans une galerie, puis redéployer 10 hôtes sans erreur ? Si vous administrez Azure Virtual Desktop au quotidien, vous connaissez la réalité : le portail Azure fonctionne très bien… mais l’opérationnel est répétitif, chronophage, et parfois fragile. Image → Sysprep → Snapshot → Galerie → Version → Déploiement → Intégration au pool → Vérifications. Et on recommence !

Azure Virtual Desktop a énormément évolué ces dernières années. Builder, améliorations ARM/Bicep, automatisations natives… mais malgré tout, dans la vraie vie d’un admin ou d’un architecte, on cherche surtout à raccourcir la boucle opérationnelle.

C’est exactement là que WVDAdmin entre en jeu. Un outil communautaire, simple, direct, qui ne cherche pas à réinventer AVD, mais à compresser le quotidien.

Et pour vous guider plus facilement dans cet article très long, voici des liens rapides :

Qu’est-ce que WVDAdmin ?

WVDAdmin est un outil graphique communautaire pour administrer Azure Virtual Desktop (anciennement Windows Virtual Desktop) via une application installée localement. WVDAdmin a été développé par Marcel Meurer et est disponible via son blog ITProCloud.

Qui est Marcel Meurer ?

Marcel Meurer est un expert allemand spécialisé dans Azure Virtual Desktop (AVD) et l’automatisation Azure. Il a reçu une double nomination en tant que Microsoft MVP, et il fait partie de ce prestigieux programme depuis plus de onze années.

Marcel Meurer est également le créateur de Hydra for Azure Virtual Desktop. Nous reviendrons sur Hydra for Azure Virtual Desktop dans un prochain article.

Que peut-on faire avec WVDAdmin ?

Une bonne manière de comprendre WVDAdmin est la suivante : il ne cherche pas à « remplacer Azure Virtual Desktop », mais à compresser la boucle opérationnelle (image → déploiement → exploitation → mise à jour) en moins de clics et dans une interface unique.

Basé sur sa documentation officielle, voici un résumé de ce que WVDAdmin peut faire pour vous.

  • Workflow d’image golden : création d’images à partir d’un « golden master » sans détruire la VM maître/modèle, avec gestion de Sysprep, des applications modernes et des opérations de nettoyage.
  • Déploiement (rollout) : déploiement de plusieurs hôtes de session, choix des tailles de VM par déploiement, prise en charge des disques éphémères, et options telles que « AAD only / joint à MEM/Intune » (selon l’auteur).
  • Opérations sur les ressources AVD : création, ajout et suppression de pools d’hôtes, groupes d’applications, espaces de travail et hôtes de session.
  • Opérations sur les sessions : déconnexion, délogage, envoi de messages et shadowing.
  • Opérations générales sur les VM Azure : inventaire des VM sur plusieurs abonnements (via Azure Resource Graph, avec un délai signalé), exécution de scripts à distance, snapshots/restaurations, et même réduction de la taille des disques OS.
  • Opérations en simultané : WVDAdmin supporte plusieurs tâches en simultané afin de gagner en efficacité.

WVDAdmin vs Hydra for AVD ?

WVDAdmin est à l’origine un outil communautaire gratuit pour Azure Virtual Desktop. WVDAdmin est intéressant lorsqu’on cherche une méthode rapide pour faire de l’imaging et du déploiement AVD. C’est une application Windows utilisée de manière interactive, donc sans automatisation planifiée.

Hydra en est une évolution plus avancée et orientée production (autoscaling, multi-tenant, orchestration plus poussée, etc.). Hydra apporte l’automatisation complète, l’optimisation des coûts, le monitoring via l’Hydra Agent, et supporte aussi des scénarios Azure Local.

WVDAdmin est donc un choix pertinent si l’on veut éviter de déployer des ressources supplémentaires Azure comme celles nécessaires pour Hydra.

CritèreWVDAdminHydra
TypeOutil GUI localPlateforme SaaS
Autoscaling
Multi-tenantLimitéOui
CoûtGratuitPayant
Infrastructure supplémentaireNonOui

Est-ce que WVDAdmin est toujours maintenu ?

L’outil WVDAdmin existe maintenant depuis au moins 5 ans. WVDAdmin est toujours maintenu, mais n’est peut-être plus aussi activement développé comme avant (les efforts d’amélioration sont principalement concentrés sur Hydra).

Il reçoit encore des mises à jour, principalement pour prendre en compte les nouveaux SKUs Azure, corriger des bugs ou assurer la compatibilité avec certains changements d’API :

Quoi qu’on en dise, plusieurs dernières releases de WVDAdmin sont sorties en 2026, avec une dernière version publiée le 06/02/2026 :

Combien coûte WVDAdmin ?

Là encore nous pouvons lui dire merci, car WVDAdmin un outil licence-free pour Azure Virtual Desktop, utilisable sans frais supplémentaires pour l’administration des ressources AVD via une application Windows.

Comment WVD accède aux ressources du tenant ?

WVDAdmin accès aux ressources Azure par le biais d’un principal de service, protégé par un secret. Celui-ci dispose de permissions sur AVD et sur les ressources Azure. L

’objectif est notamment d’éviter toute confusion lorsque l’administrateur IT est un compte invité dans un tenant client et doit changer régulièrement de tenant.

Voici d’ailleurs un exemple de fonctionnement dans le cadre de plusieurs tenants :

Comment WVDInfra marche ?

Au travers de sa chaîne YouTube, Marcel a mis à disposition une playlist spécifiquement consacré à WVDInfra, de son installation à différentes qu’il peut faire sur votre environnement Azure Virtual Desktop :

Et enfin, comme toujours, je vous propose dans la suite de cet article d’effectuer ensemble un pas à pas pour couvrir l’installation de WVDInfra, sa mise en service, la capture d’une image Windows 11 custom et enfin la création d’une hôte dans un environnement AVD :

Etape 0 – Rappel des prérequis :

Pour réaliser ce test sur WVDInfra, il vous faudra disposer de :

  • Un abonnement Azure valide
  • Un tenant Microsoft

Commençons par l’installation de WVDInfra sur votre poste local.

Etape I – Installation de WVDInfra :

Utilisez la page officielle de WVDAdmin pour accéder au téléchargement :

Lancez l’installation en spécifiant le contexte d’utilisation de celle-ci, puis cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

Cliquez sur Suivant pour démarrer l’installation :

Une fois l’installation réussie, cliquez ici pour fermer :

Cliquez sur WVDAdmin présent dans dans le menu Démarrer :

WVDAdmin se charge et n’affiche pour le moment aucune ressource ou information de l’environnement Azure :

Pour cela WVDInfra vous demande les informations suivantes sur l’onglet « Welcome » :

  • l’ID de tenant
  • le secret client
  • l’ID client du principal de service

Mais avant d’aller plus loin, il est nécessaire de configurer ce nouveau principal de service sur votre tenant afin de donner à WVDInfra un moyen de s’y authentifier :

Etape II – Configuration Entra :

La création du principal de service via le centre d’administration Entra :

Nommez votre application, puis cliquez ici :

Pour permettre la résolution des utilisateurs et groupes, des permissions doivent être rajoutées :

Cherchez la permission suivante, puis cliquez sur Ajouter :

WVDInfra a besoin d’un consentement administration afin d’accorder les permissions demandées au nom de toute l’organisation :

Vérifiez le changement de statut des permissions :

Le client secret est l’équivalent d’un mot de passe pour l’application. Il sert à authentifier l’application lorsqu’elle demande un token OAuth à Microsoft Entra ID. Ajoutez un secret à votre application WVDInfra :

Copiez la valeur de votre secret immédiatement lors de sa création, car il ne sera plus affiché par la suite :

L’ID d’application (client) et l’ID du tenant doivent être conservés pour la suite :

Collez ces trois valeurs dans l’interface de WVDInfra, sauvegardez, puis lancez un rechargement de l’inventaire :

A ce stade, WVDInfra a bien accès au tenant mais pas encore au ressource Azure :

En l’état, l’application WVDInfra a le service principal, avec qui il peut s’authentifier avec son client ID et son secret, mais n’a par défaut aucun droit sur les ressources Azure. Il peut demander un token, mais ce token ne lui permet rien tant qu’on ne lui attribue pas un rôle RBAC.

Etape III – Configuration Azure :

WVD infra doit modifier des ressources Azure. Et attribuer un rôle RBAC au service principal WVDInfra revient à dire : “Cette application a le droit de faire telle action, sur tel périmètre.”

Pour cela, configurez avec le rôle RBAC de Contributeur sur l’application WVDInfra :

Sur WVDInfra, relancez un rechargement afin de voir apparaître l’inventaire des groupes de ressources et des VMs :

Etape IV – Test de capture d’une VM :

Microsoft recommande que tous les hôtes de session d’un pool soient issus de la même image afin de garantir une expérience utilisateur cohérente. WVDAdmin positionne l’imagerie comme une fonctionnalité centrale : création d’images à partir d’un golden master sans détruire la VM source.

Créez une machine virtuelle Azure :

Créez également une galerie d’images :

Sur WVDInfra, lancez la création d’image depuis votre machine virtuelle :

Les journaux de WVDInfra commence par montrer la création de ressources Azure temporaires (snapshot, VM temporaire, disque temporaire) :

Par la suite, les journaux de WVDInfra montre la généralisation de l’image, la création de la version dans la galerie :

Enfin, les journaux de WVDInfra montre le nettoyage complet des ressources Azure temporaires :

En quelques clics, nous avons une image prête à être déployée sur votre environnement Azure Virtual Desktop. La suite des étapes se fait toujours dans WVDInfra.

Etape V – Test de création d’un hôte :

Avant cela, créez les objets AVD de base (pools d’hôtes, groupes d’applications, espaces de travail) :

Retournez sur WVDInfra, sélectionnez la version d’image, puis lancez le processus de création d’hôtes AVD :

Renseignez le formulaire de déploiement :

  • le nommage des VM,
  • le nombre d’hôtes,
  • la version d’image,
  • le pool d’hôtes,
  • le sous-réseau,
  • les paramètres de disque,
  • la taille des VM,
  • les options de jointure Entra / Intune.

Puis lancez la création des machines virtuelle AVD :

Les journaux confirment la création de la VM et de son intégration au pool d’hôtes :

Constatez sur le portail Azure la création de ressources :

Votre pool d’hôtes affiche la nouvelle capacité disponible :

Dams mon cas, l’hôte de session apparait comme appareil joint à Entra ID :

Cette hôte de session est également enrôlés dans Intune :

Un test en session (nom de machine, version de l’OS, application installée) valide le bon fonctionnement :

Etape VI – Fonctionnalités annexes :

WVDAdmin couvre également beaucoup d’opérations IT sur les machines virtuelles Azure :

  • démarrage, arrêt, redémarrage, hibernation
  • changement de taille de la VM

Certains actions particulières, comme l’exécution de scripts, sont possibles :

Ou encore la création de snapshot ou le redimensionnement de disque OS :

D’autres sont propres aux machines virtuelles AVD :

  • gestion du mode drain
  • actions sur les sessions
  • suppression complète de l’hôte

Il permet aussi de modifier les affectations se font au niveau des groupes d’applications :

La gestion des applications publiées aussi possible :

Mon avis personnel

Je vais être clair. WVDAdmin n’est pas un remplacement du portail d’Azure Virtual Desktop.
Ce n’est pas non plus une solution d’architecture d’entreprise complète. C’est un accélérateur opérationnel.

Et dans certains un contextes, WVDAdmin est redoutablement efficace :

  • Lab
  • PoC
  • Environnement SMB
  • Client où l’on veut éviter de déployer une surcouche d’automatisation complète
  • Équipe IT réduite

La capture d’image est propre, le déploiement est rapide, L’interface centralise ce que le portail disperse. Besoin de plus ? Hydra for AVD sera peut être votre réponse.

Conclusion

Azure Virtual Desktop continue de se moderniser, les outils natifs progressent et l’automatisation devient centrale.

Mais entre la théorie et le terrain, il y a toujours l’opérationnel quotidien. WVDAdmin n’a jamais prétendu pas transformer votre architecture, mais il simplifie votre quotidien. Il évite les allers-retours dans le portail, réduit la friction et accélère les tâches répétitives.

Dans un monde où l’on parle beaucoup d’IA, d’automatisation avancée et de plateforme complexe, parfois un bon outil bien conçu fait simplement gagner du temps.

Et en tant qu’architecte AVD, je préfère toujours une solution claire, maîtrisée et comprise, plutôt qu’une sur-ingénierie inutile.

WVDAdmin ne remplace pas une stratégie, il optimise l’exécution. Et ça, pour un admin AVD, ça a énormément de valeur.

Opal sur Windows 365 : quand un agent IA dispose enfin d’un vrai poste de travail

Ces derniers mois, on parle beaucoup d’agents IA, d’automatisation et de “copilots capables d’agir”. Mais dans la réalité du terrain, dès qu’un processus sort des APIs bien propres et documentées, tout s’arrête très vite. Formulaires web sans connecteurs, portails fournisseurs legacy, applications internes sans automatisation possible… C’est exactement là que, jusqu’à présent, l’IA savait quoi faire… mais ne pouvait rien exécuter. C’est précisément ce fossé entre “savoir quoi faire” et “pouvoir le faire” qu’Opal vient combler.

Avec Opal, Microsoft franchit un cap important : pour la première fois, un agent IA ne se contente plus de raisonner ou de proposer des actions : il dispose d’un véritable poste de travail Windows pour les exécuter.

Dans cet article, je vous propose un retour sur Opal, son lien étroit avec Windows 365, son mode de fonctionnement, ses limites actuelles, et surtout dans quels cas d’usage réels cette approche prend tout son sens.

Qu’est-ce que le projet Opal dans Microsoft 365 Copilot ?

Annoncé durant l’Ignite 2025, Opal est une nouvelle capacité de Copilot orientée vers l’automatisation de tâches concrètes et complexes, au-delà de la simple génération de texte ou de réponses. Cette fonctionnalité expérimentale est disponible via le programme Frontier de Microsoft 365 Copilot.

Opal n’est pas un nouveau Copilot de plus :

  • Opal n’est ni un chatbot, ni un simple outil de RPA, ni une extension de Power Automate.
  • C’est un agent IA qui opère dans un environnement Windows réel, avec les mêmes contraintes qu’un utilisateur humain.

Pour faire simple, il s’agit d’un agent IA qui exécute pour vous des tâches réelles et multi-steps dans un environnement sécurisé, en utilisant un PC cloud Windows 365 pour interagir avec des applications web ou systèmes comme le ferait un humain (cliquer, remplir des formulaires, naviguer, etc.).

Toutes les organisations sont confrontées au défi des tâches manuelles répétitives, qui prennent un temps précieux et les détournent de leurs priorités stratégiques, de leur créativité et de leurs activités à fort impact.

Pensez au temps nécessaire pour rassembler des informations provenant de plusieurs sites et outils dans le cadre d’un audit de conformité, pour intégrer de nouveaux employés avec des commandes d’équipement et des accès au système, ou pour valider des bons de commande.

Toutes ces tâches importantes doivent être accomplies, et c’est précisément le type de travail pour lequel Opal a été conçu.

Microsoft Techcommunity

Microsoft met également une FAQ disponible juste ici.

Dans quels cas Opal peut être utile ?

Les entreprises disposent encore de dizaines d’applications sans API, sans connecteur et sans automatisation possible. Opal cible précisément ce vide. Quand aucune API n’existe, Power Automate s’arrête. Opal, lui, continue via l’interface utilisateur.

Opal n’est ni Power Automate, ni un RPA classique : c’est un agent IA capable d’interagir avec un PC cloud Windows 365 :

  • Dès qu’un processus nécessite de cliquer dans une application web ou legacy
  • Télécharger une facture depuis un portail fournisseur, la renommer, puis la déposer dans SharePoint est un scénario typique Opal.

Par contre, Opal n’est pas conçu pour les processus temps réel ni transactionnels critiques.

Quel est le lien entre Windows 365 et Opal ?

Microsoft 365 Copilot sait raisonner, analyser et décider, mais il ne peut pas exécuter d’actions réelles sans poste de travail. Le lien entre Windows 365 et Opal est alors fondamental : Opal a besoin d’un véritable environnement Windows pour pouvoir agir.

Les actions Opal sont exécutées dans un Cloud PC dédié, sans accès direct au poste de l’utilisateur. Le PC cloud Windows 365 sert donc d’environnement sécurisé et isolé pour les actions de l’agent.

On peut résumer l’architecture ainsi :

  • Windows 365 = le corps
  • Opal = les mains
  • Copilot = le cerveau

Ici, Windows 365 fournit à votre IA :

  • une isolation complète du poste de l’utilisateur
  • un PC cloud dédié à l’agent IA
  • un navigateur Edge réel
  • un système de fichiers Windows
  • une session utilisateur contrôlée
  • une identité Microsoft Entra associée

Pourquoi Microsoft n’utilise pas un simple navigateur sandbox ?

Un simple navigateur sandboxé ne permet pas de couvrir les scénarios ciblés par Opal.
Opal n’est pas conçu pour exécuter une action isolée, mais pour enchaîner des tâches complexes, multi-applications et persistantes dans le temps.

Les agents Opal doivent parfois :

  • télécharger et stocker des fichiers localement,
  • ouvrir et manipuler des fichiers Excel, PDF ou CSV,
  • interagir avec plusieurs onglets et fenêtres,
  • conserver un état entre plusieurs étapes,
  • utiliser une identité utilisateur complète (cookies, sessions, certificats),
  • fonctionner avec des extensions navigateur ou des paramètres Edge spécifiques.

Un navigateur isolé et éphémère ne permet pas cela de manière fiable. Un système d’exploitation Windows complet est donc nécessaire pour garantir la continuité, la stabilité et la sécurité de l’exécution.

À quoi à accès Opal sur ces postes Windows 365 ?

Par défaut, Opal n’a accès à aucun site web.

Toute navigation sortante est bloquée tant qu’aucune URL n’a été explicitement autorisée dans le portail d’administration Opal. Sans cette configuration :

  • l’agent ne peut pas ouvrir de site web,
  • il ne peut pas effectuer de recherche internet,
  • il ne peut pas se connecter à une application SaaS.

Ce modèle repose sur une approche deny by default, essentielle pour limiter le périmètre d’action de l’agent IA et éviter toute dérive ou accès non maîtrisé.

Chaque URL autorisée devient ainsi un périmètre fonctionnel clairement défini pour l’agent Opal.

Quels sont les prérequis pour activer Opal sur son tenant ?

Les prérequis exacts ne sont pas encore officiellement figés par Microsoft. À ce jour, Opal est uniquement disponible :

  • dans le cadre du programme Microsoft 365 Copilot Frontier,
  • avec une licence Microsoft 365 Copilot active pour les utilisateurs concernés.

Les dépendances techniques observées incluent également :

  • Microsoft Intune (gestion des Cloud PC),
  • Windows 365 (provisionnement des postes agents),
  • Microsoft Entra ID (identité et accès),
  • Microsoft Graph (onboarding automatisé).

Combien coûte Opal ?

Microsoft n’a communiqué aucun tarif dédié pour Opal à ce stade. Opal n’est pas facturé comme une licence distincte.

Il est inclus, pour le moment, comme fonctionnalité expérimentale du programme Frontier, accessible uniquement avec une licence Microsoft 365 Copilot valide.

Le coût indirect à prendre en compte reste principalement :

  • les licences Windows 365 associées aux Cloud PC agents,
  • les licences Intune,
  • et la licence Microsoft 365 Copilot par utilisateur.

Où les utilisateurs trouvent-ils Opal ?

Les utilisateurs ne trouvent pas Opal comme une application classique dans leur menu Microsoft 365. Opal apparaît dans l’interface Copilot, une fois que l’administrateur a activé la fonctionnalité sur le tenant.

L’URL directe est https://opal.frontier.microsoft365.com peut aussi être utilisée.

Pas de promesses marketing ici : uniquement ce que j’ai pu tester, observer et configurer moi-même sur un tenant Microsoft 365 étape par étape :

Etape 0 – Rappel des prérequis :

Avant toute chose, assurez-vous :

  • d’avoir accès au programme Frontier,
  • de disposer d’un compte Administrateur général,
  • d’avoir Intune et Windows 365 fonctionnels sur le tenant,
  • d’avoir des licences Microsoft 365 Copilot assignées.

Etape I – Configuration du tenant :

Connectez-vous au portail d’administration de Microsoft 365, et depuis le menu de gauche, ouvrez les paramétrages de Copilot, puis sélectionnez Opal (Frontier) dans la liste des fonctionnalités Copilot :

Dans le panneau de configuration Opal, l’option Specific user groups permet de restreindre l’accès à Opal à des groupes Microsoft Entra ID précis, puis sauvegardez :

Etape II – Configuration d’Opal :

Puis cliquez ici pour vous rendre sur le portail d’administration d’Opal afin de continuer la suite de la configuration.

https://opal.frontier.microsoft365.com/admin

Si le message suivant apparaît, vérifiez que vous êtes bien authentifié avec un compte administrateur général, attendez quelques minutes, puis revenez sur le même portail :

Une fois sur le portail d’administration d’Opal, avant d’aller plus loin, prenez le temps de lire le message d’avertissement affiché en évidence :

Afin de mettre en route Opal sur votre tenant Microsoft, téléchargez le script PowerShell suivant via un clic droit :

Le script OpalOnboard.ps1 automatise l’onboarding d’Opal dans un tenant Microsoft 365 via Microsoft Graph, il :

  • installe/charge les modules Microsoft Graph nécessaires, puis se connecte à Graph avec des droits d’admin,
  • crée (si absents) 8 service principals (Opal, Windows 365, AVD, Windows Cloud Login, etc.) pour que le tenant ait les identités applicatives requises,
  • crée un groupe dynamique de devices (“Opal App Device Group”) basé sur une règle de type enrollmentProfileName == « Windows 365 Opal Device Pool »,
  • configure le service principal “Windows Cloud Login” pour activer le RDP et cibler ce groupe de devices,
  • télécharge une policy Edge au format JSON depuis une URL Microsoft, la crée côté Intune (Settings Catalog), puis assigne la policy au groupe de devices.

Sur votre poste local, installez et ouvrez PowerShell 7 :

winget search --id Microsoft.PowerShell

Ouvrez PowerShell 7 avec les droits d’administrateur, exécutez le script, confirmez l’action d’exécution, puis laissez-vous guider :

.\OpalOnboard.ps1

Après l’installation de module, le script se connecte à votre tenant grâce à un compte d’administrateur :

Acceptez les permissions nécessaires :

Si l’erreur suivante apparaît, fermez puis rouvrez simplement PowerShell :

Confirmez les actions d’exécution de création :

  • Création de principaux de services, si absents :
    • 03b184b5-8cb6-45d1-bef1-10db52790f06 Opal – Primary App
    • 90c719d1-2849-4e57-a1d1-0c9edb406be2 Opal Native (On-box agent)
    • 0af06dc6-e4b5-4f28-818e-e78e62d137a5 Windows 365
    • 9cdead84-a844-4324-93f2-b2e6bb768d07 Azure Virtual Desktop
    • a85cf173-4192-42f8-81fa-777a763e6e2c AVD Client
    • 50e95039-b200-4007-bc97-8d5790743a63 AVD ARM Provider
    • 270efc09-cd0d-444b-a71f-39af4910ec45 Windows Cloud Login
    • 351add99-7ff7-4e1f-870f-f98b509209c2 Cloud Device Platform
  • Création d’un groupe dynamique de machines :
    • Nom ame: Opal App Device Group
    • Type: groupe de sécurité
    • (device.enrollmentProfileName -eq « Windows 365 Opal Device Pool »)
  • Configuration du Windows Cloud Login avec notre nouveau groupe de machines :
  • Création de la police Microsoft Edge via Intune :
  • Assignation de la police au groupe dynamique de machines :

Une fois le processus correctement terminé, le message suivant apparaît :

Si cela n’est pas automatique, cliquez sur le bouton de rafraîchissement afin de constater la validation de cette étape :

Enfin, lancez la dernière étape d’onboarding :

Attendez quelques minutes la fin de l’étape suivante :

Quelques minutes plus tard, constatez le succès final de l’étape d’onboarding, puis cliquez sur Suivant :

Une fois l’onboarding technique terminé, vous devez configurer le pool de Cloud PC Windows 365 qui sera utilisé par Opal pour exécuter les tâches.

Etape III – Configuration du pool de machines Windows 365 :

Quelques points importants à retenir :

  • Le Cloud PC est le poste de travail de l’agent Opal, pas celui de l’utilisateur.
  • Toutes les actions (navigation, clics, téléchargements) sont exécutées dans ces Cloud PC Windows 365.
  • Les restrictions d’accès aux sites web permettent de contrôler précisément le périmètre d’action de l’agent.

Cette étape se réalise encore depuis le portail d’administration Opal.

Cette première section permet de définir où seront hébergés les Cloud PC et combien de machines Windows 365 seront créées. Il est recommandé d’utiliser la même région que vos utilisateurs Microsoft 365 :

La création du pool de machines peut prendre plusieurs minutes. Vous pourrez suivre l’état d’avancement directement dans cette section. Ce pictogramme vous indique l’état en cours du provisionnement, ou du re-provisionnement quand un traitement Opal est terminé :

Environ 30 minutes plus tard, les machines Windows 365 sont provisionnées sur votre tenant :

Vous pouvez même retrouver ces nouvelles machines Windows 365 sur votre portail Intune :

Le modèle de machines Windows 365 est d’ailleurs spécifique à ce service d’IA :

Comme attendu, le groupe dynamique de machines Windows 365 regroupe bien celles-ci :

Et la police créée via le script d’onboarding s’affecte bien sur les machines Windows 365 :

De retour sur la console d’administration, ajoutez le ou les sites auxquels les machines auront accès pour effectuer leurs tâches. Dans mon test, je vais ajouter le site suivant :

https://computerusedemos.blob.core.windows.net

L’écran Starters permet de créer des actions prédéfinies proposées aux utilisateurs d’Opal. Un starter correspond à une instruction prête à l’emploi, associée à un site web précis, que l’utilisateur pourra lancer en un seul clic :

Une fois un premier Starter créé, cliquez sur Suivant :

Microsoft recommande de créer un profil Enrollment Status Page (ESP) personnalisé, spécifiquement pour les machines Opal. Ce profil permet notamment de :

  • réduire le temps d’initialisation du Cloud PC,
  • éviter les écrans ESP bloquants,
  • empêcher l’attente d’applications non nécessaires.

Le profil ESP doit être assigné aux appareils correspondant au pool Opal, à l’aide du critère :

enrollmentProfileName = "Windows 365 Opal Device Pool"

Une fois la configuration entièrement complétée, cliquez ici pour terminer le processus :

La suite consiste désormais à créer vos premiers scénarios métier afin de transformer Opal en véritable agent opérationnel capable d’exécuter des tâches concrètes sur des applications web réelles.

Etape IV – Premiers tests d’Opal :

L’URL pour utiliser Opal est celle-ci :

https://opal.frontier.microsoft365.com

Il est aussi possible de retrouver Opal depuis la page d’accueil de Copilot :

Sur Opal, saisissez le prompt suivant afin d’effectuer plusieurs actions, puis cliquez sur Démarrer :

Navigate to https://computerusedemos.blob.core.windows.net/web/Contoso/invoice-manager.html. Filter the invoices by selecting "Last 24 Hours" to find the most recent invoice. Open the PDF of the most recent invoice. In a new browser tab, go to:
https://computerusedemos.blob.core.windows.net/web/Contoso/index.html Fill out the invoice submission form using the data extracted from the PDF. Submit the form without asking for confirmation.

Opal commence par se connecter à une des machines Windows 365 préalablement provisionnées :

Opal attend ensuite que Windows 11 finalise sa configuration OS :

Si besoin, cliquez sur l’image de la VM pour avoir plus de détail. Comme ici, Edge s’ouvre et affiche le site web contenant les factures :

La dernière facture est ouverte pour y récupérer toutes les informations :

Un nouvel onglet s’ouvre dans Edge afin de saisir la nouvelle facture dans le système de comptabilité :

Une fois la saisie complète, une notification apparaît à la fin du traitement de saisie :

Opal compare l’état obtenu aux actions demandées :

Une dernière phase de revue est déclenchée afin que l’utilisateur puisse contrôler le travail effectué :

L’utilisateur n’a qu’à confirmer pour que le travail soit considéré comme terminé :

Afin de vous faire une meilleure idée du traitement effectué par Opal, le voici en fonctionnement :

Etape V – Quelques remarques sur Opal :

Au travers de différents tests, plusieurs points méritent d’être soulignés :

  • Sans finalisation de la configuration d’Opal, le message suivant apparaît pour les utilisateurs :
  • Sans licence Microsoft 365 Copilot, l’accès à Opal retourne une erreur 403 :
  • Après chaque traitement, la machine Windows 365 utilisée est réinitialisée et repart sur un état propre :
  • Il faut attendre environ 15 minutes avant que la machine soit de nouveau disponible pour un autre traitement :
  • Le bouton Pause permet de suspendre temporairement l’exécution sans annuler le scénario, tout en conservant le contexte courant. Cela est très utile si l’utilisateur souhaite reprendre la main quand l’agent part dans une mauvaise direction :
    • l’agent arrête immédiatement d’exécuter des actions (clics, saisies, navigation, appels d’outils)
    • le contexte et l’état courant sont conservés (où il en est dans la tâche)
  • Opal peut décider de s’arrêter de lui-même s’il rencontre une situation ambiguë ou non résoluble, et attend alors une instruction humaine.
  • Durant la phase de traitement d’Opal, 3 autres actions sont possibles :
    • Répéter la requête initiale : Cette action relance exactement le même job depuis le début, en réutilisant la requête initiale, les mêmes instructions et le même contexte de départ. C’est comme cliquer sur “Rejouer le scénario”, sans modifier quoi que ce soit.
    • Terminer le travail : Cette action met fin au job en cours et empêche toute poursuite de ce run, mais le job reste disponible dans l’interface.
    • Supprimer le travail : Le job n’est plus visible ni relançable, mais cela ne désactive pas automatiquement un trigger externe (mail, événement, etc.) s’il existe.

Conclusion

Opal marque une rupture importante dans l’approche de l’automatisation chez Microsoft.
Là où Power Automate s’arrête faute d’API, Opal continue grâce à un véritable poste de travail Windows 365 piloté par une IA.

Nous ne sommes plus dans la simple génération de contenu, mais dans l’exécution réelle de tâches métier, au plus proche du travail humain.

Les premiers usages montrent un potentiel considérable, à condition de bien cadrer les périmètres, les accès et les scénarios. On ne parle pas encore d’autonomie totale, mais d’un changement profond dans la manière dont une IA peut interagir avec des systèmes existants.

Opal n’est pas encore prêt pour des processus critiques temps réel, mais il ouvre clairement la voie à une nouvelle génération d’agents opérationnels.

Azure Virtual Desktop hybride + SSO

Azure Virtual Desktop est souvent présenté comme une solution offrant un Single Sign-On “natif”. Dès que l’on sort d’un environnement cloud-only pour entrer dans un contexte hybride, les mécanismes d’authentification deviennent toutefois plus complexes, et parfois déroutants. Entre Microsoft Entra ID, Active Directory, Kerberos, PRT, Seamless SSO et Cloud Kerberos Trust, il est facile de confondre des briques aux noms proches, mais qui n’interviennent ni au même moment ni au même niveau.

Dans un précédent article, j’avais détaillé la mise en place du SSO Azure Virtual Desktop dans un environnement cloud-only.

Dans cet article, j’ai volontairement changé de contexte pour travailler sur un environnement hybride. L’objectif de cet article est de répondre aux trois questions suivantes :

  • Clarifier les mécanismes d’authentification (PRT, Seamless SSO, Kerberos, etc.)
  • Montrer pas à pas pourquoi certaines étapes sont indispensables pour obtenir un SSO réellement transparent dans AVD.
  • A quoi sert le Seamless SSO disponible dans Entra Connect Sync ?

Avant d’aborder la configuration et les tests, il est utile de poser le cadre : comprendre quels mécanismes d’authentification sont utilisés, à quel moment, et pourquoi certains fonctionnent seuls alors que d’autres doivent être combinés.

Cette FAQ a pour objectif de lever les confusions les plus fréquentes autour des tokens, du Kerberos, et du Single Sign-On dans un environnement Microsoft Entra hybride.

Quels sont les tokens utilisés par Microsoft Entra ID ?

Microsoft Entra ID utilise plusieurs types de tokens, chacun ayant un rôle précis :

  • Primary Refresh Token (PRT)
    • Jeton long terme
    • Spécifique à l’appareil
    • Sert à demander d’autres tokens
    • Utilisé par Windows (WAM – Web Account Manager)
  • Access Token
    • Jeton court terme
    • Présenté aux applications (API, Office, AVD…)
    • Contient les claims utilisateur
  • Refresh Token
    • Permet de renouveler un Access Token
    • Généralement géré automatiquement par le système

Qu’est-ce que le Primary Refresh Token (PRT) ?

Dans le monde de Microsoft, le PRT est un jeton émis par Microsoft Entra ID lorsqu’un appareil est Microsoft Entra Joined ou Microsoft Entra Hybrid Joined.

Un jeton d’actualisation principal (PRT) est un artefact clé de l’authentification Microsoft Entra dans les versions prises en charge de Windows, iOS/macOS, Android et Linux. Un PRT est un artefact sécurisé spécialement émis aux répartiteurs de jetons microsoft pour activer l’authentification unique (SSO) sur les applications utilisées sur ces appareils.

Microsoft Learn

Le PRT est stocké localement sur la machine et sert de jeton racine pour :

  • obtenir des tokens d’accès OAuth 2.0
  • s’authentifier automatiquement aux services cloud Microsoft
  • éviter toute ressaisie de mot de passe pour les applications modernes

Concrètement, le PRT permet :

  • l’ouverture automatique de session dans Edge
  • l’authentification transparente à Office, Teams, OneDrive
  • l’utilisation de Windows App / Azure Virtual Desktop web

Point important : le PRT n’est pas Kerberos et ne permet pas, à lui seul, d’ouvrir une session Windows sur une machine Active Directory.

Pourquoi le PRT ne suffit-il pas pour Azure Virtual Desktop en mode Hybride ?

Dans un environnement Azure Virtual Desktop en mode Hybride, il y a deux niveaux d’authentification distincts :

  1. Accès au service AVD (broker / portail)
    → Authentification Microsoft Entra ID
    → Le PRT suffit
  2. Ouverture de la session Windows sur le session host
    → Authentification Active Directory
    → Un TGT Kerberos est obligatoire

Dans un environnement Microsoft Entra Hybrid Joined, le PRT est présent, mais le TGT Kerberos n’est pas automatiquement délivré par Entra.

Cela permet de comprendre pourquoi une seconde authentification Active Directory est fréquemment observée dans de nombreux environnements AVD, après une première authentification Entra.

Qu’est-ce qu’un TGT Kerberos Active Directory ?

Le Ticket Granting Ticket (TGT) est un jeton Kerberos délivré par un contrôleur de domaine Active Directory.

Il est obtenu :

  • lors de l’ouverture de session Windows
  • après une authentification réussie auprès de l’AD

Le TGT permet ensuite :

  • d’accéder aux ressources Active Directory
  • d’obtenir des tickets de service (CIFS, LDAP, HTTP, etc.)
  • d’ouvrir une session Windows locale ou distante

Sans TGT Kerberos, l’ouverture d’une session Active Directory n’est pas possible.

Qu’est-ce que Microsoft Entra Kerberos (Cloud Kerberos Trust) ?

Microsoft Entra Kerberos est le mécanisme qui permet à Microsoft Entra ID de :

  • générer un TGT Kerberos Active Directory
  • à partir d’une authentification cloud
  • sans nécessiter ADFS

Techniquement :

  • un objet Kerberos spécial est créé dans l’Active Directory
  • les clés sont synchronisées avec Microsoft Entra ID
  • Entra devient capable d’émettre un TGT valide pour l’AD

C’est l’élément nécessaire pour obtenir un SSO complet dans AVD en environnement hybride.

Pourquoi la jointure hybride améliore l’expérience SSO ?

Avec Microsoft Entra Hybrid Join :

  • l’appareil est reconnu par Entra
  • un PRT est délivré
  • les applications cloud utilisent un SSO moderne

En ajoutant Microsoft Entra Kerberos :

  • Entra peut aussi délivrer un TGT AD
  • Windows peut ouvrir la session sans redemande de mot de passe

On comprend alors que la combinaison du PRT et d’un TGT Kerberos est nécessaire pour obtenir un SSO transparent dans Azure Virtual Desktop.

À quoi sert la case “Single sign-on” dans Entra Connect ?

La case Single sign-on dans Microsoft Entra Connect active ce qu’on appelle Seamless SSO.

Seamless SSO repose sur :

  • Kerberos
  • le compte AD AZUREADSSOACC
  • le site autologon.microsoftazuread-sso.com

Son objectif est volontairement limité :

  • éviter la saisie du mot de passe AD
  • lors d’une authentification navigateur vers Entra ID
  • sur une machine AD-only

Il est important de distinguer Seamless SSO des autres mécanismes :

  • ne crée PAS de PRT
  • ne remplace PAS Microsoft Entra Kerberos
  • ne supprime PAS tous les écrans de login

Pour se donner une meilleure idée de cette fonctionnalité SSO spécifique, nous la testerons dans la dernière étape de cet article.

Mais commençons d’abord par tester la mise en place du single sign-on complet pour un environnement AVD de mode hybride, dont les procédures officielles sont disponibles ici et :

Etape 0 – Configuration de base :

Dans mon environnement de test, j’ai déjà configuré certains composants.

  • Un environnement Active Directory
  • Microsoft Entra Connect configuré avec
    • Password Hash Synchronization (PHS)
    • sans Single sign-on,
    • avec Hybrid Joined pour les machines Windows 10/11
    • Synchronisation de l’OU des utilisateurs AVD
    • Synchronisation de l’OU des machines hôtes AVD
  • Un environnement Azure Virtual Desktop avec deux machines virtuelles jointes à AD :

Notre environnement AVD en mode hybride est en place, commençons par un premier test.

Etape I – Test sans configuration SSO :

Avant d’aller plus loin, j’effectue déjà un premier test de connexion d’un utilisateur AVD depuis le portail web :

Une authentification AD est demandée lors de l’ouverture de la session Windows, c’est un comportement normal à ce stade car rien n’est configuré :

La commande dsregcmd /status sert à afficher l’état d’enregistrement de l’appareil auprès d’Entra ID et, concernant le PRT (Primary Refresh Token), elle fournit des informations de diagnostic sur sa présence et son état :

  • AzureAdPrt : YES / NO : Indique si un PRT est présent sur la machine pour l’utilisateur
  • AzureAdPrtUpdateTime : Date/heure du dernier rafraîchissement du PRT
  • AzureAdPrtExpiryTime : Date/heure d’expiration du PRT
  • AzureAdPrtAuthority : Autorité qui a émis le token (généralement login.microsoftonline.com).

Concernant la partie des tickets, voici ce que l’on peut aussi en déduire :

  • OnPremTgt : NO : cela indique si la session utilisateur courante ne possède pas Ticket Granting Ticket Kerberos émis par un contrôleur de domaine AD.
  • CloudTgt : YES : indique la présence d’un TGT Kerberos cloud, émis par Entra ID.

Comme on peut le constater, le PRT émis via Entra fonctionne bien pour les services Cloud, mais l’ouverture de session et l’accès à certaines ressources gérées par l’AD pourraient être restreints dans la situation actuelle.

Commençons étape par étape les changements pour arriver à une configuration complète.

Etape II – Configuration SSO du pool d’hotes AVD :

Sur le portail Azure, comme l’indique la documentation Microsoft, j’effectue la configuration SSO du host pool Azure Virtual Desktop afin d’activer “Microsoft Entra authentication for single sign-on” :

J’effectue un nouveau test avec mon utilisateur :

À ce stade, une authentification AD est encore demandée lors de l’ouverture de la session Windows :

Etape III – Création d’un objet serveur Kerberos :

Sur le serveur AD, comme l’indique la documentation Microsoft, je commence par installer le module AzureADHybridAuthenticationManagement :

# First, ensure TLS 1.2 for PowerShell gallery access.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the AzureADHybridAuthenticationManagement PowerShell module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Pour créer l’objet Kerberos Server nécessaire au Cloud Kerberos Trust, j’ai choisi l’exemple 4 de la documentation Microsoft :

  • Cet exemple exploite l’authentification moderne basée sur le User Principal Name (UPN) sans exiger de mot de passe AD explicite.
  • Il s’intègre parfaitement dans un environnement hybride sécurisé avec MFA et politiques d’accès conditionnel
  • Il évite les écueils des méthodes utilisant NTLM ou des identifiants AD en clair.
# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Je lance donc le script à la suite du précédent, en prenant soin de remplacer l’UPN par un administrateur général ou hybride :

Je vérifie le serveur Microsoft Entra Kerberos nouvellement créé à l’aide de la commande suivante :

# When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)

Enfin je constate la présence krbtgt_AzureAD utilisé par les DC pour signer les TGT Kerberos. Il s’agit d’une séparation cryptographique claire avec krbtgt dans le cadre de Kerberos émis depuis Entra :

J’effectue un nouveau test avec mon utilisateur :

Une fois le Cloud Kerberos Trust et l’authentification RDP Microsoft Entra activés, la seconde authentification Active Directory disparaît et est remplacée par un simple message de consentement Allow Remote Desktop connection :

Entra veut un consentement explicite de l’utilisateur. Ce message ne correspond pas à une authentification supplémentaire, mais à une demande de confiance entre l’utilisateur et le session host :

Si l’utilisateur clique sur Oui, ce consentement sera conservé 30 jours et ne pourra pas mémoriser plus de 15 hôtes.

L’Étape suivante consiste donc à supprimer définitivement le popup en déclarant les session hosts comme appareils de confiance dans Microsoft Entra ID.

Etape IV – Activation de l’authentification Microsoft Entra pour RDP :

Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise Azure Cloud Shell depuis le portail Azure :

J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte au permissions appropriées :

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

Je récupère l’ID d’objet pour le principal du service de connexion au Windows Cloud :

$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Je modifie la propriété isRemoteDesktopProtocolEnabled sur True :

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}

Je vérifie que la propriété isRemoteDesktopProtocolEnabled est correctement définie :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Afin de masquer la boîte de dialogue en configurant la liste des hôtes AVD approuvés, je créé un groupe dans Entra ID contenant les hôtes de sessions :

J’utilise une requête dynamique pour ajouter automatiquement mes prochains hôtes dans le groupe :

Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login.

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"
New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Enfin, je vérifie la bonne assignation du groupe :

J’effectue un nouveau test avec mon utilisateur :

Cette fois l’authentification passe sans encombre. Un TGT Kerberos AD DS (on-premises) est maintenant présent dans la session.

Cela permet d’observer que :

  • La machine est Hybrid Entra ID Joined
  • Le PRT est valide
  • Le Kerberos cloud fonctionne
  • Le Kerberos AD DS fonctionne
  • Les deux mondes coexistent simultanément dans la même session

Cette sortie correspond à un état hybride cohérent, où les mécanismes cloud et on-premises coexistent.

Pour finir, je vous propose de tester l’impact du Seamless SSO présent et configurable dans Entra Connect Sync.

Etape V – Activation du SSO d’Entra Connect Sync :

Pour cela, je décide de rajouter une troisième machine AVD :

Celle-ci est bien présente dans l’Active Directory :

Mais elle n’est pas présente dans Entra ID :

Pour ne pas perturber mes tests, je décide donc de bloquer la connexion aux deux autres VMs AVD :

J’effectue un test avec mon utilisateur :

Comme aucune configuration hybride n’est en place pour cette machine AVD, il n’y a pas de ticket TGT Kerberos émis par Entra ID, donc la seconde authentification AD est logique :

Une fois dans la session Windows, dsregcmd nous affiche les informations suivantes :

  • La machine est jointe uniquement à Active Directory on-premises
  • Elle n’est pas jointe à Entra ID
  • Elle n’est pas Hybrid Join
  • Aucun PRT
  • Aucun SSO cloud
  • Aucune authentification Entra ID
  • Une tentative d’Entra ID Join / Hybrid Join a eu lieu
    • Elle a échoué côté Entra ID
    • La machine AVD n’existe pas ou n’est pas reconnu dans le tenant

L’ouverture de la page d’authentification d’Office 365 dans Microsoft Edge me montre d’ailleurs aucune connexion SSO :

Je décide donc d’activer la fonctionnalité SSO dans Entra Connect Sync :

Une fois la configuration terminée, je constate la création de AZUREADSSOACC en tant que compte ordinateur créé dans Active Directory :

Ce dernier est créé automatiquement lors de l’activation de Seamless Single Sign-On (Seamless SSO) avec Entra ID. Le compte est utilisé par Entra ID pour :

  • établir une relation de confiance Kerberos avec l’AD on-prem
  • permettre le SSO sans saisie de mot de passe depuis des postes domain-joined vers Entra ID

J’effectue donc un nouveau test avec mon utilisateur :

Dans ce contexte, il est logique que l’authentification AD soit toujours demandée :

Une fois la session Windows ouverte, comme Seamless SSO fonctionne via l’adresse autologon.microsoftazuread-sso.com, je décide de la rajouter en tant qu’URL de l’Intranet local.

Pour cela, j’ouvre inetcpl.cpl :

Je clique sur Site dans Intranet local :

Je clique sur Avancée :

Je rajoute l’URL suivante :

https://autologon.microsoftazuread-sso.com

Toujours dans Intranet Local, je coche Connexion automatique avec le nom d’utilisateur et le mot de passe actuels :

Quelques minutes plus tard, j’ouvre Microsoft Edge et je constate l’authentification automatique de mon compte Cloud correspondant :

La présence du ticket HTTP/autologon.microsoftazuread-sso.com dans le cache Kerberos confirme que le mécanisme Seamless SSO est bien actif. Ce ticket, émis par le contrôleur de domaine à destination de Microsoft Entra ID, permet une authentification navigateur sans saisie de mot de passe.

klist

Il est important de noter que ce mécanisme n’est pas celui utilisé pour l’ouverture de session Windows dans Azure Virtual Desktop, qui repose sur un TGT Kerberos distinct délivré via Microsoft Entra Kerberos (krbtgt_AzureAD).

Conclusion

À travers ces différents tests et configurations, on constate que le Single Sign-On dans Azure Virtual Desktop hybride ne repose pas sur un mécanisme unique, mais sur une combinaison cohérente de plusieurs briques d’authentification.

Le PRT permet une authentification fluide aux services cloud, mais il ne suffit pas à lui seul pour ouvrir une session Windows dans un contexte Active Directory. C’est bien l’association du Hybrid Join, du Cloud Kerberos Trust et de l’authentification Microsoft Entra pour RDP qui permet d’aligner les mondes cloud et on-premises, et d’obtenir une expérience utilisateur réellement transparente dans AVD.

Comprendre ces mécanismes permet non seulement d’éviter des configurations incomplètes, mais aussi d’expliquer pourquoi certains scénarios fonctionnent “presque”, tout en continuant à demander une authentification supplémentaire.

FSLogix pour Entra ID !

Depuis de longues années, la communauté Azure Virtual Desktop attendait la possibilité de déployer un environnement entièrement cloud, sans dépendance à un domaine Active Directory classique ou à une architecture hybride complexe. Cette évolution permet enfin d’envisager un modèle moderne, simplifié et résolument cloud-native.

Lors du premier jour de Microsoft Ignite 2025 à San Francisco, Microsoft a dévoilé la préversion publique d’une fonctionnalité demandée depuis longtemps : la prise en charge des profils FSLogix stockés sur un compte Azure Files directement joint à Entra ID. Une étape majeure dans la modernisation de l’environnement AVD.

Au-delà du progrès technique évident (principalement la simplification de l’infrastructure) cette nouveauté transforme aussi la manière d’aborder la gestion des accès distants et des profils utilisateurs.

Elle marque le passage d’un modèle traditionnel mêlant domaine Active Directory, synchronisation, et Kerberos hybride, vers un modèle entièrement cloud-only : plus léger, plus agile et parfaitement adapté aux organisations modernes, aux partenaires externes ou encore aux environnements projet éphémères.

Cette annonce fut d’ailleurs intégrée à celle des identités externes sur AVD et Windows 365 :

Pour offrir une expérience simplifiée dans un environnement mutualisé Azure Virtual Desktop pour les identités externes, vous pouvez créer un partage de fichiers dans Azure Files afin de stocker les profils FSLogix pour ces identités.

Cette fonctionnalité est désormais disponible en préversion publique. Pour créer un partage de fichiers SMB pour les profils FSLogix pour les identités externes :

Créez un nouveau compte de stockage et un nouveau partage de fichiers configurés pour utiliser l’authentification Microsoft Entra Kerberos.(Nouveau) Lorsque vous attribuez des autorisations pour le partage de fichiers, utilisez la nouvelle page Gérer l’accès pour attribuer des listes de contrôle d’accès (ACL) au groupe Entra ID contenant vos identités externes.

Microsoft Techcommunity

Microsoft illustre également cette nouveauté avec une copie d’écran montrant la gestion native des droits NTFS d’un partage Azure Files directement depuis le portail Azure, ce qui constitue une avancée très attendue :

Qu’est-ce qu’une identité cloud-only ?

Il s’agit d’un utilisateur géré uniquement dans Entra ID, sans représentation dans un Active Directory on-prem, ni synchronisation : idéal pour des contractors, partenaires, ou utilisateurs externes.

Est-ce que FSLogix fonctionne avec ces identités externes / cloud-only ?

Oui, le support FSLogix pour cloud-only & external identities est désormais en preview, ce qui permet de gérer les profils utilisateurs de façon identique à un utilisateur « classique ».

Que change concrètement pour un architecte cloud ou un administrateur ?

Cela signifie moins de dépendances à un AD on-prem, moins de complexité, une gestion simplifiée des utilisateurs externes ou contractors, et un modèle plus cloud-native.

Plusieurs vidéos sont également disponible pour vous aider à la tâche :

Pour y parvenir, plusieurs documentations sont disponibles afin de mettre en place toute la chaîne. Le premier guide Microsoft explique comment activer Kerberos Entra sur Azure Files, tandis que le second part de ce socle et donne seulement ce qu’il faut ajouter pour FSLogix :

Je vous propose donc de passer en revue, étape par étape, l’ensemble de la configuration permettant de tester cette nouvelle fonctionnalité encore en préversion.

L’objectif est de comprendre son fonctionnement réel, ses limites et les scénarios dans lesquels elle pourra s’intégrer :

Etape 0 – Rappel des prérequis :

Pour réaliser ce test FSLogix en mode 100% Cloud-only, il vous faudra disposer de :

  • Un abonnement Azure valide
  • Un tenant Microsoft

Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une nouvel utilisateur 100% Cloud, donc non synchronisé à un environnement Active Directory.

Etape I – Préparation de l’environnement :

Création d’un utilisateur cloud-only pour préparer l’environnement sans synchronisation AD :

Mise en place du réseau virtuel qui servira de base à l’environnement Azure Virtual Desktop :

Déploiement d’un compte de stockage Azure Files Premium pour accueillir les profils FSLogix :

Activation de l’identité Microsoft Entra directement sur le compte de stockage :

Activation du support Microsoft Entra Kerberos pour gérer l’authentification :

Application des permissions par défaut via le rôle Storage File Data SMB Share Contributor :

Création du partage de fichiers pour FSLogix, avec l’identité Microsoft Entra toujours active :

Recherche de l’application d’entreprise générée automatiquement pour ce compte de stockage :

Attribution du consentement administrateur global pour autoriser l’application

Validation de l’autorisation accordée à l’application d’entreprise :

Vérification des permissions héritées depuis l’admin consent sur l’application liée au stockage :

Retrait du compte de stockage dans les polices d’accès conditionnel exigeant une MFA :

Création d’un environnement Azure Virtual Desktop avec deux machines virtuelles :

Activation du Single Sign-On directement dans les propriétés RDP :

Exécution du premier script PowerShell via Run Command pour activer la récupération du ticket Kerberos :


reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /f

Confirmation que la clé de registre est bien apparue :

Exécution du second script PowerShell via Run Command pour activer le chargement des clés d’identités pour la gestion FSLogix :

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

Vérification de la création de la clé de registre attendue dans Windows :

Application de la configuration complète FSLogix via les différentes clés de registre :

reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v FlipFlopProfileDirectoryName /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryInterval /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ProfileType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachIntervalSeconds /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v SizeInMBs /t REG_DWORD /d 30000 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VHDLocations /t REG_MULTI_SZ /d "\\cloudonlysa.file.core.windows.net\profiles" /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VolumeType /t REG_SZ /d "VHDX" /f

Vérification de la création des clés de registre attendues pour FSLogix :

Alternative via Intune pour gérer ces mêmes paramètres sans script :

Redémarrage des machines virtuelles du host pool pour appliquer la configuration :

Etape II – Test de connexion AVD :

Attente du retour en ligne des machines dans l’environnement AVD :

Activation du mode de drainage sur la seconde machine pour préparer les tests :

Connexion avec l’utilisateur de test pour valider le fonctionnement :

Observation du démarrage du service FSLogix App Services à l’ouverture de session :

Création du dossier de profil FSLogix directement dans le file share :

Présence du fichier VHDx correspondant au profil utilisateur :

Impossibilité de supprimer le fichier VHDx car il est monté et en cours d’utilisation :

Confirmation dans les logs FSLogix que le profil VHDx est correctement chargé :

Inversion du mode de drainage sur les deux machines AVD :

Reconnexion avec l’utilisateur de test pour valider la bascule du profil :

Montage d’un partage réseau pour inspecter le contenu du partage de fichier Azure :

Vérification que la permission générée pour l’utilisateur de test est bien présente :

Afin de finaliser correctement la configuration des permissions pour les profils FSLogix, il est nécessaire de les restreindre pour plus de sécurité.

Etape III – Configurations des permissions NTFS Access Control Lists :

Depuis l’explorateur Windows, je constate que certaines permissions restent visibles, alors qu’elles ne devraient être retirées pour des questions de sécurité :

Je constate également l’impossibilité de modifier les permissions directement depuis Windows ou via une commande ICACLS :

Comme l’indique la documentation Microsoft ci-dessous, tout ne semble pas encore au point :

Travis Roberts rencontre d’ailleurs le même souci que moi :

Pour configurer les Windows ACLs, il sera donc nécessaire de passer par le menu Manage Access, visible depuis un portail Azure en préversion, comme le recommande Microsoft dans la documentation :

Le bouton Manage access est alors visible juste ici :

Ce menu n’est d’ailleurs pas visible dans le portail classique d’Azure :

L’affichage des permissions NTFS Access Control Lists configurées par défaut :

Les permissions pour FSLogix doivent alors être reconfigurées comme telles :

Cela donne ceci sur le partage de fichier FSLogix :

Les tests initiaux montrent que l’intégration fonctionne correctement entre FSLogix et Azure Virtual Desktop. Toutefois, quelques écarts apparaissent encore entre la documentation Microsoft et le comportement observé dans mon environnement, ce qui mérite d’être signalé dans le cadre de cette préversion.

Pour compléter mon analyse, il est intéressant de comparer les performances (IOPS et Throughput) entre plusieurs types de stockage, notamment ceux intégrés avec Entra ID.

Etape IV – Tests de performances :

J’ai souhaité comparé les performances entre différents types de stockage afin de bien comprendre l’impact ou non des performances avec cette jointure à Entra ID :

  • Partage de fichiers sur un compte de stockage Premium joint à Entra ID
  • Partage de fichiers sur un compte de stockage Premium non joint à Entra ID
  • Disque Premium SSD v2, configuré avec 30000 IOPS et 1200 de Throughput

Pour réaliser les mesures, nous utiliserons l’outil Diskspd :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :

Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :

L’exécutable se trouve dans le sous-dossier amd64 :

Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :

  • Deux séries de tests sont conseillées pour exploiter le deux caractéristiques suivantes :
    • IOPS
    • Débit
  • Le changement entre ces deux séries se fera au niveau de la taille des blocs.

Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID :

Partage de fichiers sur un compte de stockage Premium non joint à Entra ID :

Disque Premium SSD v2 configuré avec 30000 IOPS et 1200 de Throughput :

Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-PSSDv2.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-PSSDv2.txt 

Les arguments utilisés pour diskspd.exe sont les suivants :

  • -d900 : durée du test en secondes
  • -r : opérations de lecture/écriture aléatoires
  • -w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
  • -F4 : nombre de threads max
  • -o128 : longueur de la file d’attente
  • -b8K : taille du bloc
  • -Sh : ne pas utiliser le cache
  • -L : mesure de la latence
  • -c50G : taille du fichier 50 GB
  • E:\diskpsdtmp.dat : chemin du fichier généré pour le test
  • > IOPS-AvecEntra.txt : fichier de sortie des résultats

Une fois tous les tests terminés, les résultats sont alors compilés pour les 3 stockages :

ScenarioIOPSBandwidth MB/s
Avec Entra ID12,446.88299.95
Sans Entra ID15,032.54341.17
Premium SSD v220,378.311,167.25

Les résultats montrent que le Premium SSD v2 délivre les meilleures performances dans ton environnement, avec le plus haut niveau d’IOPS et de bande passante, suivi par le scénario Sans Entra ID, puis par le scénario Avec Entra ID qui obtient systématiquement les valeurs les plus faibles.

La différence entre les scénarios avec et sans Entra ID pourrait s’expliquer par la présence d’une couche d’authentification et de gestion de profils qui ajoute des opérations supplémentaires lors des accès disque, en particulier si le système doit interroger un service distant, valider un token, ou maintenir une session d’identité pour chaque opération liée au profil utilisateur.

Même si cette charge reste faible en théorie, elle peut introduire une latence additionnelle dans un flux d’I/O intensif, ce qui réduirait mécaniquement les IOPS et la bande passante observées.

Conclusion

Le support des identités cloud-only et externes pour Azure Virtual Desktop, associé à l’intégration de FSLogix, représente une évolution majeure dans l’écosystème Microsoft. Cette approche permet désormais de déployer des environnements VDI complets sans aucune dépendance à Active Directory, tout en simplifiant considérablement l’architecture.

Cette modernisation apporte davantage de flexibilité, réduit les contraintes opérationnelles et ouvre la voie à de nouveaux scénarios cloud-native, adaptés aussi bien aux entreprises qu’aux équipes projet, partenaires ou prestataires externes.

Bien que la fonctionnalité soit encore en préversion, elle laisse entrevoir un futur où les environnements virtualisés seront plus simples, plus économiques et mieux intégrés à l’identité Microsoft Entra.

Configurez le presse-papier dans AVD/W365

Depuis la mi-2025, Microsoft renforce progressivement les paramètres de sécurité par défaut dans ses environnements Windows 365 et Azure Virtual Desktop (AVD). L’un des changements les plus visibles pour les administrateurs et utilisateurs concerne la redirection du presse-papiers (clipboard), désormais désactivée par défaut dans les nouvelles configurations.

Cette évolution, alignée avec la Microsoft Secure Future Initiative (SFI), vise à limiter les risques d’exfiltration de données et à uniformiser la posture de sécurité entre Windows 365 et AVD.
Mais concrètement, comment ce changement s’applique-t-il ? Quels paramètres contrôlent réellement le comportement du presse-papiers ? Et comment vérifier la configuration effective entre les deux couches (Propriétés RDP et stratégies GPO/Intune) ?

Dans mon précédent article, publié fin 2024, je présentais les options de durcissement du presse-papiers AVD via Intune et les propriétés RDP. Depuis mi-2025, Microsoft est passé d’une approche configurable à une approche imposée par défaut : les redirections (presse-papiers, lecteurs, USB, imprimantes) sont désormais désactivées nativement dans Windows 365 et AVD. Ce qui était un bon réflexe de sécurité devient aujourd’hui la norme.

Une excellente référence pour cette mise à jour est l’article de Dieter Kempeneers, Configure Advanced Clipboard AND Drive Redirection for AVD and Windows 365, dans lequel il détaille non seulement la désactivation par défaut des redirections (presse-papiers, lecteurs, imprimantes) sur les nouveaux hôtes AVD et les Cloud PC Windows 365, mais aussi la façon d’en réactiver certains comportements de façon granulaire.

Dans ce nouvel article, je décortique la logique de redirection RDP, les nouvelles valeurs par défaut introduites par Microsoft, et surtout, les implications pratiques pour vos déploiements et modèles AVD / Windows 365.

Depuis quand Microsoft a changé la règle du presse-papier pour Windows 365 ?

Microsoft a introduit de nouveaux paramètres de sécurité par défaut pour Windows 365 Cloud PCs le 18 juin 2025 :

Windows 365 renforce la sécurité des PC cloud en désactivant par défaut les redirections du presse-papiers, des lecteurs, des périphériques USB et des imprimantes pour tous les PC cloud nouvellement provisionnés et reprovisionnés. Cette modification minimise le risque d’exfiltration de données et d’injection de logiciels malveillants, ce qui offre une expérience plus sécurisée et s’aligne sur le principe de l’initiative Microsoft Secure Future Initiative (SFI) visant à activer et à appliquer par défaut les protections de sécurité.

Microsoft

Un message sous forme de bandeau est bien visible lors de la création d’une police de provisionnement Windows 365 :

D’ailleurs, la police de configuration de sécurité appelée Windows 365 Security Baseline et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc, de facto, le transfert de fichiers :

Est-ce que cette restriction concerne aussi Azure Virtual Desktop ?

Oui, les nouveaux pools d’hôtes Azure Virtual Desktop sont aussi concernés par ce renforcement :

Cette modification des paramètres par défaut de redirection sera bientôt effective. Afin d’aider les administrateurs informatiques à s’y préparer, une bannière pouvant être ignorée s’affichera sur la page d’accueil « Créer un pool d’hôtes » du portail Azure. Cette bannière informera les administrateurs des nouveaux paramètres par défaut pour les nouveaux pools d’hôtes et fournira des liens vers la documentation expliquant comment les remplacer en modifiant les propriétés RDP du pool d’hôtes une fois celui-ci créé.

Microsoft

Remarque : pour les pools d’hôtes existants, aucune modification ne sera apportée à la configuration de redirection en votre nom. Cependant, nous vous recommandons de renforcer la sécurité des paramètres en désactivant les redirections qui ne sont pas nécessaires. Pour effectuer ces modifications, consultez la section relative à la redirection des appareils dans la documentation sur les propriétés RDP.

Microsoft

Voici la nouvelle option de configuration RDP mise par défaut, et visible dans les propriétés du pool d’hôtes AVD :

D’ailleurs, la police de configuration de sécurité appelée Security Baseline for Windows 10 and later et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc de facto le transfert de fichiers :

Qu’est-ce que cela change pour mes futures créations AVD et Windows 365 ?

  • Pour AVD : pour tout nouveau pool d’hôtes créé après la date de changement, les redirections de presse-papier, lecteurs, USB et imprimantes seront désactivées par défaut.
  • Pour Windows 365 : idem pour tous les Cloud PCs nouvellement provisionnés ou reprovisionnés : les mêmes redirections sont désactivées par défaut.

Impact : vos modèles, templates ou polices qui s’appuyaient sur ces redirections devront être revus. Si vous aviez des scénarios utilisateur où l’on transférait facilement du contenu local vers le poste cloud, il faudra anticiper ce nouveau comportement.

Comment identifier la configuration actuelle des postes ?

Le comportement dépend de deux couches complémentaires. Le serveur RDP n’impose pas unilatéralement la redirection : il la négocie avec le client en fonction de ces deux niveaux :

  1. Le client (.rdp / Propriétés RDP AVD) détermine ce qui est demandé ou refusé pour la session. Exemple : redirectclipboard:i:0 dans les propriétés RDP d’un host pool.
  2. Le serveur (Policies / GPO / Intune) définit ce qui est autorisé ou interdit de manière globale sur la machine. Exemple : fDisableClipboard dans le registre des stratégies.

Première couche : configuration client / RDP Properties :

Ces valeurs correspondent à la configuration du service RDP. Elles sont mises à jour lorsque tu modifies les RDP Properties d’un host pool dans AVD, par exemple :

Set-AzWvdHostPool -Name "pool1" -CustomRdpProperty "redirectclipboard:i:0"

Lorsqu’une session RDP s’ouvre :

  • Le Remote Desktop Agent (ou rdpinit.exe) initialise la session avec les paramètres .rdp transmis par le broker AVD.
  • Ces paramètres ne sont pas écrits dans le registre immédiatement.

Seconde couche : configuration serveur / Polices :

Pour consulter les paramètres imposés par une stratégie locale, GPO ou Intune :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Ces valeurs représentent la couche de gouvernance :

  • Elles sont prioritaires sur les paramètres locaux et sont appliquées au démarrage du service TermService.
  • Elles déterminent ce qui est autorisé ou interdit globalement sur la machine, indépendamment des paramètres envoyés par le .rdp.

La configuration peut se faire très facilement depuis une police de configuration Intune :

Interaction entre les deux couches :

Le comportement effectif correspond toujours à la configuration la plus restrictive :

Policy (serveur)RDP Property (client/session)Résultat final
AutoriseInterdit (redirectclipboard:i:0)❌ Redirection désactivée
InterditAutorise (redirectclipboard:i:1)❌ Redirection désactivée
AutoriseAutorise✅ Redirection active

Résultats de tests : comportement réel du presse-papiers RDP

Pour mieux comprendre ces nouveaux paramètres de redirection du presse-papiers, j’ai réalisé une série de tests sur plusieurs configurations RDP (AVD et Windows 365).

Le but était de vérifier quels types de données (texte, image, HTML, binaire, etc.) pouvaient être copiés dans chaque sens selon les paramètres du serveur et du client.

Les couches de configuration RDP :

Les deux couches peuvent définir différentes valeurs, mais elles ne s’écrasent pas : le moteur RDP évalue d’abord la police, puis les propriétés RDP :

CoucheRôle
1. Configuration RDP Paramètres appliqués au niveau du service RDP local. C’est ce qu’utilise la session à l’exécution. Modifié par les propriétés RDP d’un host pool AVD.
2. Policy configuration (GPO / Intune)Paramètres de gouvernance. Écrits par une stratégie (GPO/MDM) et prioritaires sur la configuration locale.

Niveaux de granularité (SCClipLevel / CSClipLevel) :

Les valeurs SCClipLevel et CSClipLevel permettent aussi d’affiner très précisément la redirection dans chaque sens :

  • SC (Server → Client) : copier du cloud vers le poste local.
  • CS (Client → Server) : copier du poste local vers le cloud.
NiveauFormats autorisésExemple
0Aucune redirectionBlocage total
1Texte brut uniquementCopier/coller texte simple
2Texte brut + imagesExemple : capture d’écran
3Texte brut + images + RTFTexte formaté (Word, Outlook)
4+ HTMLCopier/coller depuis un navigateur

Comment cela se voit pour Windows 365 ?

Voici un récapitulatif des différents tests effectués, en modifiant les propriétés pour AVD ou Windows 365 :

Et voici le détail de ces tests avec les configurations Intune appliquées pour impacter le registre Windows :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Test A – Clipboard redirection isn’t available : Le presse-papiers est complètement désactivé côté session RDP. Aucun copier/coller ne fonctionne dans aucun sens :

Test B – Clipboard redirection is available : Le presse-papiers est activé côté session RDP. Le copier/coller fonctionne dans les deux sens :

Test C – Do not allow Clipboard redirection Disabled (fDisableClip=0). Le comportement dépend donc de la configuration du fichier .rdp, qui est activé. Le copier/coller fonctionne dans les deux sens :

Test D – Do not allow Clipboard redirection Enabled (fDisableClip=1). Blocage complet du copier/coller, même si le .rdp autorise la redirection :

Test E – Do not allow Clipboard redirection Disabled (fDisableClip=0), comme la configuration du fichier .rdp, qui est activé. Disable clipboard transfers from session host to client (SCClipLevel=0) et inversement (CSClipLevel=0). Aucun copier-coller descendant ou montant n’est possible :

Test F – Allow plain text : Autorise uniquement le texte brut (SCClipLevel=1 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement, et pas d’images ni de formats enrichis :

Test G – Allow plain text and image : Autorise texte brut + images (SCClipLevel=2 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :

Test H – Ajoute le support du Rich Text (SCClipLevel=3 / CSClipLevel=0 / fDisableClip=0). Le copier/coller de texte et d’images fonctionne, mais pas HTML ni formats binaires. Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :

Test I – Allow plain text, images, Rich Text Format and HTML. Ajoute HTML (SCClipLevel=4 / CSClipLevel=0 / fDisableClip=0). Formats binaires toujours bloqués. Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :

Test J – Allow plain text, images, Rich Text Format, HTML and Binary. Autorise tous les formats, y compris binaires (CSClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du host vers client :

Test K – Allow plain text (inverse direction). Même logique que F mais appliquée au client → host (SCClipLevel=0 / CSClipLevel=1 / fDisableClip=0). Seul le texte brut passe du poste local vers le cloud :

Test L – Allow plain text and images (inverse direction). Autorise texte et images du client vers la session (SCClipLevel=0 / CSClipLevel=2 / fDisableClip=0) :

Test M – Allow plain text, images and Rich Text Format (inverse direction). Ajoute RTF côté client → host (SCClipLevel=0 / CSClipLevel=3 / fDisableClip=0). HTML et binaire toujours bloqués :

Test N – Allow plain text, images, Rich Text Format and HTML (inverse direction). Permet HTML du client vers la session (SCClipLevel=0 / CSClipLevel=4 / fDisableClip=0) :

Test O – Allow plain text, images, Rich Text Format, HTML and Binary (inverse direction). Autorise tous les formats, y compris binaires (SCClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du client vers le host :

Conclusion

La désactivation par défaut des redirections RDP dans Windows 365 et AVD s’inscrit dans une tendance claire : un durcissement progressif des environnements cloud Windows pour tendre vers le secure by default.

Pour les architectes et administrateurs, cela signifie qu’il faut désormais anticiper ce comportement dans les modèles de provisionnement, les recommandations Intune et les templates de pools AVD.

Le presse-papiers, souvent considéré comme un simple confort utilisateur, devient un point de contrôle important dans la stratégie de sécurité : il faut choisir entre flexibilité et maîtrise du flux de données entre les environnements locaux et cloud.

En maîtrisant les deux couches de configuration (Propriétés RDP et polices GPO/MDM) et les niveaux SCClipLevel / CSClipLevel, vous pouvez adapter finement le niveau de redirection autorisé, du simple texte brut jusqu’à la copie complète de formats binaires.

En résumé : ce changement n’est pas une contrainte, mais une opportunité d’élever le niveau de sécurité sans perdre la visibilité sur le fonctionnement interne du protocole RDP.

AVD encore sous Windows 10 22H2 ?

Pourquoi, en 2025, mettre à jour son AVD ronronnant encore et toujours sous Windows 10 22H2 ? Windows 10 ou 11, comme leurs prédécesseurs, reçoivent régulièrement plusieurs types de mises à jour (sécurité, correctifs de bugs, feature update, pilotes, …) . Bien que les Extended Security Updates soient gratuites pour les environnements AVD ou Windows 365 pendant encore une année, il ne faudrait pas trop traîner non plus. Mais … attention à BitLocker !

Voici d’ailleurs le lien vers la FAQ Microosft des Extended Security Updates (ESU) pour Windows 10.

Sous Windows 11, la fréquence des Feature Updates a changé par rapport à Windows 10. Depuis 2022, Microsoft publie une seule Feature Update par an, généralement au second semestre (H2) :

  • 21H2 → sortie en octobre 2021
  • 22H2 → sortie en septembre 2022
  • 23H2 → sortie en octobre 2023
  • 24H2 → sortie en septembre/octobre 2024

Mais, Microsoft ne maintient pas indéfiniment ses produits. La transition vers des versions plus récentes est donc inévitable :

SystèmeÉditionVersionDate de fin de support / fin de maintenance
Windows 10Windows 10 Enterprise
Windows 10 Enterprise multi-session
Windows 10 Education,
Windows 10 IoT Enterprise
20H29 Mai 2023
Windows 10Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation
21H213 juin 2024
Windows 10Enterprise
Education
Home
Pro
Enterprise 2015 LTSB
IoT Enterprise LTSB 2015
22H214 octobre 2025
Windows 10Enterprise and IoT Enterprise LTSBex. LTSC 202112 janvier 2027
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation
21H210 octobre 2023
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation
22H28 octobre 2024
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation
23H211 novembre 2025
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation
24H213 Octobre 2026
Windows 11Windows 10 Home
Windows 10 Pro
Windows 10 Pro Edu
Windows 10 Pro workstation
25H212 Octobre 2027

Les versions Entreprise de Windows 11 ont toute une année de service en plus que leurs homologues respectives en version pro.

Comment les versions de Windows 10/11 sont disponibles sous Azure ?

Lors de la création d’une machine virtuelle sous Azure, Microsoft propose toujours plusieurs versions de Windows 10 ou 11, accessibles via le Marketplace Azure :

Un menu déroulant propose différentes versions et générations (Il est important de vérifier que la VM sélectionnée réponde aux conditions (hardware, Gen2, virt-TPM, Secure Boot…) car toutes les séries de VMs ne sont pas compatibles) :

On peut noter qu’il y a donc distinction entre les éditions clients (Pro, Enterprise). De plus, certaines images sont destinées à des usages spécifiques comme Windows 11 Enterprise multi‑session.

Qu’est-ce qu’Azure Update Manager, et peut-il m’aider ?

Azure Update Manager (AUM) est un service de Microsoft disponible sur Microsoft Azure, conçu pour gérer et superviser les mises à jour logicielles (patches) des machines, tant sous Windows que sous Linux, dans des environnements Azure, sur-premises ou multicloud via Azure Arc.

Grâce à Azure Update Manager, vous allez pouvoir :

  • Superviser la conformité des mises à jour pour les machines Windows et Linux, qu’elles soient dans Azure ou connectées via Azure Arc (on-premises ou multicloud).
  • Planifier des fenêtres de maintenance pour appliquer les patches.
  • Déployer un patch à la demande, ou d’un déploiement automatique selon une plage horaire définie.
  • Mettre en œuvre des mises à jour critiques et les suivre via le monitoring.
  • Gérer les droits via la granularité d’accès (RBAC) et d’autres fonctions de gouvernance Azure.

En ce qui concerne une machine virtuelle Azure avec un OS sous Windows 11, Microsoft est très clair sur ce point :

Automation Update Management ne fourni pas de prise en charge pour l’application de patchs à Windows 10 et 11. Il en va de même pour le Gestionnaire de mises à jour Azure. Nous vous recommandons d’utiliser Microsoft Intune comme solution pour maintenir les appareils Windows 10 et 11 à jour.

Microsoft Learn

Peut-on faire une upgrade d’une VM Azure Windows 10 existante ?

Oui, mais avant d’aller plus loin, sachez que Microsoft recommande déjà de ne pas le faire 🤣

Le processus de cet article entraîne une déconnexion entre le plan de données et le plan de contrôle de la machine virtuelle.

Les fonctionnalités Azure telles que la mise à jour corrective automatique de l’invité, les mises à niveau automatiques de l’image du système d’exploitation, la mise à jour corrective à chaud et le Gestionnaire de mise à jour Azure ne seront pas disponibles.

Pour utiliser ces fonctionnalités, créez une machine virtuelle à l’aide de votre système d’exploitation préféré au lieu d’effectuer une mise à niveau sur place.

Microsoft Learn

Microsoft ne recommande donc pas de faire une mise à niveau sur place pour une machine virtuelle Windows 10 ou 11 dans Azure pour des raisons techniques et structurelles.

Une mise à niveau sur place modifie profondément le système d’exploitation à l’intérieur de la VM sans qu’Azure en soit informé.

Résultat : La machine continue d’exister dans Azure avec les anciennes métadonnées d’image (Publisher, Offer, Plan, version, etc.), ce qui empêche Azure de reconnaître la nouvelle version de l’OS.

Et cela pose un ensemble de problèmes :

  • de gestion du cycle de vie
  • de sécurité et conformité (Azure Security Center/Azure Policy peuvent se tromper sur la version de l’OS)
  • du support Microsoft, car ce dernier s’appuie sur l’image déclarée dans Azure

Mais Microsoft propose pourtant la mise à niveau pour Windows Server ?

Il existe bien une procédure d’upgrade sur place pour Windows Server pour une VM Azure :

Passer d’une version antérieure de Windows Server à une version plus récente tout en conservant les rôles, données et applications.

Que recommande alors Microsoft pour gérer une MAJ sur Windows 10 ?

Microsoft recommande donc de créer une nouvelle VM avec le système d’exploitation cible, car les mises à jour directes peuvent empêcher certaines fonctionnalités Azure de fonctionner correctement.

Donc, la meilleure pratique consiste à :

  1. Déployer une nouvelle VM avec l’image du nouvel OS supporté.
  2. Migrer les applications, données, configurations vers cette nouvelle VM.
  3. Valider le bon fonctionnement, puis retirer l’ancienne VM.

Plusieurs vidéos tutorielles existent sur Internet pour proposer des mises à jour depuis Windows 10 :

Et quid du passage de la 22H2 à la 24H2 ?

Si malgré tout vous devez conserver votre image de base et effectuer une mise à jour vers Windows 11 24H2, vous risquez de rencontrer un problème de démarrage après la capture de votre image après un sysprep.

Lors du passage de Windows 10 22H2 ou Windows 11 22H2 vers la version 24H2, plusieurs administrateurs ont rencontré des écrans bleus ou des erreurs EFI (0xc000000f) juste après la capture d’image via Sysprep.

Le problème provient d’un bug dans le processus de Sysprep, qui modifie la configuration BCD lorsque BitLocker (ou le chiffrement automatique du périphérique) est actif.

Et le souci se manifeste à nouveau si on réactive BitLocker sans avoir corrigé la configuration BCD.

Résultat : l’image capturée devient partiellement chiffrée et inutilisable au déploiement.

Ce souci de démarrage est d’ailleurs confirmé dans les journaux de diagnostic Azure :

Pas de workaround possible ?

Pour éviter cela, il faut désactiver BitLocker avant le Sysprep. Une fois l’image déployée, BitLocker peut être réactivé proprement après correction de la configuration BCD. Ce comportement est spécifique aux builds 26100.x (Windows 11 24H2 et LTSC 2024) .

Voici d’abord une comparaison de l’état de BitLocker sur deux machines virtuelles Azure :

  • A droite : Windows 10 Multi-session 22H2
  • A gauche : Windows 11 Multi-session 24H2

La désactivation de BitLocker doit donc être complète et certaine avant de lancer Sysprep, sous peine de le voir se réactiver.

Afin de voir ce qu’il est possible de faire pour résoudre le souci de BitLocker , je vous propose au travers de cet article un pas à pas sur le processus complet :

Etape 0 – Rappel des prérequis :

Pour réaliser ces tests de mise à jour de VM, il vous faudra disposer de :

  • Un abonnement Azure valide
  • Un tenant Microsoft

Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une machine virtuelle à partir d’une image Windows 10/11 multi-session en 22H2, que nous allons mettre à jour dans la foulée.

Etape I – Création d’une VM W10 Multi-session 22H2 + MAJ 24H2 :

Pour cela, je commence par créer une machine virtuelle Azure en Windows 10 en 22H2 :

Une fois la machine virtuelle déployée, je vérifie la présence de mon application et de ma version actuelle de Windows :

J’ouvre PowerShell ISE en mode administrateur afin de vérifier l’état actuel de BitLocker :

  • Get-Service BDESVC : affiche l’état du service BitLocker Drive Encryption Service, qui gère le chiffrement BitLocker sur Windows.
  • manage-bde -status : affiche le statut détaillé du chiffrement BitLocker sur tous les lecteurs du système.
  • (Get-ComputerInfo).WindowsVersion : retourne la version majeure de Windows (ex. 10, 11, etc.).
  • (Get-ComputerInfo).OsBuildNumber : affiche le numéro de build du système d’exploitation Windows.
  • (Get-ComputerInfo).WindowsBuildLabEx : fournit la version complète du build Windows avec des informations additionnelles (branche, révision, date de compilation).
Get-Service BDESVC

manage-bde -status

(Get-ComputerInfo).WindowsVersion
(Get-ComputerInfo).OsBuildNumber
(Get-ComputerInfo).WindowsBuildLabEx

Je télécharge ensuite l’ISO Windows 11 24H2 depuis Visual Studio :

Je lance l’installation de Windows 11 en 24H2 :

Je vérifie le maintien de la version Multi-session, puis je démarre l’installation :

L’installation progresse lentement mais sûrement :

Afin de m’assurer que la mise à jour est terminée, je vérifie les journaux de diagnostic Azure pour confirmer le bon démarrage de la machine virtuelle :

Je me connecte via Azure Bastion et je vérifie le statut de BitLocker :

Get-Service BDESVC

manage-bde -status

(Get-ComputerInfo).WindowsVersion
(Get-ComputerInfo).OsBuildNumber
(Get-ComputerInfo).WindowsBuildLabEx

Le service de BitLocker BDESVC est maintenant démarré en 24H2 :

Je lance les commandes suivantes pour arrêter le service BitLocker BDESVC, mais aussi pour bloquer son changement de statut lors du sysprep :

# 1. Empêcher toute activation BitLocker automatique
reg add "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /t REG_DWORD /d 1 /f

# 2. Désactiver le service BitLocker
Set-Service -Name BDESVC -StartupType Disabled

# 3. Stopper le service s’il est actif
Stop-Service -Name BDESVC -Force

# 4. Vérifier que tout est propre
Get-Service BDESVC
manage-bde -status

La machine virtuelle est maintenant prête pour la capture. Avant cela je pourrais effectuer un snapshot. Je décide de continuer avec la commande Sysprep.

Etape II – Capture de l’image Windows 11 24H2 :

Je lance la commande Sysprep pour capturer cette nouvelle image 24H2 :

C:\Windows\System32\Sysprep\sysprep.exe /quiet /generalize /oobe /mode:vm /shutdown

Une fois Sysprep terminé, j’arrête complètement la machine pour qu’elle soit désallouée, puis je lance l’action de capture de l’image depuis le portail Azure :

Je crée une nouvelle image au sein de ma Azure Compute Gallery :

Avec cette nouvelle image en place, je déclenche la création d’une nouvelle machine virtuelle 24H2 à partir de celle-ci :

La nouvelle machine virtuelle est fonctionnelle, et cela est confirmé dans les journaux de diagnostic Azure :

Etape III – Réactivation de BitLocker :

Une fois la VM créée, je m’y connecte via Azure Bastion, puis je lance la vérification initiale de l’état du service BitLocker et du chiffrement :

Write-Host "=== Vérification initiale ===" -ForegroundColor Cyan
Get-Service BDESVC
manage-bde -status
Write-Host "WindowsVersion: $((Get-ComputerInfo).WindowsVersion)"
Write-Host "OS Build: $((Get-ComputerInfo).OsBuildNumber)"
Write-Host "BuildLabEx: $((Get-ComputerInfo).WindowsBuildLabEx)"
Write-Host ""
Start-Sleep -Seconds 3

Le statut du service BitLocker est toujours sur OFF comme attendu, et le disque OS se trouve toujours dans un état de déchiffrement :

Avant de pouvoir chiffrer le disque OS, nous avons besoin de corriger la configuration de BCD.

Je vérifie la configuration actuelle du BCD, corrige les entrées BCD liées à la partition système et au diagnostic mémoire :

# --- Vérifie le BCD avant correction
Write-Host "=== BCD avant correction ===" -ForegroundColor Yellow
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2

# --- Corrige les entrées BCD (selon le bug 24H2 /generalize)
Write-Host "=== Correction BCD ===" -ForegroundColor Cyan
cmd /c "bcdedit /set {current} osdevice partition=C:"
cmd /c "bcdedit /set {current} device partition=C:"
cmd /c "bcdedit /set {memdiag} device partition=\Device\HarddiskVolume3"
Write-Host "BCD corrigé."
Write-Host ""
Start-Sleep -Seconds 2

# --- Vérifie le BCD après correction
Write-Host "=== BCD après correction ===" -ForegroundColor Green
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2

La correction est bien visible sur cette seconde partie de l’écran :

Je supprime la clé de registre PreventDeviceEncryption si elle est présente, je rétablis le service BitLocker en mode manuel, je le démarre, puis je contrôle à nouveau l’état du service BDESVC et de BitLocker :

# --- Nettoyage de la clé PreventDeviceEncryption
Write-Host "=== Suppression clé PreventDeviceEncryption ===" -ForegroundColor Cyan
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /f | Out-Null
Write-Host "Clé supprimée (si existante)."
Start-Sleep -Seconds 2

# --- Rétablir le service BitLocker (manuel + démarrage)
Write-Host "=== Réactivation du service BitLocker ===" -ForegroundColor Cyan
Set-Service -Name BDESVC -StartupType Manual
Start-Service -Name BDESVC
Write-Host "Service BDESVC en cours d’exécution."
Write-Host ""
Start-Sleep -Seconds 2

# --- Vérifie l’état avant chiffrement
Write-Host "=== État avant chiffrement ===" -ForegroundColor Yellow
Get-Service BDESVC
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 2

J’attends environ 15 minutes la fin du chiffrement du disque OS :

Ensuite, j’active la protection BitLooker :

# --- Active BitLocker avec TPM (UsedSpaceOnly)
Write-Host "=== Activation BitLocker (TPM) ===" -ForegroundColor Cyan
Enable-BitLocker -MountPoint "C:" -TpmProtector -UsedSpaceOnly
Write-Host "BitLocker initialisé. Vérification du statut..."
Start-Sleep -Seconds 3
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 2

Cette activation est visible par le petit cadenas présent dans les paramétrages BitLocker et dans l’explorateur de fichier, suivi éventuellement d’un avertissement pour me signaler que la protection est encore sur OFF :

Une fois le chiffrement en place, je remets en route la protection (clé TPM active, verrouillage à l’amorçage autorisé)”.

# --- Finalisation
Write-Host "=== Activation finale (Resume-BitLocker) ===" -ForegroundColor Cyan
Resume-BitLocker -MountPoint "C:"
Write-Host "BitLocker réactivé avec succès."
Write-Host ""
Start-Sleep -Seconds 3

# --- Vérification finale
Write-Host "=== Vérification finale ===" -ForegroundColor Green
Get-Service BDESVC
manage-bde -status
Write-Host "=== FIN DU SCRIPT ===" -ForegroundColor Cyan

Cette validation est visible par la disparition de l’avertissement pour me signaler que la protection est maintenant sur ON :

Etape IV – Azure Virtual Desktop :

Je redémarre la machine virtuelle pour vérifier le bon fonctionnement du boot de Windows :

Une fois la VM redémarrée, je me reconnecte et confirme la présence de mon application, de la version 24H2 et de l’état actif de BitLocker sur cette machine virtuelle :

Je teste l’ajout de cette image dans un environnement Azure Virtual Desktop :

J’attends la fin de déploiement afin de constater la présence des VMs AVD comme étant disponibles :

Je passe sur chacune des machines pour lancer le script suivant en local ou à distance :

<#
.SYNOPSIS
  Répare la configuration BitLocker après Sysprep /generalize sur Windows 11 24H2.
  Corrige le BCD EFI et réactive BitLocker proprement.

.DESCRIPTION
  Ce script :
    1. Affiche l’état initial BitLocker et du service BDESVC
    2. Corrige les entrées BCD {current} et {memdiag}
    3. Supprime la clé PreventDeviceEncryption
    4. Rétablit le service BitLocker (mode Manuel)
    5. Démarre BDESVC et attend qu’il soit prêt
    6. Active BitLocker avec TPM (si nécessaire)
    7. Attend la fin du chiffrement (max 2h)
    8. Finalise avec Resume-BitLocker
#>

# --- FONCTIONS UTILITAIRES ---

function Wait-ForService {
    param (
        [string]$ServiceName,
        [int]$TimeoutSec = 120
    )
    Write-Host "Attente du service $ServiceName..." -ForegroundColor Yellow
    $sw = [Diagnostics.Stopwatch]::StartNew()
    while ($sw.Elapsed.TotalSeconds -lt $TimeoutSec) {
        $status = (Get-Service $ServiceName -ErrorAction SilentlyContinue).Status
        if ($status -eq 'Running') {
            Write-Host "Service $ServiceName opérationnel." -ForegroundColor Green
            return
        }
        Start-Sleep -Seconds 3
    }
    Write-Host "⚠️ Le service $ServiceName n’a pas démarré après $TimeoutSec secondes." -ForegroundColor Red
}

function Wait-ForEncryption {
    param (
        [string]$MountPoint = "C:",
        [int]$CheckIntervalSec = 15,
        [int]$TimeoutSec = 7200  # 2 heures
    )

    Write-Host "Attente de la fin du chiffrement BitLocker sur $MountPoint (timeout $($TimeoutSec/60) min)..." -ForegroundColor Yellow
    $sw = [Diagnostics.Stopwatch]::StartNew()

    while ($sw.Elapsed.TotalSeconds -lt $TimeoutSec) {
        $status = manage-bde -status $MountPoint | Select-String "Conversion Status"
        $percent = manage-bde -status $MountPoint | Select-String "Percentage Encrypted"
        $state = ($status -replace ".*:\s*", "").Trim()
        $progress = ($percent -replace ".*:\s*", "").Trim()

        Write-Host "État: $state | Progression: $progress"

        if ($state -match "Fully Encrypted|Used Space Only Encrypted") {
            Write-Host "✅ Chiffrement terminé sur $MountPoint" -ForegroundColor Green
            return
        }
        Start-Sleep -Seconds $CheckIntervalSec
    }

    Write-Host "⚠️ Le chiffrement sur $MountPoint n’est pas terminé après $($TimeoutSec/60) minutes." -ForegroundColor Red
    Write-Host "Le script continue, mais vérifie manuellement l’état avec 'manage-bde -status $MountPoint'." -ForegroundColor Yellow
}

# --- DÉBUT DU SCRIPT ---

Write-Host "=== Vérification initiale ===" -ForegroundColor Cyan
Get-Service BDESVC
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 3

# --- Vérifie le BCD avant correction
Write-Host "=== BCD avant correction ===" -ForegroundColor Yellow
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2

# --- Corrige les entrées BCD
Write-Host "=== Correction BCD ===" -ForegroundColor Cyan
cmd /c "bcdedit /set {current} osdevice partition=C:"
cmd /c "bcdedit /set {current} device partition=C:"
cmd /c "bcdedit /set {memdiag} device partition=\Device\HarddiskVolume3"
Write-Host "BCD corrigé."
Start-Sleep -Seconds 2

# --- Vérifie le BCD après correction
Write-Host "=== BCD après correction ===" -ForegroundColor Green
cmd /c "bcdedit /enum"
Start-Sleep -Seconds 2

# --- Supprime PreventDeviceEncryption
Write-Host "=== Suppression clé PreventDeviceEncryption ===" -ForegroundColor Cyan
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /f | Out-Null
Write-Host "Clé supprimée (si existante)."
Start-Sleep -Seconds 2

# --- Réactive BDESVC
Write-Host "=== Réactivation du service BitLocker ===" -ForegroundColor Cyan
Set-Service -Name BDESVC -StartupType Manual
Start-Service -Name BDESVC
Wait-ForService -ServiceName "BDESVC"
Write-Host ""

# --- Vérifie l’état avant chiffrement
Write-Host "=== État avant chiffrement ===" -ForegroundColor Yellow
Get-Service BDESVC
manage-bde -status
Start-Sleep -Seconds 2

# --- Active BitLocker avec TPM si nécessaire
Write-Host "=== Activation BitLocker (TPM) ===" -ForegroundColor Cyan
$bitlockerStatus = (manage-bde -status C: | Select-String "Conversion Status").ToString()

if ($bitlockerStatus -match "Encryption in Progress|Fully Encrypted|Used Space Only Encrypted") {
    Write-Host "ℹ️ BitLocker est déjà actif ou en cours de chiffrement sur C:. Aucune réactivation nécessaire." -ForegroundColor Yellow
} else {
    try {
        Enable-BitLocker -MountPoint "C:" -TpmProtector -UsedSpaceOnly -ErrorAction Stop
        Write-Host "BitLocker initialisé." -ForegroundColor Green
    } catch {
        Write-Host "⚠️ Impossible d’ajouter un protecteur TPM (probablement déjà présent) : $($_.Exception.Message)" -ForegroundColor Red
    }
}

Write-Host "Vérification du statut..."
Wait-ForEncryption -MountPoint "C:" -TimeoutSec 7200
Write-Host ""

# --- Finalisation
Write-Host "=== Activation finale (Resume-BitLocker) ===" -ForegroundColor Cyan
Resume-BitLocker -MountPoint "C:"
Wait-ForEncryption -MountPoint "C:" -TimeoutSec 7200
Write-Host "BitLocker réactivé avec succès." -ForegroundColor Green
Write-Host ""

# --- Vérification finale
Write-Host "=== Vérification finale ===" -ForegroundColor Green
Get-Service BDESVC
manage-bde -status
Write-Host "=== FIN DU SCRIPT ===" -ForegroundColor Cyan

Je redémarre la machine AVD pour vérifier son statut dans les journaux de diagnostic Azure :

Je teste également la connexion Azure Virtual Desktop avec un utilisateur :

Enfin, comme mon environnement est liée à Entra ID, je constate également la remontée automatqiue de ma clef de secours BitLocker dans Entra ID :

Conclusion

Cette expérience montre bien qu’une mise à jour in-place d’une image Windows 10/11 dans Azure n’est jamais anodine.
Entre la gestion du chiffrement BitLocker, les effets secondaires du Sysprep et les métadonnées Azure qui ne se mettent pas toujours à jour correctement, le risque d’image inutilisable est bien réel.

Le bon réflexe reste donc de désactiver BitLocker avant le Sysprep, de corriger la configuration BCD, puis de réactiver proprement la protection une fois la VM redéployée.
Cette approche garantit un chiffrement fonctionnel sans compromettre la capture ni le déploiement de l’image.

Mais il existe aujourd’hui une alternative plus élégante et performante : Encryption at Host.
Cette fonctionnalité permet de chiffrer les disques directement au niveau de l’hôte Azure, sans impliquer le service BitLocker à l’intérieur de la VM.

Résultat :

  • Moins de charge CPU côté invité,
  • Pas de dépendance au TPM virtuel,
  • Et une gestion centralisée du chiffrement dans Azure, plus simple à auditer et à maintenir.

C’est cette approche, à la fois plus moderne et plus légère, que nous verrons dans le prochain article.

On parlera en détail de la mise en œuvre d’Encryption at Host, de son impact sur les performances et des bonnes pratiques pour combiner sécurité et efficacité énergétique dans vos environnements AVD.

Azure Virtual Desktop – Invités

Comme pour Windows 365, Microsoft continue de faire évoluer Azure Virtual Desktop pour répondre aux besoins des organisations qui travaillent avec des partenaires externes, freelances ou prestataires. La dernière nouveauté, actuellement en préversion publique, permet de provisionner dans votre AVD une ou plusieurs identités externes (invités B2B dans votre tenant Microsoft Entra ID).

Spoiler alert : cet article est la copie quasi-identique de celui consacré aux comptes invités sur Windows 365.

Fini la création systématique de comptes internes temporaires : les utilisateurs peuvent se connecter avec leur propre identité tout en profitant d’un accès à un environnement Azure Virtual Desktop créé sur votre tenant.

Qui peut bénéficier de cette nouveauté ?

Nous venons de sortir il y a peu de la préversion privée, et nous sommes donc maintenant en préversion publique, avant une mise à disposition générale (GA) dans plusieurs mois je suppose. Tout utilisateur externe invité dans votre tenant Microsoft Entra ID peut donc en profiter.

Comme rappelé plus haut, les scénarios typiques sont : prestataires, auditeurs, partenaires de développement…

Le flux d’approvisionnement change-t-il pour ces utilisateurs invités ?

Non, vous utilisez les mêmes pool d’hôtes Azure Virtual Desktop et les mêmes licences que pour les utilisateurs internes à votre tenant.

Depuis quelles plate-formes le compte invité fonctionne ?

A ce jour où ces lignes sont écrites, la documentation Microsoft mentionne deux moyens possibles :

  • Navigateur internet
  • Windows App

Quelles sont les conditions techniques ?

Plusieurs conditions sont actuellement en vigueur et sont rappelées sur cette page de la documentation Microsoft :

  • VM AVD sous Windows 11 Enterprise avec mise à jour 24H2 (KB5065789) ou plus récente
  • VM AVD jointe à Entra ID
  • Single Sign-On activé au niveau du pool d’hôtes AVD

Quelles sont les principales limitations actuellement dans cette préversion ?

  • FSLogix n’est pas encore pris en charge : un nouveau profil utilisateur sera créé sur chaque hôte de session auquel elles se connectent.
  • Les polices Intune assignées à l’utilisateur externe ne s’appliquent pas (cibler les VMs AVD).
  • Pas de support pour le Cloud Government ni pour les invités cross-cloud (Azure Gov, 21Vianet).
  • Pas d’authentification Kerberos/NTLM vers les ressources on-premises.
  • Quelques limites sur la Token Protection pour identités externes.

Quelle licence Azure Virtual Desktop faut-il pour ces utilisateurs invités ?

Comme dit plus haut, il faut toujours provisionner une licence dans votre tenant pour le compte invité.

Les licences détenues par un compte invité dans son propre tenant ne confèrent aucun droit pour utiliser Azure Virtual Desktop dans votre tenant :

Si vous déployez Azure Virtual Desktop pour une utilisation avec des identités externes (actuellement en préversion publique), certaines considérations particulières peuvent s’appliquer concernant la manière de licencier Azure Virtual Desktop ainsi que d’autres produits et services Microsoft.

Microsoft Learn

Vous devez donc acheter et attribuer les mêmes licences AVD que pour vos utilisateurs internes, et aussi une licence Microsoft 365, si nécessaire.

Maintenant, il ne nous reste plus qu’à tester tout cela 😎

Pour vous aider et durant mes tests, j’ai rencontrés les soucis suivants :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Un abonnement Azure valide
  • Un tenant Microsoft
  • Une des licences requises pour Azure Virtual Desktop

Avant d’aller plus loin, commençons par vérifier que notre environnement AVD répondent bien aux prérequis de la fonctionnalité.

Pour cela, rendez-vous dans le portail Azure, puis rendez-vous sur la page de votre pool d’hôtes AVD :

Vérifiez sur une des VMs AVD que la jointure est bien définie vers Entra :

Contrôlez également sur le pool d’hôtes que le Single Sign-On (SSO) est activé :

Vérifiez ensuite que l’image Windows 11 utilisée pour le provisionnement est au minimum en version 24H2, avec le correctif KB5065789, ou plus récent :

Si tous ces points sont OK, commençons par inviter un nouvel utilisateur externe à notre tenant.

Etape I – Création de l’utilisateur invité :

Pour cela, rendez-vous dans le portail Microsoft Entra ID pour créer un nouvel utilisateur invité.

Cliquez sur Nouvel utilisateur, puis choisissez Inviter un utilisateur externe :

Renseignez l’adresse e-mail du compte Microsoft Entra de l’invité, puis cliquez ici :

Attendez quelques secondes, puis constatez la réception de l’e-mail d’invitation dans la boîte du compte invité, et enfin cliquez sur lien présent dans ce dernier :

Cliquez sur Accepter pour rejoindre le tenant qui vous a invité :

Sur votre tenant, ouvrez le portail d’administration de Microsoft 365 :

Ouvrez la fiche de l’utilisateur invité et attribuez-lui la licence AVD nécessaire, puis enregistrez :

Notre utilisateur invité est maintenant présent. Nous allons pouvoir nous intéresser au provisionnement de son accès à l’environnement AVD.

Etape II – Provisionnement de l’accès AVD à notre invité :

Pour cela, rendez-vous dans le portail Azure, puis rendez-vous sur la page du groupe d’application concerné :

Ajoutez l’utilisateur invité à votre groupe d’applications Azure Virtual Desktop :

Pensez également à lui ajouter un droit de connexion à la machine AVD via un rôle Azure RBAC :

Le provisionnement de l’utilisateur invité à notre environnement AVD est terminé. Nous allons maintenant pouvoir tester la connexion de ce dernier à Azure Virtual Desktop.

Etape III – Test de connexion invité depuis le navigateur internet :

Commençons nos tests par le navigateur internet. Pour cela, rendez-vous sur l’URL historique d’Azure Virtual Desktop, puis authentifiez avec le compte invité de votre utilisateur :

https://client.wvd.microsoft.com/arm/webclient/index.html

Une fois authentifié, constatez l’absence d’accès à l’environnement Azure Virtual Desktop provisionné sur votre tenant pour votre compte invité :

Ouvrez alors une nouvelle page internet en vous connectant, toujours avec le compte invité, sur une autre URL contenant le domaine de votre tenant :

https://client.wvd.microsoft.com/arm/webclient/index.html?tenant=<domainName>

Vérifiez que l’URL reste bien sur le domaine de votre tenant, et que votre environnement AVD apparaît cette fois :

Testez au besoin une seconde URL, commune entre les services Azure Virtual Desktop et Windows 365 :

https://windows.cloud.microsoft?tenant=<domainName>

Peu importe le site internet utilisé, cliquez sur Connecter :

Cliquez à nouveau sur Connecter :

Cliquez sur Oui :

Constatez l’apparition du message de chargement de FSLogix :

Constatez la bonne ouverture de session de votre compte invité :

Ouvrez Windows PowerShell :

Lancez la commande suivante afin d’afficher l’état de l’enregistrement dans Entra ID :

dsregcmd /status
  • AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID
  • EnterpriseJoined : NO
  • DomainJoined : NO :
  • TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.
  • SSO / Primary Refresh Token :
    • AzureAdPrt : YES
    • DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :

Ouvrez Microsoft Edge, puis constatez l’absence de récupération automatique du token de connexion pour le SSO :

Ouvrez Microsoft OneDrive, puis constatez, là aussi, l’absence de récupération automatique du token de session pour le SSO :

Malgré l’absence de SSO, la connexion à AVD depuis le navigateur internet se passe bien. Continuons les tests avec l’application Windows App.

Etape IV – Test de connexion invité depuis Windows App :

Avant de continuer, ouvrez les Paramètres de l’application Windows App, puis vérifiez la version installée :

Ouvrez localement PowerShell en tant qu’administrateur, puis lancez la commande ci-dessous pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :

reg add "HKLM\SOFTWARE\Microsoft\WindowsApp\Flights" /v EnableIdSignInUx /t REG_DWORD /d 1 /f

Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier :

Avant de saisir votre e-mail, cliquez sur le bouton des options avancées :

Cliquez sur le menu Organisation :

Indiquez le domaine de votre organisation, puis cliquez sur Suivant :

Renseignez l’adresse e-mail et le mot de passe du compte invité :

Constatez la bonne ouverture de l’application Windows App connectée à votre tenant avec le compte invité :

Cliquez sur Connecter pour lancer la session Azure Virtual Desktop :

Constatez la bonne ouverture de session AVD pour votre compte invité, puis ouvrez PowerShell :

Lancez la commande suivante afin d’afficher l’état de l’enregistrement AVD dans Entra ID :

dsregcmd /status
  • AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID
  • EnterpriseJoined : NO
  • DomainJoined : NO
  • TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.
  • SSO / Primary Refresh Token :
    • AzureAdPrt : YES
    • DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :

Enfin, la console de gestion Azure Virtual Desktop affiche bien votre utilisateur invité :

Par contre, aucune information n’y est disponible pour notre utilisateur invité :

Mais en passant par l’hôte de session AVD, les actions semblent également fonctionner sur notre utilisateur invité :

Vous voilà bien connecté avec votre compte invité sur l’environnement AVD de votre tenant Microsoft.

Pour vous aider et durant mes tests, j’ai rencontrés les soucis suivants :

Souci I – Impossible de se connecter malgré une version 24H2 :

Si, malgré le respect des prérequis, il est possible que vous rencontriez le blocage suivant au moment de vous connecter :

Commencez par vérifier que votre utilisateur invité est bien autorisé à ouvrir une session sur votre machine virtuelle AVD via le rôle Azure RBAC suivant :

Ensuite, cela vient peut-être de l’absence du correctif KB5065789 sur votre machine AVD, pourtant en version 24H2.

Pour remédier à cette mise à jour manquante, connectez-vous avec un administrateur sur votre machine AVD, puis lancez la commande PowerShell suivante pour vérifier les correctifs installés :

Get-HotFix | Where-Object {$_.HotFixID -like "KB506*"}

Si besoin, allez dans Windows Update, puis lancez la recherche de mises à jour :

Redémarrez si nécessaire :

Vérifiez avec la commande PowerShell que le correctif KB5065789 (24H2) est maintenant bien présent :

Get-HotFix | Where-Object {$_.HotFixID -like "KB506*"}

Retournez sur la page web de Azure Virtual Desktop ouverte avec le compte invité :

Constatez cette fois la bonne ouverture de session sur votre compte invité :

Souci II – Impossible de choisir une entreprise via Windows App :

Si, dans Windows App, le choix d’une authentification alternative n’apparaît pas, et que l’application ne vous propose qu’une adresse e-mail à renseigner :

C’est qu’il vous manque une clef de registre Windows pour faire apparaître ce choix alternatif.

Pour cela, sur votre PC local, ouvrez PowerShell en tant qu’administrateur puis lancez la commande indiquée pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :

reg add "HKLM\SOFTWARE\Microsoft\WindowsApp\Flights" /v EnableIdSignInUx /t REG_DWORD /d 1 /f

Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier, afin de voir le choix apparaître maintenant :

Souci III – Impossible de se connecter via Windows App – Erreur 7q6ch :

J’ai rencontré ce souci lors de l’authentification dans l’application Windows App, sur 2 postes uniquement. Les autres n’ont posé aucune difficulté.

Malgré une authentification réussie pour mon compte invité, le message d’erreur suivant apparaissait :

Suivi de ce seconde message :

Malgré plusieurs réinstallations de l’application Windows App, je n’ai pas encore trouvé la cause de ce souci. Je suis toujours en contact avec les équipes de Microsoft pour en comprendre la cause.

Conclusion

L’arrivée des identités externes sur Azure Virtual Desktop simplifie enfin l’accès des prestataires et partenaires, sans créer de comptes temporaires.

La fonctionnalité reste en préversion publique avec plusieurs limites (SSO partiel, stratégies Intune incomplètes, pas de support Government/cross-cloud), mais Microsoft annonce déjà des évolutions à venir.

C’est donc le bon moment pour tester, identifier les impacts et se préparer à son adoption lorsque ces restrictions seront levées.

Mise en place d’une identité managée pour AVD

Dès ce mois de septembre 2025, Microsoft introduit l’identité managée (Managed identity) aux environnements Azure Virtual Desktop. Cet ajout permettra d’exécuter en toute sécurité des actions lors de la création, suppression et mise à jour des machines virtuelles du pool d’hôtes. Cette nouvelle identité managé, de type système ou utilisateur est encore en préversion, remplacera certains usages du bien connu service principal Azure Virtual Desktop, que l’on utilise jusqu’à présent sur Azure comme sur Entra.

A partir du 15 novembre 2025, toute configuration utilisant le système de gestion des mises à jour intégré à Azure Virtual Desktop devra obligatoirement être associée à une identité managée (Managed Identity) pour continuer à fonctionner.

Concrètement, cela signifie que l’ancien modèle basé sur le service principal AVD disparaît progressivement au profit d’une approche plus robuste, où les opérations de création, suppression et mise à jour des machines virtuelles, passent par une authentification native dans Microsoft Entra ID.

Voici le service principal que l’on utilise actuellement :

Pour les administrateurs, c’est une étape importante qu’il faut anticiper dès maintenant, car elle touche directement la gestion quotidienne des environnements AVD.

Pourquoi ce changement ?

Historiquement, AVD utilisait un service principal spécifique pour réaliser certaines actions sur les ressources Azure associées aux hôtes de session :

Une identité managée s’authentifie automatiquement auprès d’Entra ID sans qu’aucun mot de passe ou secret ne soit stocké dans vos scripts ou vos ressources. Cela réduit considérablement la surface d’attaque et améliore la conformité.

Côté gouvernance, tout passe par l’Azure RBAC, ce qui rend les permissions plus lisibles et plus faciles à auditer.

System-assigned ou User-assigned ? deux modèles possibles :

Azure propose deux types d’identités managées.

  • System-assigned : créée et rattachée directement au pool d’hôtes Son avantage principal est sa simplicité : elle vit et meurt avec la ressource. Si vous supprimez le pool d’hôtes , l’identité disparaît automatiquement.
  • User-assigned : ressource indépendante dans Azure que vous pouvez rattacher à un ou plusieurs pools d’hôtes. Elle est donc plus flexible, particulièrement utile dans des environnements complexes où plusieurs ressources doivent partager la même identité et les mêmes permissions. En revanche, elle demande une gestion supplémentaire : l’objet reste actif même si le pool d’hôtes est supprimé.

Quelles fonctionnalités AVD utiliseront cette identité managée ?

Pour le moment, toutes les fonctionnalités d’Azure Virtual Desktop ne basculent pas encore vers ce modèle. Seule la fonction de mise à jour d’un pool d’hotes est prévue actuellement :

Les autres fonctionnalités, telles que App Attach, Autoscale et Start VM on Connect s’appuient encore sur le service principal Azure Virtual Desktop :

Cela signifie que vous aurez peut-être à gérer une période de transition où les deux approches cohabitent.

Quels impacts pour vos environnements AVD existants et futurs ?

Pour les administrateurs AVD, ce changement implique de revoir la configuration des pool d’hôtes, en particulier ceux qui utilisent ou vont utiliser la session host configuration.

À partir de novembre 2025, il ne sera plus possible d’ajouter de nouveaux hôtes de session sans identité managée :

  • À partir du 19 septembre 2025, les nouveaux pools d’hôtes utilisant une configuration d’hôtes de session dans le portail Azure devront être créés avec une identité managée.
  • À partir du 15 octobre 2025, les pools d’hôtes existants avec une configuration d’hôtes de session ne pourront plus mettre à jour leur configuration tant qu’une identité managée n’aura pas été ajoutée.
  • À partir du 15 novembre 2025, les pools d’hôtes existants avec une configuration d’hôtes de session ne pourront plus créer de nouveaux hôtes de session tant qu’une identité managée n’aura pas été ajoutée.

Quels sont les rôles AVD nécessaires avec l’identité managée ?

Lorsqu’on assigne une identité managée à un pool d’hôtes AVD, il faut lui donner les bons rôles RBAC pour qu’Azure Virtual Desktop puisse automatiser les opérations sur les hôtes de session. Voici les rôles clés utilisés avec la session host configuration et leur utilité :

  • Desktop Virtualization Virtual Machine Contributor – Resource group of image gallery : Autorise l’accès à la Compute Gallery pour que l’identité managée puisse lire et utiliser les images servant de base au déploiement des VMs. Sans ce rôle, AVD ne peut pas provisionner une VM à partir de l’image de référence.
  • Desktop Virtualization Virtual Machine Contributor – Resource group for session hosts : Donne le droit de créer, mettre à jour et supprimer les machines virtuelles qui composent le pool d’hôtes. C’est le rôle central pour permettre à AVD de gérer le cycle de vie des hôtes de session.
  • Desktop Virtualization Virtual Machine Contributor – VNet / NSG : Permet à l’identité de connecter les cartes réseau des VMs au bon sous-réseau et d’appliquer les règles de sécurité (NSG). Ce rôle est indispensable pour que les hôtes de session soient correctement intégrés au réseau et puissent rejoindre le domaine ou accéder aux ressources.
  • Key Vault Secrets User – Domain join Key Vault : Autorise l’identité à récupérer les secrets nécessaires à la jointure au domaine, comme le mot de passe d’un compte de service stocké dans Azure Key Vault. Cela automatise le processus sans exposer les identifiants en clair.
  • Key Vault Secrets User – Admin account Key Vault : Permet à l’identité d’accéder aux identifiants administrateur stockés dans un Key Vault. Ces informations peuvent être nécessaires lors de la création ou de la configuration initiale des hôtes de session.

Pour illustrer concrètement la mise en place et l’utilisation d’une identité managée dans Azure Virtual Desktop, j’ai choisi de documenter deux scénarios distincts. Cela permettra de couvrir à la fois un environnement AVD neuf et un environnement AVD existant, afin que chacun puisse s’y retrouver selon sa situation.

Dans ce premier cas, je pars de zéro avec un déploiement complet d’Azure Virtual Desktop. Ce scénario illustre la nouvelle exigence imposée par Microsoft pour les nouveaux déploiements, et montre comment intégrer cette configuration proprement dès le départ.

Scénario I – Création d’un nouvel environnement AVD :

L’objectif est de créer un tout nouveau pool d’hôtes après le 19 septembre 2025, et en activant directement l’assignation d’une identité managée dès le processus de création.

Lors de la création de mon pool d’hôtes AVD, sur l’onglet Management, je constate que la case Identité managée est déjà cochée, ainsi que les permissions attribuées à cette identité :

Durant le déploiement, je vois les assignations de rôle automatiquement créées sur différentes ressources Azure pour cette identité managée :

Une fois l’environnement créé, la configuration de l’identité managée est visible directement dans les paramètres du pool d’hôtes :

En cliquant sur l’assignation de rôles, je peux voir les rôles effectivement appliqués sur les ressources du déploiement :

En vérifiant les rôles associés au pool d’hôtes, je constate la présence d’une identité managée de type system-assigned :

Dans le coffre Azure, je retrouve également cette identité managée avec les permissions nécessaires :

Afin de voir l’impact de celle-ci, je déclenche une mise à jour immédiate sur mon nouveau pool d’hôtes AVD :

La mise à jour se déclenche correctement :

Environ quinze minutes plus tard, la mise à jour se termine avec succès :

Les journaux montrent bien que c’est l’identité managée qui a été utilisée comme initiateur de la mise à jour :

Le deuxième test consiste maintenant à prendre un environnement AVD déjà déployé, avec un pool d’hôtes fonctionnel, et à lui associer une identité managée après coup.

Scénario II – Ajout d’une identité managée à un environnement AVD existant :

Ce scénario reflète les besoins de nombreuses organisations qui disposent déjà d’un parc en production AVD et qui doivent se mettre en conformité avant la date butoir de novembre 2025.

Sur mon environnement AVD déjà en place avant le 19 septembre 2025, je lance également une mise à jour via l’interface :

La mise à jour se déclenche correctement :

Après environ quinze minutes, la mise à jour se réalise avec succès :

Dans l’activité, je vois l’identité applicative AVD utilisée pour orchestrer l’opération.

Afin de mettre une identité managée sur mon ancien environnement AVD, je coche la case suivante sur ce pool d’hôtes, puis j’enregistre ma modification :

L’identité managée apparaît désormais dans la configuration du pool d’hôtes :

Une commande PowerShell permet de confirmer la présence de l’identité managée affectée au pool d’hôtes :

$parameters = @{
    Name = '<HostPoolName>'
    ResourceGroupName = '<ResourceGroupName>'
}

Get-AzWvdHostPool @parameters | Format-Table Name, IdentityType

Je constate cependant que cette identité n’a encore aucune assignation de rôle.

Malgré tout, je déclenche une mise à jour immédiate AVD :

Cette dernière échoue immédiatement :

Les journaux indiquent clairement que l’identité managée ne dispose pas des droits suffisants sur l’environnement AVD :

Je retourne dans la configuration et ajoute un par un les rôles nécessaires (Compute Gallery, Session Hosts, VNet/NSG, Key Vaults).

J’effectue l’opération autant de fois que nécessaire :

Je contrôle que les rôles sont bien en place sur le pool d’hôtes et sur le coffre associés :

Je relance la mise à jour du pool d’hôtes.

La mise à jour de mon environnement AVD se lance :

Après une quinzaine de minutes, la mise à jour est finalisée avec succès :

Les logs confirment que l’identité managée a bien été utilisée pour piloter la nouvelle mise à jour :

Conclusion

L’introduction des identités managées dans Azure Virtual Desktop marque une étape importante dans la sécurisation et la modernisation du service. Là où le service principal AVD imposait la gestion de secrets et une gouvernance parfois complexe, l’identité managée apporte une intégration native à Microsoft Entra ID et une simplification des processus.

Les deux scénarios que j’ai présentés montrent bien la dualité de la situation actuelle :

  • Pour les nouveaux environnements, l’identité managée est désormais intégrée par défaut, et il suffit de l’accepter et de valider les rôles nécessaires.
  • Pour les environnements existants, une phase d’adaptation est incontournable. Il faut ajouter manuellement l’identité managée, attribuer progressivement les bons rôles RBAC, et valider que toutes les opérations AVD critiques fonctionnent correctement.

Au-delà de l’exemple des mises à jour de pools d’hôtes, ce changement illustre surtout la direction que prend Microsoft : réduire la dépendance aux secrets et renforcer la sécurité par défaut. D’ici novembre 2025, l’identité managée sera obligatoire pour l’ensemble des environnements AVD utilisant la session host configuration.

Mon conseil : n’attendez pas la date butoir. Prenez le temps dès maintenant de tester, documenter et industrialiser vos déploiements AVD avec une identité managée. Cela vous évitera des blocages en production et vous assurera une transition fluide vers ce nouveau modèle de sécurité.

Accès sortant par défaut : Microsoft ferme le robinet en septembre 2025

Depuis toujours, Azure offrait une “porte de sortie cachée” vers Internet à toutes les machines virtuelles déployées dans un réseau virtuel sans configuration explicite : le fameux Accès sortant par défaut (Default Outbound Access). En clair, si vous créiez une VM sans NAT Gateway, sans Équilibreur de charge, sans IP publique attachée… eh bien Azure vous donnait quand même un accès internet de secours via une IP publique éphémère. Mais tout cela change bientôt !

À partir du 30 septembre 2025, cette facilité disparaît pour tous les nouveaux réseaux virtuels. Les workloads qui comptaient dessus devront désormais passer par des méthodes explicites de sortie (NAT Gateway, Load Balancer SNAT, ou IP publique directe).

Pas d’inquiétude donc pour vos environnements déjà en place ! Ce changement ne concerne pas les réseaux virtuels déjà déployés avant cette date. Mais une modernisation de ces derniers est à envisager afin de les harmoniser avec les nouveaux réseaux virtuels dépourvus de l’Accès sortant par défaut.

Qu’est-ce que l’Accès sortant par défaut ?

L’Accès sortant par défaut est une connectivité internet implicite que Microsoft Azure attribuait automatiquement aux machines virtuelles créées dans un réseau virtuel sans configuration explicite de sortie.

Dans Azure, lorsqu’une machine virtuelle (VM) est déployée dans un réseau virtuel sans méthode de connectivité sortante explicitement définie, une adresse IP publique sortante lui est automatiquement attribuée.

Cette adresse IP permet la connectivité sortante depuis les ressources vers Internet et vers d’autres points de terminaison publics au sein de Microsoft. Cet accès est appelé « accès sortant par défaut ».

Microsoft Learn

Comment et quand l’accès sortant par défaut était-il utilisé ?

Microsoft décrit ici l’ordre de résolution de la connectivité sortante d’une VM dans Azure par plusieurs tests chaque par ordre de priorité :

  • Firewall
    • NAT Gateway
      • IP publique
        • Équilibreur de charge
          • Accès sortant par défaut

L’accès sortant par défaut n’est donc qu’un dernier recours. Et après la fin septembre 2025, il disparaîtra pour les nouveaux réseaux virtuels, seules les méthodes explicites resteront.

Pourquoi Microsoft le retire ?

Microsoft met fin à ce mécanisme pour trois raisons principales :

  • La première est la sécurité : cette IP “fantôme” ne figurait souvent dans aucun inventaire, ce qui compliquait la gestion et exposait à des risques.
  • La deuxième est la stabilité : ces adresses publiques pouvaient changer sans prévenir, cassant certaines intégrations critiques avec des services externes.
  • Enfin, la troisième est la conformité : dans un contexte d’audit, il était difficile de tracer les flux sortants d’une VM utilisant ce mode implicite. L’objectif est donc de forcer les clients à adopter des méthodes explicites et maîtrisées de connectivité.

Voici un exemple concret avec un Accès sortant par défaut :

Vous déployez une VM, elle se met à parler à internet avec une IP que vous ne connaissiez pas, qui peut changer sans prévenir, et qui n’apparaît pas dans vos inventaires de sécurité. C’était cela l’Accès sortant par défaut.

Dès la fin septembre, Microsoft dit stop à cette approche :

En supprimant cette facilité, Microsoft pousse à adopter des designs réseau clairs, contrôlables et audités. Malgré la contrainte en tant que telle, cela reste une excellente nouvelle pour la gouvernance cloud.

Qui est impacté ?

Tout le monde. Mais seuls les nouveaux réseaux virtuels créés après le 30 septembre 2025 seront concernés :

Après le 30 septembre 2025, les nouveaux réseaux virtuels exigeront par défaut des méthodes de connectivité sortante explicites au lieu d’avoir un repli vers la connectivité d’accès sortant par défaut.

Azure Updates

Les réseaux existants continueront de fonctionner comme avant, mais Microsoft recommande déjà à tous les clients de migrer afin d’éviter les discordances entre les anciens et nouveaux réseaux virtuels :

Toutes les machines virtuelles (existantes ou nouvellement créées) dans les réseaux virtuels existants qui utilisent l’accès sortant par défaut continueront de fonctionner après cette modification. Cependant, nous vous recommandons vivement de passer à une méthode sortante explicite.

Azure Updates

Même confirmation sur le site Learn de Microsoft :

Aucune modification n’est apportée aux réseaux virtuels existants. Cela signifie que les machines virtuelles existantes et les machines virtuelles nouvellement créées dans ces réseaux virtuels continuent de générer des adresses IP sortantes par défaut, à moins que les sous-réseaux ne soient modifiés manuellement pour devenir privés.

Microsoft Learn

Quelles sont les alternatives recommandées ?

Afin de maintenir un accès internet à vos machines virtuelles, plusieurs services sont proposés par Microsoft selon vos besoins :

  • La solution de référence est le NAT Gateway, qui offre une connectivité sortante hautement disponible, scalable et simple à gérer.
  • Dans certains cas, on pourra également utiliser un Équilibreur de charge configuré avec des règles SNAT.
  • Pour des scénarios plus ponctuels, il reste possible d’associer une IP publique directement à une VM, même si cela n’est pas conseillé pour des environnements critiques.
  • Enfin, dans les architectures plus sécurisées, le trafic sortant peut être centralisé à travers un Azure Firewall, un proxy ou une appliance réseau virtuelle (NVA).

Comment préparer ma migration ?

La première étape est d’inventorier vos workloads et d’identifier ceux qui reposent encore sur ce mode implicite d’Accès sortant par défaut.

Ce script PowerShell parcourt toutes les souscriptions Azure et dresse, pour chaque réseau virtuels et sous-réseaux, l’état de l’option Accès sortant par défaut :

$results = New-Object System.Collections.Generic.List[object]
$subs = Get-AzSubscription -ErrorAction Stop

foreach ($sub in $subs) {
    Set-AzContext -SubscriptionId $sub.Id -Tenant $sub.TenantId | Out-Null
    $vnets = Get-AzVirtualNetwork -ErrorAction SilentlyContinue

    foreach ($vnet in $vnets) {
        foreach ($subnet in $vnet.Subnets) {
            $hasProp = $subnet.PSObject.Properties.Name -contains 'DefaultOutboundAccess'
            $raw = if ($hasProp) { $subnet.DefaultOutboundAccess } else { $null }

            $status = if ($raw -eq $false) { 'Disabled' } else { 'Enabled' }

            $results.Add([PSCustomObject]@{
                SubscriptionName = $sub.Name
                SubscriptionId   = $sub.Id
                ResourceGroup    = $vnet.ResourceGroupName
                VNet             = $vnet.Name
                Region           = $vnet.Location
                Subnet           = $subnet.Name
                DefaultOutbound  = $status
            }) | Out-Null
        }
    }
}

$results |
    Sort-Object SubscriptionName, ResourceGroup, VNet, Subnet |
    Format-Table -AutoSize

Ensuite, choisissez une stratégie adaptée :

  • Associez une passerelle NAT
  • Associez un équilibreur de charge
  • Associez une adresse IP publique
  • Ajoutez un pare-feu

Puis, testez ensuite vos flux réseau, notamment tout ce qui dépend de l’accès à Internet : mise à jour, activation Windows, appels API externes, DNS.

Quelles sont les limitations des subnets privés ?

Dans un sous-réseau privé entièrement fermé à Internet, certaines contraintes importantes impactent la bonne marche des machines virtuelles.

Plusieurs fonctionnalités essentielles demandent de mettre en place obligatoirement une méthode explicite de connectivité sortante.

  • Impossibilité d’utiliser les services Microsoft 365
  • Impossibilité d’activer le système d’exploitation
  • Impossibilité de mettre à jour le système d’exploitation via Windows Update
  • Impossibilité d’associer une machine virtuelle à Azure Virtual Desktop
  • Les routes configurées avec un next hop de type Internet deviennent inopérantes

Note : Les sous-réseaux privés ne s’appliquent pas non plus aux sous-réseaux délégués ou gérés utilisés par des services PaaS. Dans ces scénarios, c’est le service lui-même (par exemple Azure SQL, App Service, etc.) qui gère sa propre connectivité sortante.

Puis-je déjà désactiver l’Accès sortant par défaut avant septembre 2025 ?

Oui, il est déjà possible de désactiver ce mécanisme dans vos réseaux virtuels pour anticiper la transition.

Cela permet de vérifier vos workloads dans des conditions proches de ce qui deviendra la norme à partir de septembre 2025 et d’éviter les mauvaises surprises le jour où le support sera officiellement retiré.

Important : Il est nécessaire d’arrêter/désallouer les machines virtuelles concernées dans un sous-réseau pour que les modifications de l’Accès sortant par défaut soient prises en compte.

Une fois ces choses dites, je vous propose de tester cela depuis un environnement de démonstration afin de voir ce qu’il est actuellement possible de faire ou de ne pas faire de nôtre côté :

Maintenant, il ne nous reste plus qu’à tester tout cela 😎

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Un abonnement Azure valide
  • Un tenant Microsoft

Commençons par tester la connectivité à internet depuis un réseau Azure créé avant septembre 2025.

Test I – Connexion internet depuis un sous-réseau non privé :

Dans un réseau virtuel Azure déjà créé, j’ai commencé par créer un premier sous-réseau non privé :

J’ai crée une machine virtuelle sans adresse IP publique associée :

Une fois la VM démarrée, la machine obtient quand même un accès Internet sortant :

Et OneDrive se configure sans problème :

Tout fonctionne comme cela à toujours fonctionné. Passons maintenant à un test reposant sur un sous-réseau virtuel cette fois privé.

Test II – Connexion internet depuis un sous-réseau privé :

Sur ce même réseau virtuel, j’ai crée un second sous-réseau, avec l’option Private subnet cochée :

Une fois connecté à la machine virtuelle, dans les paramétrages Windows, l’état du réseau indique qu’il n’y a plus d’accès Internet :

Impossible d’ouvrir des sites web depuis le navigateur internet :

Windows Update échoue également à télécharger les mises à jour :

L’activation Windows ne se fait pas non plus :

Et cette fois, OneDrive refuse de se configurer :

Et pourtant, j’accède sans problème à un compte de stockage via son URL publique :

Tout montre que l’accès extérieur à Azure, y compris Microsoft 365, est bloqué dans ce sous-réseau privé.

Sur ce second sous-réseau, je décoche l’option précédemment activée, puis je sauvegarde :

Malgré cela, la machine n’a toujours pas retrouvé Internet :

Je tente même un redémarrage de la machine virtuelle depuis le portail Azure :

Mais après ce redémarrage, rien ne change côté accès Internet :

Après un arrêt complet puis un redémarrage manuel, la sortie vers Internet revient :

Cette fois, la VM a bien une IP publique éphémère pour sortir sur Internet :

Ce test nous montre l’impact de cette option sur les ressources externes accessibles à notre machine virtuelle. Continuons avec un test sur le comportement d’Azure Virtual Desktop dont les VMs seraient sur ce type de sous-réseau privé.

Test III – Connexion Azure Virtual Desktop depuis un sous-réseau privé :

Je dispose d’un environnement Azure Virtual Desktop contenant déjà plusieurs machines virtuelles dans le pool d’hôtes :

J’ai donc modifié le sous-réseau AVD pour qu’il soit privé :

J’ai ajouté une nouvelle machine virtuelle via le plan de mise à l’échelle AVD :

La création de la VM se déroule normalement et celle-ci apparaît :

Mais, elle n’a jamais rejoint automatiquement mon Active Directory :

Et elle n’a pas non plus intégré le pool d’hôtes AVD :

Enfin, au bout d’un certain temps, elle s’est même auto-supprimée :

Ce test nous montre qu’un environnement Azure Virtual Desktop déployé après septembre 2025 nécessitera des ressources supplémentaires pour fonctionner correctement.

Continuons nos tests en appliquant les méthodes proposées par Microsoft pour compenser le changement à venir.

Test IV – Connexion internet avec une adresse IP publique :

Je recoche l’option Private subnet sur mon 2ᵉ sous-réseau :

J’y crée une machine virtuelle, cette fois disposant d’une adresse IP publique associée :

La VM a bien accès à Internet, et l’IP vue depuis l’extérieur correspond à l’IP publique de la machine virtuelle :

Voici le coût de cette IP publique dans le Azure Pricing Calculator :

Il s’agit de la solution la plus économique pour retrouver un accès internet. Mais la question va se poser si un grand nombre de machines virtuelles existent. Si l’ajout d’une adresse IP publique sur une machine virtuelle n’est pas sans conséquence sur la sécurité.

Continuons avec le service Azure NAT Gateway.

Test V – Connexion internet avec Azure NAT Gateway :

Je crée un 3ᵉ sous-réseau privé, dédié cette fois à un test avec NAT Gateway :

Je déploie un service NAT Gateway et je lui assigne une IP publique :

Le nouveau sous-réseau privé est bien associé au service NAT Gateway :

Je crée une VM dans ce 3ᵉ sous-réseau :

Les tests montrent que la VM utilise bien l’adresse IP publique du NAT Gateway pour sortir sur Internet :

Je reproduis ensuite ce même test sur le sous-réseau dédié à Azure Virtual Desktop :

Je lance la création d’une 4ᵉ VM AVD :

Cette fois, la VM rejoint correctement mon Active Directory :

Elle est aussi intégrée automatiquement au host pool d’AVD, et devient accessible :

Voici le coût estimé par Azure Pricing Calculator pour un service NAT Gateway et son IP publique :

L’Azure NAT Gateway est un service géré qui permet aux machines virtuelles dans un sous-réseau privé de sortir sur Internet de manière sécurisée, performante et scalable.

Continuons avec le service Azure Firewall.

Test VI – Connexion internet avec Azure Firewall :

Je crée un 4ᵉ sous-réseau privé dédié cette fois à un test avec Azure Firewall :

Je crée aussi le sous-réseau spécifique réservé au service Azure Firewall :

Je déploie un Azure Firewall en SKU Basique pour ce test :

Deux adresses IP publiques sont automatiquement créées pour le Firewall :

Je configure une Firewall Policy avec plusieurs règles et adresses IPs cibles :

Je crée une nouvelle machine virtuelle sur ce nouveau sous-réseau privé :

Enfin je crée une table de routage associée à mon sous-réseau virtuel de test, dont le prochain saut envoie tout le trafic sortant vers l’adresse IP privée de mon Firewall Azure :

Les tests montrent que la sortie Internet se fait bien via l’IP publique de l’Azure Firewall :

Voici le coût estimé par Azure Pricing Calculator pour un service Azure Firewall et ses deux adresses IP publiques :

L’Azure Firewall a un rôle différent d’un NAT Gateway : ce n’est pas juste de la connectivité sortante, c’est une véritable appliance de sécurité managée par Microsoft. Mais d’autres appliances tierces auraient elles-aussi pu faire l’affaire.

Terminons avec un Équilibreur de charge Azure.

Test VII – Connexion internet avec Azure Load Balancer :

Je crée un 5ᵉ sous-réseau privé, cette fois pour tester Azure Load Balancer :

Je crée une nouvelle VM dans ce nouveau sous-réseau privé :

Je déploie un Équilibreur de charge et lui associe une IP publique :

La VM est ajoutée au backend pool :

Je configure une règle SNAT de sortie sur l’Équilibreur de charge :

En me connectant à la VM, je constate que la sortie Internet se fait bien via l’IP publique de l’Équilibreur de charge :

Voici le coût estimé par Azure Pricing Calculator pour un Équilibreur de charge et son adresse IP publique :

Ce service permet aux VM backend de sortir vers Internet sans IP publique dédiée, mais il est limité pour les gros volumes de connexions (NAT Gateway est plus adapté).

Conclusion

La fin de l’Accès sortant par défaut marque une étape clé dans la maturité du cloud Azure. Fini les “raccourcis” implicites : désormais, chaque sortie vers Internet devra être pensée, tracée et gouvernée.

Ce changement n’est pas une contrainte, mais une opportunité :

  • Opportunité de renforcer la sécurité en éliminant des flux fantômes.
  • Opportunité d’améliorer la stabilité et la prévisibilité des intégrations.
  • Opportunité de consolider vos architectures autour de designs réseau clairs, basés sur NAT Gateway, Azure Firewall ou un Équilibreur de charge.

AVD/W365 + RDP Multipath = 😍

Excellente nouvelle pour celles et ceux rencontrant des soucis de connexion à Azure Virtual Desktop ou Windows 365 ! Disponible en préversion depuis début 2025, le RDP Multipath vient d’être annoncé il y a peu en disponibilité générale par Microsoft. Nous allons justement voir comment en bénéficier, et qu’est-ce que cela apporte par rapport à du TCP ou à l’UDP simple-path.

Comment fonctionne la connexion d’un utilisateur à une VM AVD ?

Azure Virtual Desktop héberge des sessions client sur des hôtes de session s’exécutant sur Azure. Microsoft gère des parties des services au nom du client et fournit des points de terminaison sécurisés pour la connexion des clients et des hôtes de session.

Le diagramme suivant fournit une vue d’ensemble générale des connexions réseau utilisées par Azure Virtual Desktop.

Microsoft Learn

Azure Virtual Desktop (AVD) utilise le protocole RDP pour établir et acheminer vos sessions vers les machines virtuelles ; voici comment la connexion se déroule :

  1. Découverte du feed (Feed Discovery)
    • L’utilisateur s’authentifie auprès de Microsoft Entra ID et obtient un jeton OAuth.
    • Le client envoie ce jeton au service de feed AVD, qui retourne la liste des desktops et applications disponibles sous forme de fichiers .rdp signés numériquement Microsoft Learn.
  2. Connexion au gateway AVD
    • Quand l’utilisateur lance l’un des fichiers .rdp, le client se connecte via TLS 1.2 (HTTPS) à Azure Front Door, qui redirige vers l’instance du Remote Connection Gateway la plus proche (latence minimale et charge équilibrée) Microsoft Learn.
    • Le gateway valide la requête et fait appel au Connection Broker pour orchestrer la suite.
  3. Établissement du canal de contrôle
    • L’hôte de session (VM AVD) maintient en permanence un canal de communication sortant chiffré (TLS) vers le broker AVD, géré par le service Reverse Connect Transport plutôt qu’un listener TCP classique Microsoft Learn.
    • Le broker utilise ce canal pour indiquer au session host de joindre le même gateway que le client.
  4. Ouverture du canal de données (RDP data channel)
    • Reverse connect transport (TCP via le gateway) : le trafic RDP transite en TCP chiffré sur 443 via le gateway, idéal si UDP est bloqué ou non configuré.
    • RDP Shortpath (UDP direct) : le client et le session host créent un canal UDP direct (STUN/TURN + ICE), évitant le relay du gateway pour réduire latence et jitter Microsoft Learn.
    • Le basculement entre TCP et UDP Shortpath est transparent et contrôlé par le client selon la configuration et la qualité réseau.
  5. Session active et résilience
    • Une fois le canal de données établi, RDP gère l’envoi d’affichage, d’audio, de redirections périphériques, etc.
    • En mode Shortpath, chaque paquet voyage de façon indépendante : en cas de perte ou de réordonnancement, RDP multi‑path ou le TCP se chargent des retransmissions, tandis que le reverse connect TCP reprend toujours – garantissant la continuité de la session même sur des réseaux instables.

Le bon vieux duel TCP vs UDP ?

Voici un tableau comparatif des principaux aspects de TCP et UDP :

CritèreTCP (Transmission Control Protocol)UDP (User Datagram Protocol)
Type de connexionOrienté connexion (handshake en trois temps)Sans connexion (pas de handshake)
FiabilitéFiable : accusés de réception et retransmissions automatiquesNon fiable : pas d’accusés de réception ni retransmissions
OrdonnancementGarantit l’ordre des paquetsPas d’ordre garanti
Contrôle de fluxOui (fenêtre glissante)Non
Contrôle de congestionOui (algorithmes AIMD, slow start, etc.)Non
Taille de l’en‑têteAu moins 20 octets8 octets
Vitesse (latence)Plus lente (overhead de contrôle)Plus rapide (faible overhead)
Utilisations courantesHTTP, HTTPS, FTP, SMTP, SSH, bases de donnéesDNS, VoIP, streaming vidéo, jeux en temps réel
Gestion des erreursVérification de somme de contrôle + retransmissionVérification de somme de contrôle uniquement
Transmission multipleFlux unique, multiplexé par portDatagrammes indépendants par port
Connection keep‑aliveOui (optionnel)Non
Adapté pour…Applications nécessitant intégrité et fiabilitéApplications temps réel et tolérantes à la perte

Dans quels cas ne pas utiliser l’UDP pour AVD ?

Certains utilisateurs ont ressenti des difficultés lors de session Azure Virtual Desktop lorsque on passe systématiquement à l’UDP. On évitera d’activer le transport UDP sur Azure Virtual Desktop dans les cas suivants :

  • Réseaux d’entreprise très « verrouillés » :
    • Pare‑feu ou appliance de sécurité qui ne laissent passer que le trafic HTTPS/TCP sur le port 443.
    • Proxies ou load‑balancers interdisant ou foreçant l’inspection de flux UDP.
    • Absence d’ouvrages STUN/TURN nécessaires au Shortpath UDP.
  • Topologies NAT ou VPN problématiques :
    • NAT très restrictif (symmetric NAT) qui empêche la découverte de chemin direct STUN.
    • VPN d’entreprise qui n’autorise que le protocole TCP encapsulé (SSLVPN, SSTP…), rendant l’UDP inopérant.
  • Contraintes de conformité ou d’audit :
    • Politiques de sécurité interne imposant que tout le trafic soit chiffré/TLS sur TCP pour centraliser la journalisation et l’inspection.
    • Nécessité de passer via des IDS/IPS qui ne gèrent que le TCP.
  • Scénarios de diagnostic ou de troubleshooting :
    • Pour isoler un problème de connectivité ou comparer les performances TCP vs UDP : on désactive l’UDP pour forcer le fallback TCP.
    • Lorsque vous suspectez que le UDP est la source de coupures intempestives (perte, réordonnancement).
  • Clients legacy ou plateformes non supportées :
    • Certains clients RDP anciens ou intégrés (HTML5 via RemoteApp) ne gèrent pas le Shortpath UDP.

Un article écrit sur ce blog montre comment justement rester sur du TCP via une configuration depuis la machine AVD ou le poste local.

Qu’est-ce que le RDP Multipath ?

Le RDP Multipath (ou « UDP Multi‑Path ») est une évolution du transport RDP Shortpath qui évite les coupures et micro‑latences en :

  1. Ouvrant plusieurs sous‑canaux UDP simultanément entre le client et l’hôte de session, au lieu d’un seul.
  2. Surveillant en continu la qualité (latence, perte, gigue) de chacun de ces chemins via ICE/STUN/TURN.
  3. Bascule instantanée du trafic sur le ou les sous‑canaux les plus sains dès qu’un chemin se dégrade, sans interrompre la session.

Concrètement, si l’un des liens subit une perte de paquets élevée, un pic de gigue ou tombe complètement, Multipath redirige automatiquement les paquets vers un autre sous‑chemin en quelques dizaines de millisecondes, assurant une expérience fluide et sans reconnexion visible pour l’utilisateur.

Comment fonctionne le RDP Multipath pour Azure Virtual Desktop ?

RDP Multipath pour Azure Virtual Desktop établit plusieurs sous‑canaux UDP simultanés (via ICE, STUN et TURN) et mesure en continu leur qualité (latence, perte, gigue).

  • Dès qu’un lien se dégrade, il bascule automatiquement en quelques dizaines de millisecondes vers le canal le plus performant, sans interrompre la session.
  • Si tous les canaux UDP tombent, Multipath retombe de façon transparente sur TCP, garantissant ainsi une expérience AVD quasi ininterrompue et nettement plus stable sur des réseaux instables.

L’excellente vidéo de Dean Cefola depuis sa chaîne YouTube Azure Academy nous permet d’en savoir un peu plus :

Le diagramme suivant illustre le fonctionnement de RDP Multipath avec Azure Virtual Desktop. Dans ce scénario, le principal chemin actif est la connexion UDP via STUN, complétée par deux connexions UDP redondantes via un serveur TURN :

Microsoft Learn

Comment en bénéficier ?

RDP Multipath fonctionne automatiquement lorsque les conditions suivantes sont remplies :

  • Assurez-vous que RDP Shortpath est configuré comme protocole de transport principal. Pour plus d’informations, voir Configurer RDP Shortpath. Nous ne prenons pas actuellement en charge les connexions WebSocket (basées sur le protocole TCP) et ces utilisateurs n’en tirent aucun avantage pour le moment.
  • Les connexions doivent être établies à partir d’un appareil Windows local utilisant Windows App, version 2.0.366.0 ou ultérieure, ou le client Remote Desktop, version 1.2.6074 ou ultérieure. Les autres plateformes ne sont pas prises en charge actuellement.

Afin de comprendre mieux le fonctionnement et l’impact entre les 3 protocoles disponibles pour Azure Virtual Desktop, j’ai préparé un environnement dédié.

Voici les différentes étapes que j’ai suivies :

Maintenant, il nous reste plus qu’à tester tout cela 😎

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Une abonnement Azure valide
  • Un tenant Microsoft

Etape I – Création de l’environnement AVD

J’ai créé un nouvel environnement Azure Virtual Desktop composé de 3 machines virtuelles et placées dans un même pool d’hôtes :

Comme le recommandait Microsoft avant la fin de la préversion, mon pool d’hôtes est encore être configuré en tant qu’environnement de validation :

Enfin j’ai laissé par défaut la configuration de la fonctionnalité RDP shortpath afin de gérer le protocole utilisé de façon individuelle sur chacune des 3 machines virtuelles AVD :

Commençons par configurer la première machine virtuelle AVD afin que celle-ci n’accepte que les connexions RDP en TCP.

Etape II – VM1 Forcer le flux TCP côté serveur :

Il est possible de forcer le serveur à n’accepter que des connexions TCP, ce qui est particulièrement utile dans des environnements où la stabilité prime. Pour cela, vous pouvez modifier le registre du serveur ou déployer une GPO.

Avant modification, le serveur accepte par défaut les connexions en UDP. Pour forcer TCP, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport.

Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :

REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SelectTransport /t REG_DWORD /d 1 /f

Après avoir mis à jour la clé de registre, il est nécessaire de redémarrer la machine AVD pour que la modification prenne effet.

Après modification, la connexion se fait exclusivement en TCP. Cette commande force le serveur à utiliser uniquement TCP pour les connexions RDP.

Continuons par configurer la seconde machine virtuelle AVD pour que celle-ci n’accepte que les connexions RDP en UDP simple-path.

Etape III – VM2 Forcer le flux UDP simple-path côté serveur :

Avant modification, le configuration par défaut de mon AVD accepte les connexions en UDP Multipath si cela est possible.

Mais il est possible de forcer le serveur à n’accepter que des connexions UDP sans Multipath. Pour cela, vous pouvez modifier le registre du serveur ou déployer une GPO.

Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 0 /f

Après avoir mis à jour la clé de registre, les utilisateurs doivent se déconnecter et se reconnecter à l’hôte de la session pour que la modification prenne effet.

Après la modification, la connexion AVD se fait exclusivement en UDP simple-path :

Terminons de préparer notre environnement par la configuration de la dernière machine virtuelle AVD pour que celle-ci accepte les connexions RDP en UDP Multipath.

Etape IV – VM3 Forcer le flux UDP Multipath côté serveur :

Compte tenu de la configuration de notre nouvel environnement Azure Virtual Desktop, il n’y a rien à faire. La connexion de notre utilisateur de test nous le prouve :

Nos machines virtuelles AVD sont prêtes. Continuons maintenant sur la préparation de notre protocole de test.

Etape V – Préparation de l’environnement de test :

J’ai utilisé la version d’essai gratuite de Connection Emulator.

Connection Emulator est un outil qui vous permet de simuler des conditions réseau dégradées (latence, perte, gigue, réordonnancement, duplication, corruption).

Voici le lien pour le télécharger en version d’essai, cliquez-ici pour télécharger et installer la version Windows :

Caractéristiques principales de l’outil

  • Limite la vitesse de connexion
  • Imite une latence fixe ou variable
  • Simule la perte, la corruption, la duplication et la réorganisation de paquets individuels et séquentiels.
  • Affiche un graphique de simulation de paquets en direct
  • Prend en charge plusieurs profils de simulation

Etape VI – Réalisation des 2 tests :

J’ai réalisé deux scénarios d’émulation réseau avec Connection Emulator :

  • Test 1 : latence 100 ms, perte 8 %, duplication 5 %, réordonnancement 30 %, corruption 2 %
  • Test 2 : latence 200 ms, perte 16 %, duplication 10 %, réordonnancement 40 %, corruption 4 %

Pour chaque scénario, j’ai démarré simultanément trois VM AVD configurées en TCP, UDP simple-path et UDP Multipath, puis lancé la même vidéo sur chacune.

Cette méthode met en évidence, de manière visuelle, la dégradation de la qualité pour TCP et UDP mono-chemin et la résilience supérieure de l’UDP Multipath face aux pires conditions réseau.

Voici ma vidéo de comparaison des 3 protocoles de connexion :

Etape VII – Configuration sur Windows 365 :

Finissons cette dernière étape par la configuration sur Windows 365. Voici les informations de connection sur un poste Windows 365 avant la modification de registre :

Pour activer RDP Multipath avant le déploiement complet, définissez la valeur de la clé de registre suivante sur 100, puis relancez la session de votre utilisateur

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 100 /f

Voici les informations de connection sur un poste Windows 365 après la modification de registre :

Si vous préférez désactiver RDP Multipath jusqu’à ce que le déploiement soit terminé, définissez la valeur de la clé de registre sur 0 :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 0 /f

Conclusion

En synthèse, RDP Multipath représente une véritable avancée pour Azure Virtual Desktop : il combine la rapidité et la légèreté du transport UDP avec robustesse et la redondance.

Grâce à la création et à la surveillance en continu de plusieurs sous‑canaux UDP, vos sessions basculent en quelques dizaines de millisecondes vers le chemin le plus sain, tout en retombant de façon transparente sur TCP si nécessaire.

Le résultat ?

Une expérience utilisateur fluide, sans micro‑coupure ni latence excessive, même sur des réseaux fortement dégradés.

N’attendez plus pour activer RDP Multipath sur vos environnements AVD : testez-le dès aujourd’hui et constatez par vous‑même l’amélioration significative de la résilience et de la qualité de vos connexions distantes.