Orchestrez votre AVD

Avec la toute nouvelle fonctionnalité appelée Session host update d’Azure Virtual Desktop, Microsoft vient de lâcher une petite bombe dans la gestion des VMs AVD. Imaginez Azure Virtual Desktop remplaçant comme un grand des VMs obsolètes pour les remplacer par d’autres basées sur votre toute dernière image ? Vous ne rêvez pas, tout cela est maintenant disponible en préversion !

Comment faisait-on avant pour mettre à jour son AVD ?

Avant l’introduction de cette nouvelle fonctionnalité, la mise à jour des hôtes de session Azure Virtual Desktop (AVD) nécessitait une gestion manuelle plus intensive. Ce processus impliquait souvent plusieurs étapes, telles que :

  1. Planification des mises à jour : Identifier les hôtes de session nécessitant des mises à jour et planifier les fenêtres de maintenance.
  2. Exécution des mises à jour : Utiliser des scripts ou des outils pour appliquer les mises à jour sur chaque hôte de session.
  3. Vérification et validation : S’assurer que les mises à jour ont été appliquées correctement et que les hôtes de session fonctionnent comme prévu.

Ces étapes pouvaient être chronophages et nécessitaient une surveillance constante pour minimiser les interruptions de service et garantir la conformité des systèmes.

Qu’est ce que les nouvelles Mises à jour AVD ?

La nouvelle fonctionnalité simplifie ce processus en automatisant la gestion des mises à jour, réduisant ainsi la charge administrative et améliorant l’efficacité opérationnelle.

Microsoft nous décrit cette toute nouvelle fonctionnalité AVD en seulement quelques phrases :

La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de la machine virtuelle (VM) sous-jacente, l’image du système d’exploitation (OS) et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session.

La mise à jour de l’hôte de session désalloue ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour.

Cette méthode de mise à jour des hôtes de session est conforme à la suggestion de gestion des mises à jour au sein de l’image source principale, plutôt que de distribuer et d’installer les mises à jour sur chaque hôte de session individuellement selon un calendrier répété continu pour les maintenir à jour.

Microsoft Learn

Que peut-on modifier dans une mise à jour AVD ?

Beaucoup de paramètres sont déjà modifiables d’une version à l’autre de votre environnement AVD :

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

Quid des machines virtuelles AVD éteintes ou avec le mode de drainage ?

L’état d’alimentation et le mode de drainage existants des hôtes de session sont respectés. Vous pouvez effectuer une mise à jour sur un pool d’hôtes où tous les hôtes de session sont désalloués pour réduire les coûts.

Existe-t-il des limitations ?

Encore en préversion Microsoft nous liste les principales limitations juste ici :

  • La mise à jour de l’hôte de session est uniquement disponible dans le cloud Azure global. Il n’est pas disponible dans d’autres clouds, tels qu’Azure US Government ou Azure exploité par 21Vianet.
  • Pour les hôtes de session créés à partir d’une image partagée Azure Compute Gallery disposant d’un plan d’achat, le plan n’est pas conservé lorsque les hôtes de session sont mis à jour. Pour vérifier si l’image que vous utilisez pour vos hôtes de session dispose d’un plan d’achat, vous pouvez utiliser Azure PowerShell ou Azure CLI.
  • La taille du disque du système d’exploitation ne peut pas être modifiée pendant une mise à jour. Le service de mise à jour utilise par défaut la même taille que celle définie par l’image de la galerie.
  • Lors d’une mise à jour, vous ne pouvez pas ajouter d’autres hôtes de session au pool d’hôtes.
  • Si une mise à jour échoue, le pool d’hôtes ne peut pas être supprimé tant que la mise à jour n’est pas annulée.
  • Si vous décidez de créer une image extraite d’un hôte de session existant que vous utilisez ensuite comme image source pour la mise à jour de votre hôte de session, vous devez supprimer le dossier C:\packages\plugin avant de créer l’image. Dans le cas contraire, ce dossier empêche l’exécution de l’extension DSC qui joint les machines virtuelles mises à jour au pool d’hôtes.
  • Si vous utilisez Azure Virtual Desktop Insights, l’agent Azure Monitor ou l’agent Log Analytics n’est pas automatiquement installé sur les hôtes de session mis à jour. Pour installer l’agent automatiquement, voici quelques options :
  • Évitez de modifier une configuration d’hôte de session dans un pool d’hôtes sans hôtes de session en même temps qu’un hôte de session est créé, car cela peut entraîner un pool d’hôtes avec des propriétés d’hôte de session incohérentes.

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

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de mise à jour de l’hôte de session pour Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire d’effectuer une demande à Microsoft via le formulaire suivant, dont le point le plus important à retenir est :

Please note, the session hosts and host pools in this preview cannot be used for any type of production workload.

Autrement dit : pas de teste sur un environnement de production 😎

Etape I – Préparation du domaine AD :

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

Nommez celui-ci, puis cliquez sur Suivant :

Considérer au besoin les différents services de sécurité, puis cliquez sur Suivant :

Validez le plan d’adressage réseau et sous-réseau, puis lancez la validation Azure :

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

Une fois le réseau virtuel déployé, recherchez le service Microsoft Entra Domain Services depuis la barre de recherche Azure :

Cliquez-ici pour créer ce service d’AD managé sur votre tenant :

Renseignez ses informations de base dont son nom et le SKU de type Standard, puis cliquez sur Suivant :

Validez les propriétés réseaux, puis cliquez sur Suivant :

Adaptez au besoin les membres du groupe d’administrateurs créé par défaut à votre domaine managé, puis cliquez sur Suivant :

Définissez le périmètre de synchronisation, puis cliquez sur Suivant :

Parcourez les options liées à la sécurité de votre domaine managé, puis lancez la validation Azure :

Cliquez sur Créer pour lancez sa création :

Lisez l’avertissement sur le blocage de modifications après sa création, puis cliquez sur OK :

Attendez environ 30 minutes la première phase de déploiement des ressources Azure :

Environ 30 minutes plus tard, cliquez-ici pour parcourir les ressources Azure liées à votre domaine managé :

Comme vous le constatez, une phase de post-déploiement prend le relai pendant encore 25 minutes environ :

Approximativement 25 minutes plus tard, la phase de post déploiement est maintenant terminée. Cliquez-sur le message ci-dessous pour corriger le problème lié aux enregistrements DNS de votre réseau virtuel :

Lancez-le diagnostique en cliquant sur Lancer :

Corrigez l’adressage DNS de votre réseau virtuel en cliquant sur Réparer :

Confirmez votre choix en cliquant à nouveau sur Réparer :

Vérifiez la disparition de la notification d’alerte sur votre domaine managé :

Retournez sur le réseau virtuel afin de vérifiez les adresses IP de votre service Entra Domain Services :

Le domaine AD managé est maintenant en place.

La nouvelle méthode de déploiement AVD exige le stockage des informations d’identification dans un Azure Key Vault. Avant de déployer notre environnement AVD de test, nous aurons donc besoin d’un coffre.

Etape II – Création du coffre Azure Key Vault :

Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

Renseignez les informations de base, puis cliquez sur Suivant :

Activez les 2 options suivantes, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre coffre :

Attendez environ 2 minutes, puis cliquez-ici une fois le déploiement terminé :

Ajoutez les rôles RBAC suivants afin de pouvoir accéder à votre coffre ainsi qu’au service Azure Virtual Desktop via son application 9cdead84-a844-4324-93f2-b2e6bb768d07 :

Ajoutez également le rôle RBAC suivant pour l’application Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07) afin que cette dernière puisse créer et supprimer de nouvelles machines virtuelles :

Retournez dans votre coffre, puis cliquez sur le bouton suivant pour créer les différents secrets :

Créez les 4 secrets suivants un par un :

  • Compte de domaine (sous la forme admindomain@jlou.local)
  • Mot de passe du compte de domaine
  • Compte admin local VM
  • Mot de passe du compte admin local VM

Cela donne alors la liste de secrets suivante :

Tous les prérequis au déploiement sont maintenant en place. Nous allons pouvoir déployer un nouveau type d’AVD ayant un management automatisé.

Etape III – Déploiement de l’environnement AVD :

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant là encore la barre de recherche du portail Azure :

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

Choisissez un pool d’hôtes de type partagé ainsi que le management automatisé, puis cliquez sur Suivant :

Définissez le nombre de machines virtuelles créées ainsi que la région Azure :

Choisissez l’image OS et les caractéristiques techniques de vos machines virtuelles AVD :

Spécifiez le réseau virtuel adéquat :

Reprenez les informations du Key Vault contenant les informations d’identification du compte de domaine :

Reprenez les informations du Key Vault contenant les informations d’identification du compte administrateur local, puis cliquez sur Suivant :

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

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

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

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

Vérifiez le bon statut de disponibilité de vos hôtes de session créées :

Afin de s’assurer du bon fonctionnement de notre environnement AVD, connectez-vous à l’URL web d’Azure Virtual Desktop, authentifiez-vous avec un utilisateur de test, puis ouvrez une session AVD :

Cliquez sur Autoriser :

Renseignez les informations de compte de votre utilisateur AVD :

Vérifiez la bonne ouverture de session Windows :

Constatez la présence d’une session AVD ouverte sur une des VM présentes à votre pool d’hôtes :

L’environnement Azure Virtual Desktop est maintenant fonctionnel. La prochaine étape consiste à créer une mise à jour de l’image et donc de déclencher le processus de création de VM et le suppression des anciennes.

Etape IV – Déploiement d’une mise à jour AVD :

Tout commence par la création d’une nouvelle mise à jour AVD, pour cela cliquez-ici :

Définissez ici les options d’Azure Virtual Desktop sur les machines virtuelles :

  • La case à cocher détermine si AVD doit supprimer les anciennes machines virtuelles une fois ces dernières correctement substituées par de nouvelles.
  • Le pas de travail par AVD sur les machines virtuelles. Dans mon exemple :
    • AVD commencera par tester la mise à jour sur 1 seule machine virtuelle.
    • Si la mise à jour a fonctionné, AVD continuera par mettre à jour 2 VMs.
    • AVD terminera par mettre à jour les 2 dernière VMs

Définissez vos paramètres, puis cliquez sur Suivant :

Apportez les modifications de taille, d’image ou d’autres paramètres sur votre template AVD, puis cliquez sur Suivant :

Planifiez la mise à jour AVD immédiatement ou programmée par la suite, puis cliquez sur Suivant :

Personnalisez au besoin le message d’information reçu par les utilisateurs encore connectés, puis lancez la validation Azure :

Une fois la validation Azure réussie, retrouvez en gras les modifications apportées, puis lancez la mise à jour AVD :

Une fois la mise à jour enclenchée, l’écran des machines virtuelles AVD vous affiche 2 informations sur le traitement en-cours :

  • Le processus de mise à jour vient de démarrer, aucune VM n’a encore été remplacée, le pourcentage de progression est donc de 0.00 %.
  • La version actuellement en place sur les machine virtuelle AVD n’est plus la plus récente.

Après un rafraîchissement de la page, Azure Virtual Desktop commence sa mise à jour sur une première machine virtuelle AVD. Cela est visible par l’activation du mode de drainage sur une seule VM :

A ce même moment, une nouvelle machine virtuelle, dont la racine du nom reprend celle qui sera remplacée, fait son apparition et est en cours de création :

Une fois la nouvelle machine virtuelle créée, AVD nous informe que la VM déjà en place est en cours d’arrêt:

Cette information est confirmée dans la liste des machines virtuelles Azure :

Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle du pool d’hôtes AVD et du domaine Active Directory :

Juste après, Azure Virtual Desktop ajoute la nouvelle machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :

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

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

L’ancienne machine virtuelle est alors supprimée, comme demandé dans la configuration de la mise à jour AVD :

Le pourcentage de progression passe alors à 20.00 %, en adéquation avec le fait qu’1 machine virtuelle sur 5 est correctement mise à jour. AVD continue le traitement activant le mode de drainage sur 2 machines virtuelles :

A ce même moment, 2 nouvelles machine virtuelles, dont la racine du nom reprend celles qui seront remplacées, font leur apparition en cours de création :

Une fois les nouvelles machines virtuelles créés, AVD nous informe que les 2 VMs déjà en place sont en cours d’arrêt :

Cette information est confirmée dans la liste des machines virtuelles Azure :

Après cela, Azure Virtual Desktop retirent les 2 anciennes machines virtuelles du pool d’hôtes AVD et du domaine Active Directory :

Juste après, Azure Virtual Desktop ajoute les 2 nouvelles machines virtuelles au pool d’hôtes AVD et au domaine Active Directory :

Le pourcentage de progression passe alors à 60.00 %, en adéquation avec le fait que 3 machine virtuelle sur 5 sont correctement mises à jour. AVD continue le traitement activant le mode de drainage sur les 2 dernières machines virtuelles :

A ce même moment, 2 nouvelles VMs sont créées, l’ancienne VM sans session utilisateur est en cours d’arrêt, tandis que celle contenant une session utilisateur reste encore active :

Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle sans session du pool d’hôtes AVD, tandis que celle contenant une session utilisateur reste encore présente :

Un message d’information apparaît dans la session encore ouverte de l’utilisateur AVD :

Quelques minutes plus tard, la session AVD est terminée sans action de l’utilisateur :

Le pourcentage de progression passe alors à 80.00 %, en adéquation avec le fait qu’une seule machine virtuelle sur cinq n’est pas encore mise à jour :

Azure Virtual Desktop force la déconnexion afin de déclencher l’arrêt de la machine virtuelle AVD :

Après cela, Azure Virtual Desktop retire la dernière machine virtuelle du pool d’hôtes AVD :

Juste après, Azure Virtual Desktop ajoute la dernière machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :

Toutes les anciennes machines virtuelles AVD ont bien été supprimées :

La mise à jour est maintenant terminée car toutes les machines virtuelles ont maintenant et correctement été mise à jour :

L’utilisateur déconnecté peut alors tenter une reconnexion à AVD :

L’utilisateur constate alors le passage à une nouvelle version de son OS :

AVD ouvre la nouvelle session Windows sur 1 des 5 machines virtuelles du pool d’hôtes :

Conclusion

Cette fonctionnalité vous permet de maximiser l’efficacité et la flexibilité de votre infrastructure virtuelle. Grâce à des outils avancés et des stratégies éprouvées, vous pouvez améliorer la gestion de vos ressources, réduire les coûts opérationnels et offrir une expérience utilisateur optimisée. Découvrez par vous-même comment l’orchestration de votre AVD peut transformer votre environnement de travail virtuel.

AVD : Enfin les 60 FPS !

Azure Virtual Desktop propose depuis longtemps la possibilité d’exploiter des machines virtuelles avec GPU pour des traitements graphiques plus ou moins gourmands. Mais des limitations persistaient, et notamment le nombre de FPS que l’utilisateur pouvait obtenir via sa connexion en bureau à distance. Et tout cela vient de changer avec une nouvelle préversion proposée par Microsoft !

H.265 vs H.264 ?

HEVC (High Efficiency Video Coding), également appelé H.265. Cela permet une compression de données de 25 à 50 % par rapport à AVC/H.264, pour la même qualité vidéo ou une meilleure qualité avec la même vitesse de transmission que si la vidéo était encodée avec AVC/H.264.

Microsoft Learn

L’accélération GPU dans Azure Virtual Desktop améliore l’expérience utilisateur pour trois composants :

  1. Rendu d’application accéléré par GPU : Le GPU aide à afficher des graphismes plus rapidement dans une session à distance. Par exemple, si vous utilisez une application de dessin, les images se dessineront plus vite et seront plus fluides.
  2. Encodage d’images accéléré par GPU : Le protocole RDP (Remote Desktop Protocol) encode les graphismes pour les envoyer à votre appareil. Par exemple, si une partie de l’écran change souvent, comme une vidéo, elle est encodée avec le codec AVC (H.264) pour une transmission plus efficace.
  3. Encodage de vidéos plein écran : Pour des applications exigeantes comme la modélisation 3D, le CAD/CAM, ou l’édition vidéo, un profil vidéo plein écran offre une meilleure qualité d’image et une fréquence d’images plus élevée. Cela utilise plus de bande passante et de ressources. Vous pouvez choisir d’encoder avec :
    • AVC/H.264 : Un codec standard pour la vidéo.
    • HEVC/H.265 : Un codec plus efficace qui compresse les données de 25 à 50 % mieux que l’AVC/H.264, offrant la même qualité vidéo avec moins de bande passante.
CaractéristiqueH.264 (AVC)H.265 (HEVC)
Efficacité de compressionUtilise des macroblocs (16×16 pixels)Utilise des unités de codage (CTU) jusqu’à 64×64 pixels
Taille des fichiersPlus volumineuxRéduit la taille des fichiers jusqu’à 50%
CompatibilitéLargement pris en charge par de nombreux appareils et plateformesMoins largement pris en charge, mais le support est en croissance
Puissance de traitementNécessite moins de puissance de calcul pour le codage et le décodageNécessite plus de puissance de calcul pour le codage et le décodage
Cas d’utilisationStreaming, disques Blu-ray, diffusions HDTVVidéos haute résolution (4K, 8K), scénarios avec bande passante et stockage limités
Qualité vidéoBonne qualité vidéoMeilleure qualité vidéo au même débit binaire
Bande passanteNécessite plus de bande passanteNécessite moins de bande passante
AdoptionUniversellement adoptéGagne en popularité, mais fait face à des obstacles de licence

En résumé, si vous avez besoin d’une meilleure compression et travaillez avec des vidéos haute résolution, H.265 est la meilleure option. Cependant, pour une compatibilité plus large et des exigences de traitement plus faibles, H.264 reste un choix logique.

Quelles machines virtuelles Azure sont compatibles ?

La bonne nouvelle est que si vous activez l’accélération matérielle HEVC/H.265 et AVC/H.264, mais que HEVC/H.265 n’est pas disponible sur l’appareil local, alors AVC/H.264 sera alors utilisé à la place.

Microsoft vous liste sur son site les familles de machines virtuelles Azure supportant partiellement ou totalement H.265 :

Taille de la machine virtuelle AzureAccélération GPU pour le rendu d’applicationAccélération GPU pour le codage d’imagesEncodage vidéo plein écran
Série NVv3Pris en chargeAVC/H.264HEVC/H.265
AVC/H.264
Série NVv4Pris en chargeNon disponiblePris en charge
NVadsA10 v5-seriesPris en chargeAVC/H.264HEVC/H.265
AVC/H.264
NCasT4_v3-seriesPris en chargeAVC/H.264HEVC/H.265
AVC/H.264

Contraintes importantes :

  • Contraintes AVD :
    • Compatible uniquement Windows 10 et Windows 11
    • Les machines virtuelles Azure des séries NC, NCv2, NCv3, ND et NDv2 ne sont généralement pas appropriées comme hôtes de session. Ces tailles de machine virtuelle sont adaptées aux outils de calcul ou de Machine Learning hautes performances spécialisés, comme ceux créés avec NVIDIA CUDA. Elles ne prennent pas en charge l’accélération GPU pour la plupart des applications ni pour l’interface utilisateur Windows.
    • Désactivation obligatoire de la redirection multimédia sur vos hôtes de session.
    • Groupe d’applications de bureau RemoteApp non pas pris en charge.
  • Contraintes sur le poste local :
    • GPU compatible HEVC (H.265)
    • Code Microsoft HEVC installé (inclus à partir de Windows 11 22H2)
    • Windows App, version 1.3.278.0 ou ultérieure.
    • Application Bureau à distance, version 1.2.4671.0 ou ultérieure.

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

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de FPS sur Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Commençons d’abord par vérifier en premier la compatibilité H.265 du poste local.

Etape I – Vérifications H.265 du poste local :

Sur votre poste, ouvrez Windows PowerShell, puis exécutez la commande suivante pour vérifier la présence du codec HEVC :

get-appxpackage *hevc*

Ouvrez maintenant au choix votre application Remote Desktop ou Windows App afin de vérifier les versions :

La configuration locale semble bonne, continuons maintenant sur Azure afin de mettre en place un environnement de test avec GPU.

Etape II – Création de l’environnement Azure Virtual Desktop :

Voici un rappel des familles de machines virtuelles dont les GPUs NVIDIA sont compatibles :

Avant de pouvoir déployer un environnement GPU pour Azure Virtual Desktop, nous avons donc besoin de disposer de quotas sur notre souscription. Pour cela, rendez-vous dans le portail Azure :

Pour mon exemple, j’ai choisi de créer mon environnement AVD sur une machine virtuelle de la familles NCasT4_v3, dont j’ai précédemment augmenté les quotas :

Une fois les quotas en place, nous avons besoin d’avoir un réseau virtuel Azure.

Nommez votre réseau virtuel, puis cliquez sur Vérifier:

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

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant la barre de recherche du portail Azure :

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

Configurez-le comme ceci, puis cliquez sur Suivant :

Choisissez une image OS sous Windows 11 :

Choisissez une taille de VM GPU :

Joignez votre VM à votre réseau virtuel et à Microsoft Entra ID :

Définissez un administrateur local, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

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

Une fois le déploiement d’Azure Virtual Desktop terminé, cliquez-ici :

Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Définissez sur le groupe de ressources les droits RBAC suivants pour votre utilisateur de test AVD :

Notre environnement Azure Virtual Desktop GPU est maintenant en place. La prochaine étape consiste à installer la configuration graphique de base, afin que la carte NVIDIA soit reconnue par Windows et pleinement exploitée.

Etape III – Configuration GPU de l’environnement AVD :

Important :

  • Pour les tailles des machines virtuelles avec un GPU NVIDIA, seuls les pilotes NVIDIA GRID prennent en charge l’accélération GPU pour la plupart des applications et l’interface utilisateur Windows. Les pilotes NVIDIA CUDA ne prennent pas en charge l’accélération GPU pour ces tailles de machine virtuelle. Si vous souhaitez télécharger et découvrir comment installer le pilote, consultez Installer les pilotes GPU NVIDIA sur les machines virtuelles de série N exécutant Windows et n’oubliez pas d’installer le pilote GRID. Si vous installez le pilote en utilisant l’Extension de pilote GPU NVIDIA, le pilote GRID est automatiquement installé pour ces tailles de machine virtuelle. Pour l’accélération matérielle HEVC/H.265, vous devez utiliser le pilote GPU NVIDIA GRID 16.2 (537.13) ou version ultérieure.
  • Pour les tailles des machines virtuelles avec un GPU AMD, installez les pilotes AMD fournis par Azure. Si vous souhaitez télécharger et découvrir comment installer le pilote, consultez Installer les pilotes GPU AMD sur les machines virtuelles de série N exécutant Windows.

Microsoft Learn

Ouvrez la page de votre machine virtuelle AVD de test afin de déployer le service Azure Bastion sur votre réseau virtuel :

Une fois Azure Bastion correctement déployé, ouvrez une session via ce dernier avec le compte administrateur local de la machine virtuelle :

Sur votre VM AVD, ouvrez la page suivante de la documentation Microsoft proposant l’installation de pilotes GRID :

Une fois l’installeur GRID téléchargé sur votre VM GPU, ouvrez ce dernier, puis confirmez le dossier de décompression au niveau local :

Après une rapide vérification du système, cliquez sur Accepter et Continuer :

Cliquez sur Suivant :

Attendez environ 2 minutes que l’installation se termine :

Une fois l’installation terminée avec succès, cliquez sur Fermer :

Ouvrez l’exécuteur de commande Windows pour ouvrir l’éditeur de stratégie de groupe locale :

Naviguez dans l’arborescence suivante :

  • Administrative Templates
    • Windows Components
      • Remote Desktop Services
        • Remote Desktop Session Host
          • Remote Session Environnment

Afin de profiter de la performance du GPU de notre machine virtuelle, activez les polices locales suivantes :

Afin de tester le nombre de FPS, installez FurMark 2. Pour cela, rendez-vous sur la page web suivante afin de télécharger l’installeur :

Lancez l’installation de FurMark 2, cochez la première case, puis cliquez sur Suivant :

Renseignez le répertoire d’installation, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Cliquez sur Suivant :

Cliquez sur Terminer :

La configuration GPU de base est maintenant en place. Nous allons pouvoir tester l’impact sans et avec la configuration additionnelle.

Etape IV – Test utilisateur SANS :

Si besoin, téléchargez le client Remote Desktop depuis cette page officielle Microsoft.

Ouvrez l’application avec votre utilisateur de test AVD, puis lancez l’application de bureau à distance :

Acceptez la demande d’autorisation pour autoriser les connexion RDP vers la VM GPU AVD :

Depuis le menu Démarrer, ouvrez l’application FurMark 2 :

Démarrez le test GPU :

Pendant que FurMark 2 poursuit son test, contrôlez le protocole, l’utilisation du GPU, la bande passante disponible ainsi que le nombre de FPS :

La configuration actuelle limite actuellement le nombre de FPS à 30. Testons maintenant avec la configuration additionnelle.

Etape V – Test utilisateur AVEC :

Pour s’assurer que la fonction débridant les 60 FPS est correctement activée, les clés de registre suivantes doivent être définies sur chaque VM hôte de session.

Ouvrez Windows PowerShell, puis exécutez les commandes suivantes :

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v HEVCModePreferred /t REG_DWORD /d 1

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v bEnumerateHWBeforeSW /t REG_DWORD /d 1

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DisplayRefreshRate /t REG_DWORD /d 60

Ouvrez l’observateur d’événements Windows et accédez au journal suivant :

  • Journaux des applications et services
    • Microsoft
      • Windows
        • RemoteDesktopServices-RdpCoreCDV
          • Operational

Recherchez l’ID d’événement 162. Si vous voyez Initial Profile avec la valeur 32768, Alors la connexion de bureau à distance utilise HEVC, ce qui n’est pas encore le cas ici :

Fermez la session utilisateur d’Azure Virtual Desktop :

Relancez la session de bureau à distance :

Réouvrez l’observateur d’événements Windows, puis accédez au journal suivant :

  • Journaux des applications et services
    • Microsoft
      • Windows
      • RemoteDesktopServices-RdpCoreCDV
        • Operational

Recherchez à nouveau l’ID d’événement 162. Si vous voyez Initial Profile avec la valeur 32768, Alors la connexion de bureau à distance utilise bien HEVC, ce qui maintenant le cas ici :

Rouvrez l’application FurMark 2, et recontrôlez le protocole, l’utilisation du GPU, la bande passante disponible ainsi que le nombre de FPS :

Bravo ! Le nombre de FPS a fait un sacré bon !

Conclusion

Grâce à l’accélération GPU et à l’utilisation des codecs HEVC/H.265 et AVC/H.264, les utilisateurs peuvent désormais bénéficier d’une expérience graphique fluide et de haute qualité, même pour des applications exigeantes comme la modélisation 3D ou l’édition vidéo.

Cette mise à jour d’Azure Virtual Desktop marque un tournant pour les utilisateurs nécessitant des performances graphiques élevées, tout en offrant une meilleure compression et une utilisation plus efficace de la bande passante 😎💪

Améliorations Teams VDI

Microsoft vient d’annoncer il y a peu la disponibilité générale (GA) d’une nouvelle optimisation pour les communications Teams sur les environnements VDI (Azure Virtual Desktop, Windows 365) baptisée SlimCore. Nous allons voir dans cet article de quoi il en retourne, et comment la mettre en place.

Prenons un peu de temps pour resituer ce changement majeur pour la VDI.

Qu’est-ce que SlimCore ?

SlimCore est un moteur multimédia développé par Microsoft pour remplacer WebRTC (Web Real-Time Communication) dans certaines applications comme Microsoft Teams. Il gère l’audio, la vidéo et le partage d’écran dans le nouveau client Teams pour ordinateur, offrant de meilleures performances, qualité et fiabilité par rapport à WebRTC.

Les principaux avantages de SlimCore sont :

  1. Parité des fonctionnalités et performances : SlimCore permet à Teams sur l’infrastructure de bureau virtuel (VDI) d’avoir des fonctionnalités et des performances similaires à celles du client Teams natif, ce qui facilite l’ajout rapide de nouvelles fonctionnalités et la réduction des écarts présents avec WebRTC.
  2. Amélioration de la qualité des appels : SlimCore optimise les performances audio et vidéo, réduisant les problèmes tels que les interruptions d’appels et la latence.
  3. Mises à jour automatiques : SlimCore est mis à jour automatiquement, garantissant que le moteur multimédia reste compatible avec les dernières fonctionnalités de Teams, sans nécessiter d’intervention manuelle ou de mises à jour d’infrastructure.

SlimCore vs WebRTC ?

SlimCore est plus performant et optimisé pour Microsoft Teams, en particulier dans des environnements VDI, avec des mises à jour transparente et une intégration plus poussée dans l’écosystème Microsoft, tandis WebRTC est une solution plus flexible et ouverte, utilisée dans de nombreuses plateformes, mais avec des performances parfois limitées dans des environnements plus complexes comme le VDI :

CaractéristiqueSlimCoreWebRTC
Origine et usageMoteur multimédia propriétaire développé par Microsoft pour Teams. Utilisé dans le client natif et les environnements VDI.Standard ouvert largement utilisé pour les communications audio, vidéo et partage de données en temps réel via les navigateurs et applications.
Performances et qualitéOptimisé pour une qualité d’appel et de vidéo élevée, même en environnements VDI (réduction de la latence, des déconnexions, meilleure stabilité).Performance variable selon les configurations réseau et navigateur. Moins optimisé pour les environnements complexes comme VDI.
Support des fonctionnalitésPermet à Microsoft de déployer plus rapidement des nouvelles fonctionnalités dans Teams, sans limitation des standards externes.Les fonctionnalités sont limitées par le standard et peuvent évoluer plus lentement.
Mises à jour et compatibilitéMises à jour automatiques et transparentes par Microsoft, sans intervention de l’utilisateur ou de l’administrateur.Dépend des mises à jour des navigateurs et autres implémentations, ce qui peut entraîner des incompatibilités ou des retards.
Flexibilité et adoptionSpécifiquement intégré dans l’écosystème Microsoft, moins flexible en dehors de cet environnement.Très flexible et largement adopté par de nombreuses plateformes, adapté à une grande variété d’applications.
Optimisation pour VDIConçu pour garantir une parité de performances entre le client natif Teams et Teams sur VDI.Moins optimisé pour les environnements VDI, avec des écarts de performance par rapport aux clients natifs.
Déploiement des nouvelles fonctionnalitésFonctionnalités déployées plus rapidement via SlimCore directement dans Teams.Limité par les capacités de WebRTC, les fonctionnalités avancées peuvent prendre plus de temps à arriver.

Est-ce en rapport avec le nouveau Microsoft Teams ?

Cette évolution est en effet dans la suite de la refonte du client Teams de 2023, dont la GA date d’octobre de cette année-là. Voici quelques-unes des principales caractéristiques et avancées :

  • Performance améliorée : L’application est désormais deux fois plus rapide tout en consommant jusqu’à 50 % de ressources en moins.
  • Interface utilisateur simplifiée : Une interface plus soignée et réactive, facilitant la navigation et l’efficacité.
  • Notifications améliorées : Les notifications sont désormais entièrement gérées dans Teams, avec des paramètres plus personnalisables.
  • Comptes multiples : Vous pouvez facilement vous connecter à plusieurs comptes professionnels, scolaires et personnels sans avoir à vous déconnecter et vous reconnecter. Cela simplifie grandement la gestion des différents rôles et responsabilités.

Quels sont les quatre grands piliers de Teams VDI ?

C’est ici qu’intervient le remplacement de WebRTC, une technologie open-source utilisée pour le streaming audio et vidéo dans de nombreuses plateformes de collaboration, au profit de SlimCore, interne à Microsoft.

Microsoft en parle des avantages de ce changement juste ici :

  1. Nouvelles fonctionnalités : SlimCore, un nouveau moteur multimédia, remplace WebRTC dans Teams. Cela permet à Teams sur ordinateur et sur VDI (bureau virtuel) d’avoir les mêmes fonctionnalités. Même si toutes les nouveautés ne sont pas disponibles immédiatement sur VDI, nous ne sommes plus limités par WebRTC, ce qui permet d’ajouter les nouvelles options plus rapidement.
  2. Amélioration des performances : Les performances de Teams sur Windows sont maintenant disponibles pour VDI. Cela permet de rejoindre les réunions plus vite, de réduire les coupures d’appels et d’améliorer le succès lors des partages d’écran et des réunions, avec l’utilisation des codecs les plus récents.
  3. Mises à jour automatiques : Microsoft met à jour SlimCore automatiquement sur l’ordinateur de l’utilisateur. Cela se fait sans interruption et sans redémarrage lorsque Teams sur VDI est mis à jour. Ce système permet d’éviter que des versions récentes de Teams interagissent avec des composants anciens, garantissant une meilleure qualité.
  4. Support simplifié : Les administrateurs n’ont besoin de contacter que Microsoft pour tout problème avec Teams sur VDI, car nous gérons l’ensemble de la solution. Nous avons analysé les délais de résolution passés pour réduire la gravité et la fréquence des incidents, et nous investissons aussi dans des solutions de dépannage et d’auto-assistance avec des guides détaillés.

Quelles sont les fonctionnalités présentes dans cette optimisation ?

Microsoft propose une liste des nouvelles fonctionnalités liées à ce changement juste ici :

FonctionnalitéDisponible
1080pOui
Accélération matérielle sur le point de terminaisonOui
Vue Galerie 3×3 et 7×7Oui
Qualité de serviceOui
Suppression du bruitOui
CACHÉOui
Mode présentateurOui
Teams PremiumOui
(En attente : filigrane, mairies, décorer mon arrière-plan)
Effet d’arrière-plan chargé par l’utilisateurBientôt disponible
Zoom +/-Bientôt disponible

Quelles sont les versions Apps ou OS supportant déjà SlimCore ?

Pour que la bascule vers SlimCore se fasse, nous avons besoin au minimum de :

RequisVersion minimale
Nouveau client Teams24193.1805.3040.8975 (pour AVD/Windows 365)
24165.1410.2974.6689 (pour les VDA à session unique Citrix)
24243.1309.3132.617 (pour les VDA multisession Citrix)
AVD/Windows 365Application Windows : 1.3.252
Client Bureau à distance : 1.2.5405.0
CitrixVDA : application Citrix Workspace 2203 LTSR CU3 ou 2305 CR
: 2203 LTSR, 2402 LTSR ou 2302 CR
Poste localWindows 10 1809 (condition minimale de SlimCore)
Les objets de stratégie de groupe ne doivent pas bloquer les installations MSIX (voir Étape 3 : Préproduction et inscription de SlimCore MSIX sur le point de terminaison)

L’architecture s’en retrouve principalement modifiée côté client via l’ajout d’un nouveau plugin appelé MsTeamsPlugin.dll :

Comment cela se traduit-il au niveau de son installation ?

Microsoft nous explique les choses assez simplement :

Une fois qu’un plugin est « arrivé » chez le client, Teams envoie des instructions sur la version spécifique du moteur média dont il a besoin et le plugin fait le reste : il contacte le CDN public de Microsoft, télécharge un paquet MSIX et l’installe/enregistre automatiquement sur l’appareil de l’utilisateur. Pas de redémarrage ni de privilèges d’administrateur !

Microsoft Tech Community

Par défaut, MsTeamsPlugin télécharge et installe automatiquement la version appropriée du moteur multimédia SlimCore sans intervention de l’utilisateur ou d’un administrateur.

Voici ce que l’on retrouve au niveau local :

Get-AppXPackage *SlimCore*

Important : Microsoft stocke jusqu’à 12 versions de SlimCore VDI à des fins de compatibilité, et dans le cas où l’utilisateur accède à différents environnements VDI (par exemple, persistant, où les nouvelles mises à jour automatiques Teams se mettent à jour automatiquement et non persistants, où les nouvelles mises à jour automatiques Teams sont désactivées).

Enfin, la nouvelle solution pour VDI stocke des données spécifiques à l’utilisateur (journaux, les configurations et les modèles IA ou ML, …) sur le poste local au démarrage de Teams sur la session VDI :

Et quid d’une mise à jour Teams côté client ou VDI ?

Grâce à ce changement d’approche, Microsoft a là aussi prévu le coup :

Chaque fois que vous mettez à niveau Teams sur le serveur, une nouvelle version du moteur de médias est déployée sur le client. Plus aucune mise à jour n’est nécessaire sur votre pile VDI (serveur ou client). Les plugins sont compatibles en amont et en aval avec les versions de SlimCore, et les plugins nettoieront également les versions de SlimCore inutilisées ou obsolètes.

Microsoft Tech Community

Doit-on prévoir des modifications au niveau des réseaux ?

Certains changement sont à prévoir selon votre cas. Microsoft met à disposition un second schéma afin de comprendre ces nouveaux changements :

Comme le signale Microsoft, assurez-vous que l’appareil de l’utilisateur dispose d’une connectivité réseau (UDP et TCP) aux ID de point de terminaison 11, 12, 47 et 127 décrits dans URL et plages d’adresses IP Microsoft 365.

IDCatégorieERAdressesPortsRemarques
11Optimiser les besoinsOui13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15, 2603:1063::/38UDP : 3478, 3479, 3480, 3481Processeurs multimédias et relais de transport 3478 (STUN), 3479 (audio), 3480 (vidéo), 3481 (partage d’écran)
12Autoriser obligatoireOui*.lync.com, *.teams.microsoft.com, teams.microsoft.com 13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15, 52.238.119.141/32, 52.244.160.207/32, 2603:1027 ::/48, 2603:1037 ::/48, 2603:1047 ::/48, 2603:1057 ::/48, 2603:1063 ::/38, 2620:1ec :6 ::/48, 2620:1ec :40 ::/42TCP : 443, 80
47Valeur par défaut requiseNon*.office.netTCP : 443, 80Utilisé pour les téléchargements SlimCore et les effets d’arrière-plan
127Valeur par défaut requiseNon*.skype.comTCP : 443, 80

Comment vérifie-t-on si SlimCore est bien utilisé ?

Si toutes les exigences sont en place, SlimCore devrait être automatiquement utilisé dans Microsoft Team lors d’une session VDI. Un contrôle rapide est possible dans le client VDI.

Ouvrez votre client Teams sur votre session VDI, puis cliquez sur le bouton des paramètres :

Puis cliquez sur la fonctionnalité A Propos :

Conclusion

La mise en place de cette nouvelle optimisation Teams dédiée aux environnements VDI montre une priorisation chez Microsoft de ses produits VDI phares que son Azure Virtual Desktop et Windows 365.

La nouvelle optimisation basée sur SlimCore offre de meilleures performances, une configuration d’appel plus rapide, un partage d’écran plus fiable, moins de temps d’arrêt et des résolutions de cas plus rapides.

Offrant de meilleures performances et de nouvelles fonctionnalités telles que la vidéo en 1080p et les mises à jour automatiques, SlimCore a pour objectif est de réduire les problèmes techniques, d’améliorer la qualité des réunions et de simplifier la gestion pour les administrateurs IT.

AVD + SSO + Accès conditionnel v2

Azure Virtual Desktop propose différentes options dans l’authentification Entra ID, comme le SSO, l’accès conditionnel, ou encore la combinaisons des 2 😎. Microsoft nous apporte justement une petite évolution sur ce mois de juin 2024. Annoncée via un email pour une partie d’entre-nous, je souhaitais refaire un point sur la configuration SSO et les différentes polices possibles dans l’accès conditionnel AVD.

Il y a quelques jours, certains ont peut-être reçu l’email suivant de la part de Microsoft Azure :

Upcoming change for conditional access policies that target the Microsoft Remote Desktop Entra ID cloud app for Azure Virtual Desktop single sign-on.

You’re receiving this notice because you have conditional access policies that explicitly include or exclude the Microsoft Remote Desktop Entra ID cloud app and use single sign-on.

This change timeline was initially targeted for April 2024. We’ve extended the timeline to 26 June 2024. Azure Virtual Desktop clients will transition to the Windows Cloud Login Entra ID cloud app for Windows authentication when single sign-on is enabled. Windows authentication will continue to work as expected when single sign-on isn’t enabled. Additionally, conditional access policies targeted towards the Azure Virtual Desktop Entra ID cloud applications will continue to be applied across resource retrieval, gateway authentication, and diagnostic processes.

Since you’re using single sign-on for Azure Virtual Desktop and have conditional access policies that specifically include or exclude the Microsoft Remote Desktop Entra ID cloud app you’ll need to update your policies to also include or exclude the Windows Cloud Login Entra ID cloud app.

  • Microsoft Remote Desktop Entra ID cloud app ID: a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID cloud app ID: 270efc09-cd0d-444b-a71f-39af4910ec45

If you have existing conditional access policies targeting the Microsoft Remote Desktop Entra ID cloud app, action is required to ensure policies continue to be applied as intended.

Required action

We recommend you update any conditional access policies that specifically target the Microsoft Remote Desktop Entra ID cloud app to add the Windows Cloud Login Entra ID cloud app to ensure a smooth transition by 26 June 2024.

  • Reach out to your Azure Global Administrator for Azure Virtual Desktop to develop a plan for deploying these updates to your infrastructure.
  • Update your internal documentation as needed and if you have a helpdesk, you may want to make them aware of this change.

To get started, review the documentation to secure user sign-in events with Microsoft Entra Multifactor authentication.

Help and support

If you need help developing a plan for deploying the updates, contact your Azure global administrator for Azure Virtual Desktop.

If you have general questions, ask community experts in Microsoft Q&A. If you have a support plan and you need technical help, open a support case in the Azure portal and select the question mark icon at the top of the page.

————————————————————-

Voici en quelques mots de ce que l’on peut en dire sur ce changement sur les polices d’accès conditionnel destinés à Azure Virtual Desktop :

Vous recevez cet avis parce que vous avez des politiques d’accès conditionnel qui incluent ou excluent explicitement l’application cloud Microsoft Remote Desktop Entra ID et/ou utilisent l’authentification unique.

La date limite de transition est prévue pour le 26 juin 2024 :

  • Changement : Les clients Azure Virtual Desktop utiliseront l’application Windows Cloud Login Entra ID pour l’authentification Windows avec SSO.
  • Impact : Vos politiques d’accès conditionnel actuelles doivent inclure l’application Windows Cloud Login Entra ID en plus de Microsoft Remote Desktop Entra ID.

Les actions requises :

  1. Mettre à jour vos politiques d’accès conditionnel pour inclure l’application Windows Cloud Login Entra ID.
  2. Contactez votre administrateur global Azure pour planifier ces mises à jour.
  3. Mettre à jour votre documentation interne et informer votre service d’assistance.

Le support :

En relisant en détail la documentation Microsoft relative à la configuration SSO pour AVD, j’avais jusqu’à présent configuré le SSO sur des environnements Azure Virtual Desktop de manière incomplète : à savoir uniquement au niveau du pool d’hôtes AVD :

Malgré cette configuration SSO partielle, mes utilisateurs n’avaient aucun souci pour s’y connecter, avec quelques clics supplémentaires.

Je vous propose donc au travers de cet article sur la configuration SSO et les accès conditionnel AVD possibles :

Commençons donc par un rappel de l’expérience utilisateur sans configuration SSO dans le cadre d’un environnement AVD joint directement à Microsoft Entra ID.

Tâche I – Premier test AVD sans SSO :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de l’utilisateur AVD :

Confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Renseignez à nouveau votre identifiant et mot de passe utilisateur :

Confirmez à nouveau votre choix en cliquant sur Continuer :

Autoriser la connexion à la machine virtuelle AVD en cliquant sur Oui :

Microsoft nous informe sur le pourquoi de cette boite de dialogue ci-dessus :

Après avoir activé l’authentification Microsoft Entra pour RDP, vous devez configurer les groupes d’appareils cibles. Par défaut, lors de l’activation de l’authentification unique, les utilisateurs sont invités à s’authentifier auprès de Microsoft Entra ID et à autoriser la connexion Bureau à distance lors du lancement d’une connexion à un nouvel hôte de session. Microsoft Entra mémorise jusqu’à 15 hôtes pendant 30 jours avant de vous présenter une nouvelle invite. Si une boîte de dialogue pour autoriser la connexion Bureau à distance s’affiche, sélectionnez Oui pour vous connecter.

Microsoft Learn

L’expérience réalisée nous montre que le SSO n’est pas opérationnel. Microsoft nous explique qu’il est possible de l’améliorer :

Vous pouvez masquer cette boîte de dialogue et fournir l’authentification unique pour les connexions à tous vos hôtes de session en configurant une liste d’appareils approuvés. Vous devez créer un ou plusieurs groupes dans Microsoft Entra ID qui contient vos hôtes de session, puis définir une propriété sur les principaux de service pour les mêmes applications Bureau à distance Microsoft et Connexion au cloud Windows, telles qu’elles sont utilisées dans la section précédente, pour le groupe.

Microsoft Learn

Voici un rappel des étapes de configuration du SSO pour un environnement AVD :

  1. Activation de l’authentification Microsoft Entra pour le protocole RDP
  2. Création du groupe de machines AVD
  3. Configuration AVD pour activer l’authentification unique

Commençons donc par correctement configurer le SSO au niveau de l’application Entra ID.

Tâche II – Activation de l’authentification Microsoft Entra pour le protocole RDP :

Depuis votre portail Azure, ouvrez le service Azure Cloud Shell :

Importez les 2 modules Graph suivants, puis connectez-vous à ce dernier :

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

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

Validez l’authentification de votre compte grâce à un Device Code :

Obtenez l’ID d’objet de chaque principal de service, puis stockez-les dans des variables en exécutant les commandes PowerShell suivantes :

  • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
$MSRDspId = (Get-MgServicePrincipal -Filter "AppId eq 'a4a365df-50f1-4397-bc59-1a1564b8bb9c'").Id
$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Vérifiez la valeur actuelle de la propriété isRemoteDesktopProtocolEnabled :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Définissez la propriété isRemoteDesktopProtocolEnabled sur true en exécutant les commandes suivantes :

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

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

Vérifiez le changement de valeur de la propriété isRemoteDesktopProtocolEnabled :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Pour information, la commande PowerShell suivante vous permet si besoin de revenir en arrière :

$params = @{
	"@odata.type" = "#microsoft.graph.remoteDesktopSecurityConfiguration"
	isRemoteDesktopProtocolEnabled = $false
}

Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId -BodyParameter $params
Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -BodyParameter $params

La suite de la configuration SSO se passe au niveau d’un groupe Entra ID.

Tâche III – Création d’un groupe de machines AVD :

Créez un groupe Entra ID dans lequel vous y ajoutez les différentes machines hôtes d’Azure Virtual Desktop :

Copiez les valeurs suivantes de votre groupe de machines virtuelles AVD :

  • Nom du groupe
  • Object ID

Intégrez ces 2 valeurs dans la commande PowerShell suivante :

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

Ajoutez le groupe à l’objet targetDeviceGroup en exécutant les commandes PowerShell suivantes :

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $MSRDspId -BodyParameter $tdg
New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Pour information, la commande PowerShell suivante vous permet si besoin de revenir en arrière :

Remove-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $MSRDspId -TargetDeviceGroupId "<Group object ID>"
Remove-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -TargetDeviceGroupId "<Group object ID>"

La suite se passe au niveau du pool d’hôtes AVD.

Tâche IV – Configuration AVD pour activer l’authentification unique :

Finissons par l’activation de l’option SSO depuis les propriétés RDP de votre pool d’hôtes AVD :

Il ne reste qu’à refaire un test utilisateur depuis votre client Microsoft Remote Desktop :

Tâche V – Second test AVD avec SSO :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de cet utilisateur :

Confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Plus aucune authentification supplémentaire n’est nécessaire, la session de bureau à distance AVD s’ouvre directement :

La fonctionnalité SSO est maintenant en place sur notre environnement Azure Virtual Desktop. Continuons maintenant avec l’accès conditionnel AVD.

Tâche VI – Accès conditionnel actuel AVD (Portail) :

Pour rappel, j’utilise déjà cet accès conditionnel pour protéger l’accès à Azure Virtual Desktop. Voici ma configuration actuelle de la police d’accès conditionnel AVD :

Comme vous pouvez le voir, l’application ciblée est Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07)

Voici l’impact sur l’utilisateur AVD quand cette première police est activée :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de ce premier utilisateur AVD :

L’accès conditionnel AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

L’ouverture de la session AVD de ce premier utilisateur se fait automatiquement :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Continuons avec un second test d’accès conditionnel ciblant cette fois les 2 applications indiquées dans l’email de Microsoft :

  • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45

Tâche VII – Accès conditionnel actuel AVD (VM) :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de ce second utilisateur AVD :

Aucune MFA renforcée n’est exigée, mais confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Renseignez à nouveau les identifiants Cloud de l’utilisateur AVD :

L’accès conditionnel à la VM d’AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’ouverture de la session AVD de ce second utilisateur se fait dans la foulée du challenge MFA :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Terminons les tests par une combinaison de 2 polices d’accès conditionnels ciblant les 3 applications AVD.

Tâche VIII – Accès conditionnel AVD doublé (Portail + VM) :

J’ai paramétré un troisième utilisateur pour avoir une MFA renforcée sur les 3 applications AVD, via 2 polices distinctes d’accès conditionnel :

Police Portail

  • Police Portail :
    • Azure Virtual Desktop : 9cdead84-a844-4324-93f2-b2e6bb768d07
  • Police VM :
    • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
    • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de cet utilisateur :

L’accès conditionnel Portail fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

L’ouverture de la session AVD de ce troisième utilisateur se fait automatiquement sans repasser par un challenge MFA de la police VM :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Conclusion

Ce mail d’information Microsoft m’a donc permis de correctement configurer le SSO AVD. Il nous explique également la mise à jour nécessaires des polices d’accès conditionnel pour garantir la continuité du service et la sécurité des connexions avec Azure Virtual Desktop.

En intégrant l’application Windows Cloud Login Entra ID avant le 26 juin 2024, vous assurerez une transition fluide et éviterez toute interruption de service 🤘

Associez un disque éphémère à votre AVD

Les disques éphémères existent depuis déjà quelques années sur Azure. Mais est-ce qu’un environnement de bureau à distance comme Azure Virtual Desktop associé à ce type de disque est possible ? Si oui, qu’est-ce que cela donne en termes de performances, mais également quelles en seraient les contraintes ?

Qu’est-ce qu’un disque éphémère sur Azure ?

Contrairement aux disques persistants, les disques éphémères sont :

  • temporaires et ne conservent pas les données au-delà du cycle de vie de la machine virtuelle.
  • Ils offrent généralement des performances supérieures aux disques persistants car ils sont directement attachés à l’hôte physique sous-jacent.
  • Ils sont également sujets à la perte de données en cas de panne de la machine virtuelle ou de redémarrage.
  • Leur prix est inclus dans le coût de la taille de la machine virtuelle.
  • Leur taille dépend exclusivement de la taille de la machine virtuelle choisie.
  • Peut se présenter sous deux formes possibles : cache ou disque temporaire (D).

L’excellente vidéo de John Savill vous permettra de bien comprendre le principe des différents disques éphémères sur Azure :

Quels sont les risques à utiliser un disque éphémère ?

Ces disques sont souvent utilisés pour des charges de travail temporaires qui ne nécessitent pas de stockage permanent ou pour des applications qui peuvent reconstruire leurs données en cas de perte.

Il est donc essentiel de sauvegarder les données importantes sur des disques persistants ou d’autres services de stockage Azure si la persistance des données est nécessaire.

Voici 2 pages utiles pour mettre en pratique les disques éphémères :

Comparé à un disque de système d’exploitation standard, un disque éphémère offre une latence plus faible pour les opérations de lecture/écriture et permet une réinitialisation plus rapide des machines virtuelles.

Microsoft Learn

Enfin, Microsoft a mis à disposition la FAQ suivante sur Microsoft Learn.

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur Azure Virtual Desktop combiné à plusieurs types de disque :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les disques éphémères intégrés à un Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Préparation de l’environnement AVD :

Avant de pouvoir déployer un environnement Azure Virtual Desktop, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

Nommez votre réseau virtuel, puis cliquez sur Vérifier:

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

Cliquez-ici pour accéder à votre réseau virtuel :

Dans le menu suivant, cliquez ici pour déployer Azure Bastion :

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant la barre de recherche du portail Azure :

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

Choisissez le type Partagé pour l’environnement AVD, puis cliquez sur Suivant :

Choisissez une image OS sous Windows 11 :

Sélectionnez la taille de VM suivante ainsi que le disque OS en Premium SSD :

Note : comme vous pouvez le voir, il n’est pas possible depuis l’interface actuelle d’AVD d’y spécifier un disque OS éphémère.

Joignez votre VM à Microsoft Entra ID, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

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

Une fois le déploiement d’Azure Virtual Desktop terminé, cliquez-ici :

Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Cliquez sur le nombre de machines AVD hôtes :

Cliquez sur le premier hôte AVD :

Cliquez sur la machine virtuelle AVD correspondante :

Vérifiez la présence d’un disque OS managé Premium SSD, puis cliquez-dessus :

Vérifiez les caractéristiques du disque :

Notre environnement Azure Virtual Desktop est maintenant en place. Nous devons maintenant rajouter 2 machines virtuelles supplémentaires pour comparer les performances des disques :

  • Création d’une VM AVD avec un disque éphémère cache
  • Création d’une VM AVD avec un disque éphémère temporaire

Commençons par la machine virtuelle dont le disque OS sera sur le cache.

Etape II – Création d’une VM AVD avec un disque éphémère CACHE :

Recherchez le services des machines virtuelles, puis cliquez ici pour en créer une nouvelle :

Renseignez les informations de votre seconde machine virtuelle en choisissant une image OS sous Windows 11 :

Choisissez une machine virtuelle de type D8ds_v3 :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Activez l’option de placement du disque OS sur le cache, puis cliquez sur Suivant :

Retirez l’adresse IP publique, puis cliquez sur Suivant :

Retirer l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la machine virtuelle :

Environ 4 minutes plus tard, la machine virtuelle est créée :

Connectez-vous à cette dernière via le service Azure Bastion :

Sur la machine virtuelle, ouvrez Microsoft Edge sur la page suivante pour installer les 2 agents AVD :

Téléchargez les 2 agents AVD sur votre machine virtuelle :

Lancez en premier l’installation de l’Azure Virtual Desktop Agent, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Sur le portail Azure, retournez sur votre pool d’hôtes AVD afin d’y récupérer la clef d’enregistrement :

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Lancez en second l’installation de l’Azure Virtual Desktop Agent Bootloader, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Retournez sur le portail Azure afin de constater l’apparition d’une nouvelle machine dans votre pool d’hôtes AVD :

Pendant que le statut de celle-ci est sur Mis à jour, constatez l’installation de 2 autres agents supplémentaires sur votre nouvelle VM AVD :

Quelques secondes plus tard, le statut de votre nouvelle VM AVD passe en indisponible :

Activez par cette option la mise en place d’une identité managée :

Dans le menu des extensions, cliquez-ici pour en ajouter une nouvelle :

Choisissez l’extension suivante pour joindre votre VM à Entra ID, puis cliquez sur Suivant :

Lancez la validation Azure :

Lancez l’installation de votre extension sur votre seconde VM :

Attendez 2 minutes la fin de l’installation de l’extension :

Vérifiez sur Entra ID l’apparition de votre seconde machine virtuelle :

Vérifiez également la jointure à Entra ID depuis la session Bastion et grâce à la commande suivante :

dsregcmd /status

Quelques secondes plus tard, le statut de votre seconde VM passe en disponible :

Continuons avec la création de la troisième VM dont le disque OS sera sur la partition temporaire.

Etape III – Création d’une VM AVD avec un disque éphémère TEMPORAIRE :

Recherchez le services des machines virtuelles, puis cliquez ici pour en créer une nouvelle :

Renseignez les informations de votre troisième machine virtuelle en choisissant une image OS sous Windows 11 :

Choisissez une machine virtuelle de type D8ds_v5 :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Activez l’option de placement du disque OS sur le temporaire, puis cliquez sur Suivant :

Retirez l’adresse IP publique, puis cliquez sur Suivant :

Retirer l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la machine virtuelle :

Environ 4 minutes plus tard, la machine virtuelle est créée :

Connectez-vous à cette dernière via le service Azure Bastion :

Sur la machine virtuelle, ouvrez Microsoft Edge sur la page suivante pour installer les 2 agents AVD :

Téléchargez les 2 agents AVD sur votre machine virtuelle :

Lancez en premier l’installation de l’Azure Virtual Desktop Agent, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Sur le portail Azure, retournez sur votre pool d’hôtes AVD afin d’y récupérer la clef d’enregistrement :

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer

Lancez en second l’installation de l’Azure Virtual Desktop Agent Bootloader, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Retournez sur le portail Azure afin de constater l’apparition d’une nouvelle machine dans votre pool d’hôtes AVD :

Pendant que le statut de celle-ci est sur Mis à jour, constatez l’installation de 2 autres agents supplémentaires sur votre nouvelle VM AVD :

Quelques secondes plus tard, le statut de votre nouvelle VM AVD passe en indisponible :

Activez par cette option la mise en place d’une identité managée :

Dans le menu des extensions, cliquez-ici pour en ajouter une nouvelle :

Choisissez l’extension suivante pour joindre votre VM à Entra ID, puis cliquez sur Suivant :

Lancez la validation Azure :

Lancez l’installation de votre extension sur votre troisième VM :

Attendez 2 minutes la fin de l’installation de l’extension :

Vérifiez sur Entra ID l’apparition de votre troisième machine virtuelle :

Quelques secondes plus tard, le statut de votre troisième VM passe en disponible :

Nos 3 machines virtuelles sont maintenant opérationnelles. Pourtant nous ne voyons qu’un seul disque en tant que ressource Azure :

Pourtant le disque OS est bien présent sur la seconde VM :

Le disque OS est également bien présent sur la troisième VM, dont les IOPS sont très très élevés :

Pour nous y connecter avec des utilisateurs AVD, nous devons maintenant rajouter des droits à des utilisateurs de test sur celles-ci.

Etape IV – Connexions aux VMs de l’environnement AVD :

Sur ce même groupe de ressources, ajoutez les deux rôles Azure RBAC suivants pour vos utilisateurs de test :

Ouvrez ensuite le client Remote Desktop puis authentifiez-vous avec 3 utilisateurs différents :

Ouvrez ensuite 3 sessions AVD de telle façon à ce que chacun se retrouve seul sur une VM :

Sur chacune des 3 sessions AVD :

  • Ouvrez le gestionnaire des disques afin de constater les différentes tailles des partitions.
  • Téléchargez l’exécutable DiskSpd via ce lien Microsoft, puis décompressez l’archive ZIP à la racine du disque C.
  • Lancez le moniteur de ressources Windows.
  • Ouvrez une fenêtre PowerShell en mode administrateur, puis exécutez les 2 scripts de tests suivants :
.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L C:\diskpsdtmp.dat > IOPS.txt
.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L C:\diskpsdtmp.dat > Throughput.txt

Machine virtuelle AVD avec disque OS Premium SSD :

Voici un tableau affichant les informations de la VM D8ds v5 :

Le disque temporaire est bien de 300 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS CACHE :

Voici un tableau affichant les informations de la VM D8s v3 :

Le disque temporaire est bien de 64 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS TEMPORAIRE :

Voici un tableau affichant les informations de la VM D8ds v5 :

Le disque temporaire est bien la soustraction de 300 Go – 128 Go, soit environ 172 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Voyons ensemble les différentes de performances des 3 machines virtuelles AVD.

Etape V – Synthèse des résultats :

Pour plus de clarté, j’ai synthétisé tous mes résultats IOPS dans le tableau ci-dessous :

j’ai également synthétisé tous mes résultats Throughput dans le tableau ci-dessous :

Conclusion

Il n’y a rien à dire, l’écart de performances entre ces 3 types de disque est très impressionnant ! Et cet écart se creuse encore plus si on change la taille de la machine virtuelle TEMP en D16ds v5 :

De plus, j’ai utilisé le Calculateur Azure afin de comparer les prix des 3 types de disque selon les performances relevées plus haut :

Enfin, Microsoft nous rappelle certaines contraintes liées à l’utilisation de disque OS éphémères :

  • Un redimensionnement de la machine virtuelle avec un disque éphémère fera perdre toute la donnée modifiée :
  • Il n’est pas possible de désallouer les ressources machines quand un disque éphémère est utilisé :
  • Il n’est pas possible de sauvegarder une machine virtuelle quand un disque OS éphémère est utilisé :

En somme, ces points ne devraient pas être des blocages pour des environnements Azure Virtual Desktop dans la mesure où ces derniers, généralement, ne stockent pas d’informations utilisateurs et sont constitués à partir d’une golden image 😎🙏.

Changez l’URL de votre AVD

Vous la souhaitez plus longue ou plus courte votre URL d’accès à Azure Virtual Desktop ? C’est à vous de choisir ! Mettez en place une URL raccourcie pour accéder à la page d’authentification AVD, vos utilisateurs vous remercieront ! Sinon, il y aussi l’URL AKA.MS d’Azure Virtual Desktop 😎🤘

En parcourant le blog de George Markou, je suis tombé sur le billet suivant : Utiliser un nom de domaine mémorable avec Azure Virtual Desktop.

Aucun doute que cette fonctionnalité pourra être très utile car plusieurs longues URLs Microsoft sont actuellement disponibles pour accéder aux services HTML5 d’Azure Virtual Desktop ou Windows 365:

Mais comment faire pour ajouter une URL de redirection depuis un nom de domaine personnalisé ?

On peut utiliser des sites comme Long URL Maker 🤣, ou faire comme moi en suivant le conseil de George Markou disponible juste ici. Cela donnera alors des URLs courtes pour AVD comme par exemple :

J’ai donc décidé de tester 2 méthodes différentes dans cet article :

Etape 0 – Rappel des prérequis :

Pour réaliser ces tests sur la personnalisation de l’URL d’Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un nom de domaine

Commençons par la première méthode basée sur une Static Web App.

Méthode IUtilisation d’une Static Web App :

Avec ce service, vous pouvez rapidement et facilement déployer un site web statique qui redirige vers un autre site web, dans notre cas il s’agirait du client HTML5 Azure Virtual Desktop. En général, Azure Static Web Apps est un service qui construit et déploie automatiquement des applications web complètes sur Azure à partir d’un dépôt de code.

George Markou

Un rapide tour dans le calculateur Azure nous montre l’avantage principal d’une Static Web App : son prix :

Disponible en version gratuite, cette Static Web App devrait correspondre à la majorité des scénarios de redirection Azure Virtual Desktop.

Le schéma ci-dessous nous montre le fonctionnement de redirection de notre Static Web App :

Vous l’aurez probablement compris, nous allons utiliser un peu de code pour effectuer cette direction.

Pour cela, commencez par créer votre compte GitHub si cela n’est pas déjà fait :

Une fois votre compte GitHub créé, rendez-vous sur le répertoire de George via ce lien afin de cloner son répertoire template vers votre compte GitHub :

Nommez ce nouveau répertoire selon vos souhaits, puis cliquer sur Créer :

Attendez quelques secondes que le traitement de copie se termine :

Retournez sur la page du portail Azure afin de recherche le service Static Web App :

Créez votre Static Web App en cliquant ici :

Renseignez les informations de base, dont le nom de votre Static Web App :

Choisissez la source GitHub, authentifiez-vous avec votre compte, choisissez le répertoire nouvellement importé, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la ressource :

Environ 1 minute plus tard, cliquez-ici pour consulter votre Static Web App :

Un dossier workflow est maintenant présent sur votre GitHub :

Cliquez sur l’URL suivante pour éditer le workflow :

Cliquez sur le bouton suivant pour éditer le fichier yaml présent sur votre GitHub :

Modifiez la ligne 31 comme ceci :

Avant :

app_location: "/" # App source code path

Après :

app_location: "/src" # App source code path

Cliquez sur Commit changes :

Indiquez si besoin une description, puis cliquez sur Commit changes :

Après quelques secondes, une action GitHub sera déclenchée, poussant le code vers la Static Web App nouvellement créée.

Retournez sur votre Static Web App afin de lui ajouter votre nom de domaine personnalisé :

Saisissez le nom de votre domaine ou sous-domaine, puis cliquez sur Suivant :

Sélectionnez le type CNAME, puis copiez la valeur de celle-ci dans votre presse-papier :

Sur la page de gestion de votre nom de domaine personnalisé, créez un nouvel enregistrement de type CNAME avec comme valeur celle copiée :

Confirmez votre création d’enregistrement DNS :

Attendez quelques secondes l’actualisation de vos enregistrements DNS :

Retournez sur le portail Azure afin de cliquer sur Ajouter :

Attendez quelques secondes qu’Azure confirme la présence de votre enregistrement DNS pointant vers le CNAME indiqué :

Une fois le domaine validé, cliquez sur Fermer :

Dans la liste des domaines personnalisés, vérifiez la présence de votre nouvel ajout :

Quelques minutes plus tard, ouvrez un nouvel onglet dans votre navigateur vers l’URL configurée :

Constatez apparition rapide du message de transfert suivant :

Constatez le changement d’URL :

Une fois les services AVD accessibles, cliquez sur l’un d’eux :

Attendez quelques secondes l’établissement de la connexion :

Attendez quelques secondes l’ouverture de la session :

L’URL personnalisée pour Azure Virtual Desktop fonctionne sans souci avec une Static Web App.

Il ne nous reste qu’à tester la même chose avec Azure Front Door.

Méthode IIUtilisation d’Azure Front Door :

Un second tour dans le calculateur Azure nous montre le coût Azure Front Door :

Bien évidemment cela s’explique par la multitude de fonctionnalités disponibles sur Azure Front Door :

Le tableau suivant fournit une comparaison entre 2 SKUs Azure Front Door :

Fonctionnalités et optimisationsFront Door StandardFront Door Premium
Livraison et accélération
Remise de fichiers statiquesOuiOui
Livraison de site dynamiqueOuiOui
Domaines et certificats
Domaines personnalisésOui – Validation de domaine basée sur un enregistrement TXT DNSOui – Validation de domaine basée sur un enregistrement TXT DNS
Prise en charge de HTTPSOuiOui
HTTPS sur un domaine personnaliséOuiOui
Apportez votre propre certificatOuiOui
Versions prises en charge de TLSTLS1.2, TLS1.0TLS1.2, TLS1.0
Mise en cache
Mise en cache des chaînes de requêteOuiOui
Gestion du cache (vidage, règles et compression)OuiOui
Purge rapideNoNon
Préchargement de ressourcesNoNon
Paramètres de comportement du curseurOui à l’aide du moteur de règles standardOui à l’aide du moteur de règles standard
Routage
Équilibrage de charge d’origineOuiOui
Routage basé sur le cheminOuiOui
Moteur de règlesOuiOui
Variable de serveurOuiOui
Expression régulière dans le moteur de règlesOuiOui
Redirection/Réécriture d’URLOuiOui
Double pile IPv4/IPv6OuiOui
Assistance HTTP/2OuiOui
Préférence de routage non mesuréeNon requis car le transfert de données de l’origine Azure vers l’AFD est gratuit et le chemin est directement connectéNon requis car le transfert de données de l’origine Azure vers l’AFD est gratuit et le chemin est directement connecté
Port de l’origineTous les ports TCPTous les ports TCP
Moteur de distribution de contenu personnalisable et basé sur des règlesOuiOui
Règles pour appareils mobilesOuiOui
Sécurité
Règles personnalisées du pare-feu d’applications webOuiOui
Ensemble de règles managées MicrosoftNonOui
Protection des botsNonOui
Connexion de liaison privée à l’origineNonOui
GéofiltrageOuiOui
Jeton d’authentificationNoNon
Protection DDOSOuiOui
Analytique et création de rapports
Surveillance MétriquesOui (plus de métriques que Classic)Oui (plus de métriques que Classic)
Analyses avancées/rapports intégrésOuiOui – comprend le rapport WAF
Journaux bruts – journaux d’accès et journaux WAFOuiOui
Journal des sondes d’intégritéOuiOui
Simplicité d’utilisation
Intégration facile avec les services Azure, tels que le stockage et les applications WebOuiOui
Gestion via REST API, .NET, Node.js ou PowerShellOuiOui
Types MIME de compressionConfigurableConfigurable
Encodages de compressiongzip, brotligzip, brotli
Intégration d’Azure PolicyNoNon
Intégration des conseils AzureOuiOui
Identités managées avec Azure Key VaultOuiOui
Tarification
Tarification simplifiéeOuiOui

Dans mon cas, j’utilise déjà un service Azure Front pour mon blog, lui-même hébergé sur une Wep app Azure.

Une fois Azure Front Door en place, rendez-vous dans le menu suivant :

Ajoutez la règle de configuration suivante :

Attendez environ une minute la fin de la création, puis associez à votre règle la route via le menu suivant :

Choisissez une route, puis cliquez sur Suivant :

Modifiez au besoin l’ordre d’exécution des règles, puis cliquez sur Associer :

Attendez environ une minute la fin de l’association :

Retournez dans le menu suivant afin d’ajouter le domaine ou sous-domaine dédié à votre URL Azure Virtual Desktop :

Auprès de votre fournisseur de nom de domaine, ajoutez les 3 enregistrements DNS suivants :

  • A
  • AAAA
  • TXT

Quelques minutes plus tard, ouvrez un nouvel onglet dans votre navigateur vers l’URL configurée :

Constatez le changement d’URL :

Une fois les services AVD accessibles, cliquez sur l’un d’eux :

Attendez quelques secondes l’ouverture de la session :

L’URL personnalisée pour Azure Virtual Desktop fonctionne là aussi sans souci avec Azure Front Door.

Conclusion

Quelle que soit la méthode choisie pour la personnalisation de votre URL Azure Virtual Desktop, celles-ci sont simple et facile à mettre en oeuvre et facilitera la vie de vos utilisateurs 🥳

FSLogix sont nos amis 🙏!

FSLogix est une excellente solution pour assurer la gestion des profils de vos utilisateurs. Très souvent utilisé dans différents types d’environnement VDI, FSLogix s’adapte très bien et très facilement à Azure Virtual Desktop. Mais la configuration de FSLogix a besoin d’être manipulée avec précaution pour ne pas devenir un cauchemar pour vos utilisateurs et par ricochet sur vous.

Un précédent article sur ce blog parle déjà de la mise en place de la solution FSLogix au sein d’un environnement Azure Virtual Desktop, dont voici le lien.

La solution FSLogix en quelques mots & vidéos :

Azure Virtual Desktop recommande les conteneurs de profil FSLogix. FSLogix est société acquise par Microsoft en novembre 2018. Elle propose une solution de conteneurisation des profils utilisateurs en itinérance, utilisable dans une large gamme de scénarios sous format VHD ou VHDX. Avec FSLogix, vous allez pouvoir réaliser les actions suivantes pour vos utilisateurs :

  • Centralisation des profils utilisateurs Azure Virtual Desktop
  • Dissociation possible entre les conteneurs Office365 avec les conteneurs profils utilisateurs
  • Gestion des applications visibles ou non via la fonction AppMasking
  • Contrôle des versions JAVA
  • Customisation de l’installation via de nombreuses règles ou via GPO
  • Sans les conteneurs de profil FSLogix, OneDrive Entreprise n’est pas pris en charge dans les environnements RDSH ou VDI non persistants

Un grand merci à Dean Cefola de l’Azure Academy pour cette playlist YouTube très complète autour de FSLogix :

Il est important de comprendre que la configuration FSLogix dépendra de beaucoup de paramètres, et qu’il est difficile d’en établir une adaptée à tous les cas d’usages.

Durant l’écriture de cet article, j’ai retrouvé un grand nombre de documentations utiles à une meilleure compréhension de FSLogix, dont certaines proviennent Microsoft Learn :

Mais aussi d’autres sources non-Microsoft :

Ce nouvel article a donc pour but de partager avec vous une problématique FSLogix possible ainsi qu’une méthode de résolution :

Pour des questions de confidentialité, l’environnement présent ci-dessous est une copie approchante de l’environnement réel du client concerné.

Etape 0 – Contexte :

Je suis intervenu sur un environnement Azure Virtual Desktop sur lequel les utilisateurs se plaignaient d’être constamment obligés de se réauthentifier à leurs outils Microsoft 365 à chaque ouverture :

Cela concernait les outils de productivités (Word, Excel, PowerPoint), mais également les outils de collaborations (Outlook, OneDrive, Teams). La gêne pour les utilisateurs était donc évidente.

Voici une description des ressources Azure déjà en place :

  • Domain managé Entra Domain Services
  • Environnement AVD avec 2 hôtes
  • Stockage des profiles FSLogix sur un Azure File Share + sauvegarde
  • Gestion des images via une Azure compute gallery
  • Accès RDP via Azure Bastion

Voici le groupe de ressources Azure contenant le domaine managé Microsoft :

Voici le groupe de ressources Azure contenant l’environnement AVD et le compte de stockage utilisé pour les profils FSLogix :

Voici le groupe de ressources Azure contenant l’image Windows 11 stockée dans une Azure compute gallery :

Voici une vue de l’environnement Azure Virtual Desktop :

Voici une vue des groupes Entra ID en relation avec Azure Virtual Desktop :

Voici une vue du compte stockage contenant le partage de fichiers dédié aux profils FSLogix :

Voici le paramétrage indiquant que le compte de stockage est joint au domaine managé Microsoft et les droits RBAC de base pour le partage :

Concernant la partie administration d’AVD, je retrouve bien des droits d’administration RBAC plus élevés et dédiés à la configuration des droits NTFS :

La sauvegarde concernant la partie FSLogix est également bien en place :

Sur ce même compte de stockage dédié à FSLogix, l’accès réseau Internet est bien coupé :

En lieu et place, un point d’accès privé pour connecter le compte de stockage au réseau virtuel AVD :

En me connectant avec un compte administrateur sur l’environnement AVD, j’ai pu vérifier que les droits NTFS appliqués au partage de fichiers FSLogix étaient bien cohérent :

Enfin les règles de registres implémentés directement sur la VM AVD et donc sur l’image reprennent les recommandations de base de Microsoft, disponible juste ici :

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles

L’environnement semble bon, et le problème semble à priori en relation avec les tokens.

L’étape suivante est alors la reproduction sur problème rencontré par les utilisateurs d’Azure Virtual Desktop.

Etape I – Premier test d’un l’utilisateur impacté :

Pour cela, j’utilise le client Remote Desktop sur Windows afin d’ouvrir une session AVD sur un utilisateur impacté :

Je renseigne les identifiants :

La session Windows 11 s’ouvre bien et indique un chargement du profil via la solution FSLogix :

Le dossier du profil est bien présent sur le partage de fichier Azure comme indiqué dans la configuration registre Windows :

J’ouvre une première fois l’outil Power Point :

Je m’identifie dans l’application avec un compte Microsoft 365 correctement licencié :

L’authentification d’Office 365 fonctionne bien et sans erreur :

Je ferme et réouvre la session Azure Virtual Desktop avec ce même utilisateur :

Je réouvre PowerPoint et je constate le besoin de réauthentification systématique, comme dans toutes les autres applications Microsoft 365 :

Par le bais de l’explorateur Windows, je me rends dans le dossier suivant pour ouvrir l’application frxtray :

  • C:\Program Files\FSLogix\Apps\
    • frxtray.exe

J’affiche les différents journaux d’évènements à la recherche d’erreurs potentielles, sans succès :

Afin de poursuivre mon investigation, je décide d’appliquer la stratégie suivante :

  • Création d’une nouvelle machine virtuelle AVD depuis la dernière image
  • Mise à jour de l’OS Windows 11
  • Mise à jour des applications Office 365
  • Mise à jour de FSLogix

Pour cela, je commence par créer cette nouvelle machine virtuelle Azure.

Etape II – Création d’une première VM image AVD :

Je créé une nouvelle machine virtuelle en prenant soin de sélectionner la dernière image AVD en Windows 11 personnalisée et stockée dans la galerie :

Une fois créée, je m’y connecte en utilisant le service Azure Bastion :

Je lance toutes les mises à jour Windows 11 disponibles :

Pour effectuer les mises à jour d’Office365, je réactive la règle de registre suivante :

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
    • UpdatesEnabled
      • True

J’ouvre un programme Office 365 et lance la recherche des mises à jour :

J’attends le message suivant signifiant la bonne installation des mises à jour Office 365 :

Je retourne dans le registre Windows pour remettre la valeur suivante :

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
    • UpdatesEnabled
      • False

Dans la liste des applications installées, je vérifie et désinstalle si besoin l’ancienne version de FSLogix :

Je redémarre la machine et retourne sur le site officiel de Microsoft pour y télécharger la dernière version de FSLogix :

J’en profite pour parcourir les notes des dernières versions de FSLogix :

Et la suite se passe de commentaire 🤣.

Etape III – Identification de la cause :

J’en profite pour parcourir les bogues connus de FSLogix :

Et je tombe sur celui-ci 😎 :

Microsoft propose également une résolution juste ici :

Je décide donc de rajouter cette clef de registre sur mon image AVD à jour :

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles
    • RoamIdentity
      • 1

La correction est maintenant appliquée sur ma machine virtuelle image. Je décide donc de créer une nouvelle image contenant les mises à jour Windows 11, Office 365 et FSLogix, mais également la correction apportée par la clef de registre.

Etape IV – Création d’une seconde VM image AVD :

Sur la machine virtuelle image, je lance la commande Sysprep suivante selon la documentation Microsoft :

Sysprep /generalize /oobe /mode:vm /shutdown

Sysprep s’exécute et m’invite à patienter quelques minutes :

La session de bureau à distance ouverte via Azure Bastion se ferme quand la machine virtuelle commence sa phase d’extinction :

Quelques secondes plus tard, le portail Azure affiche bien la machine virtuelle image comme étant arrêtée, je décide donc de l’arrêter complètement :

Une fois entièrement désallouée, je lance la capture :

Je créé une nouvelle version dans la galerie utilisée précédemment, et attends environ 20 minutes que le traitement se termine :

L’environnement Azure Virtual Desktop est maintenant prêt pour recevoir une nouvelle machine virtuelle à partir de cette image.

Etape V – Création d’une nouvelle hôte AVD :

Je retourne sur la page de mon pool d’hôte AVD afin d’y ajouter une nouvelle VM comme ceci :

Je reprends la même taille de VM qu’utilisée précédemment tout en choisissant la dernière version de mon image, puis lance la création des ressources Azure :

Environ 10 minutes plus tard, une nouvelle hôte apparaît dans mon environnement Azure Virtual Desktop. Enfin j’active le mode Drain sur les autres machines virtuelles encore sous ancienne version d’image AVD :

Il ne me reste plus maintenant qu’à retester avec le compte d’un utilisateur impacté pour constater un changement après plusieurs réouvertures d’une session AVD.

Etape VI – Second test d’un l’utilisateur impacté :

J’utilise à nouveau le client Remote Desktop sur Windows afin d’ouvrir une session AVD sur un utilisateur de test :

Après plusieurs connexions / déconnexions, l’authentification 365 persiste bien dans les différentes applications 365. Pour en être sûr, plusieurs tests sont effectués dans les applications Word, Excel, PowerPoint, Outlook, OneDrive, Teams. 😎💪

Conclusion

Dans mon cas le problème a été résolu car plusieurs informations ont été partagées sur des forums IT et sur la documentation Microsoft. Cela n’est pas toujours le cas et peut engendrer une certaine frustration quand aucune solution n’est trouvée.

Néanmoins, je souhaitais partager avec vous au travers de cet article une approche assez classique dans la résolution de souci liée à des produits IT en général (chose que l’on ne fait pas toujours, moi le premier)

  • Lire les documentations officielles 😎
  • Ne pas touchez aux environnements de productions
  • Mettez à jour les OS (Windows 11)
  • Mettez à jour les applications (Office 365)
  • Mettez à jour les intermédiaires (FSLogix)
  • Appliquez les méthodes correctives préconisées par les éditeurs

Hibernez votre AVD ⛄❄️

Non cet article n’est pas un doublon du précédent, appelé Faites hiberner vos VMs, et parlant d’une méthode astucieuse pour ne pas entièrement éteindre une VM lorsque l’on souhaite réduire les coûts. Vous l’aurez compris, Microsoft propose également l’hibernation de VM pour son produit VDI phare : Azure Virtual Desktop.

Ça y est, l’Ignite de Microsoft est juste terminé ! Beaucoup de news très intéressantes ont été annoncées concernant Azure. Je vous invite d’ailleurs à lire le Book of news de cette édition 2023.

Concernant l’hibernation d’Azure, voici quelques petits rappels :

  • Lorsqu’on hiberne une VM Azure : ce dernier échange avec l’OS afin de stocker le contenu de la mémoire de la VM sur le disque du système d’exploitation, puis désalloue la VM.
  • Lorsque la VM est redémarrée et sort d’hibernation : le contenu de la mémoire est retransféré du disque OS vers la mémoire. Cela permet alors de retrouver les applications et processus en cours d’exécution.

Si l’envie vous prend d’en savoir un peu plus, je vous invite à lire l’article de la semaine dernière. Enfin, une toute nouvelle vidéo de Dean parle de l’hibernation dans un environnement AVD, le combo ultime :

Inutile de reparler en détail de l’hibernation, comme toujours je vous propose de réaliser un petit exercice, combinant AVD et l’hibernation.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice d’hibernation sur des VMs Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Préparation de l’environnement Azure :

Avant de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire d’activer cette dernière sur la souscription Azure concernée.

Pour cela, rendez-vous dans le portail Azure, sur la page des fonctionnalités en préversion de votre souscription, puis effectuez une activation en recherchant celle-ci comme ci-dessous :

Attendez environ une minute que votre demande soit acceptée par Microsoft :

La notification suivante vous indique alors le succès de l’opération :

La suite consiste maintenant à créer un environnement AVD et avec l’hibernation activée.

Etape II – Déploiement de l’environnement AVD :

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

Nommez celui-ci, puis cliquez sur Vérifier:

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

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant là encore la barre de recherche du portail Azure :

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

Choisissez le type Personnel pour l’environnement AVD, puis cliquez sur Suivant :

Confirmez la sécurité de la VM comme ceci :

Choisissez dans la liste des images Microsoft l’image Windows 11 version 22H2, sélectionnez une VM de Séries Dsv5, puis cochez la case Hibernation :

Joignez vos VMs AVD à Entra ID, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

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

Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer sa configuration des rôles RBAC :

Ajoutez-y les 3 rôles RBAC suivants à un utilisateurs de test AVD et à l’application Azure Virtual Desktop :

Nous devons rajouter un rôle Azure RBAC pour permettre à Azure Virtual Desktop (ou anciennement Windows Virtual Desktop) de pouvoir allumer et éteindre les VMs AVD :

De retour sur votre pool d’hôte AVD, activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Ajoutez le scaling plan qui pilotera la VM individuelle selon les besoins de connexion, puis cliquez sur Créer :

Donnez-lui un nom, placez-le dans la même région Azure que votre pool d’hôtes AVD, puis cliquez sur Suivant :

Ajoutez un ou plusieurs plannings selon vos besoins, sachant qu’une journée de la semaine ne peut être présent que dans un seul planning.

L’onglet suivant reprend le fuseau horaire du premier onglet et vous demande de renseigner les champs ci-dessous, puis de cliquer sur Suivant :

  • Heure de début : heure correspondant au début de la phase.
  • Démarrage de la VM : permet à l’utilisateur de pouvoir démarrer une VM éteinte pendant la phase. Cette option prend le pas sur la configuration renseignée dans le pool d’hôtes.
  • VMs à démarrer : propose de démarrer automatiquement des VMs si nécessaire dès le début de la phase, ou pas.
  • Paramètres de déconnexion : permet d’effectuer l’hibernation ou non.
  • Paramètres de fermeture de session : permet d’effectuer l’hibernation ou non

Renseignez les mêmes options que pour la phase précédente, puis cliquez sur Suivant :

Renseignez les mêmes options que pour la phase précédente, puis cliquez sur Suivant :

Renseignez les mêmes options que pour la phase précédente, puis cliquez sur Ajouter :

Cliquez sur Suivant pour continuer :

Rattachez votre pool d’hôtes à la configuration en n’oubliant pas de cocher la case pour l’activer, puis cliquez ici pour lancer la validation Azure :

Une fois la validation Azure réussie, cliquez sur Créer pour valider la configuration :

Attendez 1 minute que la configuration soit déployée :

Notre environnement AVD combiné à l’hibernation est enfin prêt, il ne nous reste plus qu’à utiliser un utilisateur pour tester les différentes phases de ce nouvel état.

Etape III – Test de l’hibernation :

Dans mon environnement de démonstration AVD, la machine virtuelle individuelle est déjà démarrée.

Depuis votre poste, téléchargez le client Remote Desktop depuis cette page officielle Microsoft, puis ouvrez l’application avec votre utilisateur de test AVD :

Lancez l’application de bureau à distance, puis authentifiez-vous encore une fois avec un compte AVD de test :

Validez la délégation en cliquant sur Oui :

Ouvrez une ou plusieurs applications sans enregistrer les travails effectués :

Fermez la session AVD en utilisant la croix du bureau à distance :

Confirmez le choix de déconnexion en cliquant sur OK :

A ce moment précis, la machine virtuelle AVD est toujours en statut Disponible :

Environ 10 minutes plus tard, son statut commence à changer :

Environ 1 minute plus tard, son statut AVD bien changé :

De retour dans la listes des machines virtuelles Azure, le statut d’hibernation est bien confirmé :

Afin de confirmer le bon retour des programmes ouvert, recliquez à nouveau sur l’application de bureau à distance, puis attendez le démarrage effectif de la VM AVD :

Environ 2 minutes plus tard, la session Windows se réouvre alors avec les programmes précédemment ouverts et non sauvegardés :

Conclusion :

La fonction d’hibernation annoncée il y seulement quelques jours est un atout non négligeable dans la gestion offline de machine virtuelle. Aucun doute que ce statut est plus pratique que l’arrêt complet dans un environnement Azure Virtual Desktop. Les utilisateurs de machines AVD individuelles seront sans aucun doute ravi ne pas devoir fermer et ouvrir toutes leurs applications tous les jours 😎

Azure Virtual Desktop + GPU = 🏎️

Cela faisait longtemps que je voulais tester une machine virtuelle disposant d’une carte graphique puissante dans un environnement Azure Virtual Desktop. Il arrive que des besoins graphiques soient présents dans certains projets. Il est actuellement impossible de les satisfaire via Windows 365, mais Azure Virtual Desktop ne dit pas son dernier mot ! Presque tous les types de machine virtuelles Azure y sont disponibles.

Commençons par quelques rappels qui ne nous feront pas de mal 😎

Qu’est-ce qu’une machine virtuelle Azure ?

Vous pouvez lire mon article dédié aux VMs Azure ou regarder cette vidéo en français :

Qu’est-ce qu’une machine virtuelle GPU Azure ?

L’idée est la même que pour une machine virtuelle classique, avec en plus une ou plusieurs cartes graphiques adaptées selon les besoins des utilisateurs :

Les tailles de machine virtuelle au GPU optimisé sont des machines virtuelles spécialisées disponibles avec des GPU uniques, multiples ou fractionnaires. Ces tailles sont conçues pour des charges de travail de visualisation, mais également de calcul et d’affichage graphique intensifs.

Microsoft Learn

Quels sont les GPUs disponibles sur Azure ?

Comme pour les autres machines virtuelles, les VM avec GPU sont organisées sous forme de séries, dont voici quelques exemples :

Peut-on créer une machine virtuelle GPU dans toutes les régions Azure ?

Malheureusement non, certaines régions ne disposent pas de VMs GPU, ou seulement certains SKUs y sont disponibles :

Pour nous aider, Microsoft a mis à disposition une page de documentation dédiée aux VMs GPU sous Azure Virtual Desktop. Plusieurs sujets y sont justement abordés :

Comme bien souvent, Dean Cefola de l’Azure Academy a lui-aussi posté il y a quelques années une vidéo YouTube parlant de ce sujet très intéressant :

Afin de se faire une meilleure idée sur le rendu possible de l’ensemble GPU + AVD, je vous propose de réaliser un petit exercice combinant ces 2 services. Nous allons détailler toutes les étapes nécessaires de la configuration aux tests de plusieurs applications :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les VMs GPU via Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Note importante : pour effectuer des tests GPU sur Azure, une souscription MSDN ne sera pas acceptée.

En effet, les machines virtuelles graphiques sont restreintes et le Support de Microsoft n’a pas souhaité octroyer des quotas sur ma souscription Azure MSDN. J’ai donc utilisé une souscription Azure payante pour réaliser ces tests GPU.

Etape I – Préparation de l’environnement Azure :

Comme indiqué précédemment, les souscriptions Azure sont restreintes dans la création de machines virtuelles dédiées aux besoins graphiques :

Cela est permet d’éviter un engorgement inutile de ces VMs très spécifiques, mais également les mauvaises surprises au moment de recevoir la facture Azure.

Il est donc nécessaire de relever le quota d’une des séries de VMs GPU pour réaliser cet exercice. Dans mon cas, je suis parti sur la série Standard NCASv3_T4.

Pour cela, rendez-vous dans le portail Azure, puis sur la page des quotas de votre souscription Azure, puis effectuez une demande d’élévation des quotas, en cliquant à droite sur la série de VMs de votre choix :

8 vCPU me semblent suffisant pour créer une ou deux petites machines virtuelles GPU.

Attendez environ une minute que votre demande soit acceptée par l’IA de Microsoft :

Nous voici maintenant autorisé à créer 2 VMs GPU Standard NC4as T4 v3, équipées chacune d’un processeur AMD EPYC 7V12 et d’une carte graphique NVIDIA Tesla T4.

Continuons maintenant à créer une première VM GPU dans le but de préparer une image modèle pour Azure Virtual Desktop.

Etape II – Création d’une machine virtuelle GPU :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant bien une image OS Windows 11 en version 22H2 :