Testez Microsoft Foundry

Bienvenue dans ce lab pratique consacré à Microsoft Foundry, la plateforme unifiée qui permet d’explorer, tester et déployer des expériences d’intelligence artificielle au sein de l’écosystème Azure. Cet article retrace pas à pas les différentes étapes du lab afin de permettre à chacun de revivre l’expérience ou de la reproduire en autonomie.

Lors du Chalet Azure Romandie du 27 novembre 2025, les participants ont pu découvrir concrètement comment manipuler des modèles avancés comme gpt-4o et Sora, créer leurs propres agents, générer des vidéos IA, ajouter des filtres de sécurité, traduire des documents, ou encore produire un avatar animé.

Voici donc les 5 défis que vous pouvez également essayer :

Etape 0 – Connexion à Microsoft Foundry :

Pour réaliser cet exercice sur Microsoft 365 Archive, il vous faudra disposer d’une souscription Azure valide.

Ouvrez un navigateur web, puis saisissez l’URL du portail Azure AI Foundry (nouvellement Microsoft Foundry) :

Authentifiez-vous avec un e-mail professionnel ou personnel :

Une fois authentifiée, conservez l’ancienne présentation du portail de Microsoft Foundry, appelée encore Azure AI Foundry, afin de suivre les consignes ci-dessous plus facilement :

Commençons le premier défi par le déploiement d’un agent.

Défi I – Création d’un Agent Smith :

Nous allons déployer un agent qui s’appuiera sur le modèle gpt-4o et répondra aux différentes questions du défi.

Pour cela, cliquez-ici pour créer votre agent :

Mais comme aucun projet IA n’est encore présent, nous allons commencer par la création de celui-ici. Pour cela, renseignez les informations pour la création de votre nouveau projet IA, puis lancez sa création :

  • Dans le champ Projet, saisissez projet-agent
  • Développez options avancées
  • Choisissez la souscription Azure disponible
  • Donnez un nom unique à votre ressource Azure AI Foundry
  • Nommez rg-chalet-romandie le nom de votre groupe de ressource
  • Vérifiez que la région Azure East US 2 est bien sélectionnée

Attendez environ 2 à 3 minutes pour la fin de la création des ressources Azure :

Une fois le déploiement terminé, cliquez sur le menu Playgrounds afin de commencer par le déploiement d’un premier modèle IA, recherchez dans la liste le modèle gpt-4o, puis cliquez sur le bouton Confirmer :

Conservez les options de base de votre modèle, puis cliquez sur le bouton Déployer :

Une fois le modèle IA déployé, retournez dans le menu Playgrounds afin de lancer le prompt suivant sur le nouvel agent, automatiquement créé et lié à votre modèle :

Générer une blague sur les informaticiens

L’erreur suivante peut apparaître. Elle indique que les ressources IA ne sont pas encore entièrement accessibles :

Après plusieurs minutes et plusieurs essais, vous devriez obtenir une réponse dans le chat de la part de votre agent IA :

Votre défi est réussi, vous pouvez le faire valider, puis passez au défit suivant.

Défi II – Génération d’une vidéo IA :

Imaginez pouvoir créer des scènes vidéo réalistes, des animations et des effets spéciaux, à partir d’instructions textuelles simples et précises. Foundry vous permet de réaliser cette prouesse à l’aide du modèle Sora d’OpenAI.

La génération de vidéos dans ce cas est un processus asynchrone. Vous créez une demande de travail avec vos spécifications d’invite (ou prompt en anglais) de texte et de format vidéo, et le modèle traite la demande en arrière-plan.

Une fois terminé, récupérez la vidéo générée via une URL de téléchargement.

Cliquez sur le menu à gauche Playgrounds, puis le menu suivant afin de tester la génération de vidéos par l’IA :

Cliquez ici pour déployer un nouveau modèle IA destiné à la génération de la vidéo :

Choisissez le modèle Sora dans la liste, puis cliquez sur Confirmer :

Conservez les options de base, puis cliquez sur le bouton Déployer :

Une fois le modèle Sora déployé, retournez dans le menu Playgrounds afin de lancer le prompt de génération de la vidéo :

Sélectionnez la résolution 720p, une durée de 10 secondes, saisissez votre prompt qui générera une vidéo époustouflante, puis cliquez sur le bouton Générer.

Attendez quelques instants avant de pouvoir constater le résultat :

Après quelques instants, visionnez le résultat généré par Sora :

Votre défi est réussi, vous pouvez le faire valider, puis passer au défit suivant.

Défi III – Filtrage IA de contenu :

Microsoft Foundry embarque en standard les composants Azure AI Content Safety pour filtrer les contenus répréhensibles générés ou traités (détection de langage toxique, données personnelles partagées, etc…).

Nous allons créer un filtre et une liste de blocage basés sur le mot AWS. Nous allons dans un premier temps créer une liste de blocage :

Saisissez un nom représentant la liste, blocklistaws, puis cliquez sur le bouton suivant pour créer celle-ci :

Ajoutez un nouveau terme :

Saisissez le terme AWS, puis ajoutez-le :

Nous allons maintenant créer notre propre filtre de contenu et l’associer à notre liste de blocage. Pour cela, cliquez sur le bouton ci-dessous pour créer un filtre de contenu :

Saisissez un nom représentant le filtre, filtrereomandie, puis cliquez sur le bouton Suivant :

Dans l’étape Filtre d’entrée, pour chaque catégorie (haine, violence …), spécifiez le niveau de dureté appliqué à Highest blocking , cochez la case Liste de blocage, sélectionnez blocklistaws, puis cliquez sur Suivant :

Dans l’étape Filtre de sortie, pour chaque catégorie (haine, violence …), spécifiez le niveau de dureté appliqué à Highest blocking , cochez la case Liste de blocage, sélectionnez blocklistaws, puis cliquez sur Suivant :

Sélectionnez le modèle qui recevra ce filtre de contenu personnalisé, dans notre cas gpt-4o :

Confirmez le remplacement du filtrage de contenu de page par le nouveau :

Lancez la création du filtrage IA :

Retournez dans Playgrounds, puis cliquez sur Chat playground :

Collez le prompt suivant dans le chat :

Comment utiliser AWS ?

Un retour négatif de la part d’Azure IA Foundry, et invoquant blocklistaws, devrait apparaître. Continuez avec le prompt suivant :

Comment me faire très mal au bras ?

Un retour négatif de la part d’Azure IA Foundry, et invoquant Self-harm, devrait apparaître.

Votre défi est réussi, vous pouvez le faire valider, puis passer au défit suivant.

Défi IV – Traduction IA de documents :

La traduction automatique est l’un des domaines historiques de l’IA de Microsoft. L’entreprise propose un service de traduction basé sur des réseaux de neurones, connu sous le nom d’Azure AI Translator, capable de traduire instantanément du texte ou des documents entiers d’une langue à une autre.

Cliquez sur le menu suivant afin de générer une traduction de texte :

Cliquez sur Text translation :

Collez le texte suivant, choisissez le français comme langue de destination, puis lancez la traduction :

好⼀朵美丽的茉莉花
好⼀朵美丽的茉莉花
芬芳美丽满枝桠
又⾹又⽩⼈⼈夸
让我来将你摘下
送给别⼈家
茉莉花呀茉莉花

Constatez le résultat traduit :

Passons maintenant au dernier défi IA.

Défi V – Avatar IA :

Azure Speech permet en résumé de tester et prototyper rapidement des fonctionnalités de reconnaissance vocale, conversion texte-vers-voix, traduction audio, etc., sans avoir à tout coder ou déployer de façon complète.

Cliquez sur le menu suivant afin de générer un avatar :

Choisissez le menu Text to speech avatar, puis cliquez sur Lisa parmi la liste des avatars disponibles :

Définissez la langue française, la voix de Vivienne, collez le texte ci-dessous, puis lancez la génération de la vidéo :

Romandie un jour, Romandie toujours.

Attendez quelques secondes la fin de la génération de la vidéo :

Une fois la vidéo générée, lancez-là pour en vérifier le contenu :

Une fois tous les défis terminés :

Conclusion

Ce parcours à travers Microsoft Foundry met en lumière la richesse des outils IA disponibles aujourd’hui : agents personnalisés, génération multimédia, filtrage de contenu, traduction, ou encore avatars vocaux.

Chaque défi illustre la maturité croissante de l’écosystème et la facilité avec laquelle il devient possible d’expérimenter, prototyper et imaginer de nouvelles solutions basées sur l’IA.

Que ce lab inspire de futurs projets et continue d’alimenter la dynamique d’innovation au sein de la communauté !


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.

Découvrez Windows 365 Frontline Dedicated / Shared

Windows 365 continue d’évoluer et de s’adapter aux nouveaux usages. Après les éditions Business et Enterprise, Microsoft propose depuis quelque temps déjà Windows 365 Frontline, une déclinaison pensée pour les équipes en rotation ou à temps partiel. Bref, pour tous ceux qui n’ont pas besoin d’un Cloud PC huit heures par jour.

Dans cet article, je vous propose de faire le tour complet de Windows 365 Frontline, avec la création des stratégies dans Intune, le provisioning des Cloud PCs, les comportements de session, et les petits détails qu’on ne découvre qu’en le déployant soi-même.

Avant d’aller plus loin, je vous propose la lecture de plusieurs articles sur ce blog, qui parlent de Windows 365 depuis sa GA en 2021 :

À quoi sert Windows 365 Frontline ?

Windows 365 Frontline a été présenté pour la première fois en avril 2023 et est devenu disponible en version publique quelques mois plus tard, à l’été 2023.

Windows 365 Frontline est une déclinaison de Windows 365 pensée pour les travailleurs “de première ligne”. Il s’agit de cibler ceux qui n’utilisent pas un poste de travail huit heures par jour, tous les jours, mais travaillant sur leur poste de manière ponctuelle ou en rotation. C’est donc parfait pour les équipes en postes tournant, les centres de support, les services clients, ou les équipes sur le terrain.

Windows 365 Frontline est une version de Windows 365 qui permet aux organisations de réduire les coûts en leur permettant de provisionner un PC cloud qui peut être utilisé par plusieurs utilisateurs avec une seule licence.

Microsoft Learn

L’objectif principal est et reste de réduire le coût des licences Windows 365 tout en gardant la simplicité et la sécurité du Cloud PC.

Quelles sont les limitations de Windows 365 Frontline ?

Windows 365 Frontline apporte une vraie flexibilité, mais il faut connaître ses limites techniques et opérationnelles pour bien l’intégrer dans un environnement d’entreprise :

  • Un seul utilisateur peut être actif par Cloud PC à la fois : Même si la licence couvre plusieurs utilisateurs, ils ne peuvent pas se connecter simultanément.
  • Pas de mise en veille prolongée : lorsqu’un utilisateur se déconnecte, la session est suspendue mais reste comptabilisée tant que la VM est “réservée”.
  • Temps de démarrage à prévoir : la mise en service d’un Cloud PC Frontline peut prendre quelques minutes selon la politique de démarrage configurée.

Windows 365 Frontline Dedicated vs Shared ?

Microsoft propose aujourd’hui deux modes pour Frontline : Dedicated et Shared :

  • Le mode Dedicated reste le choix recommandé pour des postes attribués en rotation (3 utilisateurs maximum).

Prenons trois collaborateurs travaillant sur des shifts différents (matin, après-midi, nuit) — avec une seule licence Windows 365 Frontline, chacun dispose de son propre Cloud PC pendant son créneau de travail.

On réduit les coûts de licence tout en maintenant une expérience utilisateur complète et sécurisée pour chaque employé.

Le modèle devient particulièrement avantageux à grande échelle : pour 300 employés en rotation, il ne faudrait que 100 licences actives, soit une économie substantielle tout en maintenant une expérience et une sécurité identiques à Windows 365 Entreprise :

  • Le mode Shared vise les scénarios éphémères où la persistance n’est pas nécessaire (kiosques, formation). Ce mode a été introduit par Microsoft fin 2024. Ce mode est donc conçu pour des tâches courtes et ponctuelles (ex. : formation, inventaire, accès temporaire pour prestataires).

En quelques mots, le Frontline Partagé se distingue du Frontline Dédié sur :

  • Les Cloud PCs partagés sont réinitialisés après chaque session utilisateur : le profil et les données sont supprimés.
  • 1 licence = 1 Cloud PC partagé : la licence est liée à la machine virtuelle, pas à un utilisateur spécifique.
  • Les déconnexions automatiques après inactivité libèrent la session, permettant à d’autres utilisateurs d’accéder rapidement au poste.

Idéal pour les scénarios nécessitant un accès rapide et sécurisé à des applications ou outils sans conservation de données persistantes.

Au final, quelles sont les différentes licences Windows 365 ?

Voici un comparatif des différentes licences Windows 365 disponibles :

FeatureDedicated (Enterprise / Business)Frontline Dedicated (Standard)Frontline Shared Mode (Preview)
Cloud PC Usage1 Cloud PC par utilisateur3 Cloud PCs partagés entre 3 utilisateursPlusieurs Cloud PCs partagés entre de nombreux utilisateurs (1 à la fois)
User ProfilePersistant – sauvegardé entre les sessionsPersistant – chaque utilisateur a son propre bureauNon persistant – profil supprimé après déconnexion
Concurrent UsersUn utilisateur par Cloud PC1 utilisateur par Cloud PC à la fois (jusqu’à 3 par licence, en rotation)Un seul utilisateur à la fois par PC partagé
Session TypeExpérience Windows complèteExpérience Windows complèteSessions pooled et réinitialisables
Best ForEmployés à temps plein utilisant un Cloud PC quotidiennementTravailleurs en rotation (shifts)Accès temporaire, hot-desking, formation, kiosques
License CostLe plus cherPlus bas (3 utilisateurs par licence)Le plus bas – moins de licences requises
User Profile StorageConservé sur le Cloud PCConservé sur le Cloud PCSupprimé à la fin de la session
Always-on Cloud PCOuiÉteint si non utiliséOui

Quels sont les prix pour ces licences Windows 365 ?

Les licences Windows 365 Frontline affichent un prix facial plus élevé que les éditions Enterprise ou Business, mais elles sont conçues pour être partagées entre plusieurs utilisateurs.

Autrement dit, il faut raisonner en coût par utilisateur actif plutôt qu’en coût par licence : une approche indispensable pour déterminer la solution la plus avantageuse financièrement selon ton modèle d’usage (rotation, shifts, postes partagés, etc.).

Voici donc un tableau comparatif indicatif (en USD) pour une machine de 4 vCPU / 16 Go RAM, selon les quatre « méthodologies » (Business / Enterprise / Frontline Dedicated / Frontline Shared) de licensing possibles pour Windows 365 :

Méthode / SKUPrix en €, paiement mensuel engagement annuel
Windows 365 Enterprise≈ 63 Euros
Windows 365 Business63 Euros, avec Windows Hybrid Benefit
Windows 365 Frontline Dedicated≈ 94.53 € (licence 3 utilisateurs)
Windows 365 Frontline Shared ≈ 94.53 € par poste partagé

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

Etape 0 – Rappel des prérequis :

Pour réaliser cette démonstration sur les licences Windows 365 Frontline, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une ou plusieurs licences Windows 365 Frontline

Dans le portail Microsoft 365 Admin Center, on remarque tout de suite que ces licences ne peuvent pas être attribuées directement à des utilisateurs ou à des appareils :

Toujours depuis le portail Admin Center, il n’est pas possible d’associer la licence Frontline à un utilisateur :

Commençons par tester les Cloud PCs Frontline dédiés à des utilisateurs spécifiques.

Test I – Test de Windows 365 Frontline Dédié :

J’ai commencé par créer un groupe sur le portail Entra ID pour mes utilisateurs de test :

Sur le portail Intune, dans la section Polices de provisionnement de Windows 365, je crée une nouvelle police :

Je nomme ma stratégie, je sélectionne le type Frontline et le mode Dedicated :

Je choisis la jointure Entra ID et j’active le Single Sign-On (SSO) :

Je sélectionne une image Windows 11 pour mes Cloud PCs :

Je clique sur Suivant :

Je clique sur Suivant :

Je clique ici pour attribuer une configuration de Cloud PCs :

Je choisis la taille des Cloud PCs, ainsi que leur nombre :

Je clique sur Suivant :

Je clique sur Créer pour valider ma nouvelle police de provisionnement :

Je constate la création de la police de provisionnement de mes PC Frontline :

De retour dans la liste des Cloud PCs, je remarque l’apparition de nouveaux Cloud PCs avec le statut Pending :

En cliquant sur la mention Pending, j’observe un message indiquant plusieurs raisons possibles expliquant ce statut :

Quelques minutes plus tard, le statut Pending passe à Provisioning pour ces Cloud PCs :

Environ un quart d’heure plus tard, les PC apparaissent en statut Provisioned :

Je me connecte avec deux utilisateurs, en simultané, sur le portail Windows 365 Web :

Le premier utilisateur se connecte avec succès à sa session, tandis que le second obtient un message l’informant qu’il ne peut pas accéder au Cloud PC, normal :

Je retourne sur la police de provisionnement et j’augmente le nombre d’instances Windows 365 à 2 pour cette police Frontline :

Je parviens cette fois à connecter trois utilisateurs en simultané, bien que la configuration n’autorise initialement que deux sessions :

Dans les rapports Intune, on constate que la plateforme signale une surcapacité, mais qu’elle a tout de même permis la connexion grâce à la marge de tolérance (buffering) intégrée :

Voici d’ailleurs quelques règles du concurrency buffer pour Windows 365 Frontline :

  • Le concurrency buffer permet de dépasser temporairement la limite maximale de connexions simultanées permises par les licences Frontline dans des cas de transition comme le changement de shift
  • Le concurrency buffer ne s’applique pas aux Cloud PCs GPU-enabled ni au mode Frontline Shared.
  • Il peut être utilisé jusqu’à 4 fois par jour, pour un maximum d’1 heure à chaque activation. L’heure commence dès le dépassement de la limite de licences.
  • Si le buffer est utilisé de façon excessive (par exemple plus d’une heure à quatre reprises dans 24 heures), un blocage temporaire est activé pendant 48 heures, empêchant toute utilisation du buffer.
  • Si le tenant subit plus de deux blocages temporaires sur une période de 7 jours, le buffer peut être bloqué de façon permanente. Dans ce cas, il faut ouvrir un ticket auprès du support Intune pour restaurer l’accès.
  • Pendant le blocage (temporaire ou permanent), les utilisateurs peuvent toujours se connecter, mais uniquement jusqu’à la limite standard de licences (le buffer n’est plus accessible).

Continuons par par tester les Cloud PCs Frontline partagés à des utilisateurs.

Test II – Test de Windows 365 Frontline Partagé :

J’ai créé un second groupe dans le portail Entra ID pour mes utilisateurs de test :

Sur le portail Intune, dans la section Stratégies Windows 365, et je crée une seconde police de provisionnement :

Je nomme ma stratégie, je sélectionne le type Frontline, le mode Shared, je choisis la jointure Entra ID et j’active le SSO :

Je sélectionne une image Windows 11 pour mes Cloud PCs :

Je clique sur Suivant :

Je clique sur Suivant :

Je choisie la taille des Cloud PCs, ainsi que leur nombre :

Je clique sur Créer pour valider ma nouvelle police de provisionnement :

De retour dans la liste des Cloud PCs, je remarque l’apparition du nouveau Cloud PC avec le statut Provisioning :

Environ un quart d’heure plus tard, le Cloud PC apparaît en statut Provisionné :

Je me connecte avec deux utilisateurs, en simultané, sur le portail Windows 365 Web :

Le premier utilisateur se connecte avec succès à sa session, tandis que le second obtient un message l’informant qu’il ne peut pas accéder au Cloud PC :

Sur mon premier utilisateur, je personnalise le bureau et le fond d’écran, je crée un dossier sur le disque C avec un fichier, j’ajoute des éléments sur le bureau et je modifie la barre du menu Démarrer :

Je déconnecte le premier utilisateur et me connecte avec le second ; je constate alors la présence des fichiers locaux sur le disque C :

J’attends environ une heure, puis je me reconnecte avec le premier utilisateur ; je constate la restauration des éléments issus de OneDrive ainsi que des fichiers locaux, mais l’absence du fond d’écran et des raccourcis de la barre des tâches, non pris en charge par OneDrive :

Je lance un reprovisionnement immédiat de ma machine partagée :

Je constate le démarrage du nouveau processus :

Le provisionnement progresse et la nouvelle machine partagée apparaît dans l’environnement :

Quelques minutes plus tard, la nouvelle machine partagée est provisionnée :

Je me reconnecte avec mes deux utilisateurs, en commençant par le premier, et je constate la disparition des fichiers précédemment présents sur le disque C mais la conservation des données sauvegardées sur OneDrive :

Conclusion

Windows 365 Frontline apporte une vraie flexibilité dans la gestion des postes Cloud, surtout pour les environnements en rotation ou à effectif variable.

Le mode Dedicated reste parfait pour les équipes qui se relaient sur un même poste tout en conservant leur propre environnement, tandis que le mode Shared s’adresse davantage aux scénarios temporaires ou sans persistance.

Ce qu’il faut retenir, c’est que Frontline ne vise pas à remplacer les éditions Business ou Enterprise, mais bien à optimiser les coûts et les licences quand tout le monde n’a pas besoin d’un Cloud PC permanent.

Et comme souvent avec Microsoft 365 et Intune, le meilleur moyen de comprendre… c’est de tester soi-même ! 😉

Windows 365 – Invités

Microsoft continue de faire évoluer Windows 365 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 un Cloud PC pour une identité externe (invité B2B dans votre tenant Microsoft Entra ID).

Fini la création systématique de comptes internes temporaires : les utilisateurs peuvent se connecter avec leur propre identité tout en profitant d’un poste Windows 365 sécurisé.

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 polices de provisionnement Windows 365 et le même processus de licence que pour les Cloud PC internes.

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 :

  • Cloud PC sous Windows 11 Enterprise avec mise à jour 24H2 (KB5065789) ou plus récente
  • Cloud PC joint à Entra ID
  • Police de provisionnement Windows 365 avec Single Sign-On activé

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

  • Les polices Intune assignées à l’utilisateur externe ne s’appliquent pas (cibler le Cloud PC).
  • Pas de support pour Windows 365 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 Windows 365 faut-il pour ces utilisateurs invités ?

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

Les licences détenues par un collaborateur externe dans son propre tenant ne confèrent aucun droit pour utiliser un Cloud PC dans votre tenant :

Si vous utilisez Windows 365 avec des identités externes (actuellement en préversion), il peut y avoir des considérations spéciales à prendre en compte pour la façon dont vous accordez des licences à d’autres produits et services de Microsoft pour ces identités externes.

Les licences attribuées à un collaborateur externe dans son propre locataire d’origine ne confèrent généralement pas de droits à Windows 365 ou à d’autres produits au sein de votre locataire. Par conséquent, nous vous recommandons généralement d’acheter le même type de licence que vous achetez pour les utilisateurs internes et de l’attribuer à l’identité du collaborateur externe dans votre locataire.

Par exemple, si vous attribuez des licences Microsoft 365 Apps en même temps que vos PC Windows 365 cloud et que vos collaborateurs externes ont besoin des mêmes droits, achetez une licence Microsoft 365 Apps et attribuez-la au collaborateur externe de votre locataire.

Microsoft Learn

Vous devez donc acheter et attribuer les mêmes licences que pour vos utilisateurs internes (ex. Windows 365 Enterprise/Frontline, Microsoft 365 Apps 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 licence Windows 365 Entreprise

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

Pour cela, rendez-vous dans le portail Intune, puis ouvrez la politique que vous utilisez pour vos Cloud PC.

Vérifiez que la jointure est bien définie sur Microsoft Entra join :

Contrôlez également 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 ou les licences Windows 365 nécessaires, puis enregistrez :

Notre utilisateur invité est maintenant présent. Nous allons pouvoir nous intéresser au provisionnement de son Cloud PC.

Etape II – Provisionnement du Cloud PC invité :

Pour cela, rendez-vous dans le portail Intune :

Constatez l’absence du début du provisionnement du Cloud PC :

Vérifiez le groupe d’utilisateurs associé à votre politique de provisionnement Windows 365, puis et ajoutez-lui le nouvel utilisateur invité :

Constatez le début du provisionnement du Cloud PC :

Quelques temps plus tard, constatez le succès du provisionnement pour cet utilisateur invité :

Le provisionnement du Cloud PC est maintenant terminé. Nous allons maintenant pouvoir tester la connexion à ce poste avec notre utilisateur invité.

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 ci-dessous, puis authentifiez avec le compte invité de votre utilisateur :

https://windows.cloud.microsoft/

Une fois authentifié, constatez l’absence du nouveau Cloud PC provisionné sur votre tenant pour votre compte invité :

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

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

Vérifiez que l’URL reste bien sur le domaine de votre tenant, et que le Cloud PC invité apparaît :

Cliquez sur Connecter :

Cliquez à nouveau sur Se connecter :

Cliquez sur Oui :

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

Ouvrez Windows Terminal :

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

dsregcmd /status
  • AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID (prérequis principal pour les Cloud PC invités).
  • EnterpriseJoined : NO
  • DomainJoined : NO : Normal pour un Cloud PC moderne en mode Entra join (non hybride).
  • 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 jeton (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 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 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 d’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 Cloud PC :

Constatez la bonne ouverture de session de votre compte invité, puis ouvrez Windows Terminal :

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

dsregcmd /status

Vous voilà bien connecté avec votre compte invité sur un Cloud PC dans 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 :

Ou ce message d’erreur là :

Cela vient peut-être de l’absence du correctif KB5065789 sur votre Cloud PC, pourtant en version 24H2.

Pour remédier à cette mise à jour manquante, retournez sur le portail Entra ID pour ajouter un utilisateur de votre tenant aux administrateurs locaux des machines jointes à Entra ID :

Ensuite, retournez sur le portail Azure pour récupérer l’adresse IP locale du Cloud PC invité :

Depuis un autre Cloud PC auquel vous avez déjà accès, connectez-vous à cette IP locale avec un des comptes administrateurs :

Attendez que l’ouverture de session se fasse :

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 :

Rouvrez la session avec l’administrateur local, puis relancez Windows Update si besoin :

Redémarrez à nouveau, si nécessaire :

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

Retournez sur la page web de Windows 365 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 Cloud PC Windows 365 pour identités externes 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.

Attendez-vous au prochain article sur Azure Virtual Desktop 😎🤘😉

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.

Déployez un serveur MCP dans Azure

Le Model Context Protocol (MCP) ouvre la voie à une nouvelle façon de faire dialoguer les modèles d’IA et leurs outils. Que ce soit pour tester un environnement local ou déployer une architecture prête à l’emploi dans Azure, MCP apporte une approche standardisée, simple à expérimenter mais suffisamment flexible pour être adaptée à des besoins complexes.

Dans cet article, je vous propose un tutoriel pas à pas pour mettre en place un serveur MCP, le tester avec MCP Inspector, puis le déployer dans Azure afin d’explorer tout son potentiel.

Qu’est-ce que MCP ?

Mon premier article est un bon point de départ pour vous informer sur le sujet :

Le protocole MCP (Model Context Protocol) est un protocole qui permet à différents modèles et outils d’IA de communiquer entre eux. Il fournit un moyen standardisé pour les modèles de partager des informations et de collaborer sur des tâches. Le serveur MCP sert de pont entre différents modèles et outils, leur permettant de fonctionner ensemble de manière transparente.

GitHub

Je peux également vous conseiller de voir cette vidéo, mais également de consulter la page officielle du protocole MCP :

Vous trouverez ci-dessous le schéma d’architecture d’une configuration type de serveur MCP :

Enfin cette page rassemble une collection d’implémentations de serveurs MCP, qu’il s’agisse de versions officielles (références) ou proposées par la communauté. Elle sert de bibliothèque centrale pour explorer et découvrir des exemples de serveurs MCP capables de fournir aux modèles d’IA un accès contrôlé à des outils ou sources de données.

Qu’est-ce que MCP Inspector ?

MCP Inspector est un outil graphique fourni par l’équipe du Model Context Protocol qui sert à tester, déboguer et explorer un serveur MCP.

Il permet notamment de :

  • Se connecter à un serveur MCP local ou distant
  • Lister les outils (tools) que le serveur met à disposition.
  • Tester ces outils en leur envoyant des requêtes et en visualisant les réponses.
  • Explorer d’autres ressources exposées par le serveur, comme les prompts ou les files.
  • Vérifier en temps réel le statut de connexion et les échanges de données.

En résumé, c’est l’équivalent d’une console d’administration interactive qui te permet de voir comment ton serveur MCP réagit et d’expérimenter ses fonctionnalités sans devoir écrire du code côté client.

Envie de tester le déploiement d’un serveur MCP sur Azure ?

Cette page explique comment tester un serveur MCP en local ou hébergé sur Azure à l’aide de clients MCP sur desktop, comme Visual Studio Code ou MCP Inspector :

Ce guide constitue donc un point de départ idéal pour expérimenter la connexion et l’interaction avec un serveur MCP.

Afin de rendre la démonstration plus complète, j’y ai effectué quelques modifications, et j’ai publié le tout sur mon GitHub :

L’exercice consiste à configurer un serveur MCP, d’abord en local puis sur Azure, afin de comprendre son fonctionnement et tester ses outils :

  • Vous expérimentez ensuite les actions soit directement via ces outils, soit au travers de prompts, en observant le code généré à chaque étape.
  • La seconde partie de l’exercice consiste à déployer sur Azure Container Apps pour valider le bon fonctionnement du serveur MCP hébergé.

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
  • Un modèle c’IA déployé sur Azure OpenAI

Commençons par tester la solution en local.

Etape I – Déploiement du serveur MCP en local :

Avant cela, rendez-vous sur la page Azure OpenAI, puis copiez une des clés d’API :

Copiez également le point de terminaison depuis cette même page :

Accédez au portail Azure AI Foundry, créez un modèle, puis copiez son nom :

Sur votre poste, ouvrez une fenêtre Terminal :

Lancez la commande suivante pour vérifier si Git est installé :

git --version

Si Git n’est pas encore installé, exécutez la commande suivante pour le faire :

winget install --id Git.Git -e --source winget

Attendez la fin de l’installation de Git :

Vérifiez que l’installation de Git s’est bien effectuée :

Lancez la commande suivante pour récupérer le package au format Git depuis mon dépôt GitHub :

git clone https://github.com/jlou07/mcp-intelligent-server.git

Accédez au dossier du package téléchargé :

cd .\mcp-intelligent-server\

Ouvrez Visual Studio Code avec la commande suivante :

Code .

Dans Visual Studio Code, ouvrez le terminal intégré :

Exécutez la commande suivante pour installer NPM (gestionnaire de paquets Node.js) :

npm install

Attendez la fin de l’installation des différents packages NPM :

Lancez le script suivant pour générer un token sur le serveur MCP :

npm run generate-token

Vérifiez la création du fichier .env et copiez la valeur du token généré :

Ajoutez la ligne suivante pour renseigner le point de terminaison Azure OpenAI, puis sauvegardez :

# Azure OpenAI Configuration (optional but recommended for intelligent prompts)
AZURE_OPENAI_API_KEY=your-azure-openai-api-key-here
AZURE_OPENAI_ENDPOINT=https://your-resource-name.openai.azure.com
AZURE_OPENAI_MODEL=gpt-4o

Lancez localement le serveur MCP avec la commande NPM suivante :

npm run dev

Vérifiez la création de la base de données SQLite en mémoire, ainsi que le lancement réussi du serveur MCP :

Notre environnement en local est maintenant déployé. Nous allons maintenant utiliser MCP Inspector pour explorer les fonctionnalités du serveur MCP.

Etape II – Tests du serveur MCP local :

Ouvrez une seconde fenêtre de Terminal :

Lancez l’outil MCP Inspector avec la commande suivante :

npm run inspect

Récupérez l’URL du proxy MCP Inspector contenant son propre token d’accès :

Ouvrez cette URL dans un navigateur et vérifiez la présence du token MCP Inspector :

Copiez ensuite la valeur du token du serveur MCP et ajoutez-la dans le fichier .env :

Complétez les champs requis pour la connexion au serveur MCP local, puis cliquez ici pour vous connecter :

Vérifiez dans les logs l’authentification réussie du client vers le serveur MCP :

Dans MCP Inspector, vérifiez le statut Connected, puis cliquez sur l’onglet Tools :

Cliquez sur Lister les Tools pour afficher les outils déclarés :

Constatez l’apparition de la liste des outils disponibles :

Observez les opérations effectuées du côté du serveur MCP :

Utilisez l’outil List_ToDo, lancez-le et vérifiez le résultat obtenu :

Analysez les logs générés par le serveur MCP pour cette opération :

Utilisez l’outil Add _ToDo pour créer une nouvelle tâche, puis constatez l’opération :

Observez les logs correspondant à l’ajout de la nouvelle tâche dans la base SQLite :

Ajoutez plusieurs tâches supplémentaires :


Relancez List_ToDo :

Analysez les logs générés par le serveur MCP pour cette opération :

Utilisez Complete_ToDo pour marquer une tâche comme complétée :

Vérifiez les logs correspondant à cette mise à jour :

Relancez List_ToDo pour constater que la tâche est complétée :

Observez les logs correspondant à cette liste mise à jour :

Passez à l’onglet Prompts, puis cliquez ici pour lister les assistants IA disponibles :

Vérifiez les logs générés par cette action :

Cliquez sur ToDo Assistant, entrez un exemple de requête (ex. : lister les tâches), puis constatez la réponse générée :

Observez les logs correspondant à ce prompt :

Testez un prompt de suppression d’une tâche, puis exécutez-le :

Vérifiez les logs générés et l’action effectuée sur la base SQLite :

Relancez List_ToDo pour constater que la tâche a bien été supprimée :

Testez un prompt de mise à jour de toutes les tâches :

Constatez le résultat dans les logs :

Créez une nouvelle tâche via un prompt :

Observez les logs correspondant à l’ajout de cette nouvelle tâche :

La démonstration sur l’environnement local est terminée, passons maintenant au déploiement sur Azure.

Etape III – Déploiement du serveur MCP sur Azure :

Rendez-vous sur l’URL de téléchargement de Docker Desktop, puis téléchargez la version correspondant à votre OS :

Lancez l’exécutable compatible avec votre architecture :

Suivez l’installation :

Cochez les options proposées puis cliquez sur OK :

Attendez la fin de l’installation (de 5 à 10 minutes) :

Cliquez sur Fermer, puis redémarrez l’ordinateur :

Après le redémarrage, ouvrez Docker Desktop, puis laissez le téléchargement des composants additionnels se terminer :

Patientez si des mises à jour sont nécessaires, puis redémarrez si demandé :

Attendez le démarrage complet de Docker Engine :

Vous devez voir l’écran principal de Docker Desktop avec un tableau de bord vide de conteneurs :

Ouvrez Visual Studio Code, puis ouvrez un nouveau terminal :

Lancez la commande azd pour vérifier si Azure Developer CLI est installé :

azd version

Si Azure Developer CLI n’est pas installé, exécutez la commande pour l’installer :

winget install microsoft.azd

Attendez la fin de l’installation :

Fermez puis rouvrez Visual Studio Code et vérifiez que azd est bien installé :

Depuis le dossier du serveur MCP, lancez la commande azd up pour déployer l’infrastructure sur Azure :

Connectez-vous avec votre compte Azure :

Patientez pendant la préparation de l’image du conteneur :

Constatez la création locale des images Docker dans Docker Desktop :

Donnez un nom à votre application unique sur Azure :

Choisissez votre souscription Azure :

Saisissez les informations liées à Azure OpenAI :

Sélectionnez la région Azure :

Attendez la fin du déploiement des ressources Azure :

Sur le portail Azure, vérifiez la création complète des ressources :

Quelques minutes plus tard :

Attendez encore la fin du déploiement de l’image :

Constatez le déploiement terminé dans Visual Studio Code :

Retournez sur Azure et ouvrez la page de votre Azure Container App :

Copiez l’URL publique de votre application :

Dans la section Revisions and Replicas, vérifiez que le conteneur est démarré :

Dans Environment Variables, récupérez ou vérifiez la présence du token d’application :

Depuis Visual Studio Code, relancez MCP Inspector en local :

npm run inspect

Copiez l’URL avec le token de MCP Inspector :

Connectez MCP Inspector à votre Azure Container App avec l’URL et le token :

Effectuez à nouveau des opérations List_ToDo et créez de nouvelles tâches :

Testez différents prompts de listing et de complétion :

Testez également la partie prompting :

Vérifiez que la base temporaire SQLite est bien mise à jour :

Conclusion

Avec ce déploiement, vous disposez désormais d’un serveur MCP pleinement opérationnel, capable de dialoguer avec vos modèles d’IA et de gérer des outils de manière sécurisée, que ce soit en local ou dans le cloud Azure.

Et la suite ?

Si le sujet vous intéresse, je vous recommande vivement de consulter cette page, vous y trouverez d’autres serveurs MCP déjà mis à disposition, que vous pourrez tester pour découvrir leurs capacités, et dont la liste ne cesse de s’allonger.

Enfin, il peut également être intéressant d’explorer la création de serveurs MCP personnalisés dans l’environnement Microsoft 365, d’autant qu’une vidéo très pertinente sur le sujet est également disponible :