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.

Forcer le flux TCP sur Azure Virtual Desktop / Windows 365

Les solutions de bureau à distance, telles qu’Azure Virtual Desktop et Windows 365, reposent sur des protocoles de transport pour offrir une expérience utilisateur fluide et réactive. Par défaut, UDP est souvent privilégié pour sa faible latence, mais dans certains environnements, la fiabilité et la stabilité offertes par TCP priment.

Cet article détaille les spécificités de chacun de ces protocoles, leurs avantages et inconvénients, et propose deux approches pour forcer l’usage de TCP : une modification côté serveur et une modification côté client, que ce soit directement via le registre ou en déployant une stratégie de groupe (GPO).

TCP et son rôle dans les solutions de bureau à distance :

Le Transmission Control Protocol (TCP) est un protocole orienté connexion qui assure la fiabilité des échanges. Il garantit que les paquets arrivent dans l’ordre et, en cas de perte, les retransmet automatiquement.

Avantages de TCP :

  • Fiabilité et intégrité des données : Chaque paquet est vérifié et retransmis en cas d’erreur ou de perte.
  • Contrôle d’erreur et ordonnancement : Les données arrivent dans le bon ordre, ce qui est essentiel pour des applications nécessitant une cohérence stricte.

Inconvénients de TCP :

  • Surcharge et latence accrue : Les mécanismes de contrôle (comme le handshake initial) ajoutent un certain délai.
  • Moins performant pour les applications ultra-réactives : La latence induite peut être un frein pour certaines applications en temps réel.

UDP et ses applications dans le Remote Desktop :Le User Datagram Protocol (UDP) est un protocole sans connexion qui envoie les paquets sans vérifier leur réception ni leur ordre. Cette approche permet une transmission rapide avec une latence très réduite, idéale pour des sessions interactives.

Avantages de UDP :

  • Faible latence : Parfait pour des sessions de Remote Desktop où la réactivité est cruciale.
  • Moindre surcharge : L’absence de contrôle d’erreur exhaustif accélère le transfert des données.

Inconvénients de UDP :

  • Fiabilité moindre : Sans retransmission automatique, la perte de paquets peut dégrader la qualité de la session.
  • Absence de contrôle d’erreur intégré : Dans des environnements instables, cela peut entraîner des distorsions.

Fort de cette comparaison, il apparaît que le choix du protocole doit être adapté au contexte réseau. Par exemple, dans des environnements à qualité réseau variable, forcer l’utilisation de TCP peut s’avérer judicieux pour garantir une meilleure stabilité des connexions.

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.

Modification via Registre

Avant modification, le serveur accepte par défaut les connexions en UDP (comme indiqué par vos captures d’écran). Pour forcer TCP, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport.

Pour ce faire, 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 modification, la connexion se fait exclusivement en TCP. Cette commande force le serveur à utiliser uniquement TCP pour les connexions RDP.

Déploiement via GPO

Microsoft propose également une stratégie de groupe qui permet de spécifier le protocole RDP à utiliser. Vous pouvez la trouver sous :

Computer Configuration > Administration Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Host > Connections

La politique associée permet de choisir entre :

  • « Use either UDP or TCP (default) » : Si la connexion UDP est possible, la majorité du trafic RDP l’utilisera.
  • « Use only TCP » : Toutes les connexions RDP se feront exclusivement via TCP.

Si cette stratégie n’est pas configurée ou est désactivée, RDP sélectionnera automatiquement le protocole optimal pour offrir la meilleure expérience utilisateur.

Testons maintenant la configuration côté client.

Forcer le flux TCP côté client

Passons à présent à la configuration côté client. Avant modification, le client se connecte en UDP, comme le montrent les captures d’écran. Pour forcer l’utilisation de TCP (via WebSocket, qui repose sur TCP), il suffit d’ajouter la clé de registre fClientDisableUDP.

Avant modification, le client fonctionnait en UDP, comme vous pouvez le constater sur la capture d’écran ci‑dessous.

Pour ce faire, la modification est simple : il suffit d’ajouter la clé de registre fClientDisableUDP.

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\Client" /v fClientDisableUDP /t REG_DWORD /d 1 /f

Après modification, la connexion se fait exclusivement en TCP. Ce changement assure que le client ne tente plus d’établir une connexion via UDP :

Conclusion

Le choix entre TCP et UDP dans des environnements de bureau à distance comme Azure Virtual Desktop et Windows 365 se résume à un compromis entre rapidité et fiabilité :

  • UDP offre une faible latence, idéale pour des sessions interactives, mais peut souffrir de pertes de paquets dans des réseaux instables.
  • TCP, même via une couche WebSocket, garantit la transmission fiable des données, au prix d’un léger surcoût en latence.

Note technique : Forcer l’utilisation de TCP est particulièrement recommandé dans les environnements où la qualité du réseau est variable ou sujette à des perturbations. Dans ces situations, bien que TCP puisse introduire une latence légèrement supérieure, il offre une stabilité et une fiabilité accrues, assurant ainsi une expérience utilisateur plus homogène.

En forçant l’utilisation de TCP via une modification de registre côté serveur (ou via une GPO) et/ou côté client, vous pouvez améliorer la stabilité des connexions, particulièrement dans des environnements où la qualité de la connexion est incertaine.

Ces approches vous permettent de mieux contrôler la configuration de votre infrastructure de Remote Desktop, optimisant ainsi l’expérience pour vos utilisateurs.

AVD : Restriction du Presse-papier

La restriction du presse-papier Windows entre le poste local et une session Azure Virtual Desktop est déjà possible depuis la configuration du protocole RDP. Mais la personnalisation des restrictions peut être poussée encore d’un cran. Avec Intune, vous pouvez exiger que le fameux copier-coller ne fonctionne que dans un sens spécifique, ou même uniquement que pour certains types de donnée !

Comme annoncé en introduction, vous pouvez déjà configurer beaucoup de paramètres RDP pour Azure Virtual Desktop. La configuration du protocole RDP est directement disponible depuis la configuration de votre pool d’hôtes de session Azure Virtual Desktop.

Le protocole RDP (Remote Desktop Protocol) possède plusieurs propriétés que vous pouvez définir pour personnaliser le comportement d’une session à distance, par exemple pour la redirection d’appareil, les paramètres d’affichage, le comportement de session, etc.

Microsoft Learn

Quelles sont les propriétés RDP prises en charges par AVD ?

Toutes les propriétés existantes au protocole RDP ne sont pas intégrées à Azure Virtual Desktop. Voici la liste de ceux compatibles avec AVD, et sont aussi disponibles sur la page officielle de Microsoft :

Propriété RDPDescription
encode redirected video captureActive ou désactive l’encodage de la vidéo redirigée.
targetisaadjoinedAutorise les connexions aux hôtes de session joints à Microsoft Entra à l’aide d’un nom d’utilisateur et d’un mot de passe. Cette propriété s’applique uniquement aux clients non-Windows et aux appareils Windows locaux qui ne sont pas joints à Microsoft Entra. Elle est remplacée par la propriété enablerdsaadauth.
camerastoredirectConfigure les caméras à rediriger. Ce paramètre utilise une liste délimitée par des points-virgules des interfaces KSCATEGORYVIDEOCAMERA des caméras activées pour la redirection.
redirected video capture encoding qualityContrôle la qualité de la vidéo encodée.
maximizetocurrentdisplaysDétermine l’affichage d’une session à distance utilisée pour l’écran plein écran lors de l’optimisation. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows et l’application Bureau à distance pour Windows.
drivestoredirectDétermine les lecteurs fixes, amovibles et réseau sur l’appareil local qui seront redirigés et disponibles dans une session à distance.
devicestoredirectDétermine les périphériques qui utilisent le protocole MTP (Media Transfer Protocol) ou le protocole PTP (Picture Transfer Protocol), comme une caméra numérique, sont redirigés d’un appareil Windows local vers une session à distance.
usbdevicestoredirectDétermine les périphériques USB pris en charge sur l’ordinateur client qui sont redirigés à l’aide d’une redirection opaque de bas niveau vers une session distante.
bandwidthautodetectDétermine s’il faut ou non utiliser la détection automatique de la bande passante réseau.
redirected clipboardDétermine s’il faut rediriger le Presse-papiers.
smart sizingDétermine si l’appareil local met à l’échelle le contenu de la session distante pour qu’il corresponde à la taille de la fenêtre.
autoreconnection enabledDétermine si l’appareil local tente automatiquement de se reconnecter à l’ordinateur distant si la connexion est supprimée, par exemple en cas d’interruption de la connectivité réseau.
redirectlocationDétermine si l’emplacement de l’appareil local est redirigé vers une session distante.
audiomodeDétermine si l’ordinateur local ou distant lit l’audio.
compressionDétermine si la compression en bloc est activée lors de la transmission de données à l’appareil local.
videoplaybackmodeDétermine si la connexion utilisera le streaming multimédia efficace par RDP pour la lecture vidéo.
networkautodetectDétermine si la détection automatique des types de réseau est activée.
dynamic resolutionDétermine si la résolution d’une session distante est automatiquement mise à jour lorsque la fenêtre locale est redimensionnée.
use multimonDétermine si la session distante utilise un ou plusieurs affichages à partir de l’appareil local.
enablerdsaadauthDétermine si le client utilisera l’ID Microsoft Entra pour s’authentifier auprès du PC distant. Lorsqu’il est utilisé avec Azure Virtual Desktop, cela offre une expérience d’authentification unique. Cette propriété remplace la propriété targetisaadjoined.
enablecredsspsupportDétermine si le client utilisera le fournisseur de support de sécurité des informations d’identification (CredSSP) pour l’authentification s’il est disponible.
redirectsmartcardsDétermine si les appareils de carte à puce sur l’appareil local sont redirigés et disponibles dans une session à distance.
keyboardhookDétermine si les combinaisons de touches Windows (Windows, OngletAlt+) sont appliquées à une session à distance.
redirectprintersDétermine si les imprimantes disponibles sur l’appareil local sont redirigées vers une session à distance.
redirectcomportsDétermine si les ports série ou COM sur l’appareil local sont redirigés vers une session distante.
redirectwebauthnDétermine si les requêtes WebAuthn d’une session distante sont redirigées vers l’appareil local, ce qui permet d’utiliser des authentificateurs locaux (tels que des clés de sécurité et de Windows Hello Entreprise).
screen mode idDétermine si une fenêtre de session distante s’affiche en plein écran lorsque vous lancez la connexion.
singlemoninwindowedmodeDétermine si une session distante à affichage multiple bascule automatiquement vers un affichage unique lors de la sortie de l’écran plein écran. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows et l’application Bureau à distance pour Windows.
audiocapturemodeIndique si la redirection d’entrée audio est activée.
desktopheightSpécifie la hauteur de résolution (en pixels) d’une session distante.
desktopwidthSpécifie la largeur de résolution (en pixels) d’une session distante.
desktopscalefactorSpécifie le facteur d’échelle de la session distante pour rendre le contenu plus grand.
kdcproxynameSpécifie le nom de domaine complet d’un proxy KDC.
selectedmonitorsSpécifie les affichages locaux à utiliser dans une session distante. Les affichages sélectionnés doivent être contigus. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows, l’application Bureau à distance pour Windows et l’application de connexion Bureau à distance de boîte de réception sur Windows.
desktop size idSpécifie les dimensions d’un bureau de session à distance à partir d’un ensemble d’options prédéfinies. Ce paramètre est remplacé si les paramètres desktopheight et desktopwidth sont spécifiés.
alternate shellSpécifie un programme à démarrer automatiquement dans une session distante en tant que shell au lieu de l’Explorateur.

Où les modifier ?

Certaines propriétés RDP sont en effet modifiables depuis ces écrans du pool d’hôtes :

  • Informations de connexion :
  • Comportement de la session :
  • Redirection de périphérique :

Comme vous pouvez le voir dans la copie d’écran ci-dessous, la configuration détermine si le presse-papiers de l’ordinateur client sera redirigé et disponible ou non dans la session distante, et vice versa :

  • Le presse-papiers de l’ordinateur local est disponible dans la session à distance (par défaut)
  • Le presse-papiers de l’ordinateur local n’est pas disponible dans la session à distance
  • Non configuré
  • Paramètres d’affichage
  • Avancé

Peut-on configurer le comportement de redirection du Presse-papiers plus finement ?

Oui, cela est possible grâce à l’une des 3 méthodes suivantes :

  • Via Microsoft Intune
  • Via une stratégie de groupe
  • Via une ou des clefs de registre dans la golden image

Travis vous explique en détail la fonctionnalité via les clefs de registre Windows :

Dans cet article, je vous propose de tester la méthode via Intune :

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

Etape 0 – Rappel des prérequis :

Peu de prérequis sont nécessaires pour réaliser ce test AVD sur les restrictions du presse-papier Windows :

  • Un tenant Microsoft
  • Une souscription Azure valide

Dans ce test, nous allons déployer un environnement Azure Virtual Desktop composé de 5 machines virtuelles individuelles. Ces 5 machines nous permettront de comparer les différentes configurations Intune afin de voir les changement dans le presse-papier :

  • Aucune restriction
  • Restriction complète
  • Restriction depuis le poste local
  • Restriction depuis AVD
  • Restriction sur le format de donné

Etape I – Préparation Azure Virtual Desktop :

Avant tout, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création par la barre de recherche :

Nommez celui-ci, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :

Une fois le réseau virtuel déployé, continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant là encore la barre de recherche du portail Azure :

Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop 

Choisissez un pool d’hôtes de type personnel, puis cliquez sur Suivant :

Définissez le nombre de machines virtuelles créées ainsi que la région Azure, puis choisissez l’image OS :

Choisissez les caractéristiques techniques de vos machines virtuelles AVD, puis spécifiez le réseau virtuel adéquat :

Effectuez une joindre à Entra ID en incluant Intune ainsi que les informations d’identification du compte administrateur local, puis cliquez sur Suivant :

Définissez un nouvel espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :

Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer l’assignation des utilisateurs :

Assignez les 5 utilisateurs de test à votre groupe d’application AVD :

Assignez ces mêmes 5 utilisateurs de test AVD aux 5 machines virtuelles créés :

N’oubliez pas la configuration RDP suivante, puis Sauvegarder :

Notre environnement Azure Virtual Desktop est maintenant en place. La suite de la configuration des restriction passera par le portail Intune.

Etape II – Configuration Intune :

Rendez-vous sur le portail Intune afin de créer 4 groupes Entra ID qui serviront à tester tous les scénarios de restriction du presse-papier :

Pour chacun de ces groupes, ajoutez dans chacun d’eux une machine virtuelles AVD de test :

Consultez la liste des machines virtuelles inscrites sur Intune pour vérification :

Commencez par créer une première police de configuration Intune, par exemple la restriction maximale :

Choisissez les options suivantes, puis cliquez sur Créer :

Nommez votre profil de configuration Intune, puis cliquez sur Suivant :

Recherchez dans le catalogue les options suivantes afin de les activer, ce qui aura pour effet de bloquer dans les 2 sens le presse-papier pour tous les types de transfert, puis cliquez sur Suivant :

Cliquez sur Suivant :

Ajouter un des 4 groupes de machines virtuelles créé précédemment, puis cliquez sur Suivant :

Vérifiez les paramètres une dernière fois, puis cliquez sur Créer :

Créer les 3 autres polices en faisant varier les réglages liés au presse-papier :

Retournez sur le menu suivant afin de pousser les configurations sur les machines virtuelles AVD dès que possible :

Renseignez les champs suivants, puis cliquez sur Suivant :

Ajoutez les machines virtuelles AVD, puis cliquez sur Suivant :

Lancez la synchronisation Intune en cliquant sur Créer :

Attendez quelques minutes afin de constater l’application avec succès des différentes polices de configuration sur les machines virtuelles AVD :

Attendez quelques minutes, puis retournez sur le portail Azure afin de redémarrer les machines virtuelles AVD pour que les modifications soient prises en compte :

Constatez l’indisponibilité des machines virtuelles AVD pendant la phase de redémarrage :

Constatez la disponibilité des machines virtuelles AVD quelques minutes plus tard :

Notre environnement avec les 5 machines virtuelles AVD est prêt pour les différents tests. Dans mon cas, je vais utiliser l’application Remote Desktop afin d’exécuter en parallèle les 5 sessions de bureau à distance :

J’ai donc ouvert 5 sessions AVD pour mes 5 utilisateurs de test :

Commençons par un premier test sans aucune restriction sur le presse-papier.

Etape III – Test Presse-papier sans restriction :

Cette première machine virtuelle n’est pas présente dans groupe Entra ID et n’a donc aucune police de configuration associée :

La copie d’écran de test ci-dessous nous apprend les éléments suivants :

  • Aucune configuration n’est présente dans le registre Windows
  • Le copier-coller d’un fichier depuis le poste local vers AVD fonctionne
  • Le copier-coller d’un fichier depuis AVD vers le poste local fonctionne

Continuons avec un second test avec une restriction complète du presse-papier.

Etape IV – Test Presse-papier avec restriction complète :

Cette seconde machine virtuelle dispose de la configuration Intune suivante :

La configuration Intune a bien été déployée sur ma machine virtuelle :

La copie d’écran de test ci-dessous nous apprend les éléments suivants :

  • 2 configurations sont présentes dans le registre Windows
  • Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
  • Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas

Continuons avec un troisième test avec une restriction sur le presse-papier depuis le poste local.

Etape V – Test Presse-papier avec restriction depuis le poste local :

Cette troisième machine virtuelle dispose de la configuration Intune suivante :

La configuration Intune a bien été déployée sur ma machine virtuelle :

La copie d’écran de test ci-dessous nous apprend les éléments suivants :

  • 1 configuration est présente dans le registre Windows
  • Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
  • Le copier-coller d’un fichier depuis AVD vers le poste local fonctionne

Continuons avec un quatrième test avec une restriction sur le presse-papier depuis AVD.

Etape VI – Test Presse-papier avec restriction depuis AVD :

Cette quatrième machine virtuelle dispose de la configuration Intune suivante :

La configuration Intune a bien été déployée sur ma machine virtuelle :

La copie d’écran de test ci-dessous nous apprend les éléments suivants :

  • 1 configuration est présente dans le registre Windows
  • Le copier-coller d’un fichier depuis le poste local vers AVD fonctionne
  • Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas

Continuons avec un dernier test avec une restriction sur le format de donnée sur le presse-papier.

Etape VII – Test Presse-papier avec restriction sur le format de donné :

Cette dernière machine virtuelle dispose de la configuration Intune suivante :

La configuration Intune a bien été déployée sur ma machine virtuelle :

La copie d’écran de test ci-dessous nous apprend les éléments suivants :

  • 2 configurations sont présentes dans le registre Windows
  • Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
  • Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
  • Le copier-coller d’un texte depuis AVD vers le poste local fonctionne
  • Le copier-coller d’une image depuis AVD vers le poste local fonctionne

Conclusion

La mise en place de restrictions sur le presse-papier via Intune renforcera la sécurité et son importance cruciale dans les environnements virtuels. En limitant le transfert de fichiers et certaines données sensibles, nous pouvons renforcer significativement la protection des informations.

Enfin, Intune permet de simplifier la gestion des politiques de sécurité Azure Virtual Desktop et Windows 365 via ses nombreuses règles disponibles sur étagère.

AVD + mise à l’échelle dynamique

Microsoft vient d’annoncer lors de l’Ignite 2024 le plan de mise à l’échelle dynamique pour Azure Virtual Desktop. Mais qu’apporte donc cette nouvelle méthode dite dynamique à cette fonctionnalité déjà existante sur Azure Virtuel Desktop? C’est ce que nous allons voir ensemble dans cet article, encore dans un état de préversion à l’heure où ces lignes sont écrites.

Mais qu’est-ce que le plan de mise à l’échelle ?

La plan de mise à l’échelle, ou autoscaling en anglais, est déjà disponible pour les environnements AVD mutualisés et individuels depuis déjà quelques temps. Deux articles parlant de ce sujet sont déjà disponibles sur ce blog :

La mise à l’échelle automatique vous permet d’effectuer un scale-up ou un scale-down de vos hôtes de session de machines virtuelles dans un pool d’hôtes pour optimiser les coûts de déploiement.

Microsoft Learn

Microsoft a mis à jour sa documentation afin d’expliquer en détail les 4 grandes fonctionnalités de la mise à l’échelle dans le cadre d’un environnement AVD partagé :

Voici d’ailleurs une représentation diapo de trois d’entre elles :

Grâce à ces différents mécanismes, le plan de mise à l’échelle vous permet de moduler à la hausse ou à la baisse le nombre de VMs allumées à un moment précis selon les besoins.

Mais quelles sont les 4 phases du plan de mise à l’échelle ?

Vous pouvez établir un plan de mise à l’échelle basé sur :

  • Des créneaux horaires exprimés en heures.
  • Des créneaux journaliers exprimés en jours.

Tous les plannings de mise à l’échelle AVD comprennent les 4 phases suivantes :

  1. Montée en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se connecter aux hôtes de session. Par exemple, si votre bureau ouvre à 9h, vous pouvez prévoir que les utilisateurs commencent à se connecter entre 8h30 et 9h.
  2. Période de pointe : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de connexion stable. Par exemple, entre 09h et 17h, la plupart des utilisateurs sont connectés et travaillent activement. De nouveaux utilisateurs peuvent se connecter, mais à un rythme plus lent que pendant la montée en charge.
  3. Descente en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se déconnecter et à terminer leurs sessions pour la journée de travail. Par exemple, entre 17h et 18h, les utilisateurs commencent à se déconnecter. Dans cette phase, vous pouvez définir un pourcentage minimum plus bas d’hôtes actifs et une taille minimale de pool d’hôtes pour réduire le nombre de VM d’hôtes de session en état de fonctionnement ou arrêtées.
  4. Hors-période : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de déconnexion stable. Par exemple, après 20h, la plupart des utilisateurs sont déconnectés. De nouveaux utilisateurs peuvent se connecter pour des scénarios d’urgence, mais ces cas peuvent être rares.

Azure Virtual Desktop propose également des graphiques afin de comprendre le gain et l’efficacité du mécanisme :

Mais qu’apporte la méthode dynamique du plan de mise à l’échelle ?

Peu importe la méthode choisie, les phases et les fonctionnalités d’un plan de mise à l’échelle restent les mêmes. Mais ce qui change concerne directement les machines virtuelles AVD :

  • Dans la méthode dite Gestion de l’énergie : la plan de mise à l’échelle peut allumer et éteindre des machines virtuelles AVD selon les usages et la programmation mise en place.
  • Dans la méthode dite dynamique : la plan de mise à l’échelle peut créer ou supprimer des machines virtuelles AVD selon les usages et la programmation mise en place.

La méthode dynamique du plan de mise à l’échelle s’appuie également sur la toute nouvelle fonctionnalité AVD, appelée Mise à jour de l’hôte de session pour Azure Virtual Desktop, pour recréer les machines virtuelles.

La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de la machine virtuelle (VM) sous-jacente, l’image du système d’exploitation (OS) et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session. La mise à jour de l’hôte de session désalloue ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour. Cette méthode de mise à jour des hôtes de session est conforme à la suggestion de gestion des mises à jour au sein de l’image source principale, plutôt que de distribuer et d’installer les mises à jour sur chaque hôte de session individuellement selon un calendrier répété continu pour les maintenir à jour.

Voici les modifications que vous pouvez apporter lors d’une mise à jour :

  • Image de machine virtuelle
  • Taille de la machine virtuelle
  • Type de disque de machine virtuelle
  • Type de sécurité de la machine virtuelle
  • Informations d’identification de jonction de domaine Active Directory
  • Inscription à Microsoft Intune
  • Informations d’identification de l’administrateur local
  • Exécutez un script PowerShell de configuration personnalisé

Microsoft Learn

Cette approche de création / suppression intégrée permet donc de réduire encore plus les coûts.

Couplée avec la mise à jour de l’hôte de session, la création et la suppression de machines virtuelles AVD devient d’autant plus simple, et assure de toujours disposer de ressources Azure Virtual Desktop dans leur dernière version.

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

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la méthode dynamique du plan de mise à l’échelle d’Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un environnement AVD configuré avec la mise à jour de l’hôte de session

Il ne faut pas oublier que certaines contraintes AVD sont de rigueur :

  • Ne fonctionne pas pour les pool d’hôtes AVD individuels
  • Ne fonctionne pas pour le moment sur un environnement AVD joint uniquement à Entra ID
  • Ne fonctionne pas sur un AVD hébergé sur Azure Local
  • Nécessite également de disposer d’un AVD déjà configuré avec la mise à jour de l’hôte de session

Cette information est disponible ici :

Il est également nécessaire de renseigner un nombre maximal de sessions AVD :

Commençons par ajouter des permissions RBAC nécessaires à la gestion des VMs AVD.

Etape I – Ajout des permissions RBAC :

Le traitement de création/suppression des machines virtuelles AVD a besoin de lire la configuration gérée par le nouvelle orchestrateur en chargement de votre pool d’hôtes. Il est pour l’instant nécessaire créer un rôle Azure personnalisé afin de pouvoir récupérer ces informations.

Pour cela, rendez-vous dans le portail Azure, puis commencez sa création depuis le groupe de ressources contenant votre environnement AVD :

Nommez votre nouveau rôle personnalisé, puis cliquez sur Suivant :

Recherchez la permission suivante, puis cliquez sur lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre rôle Azure personnalisé :

Toujours sur votre groupe de ressources AVD, assignez à l’application Azure Virtual Desktop les 3 rôles suivant, en plus de votre nouveau rôle personnalisé :

  • Contributeur de mise sous et hors tension de la virtualisation du Bureau
  • Contributeur à la machine virtuelle de la virtualisation des postes de travail
  • Utilisateur de Key Vault Secrets

Une fois les droits en place, il ne reste qu’à rajouter la mise à l’échelle dynamique sur notre environnement Azure Virtual Desktop.

Etape II – Création du plan de mise à l’échelle dynamique :

Comme avant, la création d’un plan de mise à l’échelle dynamique AVD apporte les avantages / restrictions suivants :

  • Le plan de mise à l’échelle dynamique est utilisable pour un ou plusieurs environnement Azure Virtual Desktop, à la condition que ces derniers nécessitent une gestion horaire identique
  • Ne pas associer le plan de mise à l’échelle dynamique avec d’autres solutions tierces de gestion des ressources Azure
  • Il n’est pas possible d’associer plusieurs plans de mise à l’échelle dynamique sur un seul environnement AVD
  • Le plan de mise à l’échelle dynamique est dépendant d’un seul fuseau horaire
  • Le plan de mise à l’échelle dynamique est configurable sur plusieurs périodes distinctes
  • Le plan de mise à l’échelle dynamique est opérationnel dès sa configuration terminée

Avant cela, prenez le temps de vérifier la configuration de l’hôte de session AVD déjà en place :

La création du plan de mise à l’échelle dynamique se fait directement sur la page d’Azure Virtual Desktop, cliquez ici pour démarrer sa création :

Remplissez le premier onglet avec vos informations de base et indiquez que votre environnement AVD est partagé :

Choisissez l’option le plan de mise à l’échelle dynamique, puis cliquez sur Suivant :

L’onglet suivant vous permet de définir quand le plan de mise à l’échelle dynamique s’active pour suivre les besoins de montée / descente en puissance tout au long de la journée.

Cliquez comme ceci pour ajouter votre première période :

Choisissez un Nom, puis sélectionnez les Jours adéquats (les valeurs par défaut qui s’affichent lorsque vous créez une planification sont les valeurs suggérées pour les jours de la semaine, mais vous pouvez les modifier selon vos besoins) :

Les informations ci-dessous de l’onglet Général ne servent qu’à définir les valeurs reprises dans les autres onglets :

  • Pourcentage minimum d’hôtes actifs : exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée :
Par exemple, si le pourcentage minimum d’hôtes actifs (%) est fixé à 10 et que la taille minimum du pool d’hôtes est fixée à 10, le plan de mise à l’échelle dynamique veillera à ce qu’un hôte de session soit toujours disponible pour accepter les connexions des utilisateurs.
  • Nombre min de VMs : nombre de machines virtuelles hôtes de session devant toujours faire partie du pool d’hôtes. Ces dernières peuvent être active ou à l’arrêt niveau OS.
  • Nombre max de VMs : nombre de machines virtuelles hôtes de session que le plan de mise à l’échelle dynamique ne dépassera pas. Ces dernières peuvent être active ou à l’arrêt niveau OS.

Puis cliquez sur Suivant :

Montée en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se connecter aux hôtes de session.

  • Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
  • Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
  • Seuil de capacité : pourcentage de la capacité disponible du pool d’hôtes qui déclenchera une action de mise à l’échelle.

Puis cliquez sur Suivant :

Dans mon exemple, je n’ai pas modifié les 49% indiqués sur mon environnement avec un minimum 1 et maximum de 2 machines virtuelles. Cela force AVD a :

  • Si le nombre d’utilisateurs AVD reste sous la limite du nombres de sessions par VM :
    • Conserver une seule machine virtuelle créée et allumée
  • Si le nombre d’utilisateurs AVD dépasse la limite du nombres de sessions par VM :
    • Créer et allumer la seconde machine virtuelle

Période de pointe : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de connexion stable. Il n’est possible que de modifier :

  • Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
  • Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.

Puis cliquez sur Suivant :

Descente en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se déconnecter et à terminer leurs sessions pour la journée de travail. Il vous est possible de modifier les champs suivant :

  • Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
  • Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
  • Seuil de capacité : pourcentage de la capacité disponible du pool d’hôtes qui déclenchera une action de mise à l’échelle.
  • Forcer la déconnexion des utilisateurs : Oui / non
  • Pourcentage minimum d’hôtes actifs : exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée :
  • Limite du nombre de machines virtuelles actives : exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée.
  • Nombre min de VMs : nombre de machines virtuelles hôtes de session devant toujours faire partie du pool d’hôtes. Ces dernières peuvent être active ou à l’arrêt niveau OS.
  • Nombre max de VMs : nombre de machines virtuelles hôtes de session que le plan de mise à l’échelle dynamique ne dépassera pas. Ces dernières peuvent être active ou à l’arrêt niveau OS.

Puis cliquez sur Suivant :

Hors-période : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de déconnexion stable. Il n’est possible que de modifier :

  • Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
  • Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.

Puis cliquez sur Ajouter :

Il est possible d’ajouter une second planning si besoin, mais uniquement sur les autres jours restants, sinon cliquez sur Suivant :

Sélectionnez le pool d’hôtes concerné et lancez la validation Azure :

Une fois la validation Azure réussie, lancez la Création :

Consultez le plan de mise à l’échelle dynamique :

Avant l’application du plan de mise à l’échelle dynamique, je retrouve bien 3 en nombre de machines virtuelles AVD :

Etape III – Test de suppression de VM :

Après l’application du plan de mise à l’échelle dynamique, je retrouve bien une seule machine virtuelle AVD :

Seule une machine virtuelle est bien encore présente dans mon environnement Azure :

Grâce à Azure Monitor, il est possible de consulter les actions faites par le plan de mise l’échelle dynamique :

Du côté des insights AVD, un nouvel onglet dédié au plan de mise à l’échelle a fait son apparition :

Etape IV – Test de création de VM :

Afin de vérifier la création automatique des machines virtuelles AVD, je décide de connecter un utilisateur à mon environnement afin de dépasser le seuil de capacité :

L’utilisateur est bien référencé comme connecté :

Un nouvel événement est alors visible dans la table et indiquant la création d’une seconde machine virtuelle :

Ce même événement est également visible depuis les insights AVD avec son explication textuelle :

Dans la liste des machines virtuelles de mon environnement, je retrouve bien la seconde VM en cours de création :

Azure Virtual Desktop met à jour au besoin les agents AVD sur la nouvelle machine rajoutée au pool d’hôtes :

La nouvelle machine virtuelle contient bien la dernière version disponible et son nom confirme la bonne jointure au domaine AD :

La nouvelle machine virtuelle devient alors disponible et prête à recevoir des utilisateurs AVD :

Etape V – Second test de création de VM :

Toujours dans la même phase je décide de connecter un second utilisateur AVD :

Ayant configuré un algorithme de répartition de la charge en Depth-first, le second utilisateur se retrouve sur la même machine virtuelle que le premier utilisateur :

Rien ne se passe malgré le dépassement de 50% du total car j’ai configuré un plafond de 2 machines virtuelles durant cette phase de mon plan de mise à l’échelle :

Cette analyse est confirmée ici par le 3ème événement :

Je décide néanmoins de modifier dans mon plan de mise à l’échelle dynamique les 2 valeurs suivantes :

La validation du plan de mise à l’échelle dynamique entraîne, comme attendu, la création immédiate d’une 3ème machine virtuelle AVD :

Cette analyse est confirmée par le 4ème événement :

La 3ème machine virtuelle AVD apparaît bien dans le pool d’hôtes avec un statut disponible :

Etape VI – Second test de suppression de VM :

Pour mon dernier test, je décide de déconnecter mes 2 utilisateurs de test AVD :

Les sessions Azure Virtual Desktop ouvertes disparaissent bien de la console Azure :

Et il ne reste plus aucune machine virtuelle Azure :

Cette analyse est confirmée par le 5ème événement :

A noter qu’un minimum de 0 sessions actives entraîne le message d’erreur suivant pour l’utilisateur :

Conclusion

En conclusion, nous avons découvert que ce plan permet une gestion flexible et efficace des ressources, assurant ainsi une optimisation des coûts et une disponibilité continue des services.

L’activation automatique d’une machine virtuelle supplémentaire en réponse à une demande accrue, ainsi que la réduction rapide du nombre de machines en cas de baisse d’activité, illustrent la capacité de ce service à s’ajuster en temps réel aux besoins des utilisateurs.

En somme, Azure Virtual Desktop, grâce à son plan de mise à l’échelle dynamique, propose une solution robuste pour la gestion des environnements de travail virtuels.