Je souhaitais faire cet article depuis quelques temps déjà. Comme pour les autres services disponibles sur le Cloud Microsoft, Azure Virtual Desktop nécessite une sécurité renforcée. Hors de question de laisser un accès ouvert aux applications de l’entreprise avec un simple identifiant / mot de passe.
Dans cet article, nous allons commencer par reprendre quelques bases sur l’accès conditionnel disponible sur Azure AD. Puis nous allons le mettre en oeuvre dans un environnement Azure Virtual Desktop.
Qu’est-ce que l’Accès Conditionnel proposé par Azure AD ?
Tous les environnements informatiques sont quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers d’un hébergeur Cloud apporte une plus grande disponibilité de l’information aux utilisateurs, mais occasionne un plus de grand nombre de connexions à distances, et donc de situations à gérer pour la sécurité IT.
Le périmètre de sécurité moderne s’étend désormais au-delà du réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations peuvent utiliser des signaux d’identité dans le cadre de leurs décisions de contrôle d’accès.
Pour cela, Microsoft propose d’intégrer dans le processus d’authentification à Azure AD de nouvelles étapes, sous forme de police :
Signal : pour Azure AD, l’accès conditionnel repose sur un certain nombre de signaux ou paramètres. Ces derniers sont les éléments mêmes qui caractérise la connexion de l’utilisateur, tels que :
Emplacement (adresse IP)
Appareil (OS, version, conformité, …)
Utilisateur Azure AD
Application interrogée
IA (Détection des risques en temps réel par Azure AD Identity Protection)
Décision : la décision sera alors le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est question ici de bloquer l’accès à l’utilisateur, ou de l’autoriser selon les conditions particulières. Ces conditions correspondent à des mesures de sécurité supplémentaires, telles que :
Exiger une authentification multifacteur (cas plus utilisé)
Exiger que l’appareil soit marqué comme conforme
Exiger un appareil joint en hybride à Azure AD
Exiger une stratégie de protection des applications
Application : apporte une supervision des sessions et des accès utilisateur aux applications en fonction des stratégies d’accès et de session, telles que :
Empêcher l’exfiltration des données
Protéger lors du téléchargement
Empêcher le chargement de fichiers sans label
Bloquer les programmes malveillants potentiels
Surveiller les sessions utilisateur pour la conformité
Bloquer l’accès
Quelles sont les licences nécessaires pour l’accès conditionnel d’Azure AD ?
L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Azure AD Premium P1. Cela est donc bien différent des offres disponibles pour disposer de l’authentification multifacteur (Challenge MFA).
Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :
Azure AD Premium P1
Azure AD Premium P2
Enterprise Mobility + Security E3
Enterprise Mobility + Security E5
Microsoft 365 Business Premium
Microsoft 365 A3
Microsoft 365 A5
Microsoft 365 F1
Microsoft 365 F3
Microsoft 365 F5 Security
Microsoft 365 F5 Security + Compliance
Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?
Cette information provient des licences assignées aux utilisateurs du tenant. Ce n’est pas à proprement parler d’une licence ou un service du tenant :
Certains services clients ne sont actuellement pas capables de limiter les avantages à des utilisateurs spécifiques. Des efforts doivent être déployés pour limiter les avantages du service aux utilisateurs sous licence.
Autrement dit, une seule licence ayant la fonctionnalité d’accès conditionnel active l’option pour l’ensemble des utilisateurs du même tenant. Seulement, les règles d’utilisation du service exigent que chaque utilisateur soit couvert par une licence disposant de cette fonctionnalité.
Comment l’accès conditionnel est vécu par un utilisateur ?
Une fois l’accès conditionnel mis en place via une police, la sécurité est immédiatement renforcée par l’application de celle-ci. L’image ci-dessous montre en exemple une authentification multifacteur déployée par ce mécanisme pour protéger le portail Azure :
L’absence de réponse entraîne alors un blocage dans le processus d’authentification et donc de l’accès au portail Azure pour l’utilisateur :
En alternative, si l’utilisateur ne peut pas utiliser cette méthode, Il lui est malgré tout possible de continuer le processus d’authentification par une autre mesure disponible dans la double authentification :
Les réussites ou les échecs des connexions d’utilisateurs sont directement visibles dans le journal des connexions de l’utilisateur sur Azure AD :
Un clic sur une authentification affiche alors les détails et l’application de la police utilisée :
Essai I : Absence de règle d’accès conditionnel
Le premier essai que nous allons faire repose sur aucune configuration particulière.
L’accès au service Azure Virtual Desktop se fait en HTML 5 via l’URL officielle. L’accès conditionnel marcherait également avec les applications installées sur le poste en local, comme le client Remote Desktop, disponible ici au téléchargement.
Aucun blocage ni contrainte pour l’utilisateur n’est constaté :
La sécurité y est donc minimale et l’obtention du login et du mot de passe par un tier permet de se connecter à son environnement et d’accéder aux données.
Essai II : Mise en place d’une règle de blocage total
Le second essai nécessite la création d’une police d’accès conditionnel. Connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :
Ouvrez le menu de la Sécurité :
Rentrez dans la section d’Accès conditionnel :
Créez votre nouvelle Police :
Saisissez un nom à votre police et sélectionnez votre utilisateur de test :
Cherchez l’application Azure Virtual Desktop dans la section suivante :
Définissez la décision sur Bloquer l’accès :
Activez votre police et validez sa création :
Attendez quelques minutes et retester l’accès à Azure Virtual Desktop sur votre utilisateur. Pour information, l’accès conditionnel d’Azure AD dispose d’une fonction Et Si pour tester vos règles avant de les appliquer :
Quelques minutes plus tard, le test de connexion nous montre que blocage est bien effectif pour cet utilisateur :
Essai III : Mise en place d’une règle pour exiger la MFA
Retournez sur votre accès conditionnel et cliquez sur votre police pour la modifier :
Modifiez la décision pour autoriser l’accès à Azure Virtual Desktop, sous réserve d’un succès au challenge MFA par votre utilisateur de test :
Retentez la connexion à Azure Virtual Desktop avec votre utilisateur de test. La modification MFA de la police est bien prise en compte ici :
Dans mon cas, l’utilisateur est alors invité à enregistrer une ou des méthodes pour le challenge MFA pour poursuivre cette nouvelle opération d’authentification. L’application Microsoft Authenticator est proposée en tant que première méthode du challenge à configurer :
La méthode MFA choisie est immédiatement vérifiée pour éviter un blocage ultérieur :
Essai IV : Mise en place d’une règle pour bloquer la connexion autre qu’au bureau
La restriction ou le blocage d’un service comme Azure Virtual Desktop est possible selon la localisation de l’utilisateur par son adresse IP. Retournez sur votre police pour la modifier comme ceci :
Pensez à créer votre location de confiance, en reprenant votrepropre IP publique :
Retentez la connexion de votre utilisateur à AVD et constatez l’absence de blocage ou de challenge MFA :
Un contrôle dans le journal des connexions nous montre bien le processus d’exclusion de la police d’accès conditionnel grâce à mon adresse IP publique, exclue :
Essai V : Mise en place d’une règle pour exiger le challenge MFA toutes les heures
La mémorisation constante du challenge MFA sur une poste peut être considérée comme un risque sécuritaire, spécialement si le poste est en accès libre pour différents utilisateurs.
Retournez sur votre police pour la modifier comme ceci :
Effectuez l’authentification de votre utilisateur et réussissez le challenge MFA :
Validez la présence des icônes et attendez une heure. Une heure plus tard, rafraîchissez votre AVD :
Une MFA est bien redemandée après le délai défini dans la police d’accès conditionnel.
Conclusion :
Grâce à l’accès conditionnel d’Azure AD, il est assez facile de renforcer la sécurité d’Azure Virtual Desktop. Comme toujours, Microsoft rappelle les risques encourus à seulement utiliser un login et mot de passe pour seule sécurité. L’excellente vidéo de Dean nous montre cela en détail :
En espérant que cela a pu vous aider à mieux sécuriser votre environnement Cloud ????
Après ces quelques chaudes semaines d’été, il est pour nous l’occasion de nous replonger dans Azure Virtual Desktop et ses dernières nouveautés. Comme vous le savez peut-être, AVD repose sur une authentification d’Azure AD, potentiellement combinée avec un Active Directory classique. Cette méthode apporte une couche de sécurité dans l’accès au service grâce aux mesures de protections disponibles sur Azure AD.
Dans cet article, nous allons nous intéresser au Single Sign-on, ou Authentification Unique, dans Azure Virtual Desktop à travers une première méthode de gestion des identités Cloud : Azure AD. Enfin, nous finirons ce billet par un rapide troubleshooting concernant cette évolution, encore en préversion à l’heure où les lignes de cet article sont écrites.
L’authentification unique, souvent désignée par le sigle anglais SSO est une méthode permettant à un utilisateur d’accéder à plusieurs applications informatiques (ou sites web sécurisés) en ne procédant qu’à une seule authentification.
Afin de bien comprendre l’évolution du SSO dans Azure Virtual Desktop, l’authentification utilisateur s’effectue en deux étapes. Voici un rappel du processus depuis le client Windows Remote Desktop utilisé pour AVD, disponible ici :
Première authentification Azure AD (ou serveur AD FS si besoin) :
Seconde authentification pour l’ouverture de la session Windows :
La mémorisation du mot de passe de session Windows est bien disponible via la case à cocher ci-dessous, mais elle pose un souci de sécurité. Il ne s’agit pas ici de SSO mais d’un classique stockage de mot de passe en local. En effet, le mot de passe sera alors sauvegardé sur le Credential Manager de Windows :
Microsoft travaille depuis déjà pas mal de temps sur du SSO pour Azure Virtual Desktop. L’excellente vidéo ci-dessous faite il y a quelques mois par Dean Cefola de l’Azure Academy nous montre son processus de mise en place, mais uniquement si l’infrastructure dispose d’un Active Directory avec un serveur AD FS :
Comment faire du SSO sans serveur AD FS ?
C’est dans ce cas précis que la nouveauté de Microsoft intervient ! Une nouvelle option RDP vient de se faire son apparition sur Azure Virtual Desktop. Cette option apporte le SSO de manière 100% native. Petit rappel toujours utile, voici la liste des propriétés RDP acceptées par AVD.
Comme pour presque tous les articles de ce blog, nous allons détailler le processus de mise en place de cette nouvelle fonctionnalité d’AVD :
Etape 0 : Rappel des prérequis
Cette fonctionnalité d’AVD est encore en préversion. Nous allons donc partir d’un environnement Azure vierge et y installer un environnement AVD joint à Azure AD. Voici la courte liste des composants déjà présents sur mon environnement de test :
Tenant Azure
Souscription Azure valide
Etape I : Création du réseau virtuel
Dans un environnement vide, il faut donc commencer par la création d’un réseau virtuel :
Dans mon exemple de test, je ne modifie pas l’adressage réseau :
Attendez que la création se termine pour continuer :
Etape II : Déploiement d’Azure Virtual Desktop
Comme pour un déploiement classique d’Azure Virtual Desktop, notre travail commence par déployer un pool d’hôtes. Vous trouverez ce dernier dans la barre de recherche d’Azure :
La procédure de départ reste identique au processus habituel pour AVD. Cependant, il est important de cocher la Validation environnement à OUI :
Le choix de l’image Windows utilisée pour Azure Virtual Desktop a son importance ! Actuellement, la fonctionnalité de préversion du SSO repose sur une modification de l’OS Windows, et n’est pour l’instant déployée que sur la version 22H2 de Windows 11 :
La suite des options concernant les machines virtuelles AVD ne changent pas :
Type de domaine à joindre : Choisissez Azure Active Directory
Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, que ce soient des machines virtuelles dédiées ou partagées entre utilisateurs.
La création de l’espace de travail ne change pas :
Lancez la création et attendez plusieurs minutes :
Une fois le déploiement terminé, constatez la présence des ressources suivantes dans le groupe de ressources :
Etape III : Affectation des utilisateursAVD
Comme pour tout environnement Azure Virtual Desktop, il est nécessaire d’affecter des utilisateurs ou groupes pour que ces derniers soient autorisés à se connecter aux machines virtuelles. Cela se passe par le groupe d’application AVD :
Il est aussi possible de passer par l’attribution d’un rôle RBAC pour cette même opération :
Etape IV : Ajout des rôles RBAC
Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles AVD jointes à Azure AD, l’attribution d’un rôle RBAC spécifique est nécessaire. Affectez les deux rôles RBAC suivants sur le groupe de ressources :
Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD
Etape V : Implémentation de la fonctionnalité SSO
Retournez sur votre pool d’hôtes afin de profiter très facilement de cette nouvelle fonctionnalité :
La sauvegarde de cette option impacte les arguments RDP affichés dans l’onglet Avancé :
Un clic sur la session RDP vous affiche toujours la demande d’authentification de la session Windows :
Lancez un rafraîchissement pour mettre à jour les options RDP :
Retentez l’opération de connexion RDP pour voir cette nouvelle fenêtre apparaître :
Confirmez votre identité :
Acceptez la demande d’autorisation pour autoriser les connexion RDP :
La session Windows 11 devrait alors s’ouvrir :
Retentez l’opération une seconde fois pour vérifier le bon fonctionnement du SSO ????
Conclusion
On peut dire que Microsoft a fait le maximum pour simplifier les choses concernant le déploiement de cette nouvelle fonctionnalité AVD ! D’autres articles suivront pour tester les autres cas de gestions des identités via Active Directory.
Troubleshoot
Depuis l’apparition de cette nouvelle fonctionnalité, je me suis retrouvé embêté dans le déploiement d’environnements AVD joint à Azure AD et sous Windows 10/11 sans utiliser cette nouvelle option.
En effet, mes utilisateurs de test n’étaient plus en mesure de passer l’authentification de la session Windows :
La faute revient à l’impossibilité de remettre l’ancien argument RDP suivant dans ma configuration RDP, comme indiqué dans mon premier article sur le sujet.
targetisaadjoined:i:1
Voici le message d’erreur en question sur mon AVD depuis le portail Azure :
La solution
Pour contourner ce blocage, il est nécessaire de passer cet argument RDP targetisaadjoined:i:1 via une commande PowerShell :
La maintenance informatique est une fenêtre nécessaire dans laquelle un service est volontairement indisponible et annoncé en amont. Les architectures basées sur des services Azure n’échappent pas à cette règle car il est toujours nécessaire d’effectuer des maintenances régulières pour des sauvegardes, des mises à jour, des refontes, des réplications, …
Dans cet article, nous allons nous intéresser une nouvelle fonctionnalité disponible sous Azure Virtual Desktop. Encore en préversion à l’heure où ces lignes sont écrites, elle permet de gérer les périodes de mise à jour des agents AVD sur les machines virtuelles qui composent votre pool d’hôtes.
Qu’est qu’un agent AVD ?
Un environnement Azure Virtual Desktop est composée d’une ou plusieurs machines virtuelles. Pour que la communication entre le contrôleur de structure Azure et ces dernières soit assurée, un agent est présent sur chaque machine virtuelle. Un tour dans les programmes installés nous montre tout cela :
L’installation de ces agents est entièrement transparente si la création de la machine virtuelle est réalisée depuis le portail Azure. Si vous créez la machine virtuelle via un script PowerShell, vous devrez alors télécharger et installer manuellement les fichiers MSI.
Quand est-ce que l’agent AVD est mis à jour ?
Avant l’apparition de cette nouvelle fonctionnalité, l’agent AVD se mettait à jour à son rythme sans logique particulière. A ce ceci près qu’il existait une option ayant un impact sur le rythme de mise à jour : environnement de validation.
Qu’est-ce que l’environnement de validation ?
Nous (Microsoft) vous recommandons vivement de créer un pool d’hôtes de validation dans lequel les mises à jour de service seront appliquées en premier. Les pools d’hôtes de validation vous permettent de superviser les mises à jour de service avant que celui-ci ne les applique à votre environnement standard ou de non-validation. Sans pool d’hôtes de validation, vous risquez de ne pas détecter les modifications qui génèrent des erreurs, ce qui peut entraîner des temps d’arrêt pour les utilisateurs de votre environnement standard.
Autrement dit, la mise à jour est orientée en premier lieu vers les pools d’hôtes marqués comme environnement de validation. Une fois la mise à jour déployée avec succès en grand nombre sur des environnements de validation, elle est aussi installée sur les machines virtuelles d’environnements AVD de production.
De manière générale, un environnement de validation a tout son sens dans une solution de bureau à distance car il apporte une couche supplémentaire de tests via des utilisateurs spécifiques et évite ainsi un déploiement pouvant provoquer un blocage massif.
Mises à jour planifiées de l’agent
Toujours dans la volonté d’apporter une meilleure maîtrise de l’environnement Azure Virtual Desktop, Microsoft introduit la fonctionnalité de planification. Celle-ci ne concerne que la mise à jour de l’agent AVD présent sur les machines virtuelles du pool d’hôtes.
Comme vous allez le voir dans les écrans ci-dessous, cette option se configure au niveau du pool d’hôtes et impacte alors toutes les machines virtuelles rattachées de la même manière.
Via le portail Azure, rendez-vous sur votre pool d’hôtes et cliquez sur Mises à jour programmées des agents :
Cliquez sur la case ci-dessous pour activer la gestion manuelle des mises à jour :
Il vous est alors possible de définir une ou deux fenêtres de maintenance. Comme indiqué sur la page, 4 tentatives de mise à jour seront effectuées avant que celle-ci soit reportée la prochaine fois que les hôtes de session seront allumés.
Commencez par définir le fuseau horaire. Vous avez le choix entre celui employé par la machine virtuelle ou un parmi la liste déroulante :
Définissez le jour et l’heure de la première fenêtre de mise à jour :
Ajoutez au besoin une seconde fenêtre de mise à jour :
Enfin cliquez pour appliquer la configuration :
Et c’est tout ! ????
Conclusion
Azure Virtual Desktop continue son chemin et évolue en permanence ????. Pour rester sur ce sujet, retrouvez la vidéo très bien expliquée faite par Dean de l’Azure Academy. Dean y aborde également la possibilité de consulter l’historique des mises à jour installées via l’utilisation du Log Analytics Workspace d’Azure :
Azure Virtual Desktop utilise le protocole RDP (Remote Desktop Protocol) pour établir la connexion avec l’utilisateur. Pour rappel, ce protocole permet de se connecter à des ordinateurs de manière distante. Dans la plupart des cas, cette connexion utilise le protocole TCP pour y parvenir. Le serveur écoute par défaut sur le port TCP 3389.
Il est néanmoins possible de varier cette approche de connexion pour des questions de perfomences et de fiabilité. Depuis déjà l’année dernière, Microsoft proposait la fonctionnalité RDP Shortpath pour améliorer cette connexion, débit et latence, entre l’utilisateur et la machine virtuelle AVD :
RDP Shortpath est une fonctionnalité d’Azure Virtual Desktop qui établit un transport direct basé sur UDP entre le client Remote Desktop et l’hôte de session. RDP utilise ce transport pour fournir le Bureau à distance et le RemoteApp tout en offrant une meilleure fiabilité et une latence constante.
Microsoft Doc
Dans cet article, nous allons regarder en détail cette évolution et effectuer un test sur un environnement AVD. Avant de commencer à manipuler Azure, cette vidéo vous explique très bien l’idée :
Voici également un schéma montrant la « simplicité évidente » à utiliser cette fonctionnalité réseau :
L’article de Microsoft expliquait déjà alors la configuration à effectuer sur les machines virtuelles dans le cadre d’un réseau non public.
L’excellent billet de Denis Gundarev nous explique avec simplicité l’inadéquation entre le protocole TCP pour un besoin RDP :
TCP est un excellent protocole pour la livraison garantie de petites quantités de données. Les applications telles que les navigateurs ou les clients de messagerie se contentent d’envoyer les données et de les oublier. Le protocole assure la cohérence et l’ordre des paquets et relance la transmission si la livraison échoue. Cependant, RDP utilise des connexions de longue durée et les connexions TCP de longue durée sont problématiques.
Le protocole TCP est idéal pour les réseaux locaux, mais pas pour l’Internet. Oui, si le paquet est perdu, il sera retransmis. La disponibilité de la bande passante est un facteur essentiel. Malheureusement, les algorithmes de contrôle de congestion TCP limitent la possibilité de saturer le réseau.
RDH Shortpath s’applique donc sur les réseau publics
Comme son grand frère, cette fonctionnalité établit un flux UDP direct pour RDP. Toutefois, elle ne nécessite pas l’ouverture de ports entrants sur le pare-feu. Au lieu de cela, elle sélectionne automatiquement les conditions du réseau. Elle utilise une combinaison de protocoles de traversée NAT tels que STUN et UPnP et le processus d’établissement de la connectivité interactive (ICE). RDP établit alors le flux UDP direct dans la plupart des configurations de réseau.
Par conséquent, vos utilisateurs bénéficieront d’une latence plus faible, d’une meilleure utilisation du réseau et d’une grande tolérance à la perte de paquets ou aux changements de configuration du réseau.
Et la sécurité ?
RDP Shortpath pour les réseaux publics étend les capacités de multi-transport de RDP. Il ne remplace pas le transport de connexion inverse mais le complète. Le courtage de la session initiale est toujours géré par l’infrastructure Azure Virtual Desktop.
Comment constater le bénéfice ?
Denis nous a même préparé une vidéo pour montrer le bénéfice possible dans la gestion des paquets perdus entre les différents protocoles possibles :
Mise en oeuvre de la solution
Dans un environnement Azure Virtual Desktop, chaque connexion RDP commence par l’établissement du transport de connexion inverse sur la passerelle Azure Virtual Desktop. Après l’authentification de l’utilisateur, le client et l’hôte de session établissent le transport RDP initial, et le client et l’hôte de session commencent à échanger leurs capacités.
Important : comme le rappel la documentation Microsoft, RDP Shortpath configurés sur des réseaux managés est actuellement incompatible avec la prévision de RDP Shortpath pour les réseaux publics.
Comme à chaque article d’Azure Virtual Desktop, vous pouvez suivre les différentes étapes pour mettre en route cette fonctionnalité, toujours en preview à l’heure où ces lignes sont écrites.
Etape 0 : Rappel des prérequis
Des prérequis sont nécessaires pour réaliser cette démonstration AVD :
Un tenant Microsoft
Une souscription Azure valide
Un réseau virtuel existant sur Azure
Un domaine Active Directory synchronisé avec Azure AD via l’agent Azure AD Connect
Une ou des machines virtuelles AVD déployées sur ce même réseau virtuel
Mon environnement Azure Virtual Desktop est donc déjà en place :
Etape I : Test avant modification du RDP Shortpath
Avant d’effectuer les modifications, connectez-vous à votre environnement AVD avec un utilisateur pour constater la connexion RDP via le protocole TCP :
Saisissez vos identifiants pour ouvrir votre session RDP :
Contrôlez la méthode de connexion TCP, mise en place par défaut :
Afin de mettre en place la configuration nécessaire sur les machines virtuelles AVD, il est possible d’y parvenir de plusieurs manières. En voici deux :
Etape IIa : Modifiez la configuration de registre d’une machine virtuelle AVDmanuellement
Fermez la session utilisateur et retournez sur une machine virtuelle via votre portail Azure. Exécutez la commande suivante comme ceci
Attendez quelques minutes et constatez le succès de celle-ci sur le portail Azure
Etape IIb : Modifiez la configuration de registre d’une machine virtuelle AVD via GPO
Au lieu de faire cette modification manuelle sur toutes vos machines virtuelles, vous pouvez également créer une GPO dans votre domaine AD et l’appliquer aux machines AVD.
Connectez à une machine de votre domaine AD pour y créer votre nouvelle GPO
Commencez la création de cette nouvelle GPO sur l’OU correspondante à vos machines AVD
Nommez votre GPO à votre convenance
Editez-là avec un clic droit
Créez y un nouvel objet de registre comme ceci
Descendez dans l’arborescence suivante et sélectionnez là :
Ajoutez-lui les propriétés suivantes et cliquez sur OK
Redémarrez les machines virtuelles AVD pour une bonne prise en compte de cette nouvelle GPO
Etape III : Test après modification du RDP Shortpath
Comme au premier essai, reconnectez-vous à votre environnement AVD avec un utilisateur de test, puis constatez le changement de protocole UDP :
Evidemment, Microsoft prévoit aussi des ajouts de règles firewall pour les machines virtuelles AVD et pour les machines clients. Ces opérations sont nécessaires si le protocole UDP est à l’origine bloqué.
Conclusion
Cette nouvelle fonctionnalité est donc une façon facile d’améliorer l’expérience de vos utilisateurs sans mettre en défaut la sécurité à travers des réseaux publics.
Pour finir et vous aider dans cette démarche, Dean nous a même préparé un seconde vidéo sur la chaine YouTube et dédiée à cette évolution du RDP Shortpath, encore en préversion !
Cela est toujours bienvenu pour l’optimisation des coûts.
Encore en préversion, vous pouvez déjà tester cette fonctionnalité depuis plusieurs jours en suivant la documentation Microsoft. Dans cet article, je vais mettre en place cette fonctionnalité étape par étape. Nous allons voir ensemble son impact sur un environnement AVD.
La fonction de mise à l’échelle automatique (ou plan d’autoscaling) vous permet de mettre en route des machines virtuelles (VM) Azure Virtual Desktop, en modulant à la hausse ou à la baisse leur nombre.
Cela permet d’optimiser les coûts de déploiement en fonction de vos besoins. Vous pouvez établir un plan d’autoscaling basé sur :
Créneaux horaires
Jours de la semaine
Plafond du nombre de sessions utilisateurs
Etape 0 : Rappel des prérequis
Cette fonctionnalité AVD nécessite de disposer d’un environnement Azure Virtual Desktop déjà en place. Voici donc la liste des composants déjà présents sur mon tenant Azure :
Domaine Active Directory Domain Services (AD DS)
Pool d’hôtes Azure Virtual Desktop
Espace de travail AVD
Groupe d’applications AVD
5 machines virtuelles D4s_v4, déjà jointes à AVD
Point important : Il est nécessaire de définir un nombre maximal de sessions utilisateurs par VM dans la configuration de votre pool d’hôtes :
Etape I : Création d’un nouveau rôle RBAC
Comme l’indique la documentation Microsoft, il est nécessaire de créer un nouveau rôle RBAC pour assurer la gestion automatique des VMs.
Besoin d’en savoir un peu plus sur les rôles Azure ? Voici une vidéo en français qui devrait vous aider :
Vous pouvez suivre la création du rôle personnalisé via cette aide Microsoft, ou en répétant les étapes suivantes :Copiez le code JSON suivant et enregistrez le dans un fichier (ex. AVD-custom-role.json) sur votre PC :
Selectionnez le type Souscription puis choisissez celle voulue, puis cliquez sur Suivant :
Contrôlez cet onglet et cliquez sur Suivant :
Lancez la création de votre rôle personnalisé :
Etape II : Création d’un nouveau rôle RBAC
Une fois le nouveau rôle créé, il ne nous reste qu’à assigner le service Azure Virtual Desktop à celui-ci. Cela s’effectue directement sur le périmètre, qu’on souhaite lui assigner.
Cherchez donc ici la Souscription Azure de votre AVD puis cliquez ici :
Utilisez la barre de recherche pour retrouver plus facilement votre rôle personnalisé :
Cliquez ici pour ajouter le service Azure Virtual Desktop :
Utilisez encore une fois la barre de recherche pour retrouver le service AVD sous son ancien nom et Sélectionnez-le :
Cliquez sur Suivant :
Lancez l’Assignation du rôle :
Vérifiez la présence de l’assignation d’AVD sur la souscription, puis cliquez sur le rôle :
Vous retrouvez ici toutes les permissions nécessaire à la fonctionnalité d’Autoscale :
La création d’un plan d’autoscaling AVD apporte les avantages / restrictions suivants :
Le plan d’autoscaling est utilisable pour un ou plusieurs environnement Azure Virtual Desktop, à la condition que ces derniers nécessitent une gestion horaire identique
Ne pas associer le plan d’autoscaling avec d’autres solutions tierces de gestion des ressources Azure
Il n’est pas possible d’associer plusieurs plans d’autoscaling sur un seul environnement AVD
Le plan d’autoscaling est dépendant d’un seul fuseau horaire
Le plan d’autoscaling est configurable sur plusieurs périodes distinctes
Le plan d’autoscaling est opérationnel dès sa configuration terminée
Le plan d’autoscaling ne tient pas compte du « Drain mode » activé sur les VMs si aucun TAG n’est pas renseigné
Le plan d’autoscaling n’est pas en interaction avec la méthode de répartition des utilisateurs configuré sur votre pool d’hôtes
Remplissez le premier onglet avec vos informations de base puis cliquez sur Suivant :
L’onglet suivant vous permet de définir quand le plan d’autoscaling s’active pour suivre les besoins de montée / descente en puissance tout au long de la journée.
Dans chaque phase de la planification, autoscale n’éteint les machines virtuelles que lorsqu’un hôte de session n’a plus de sessions actives.
Les valeurs par défaut qui s’affichent lorsque vous créez une planification sont les valeurs suggérées pour les jours de la semaine, mais vous pouvez les modifier selon vos besoins.
Cliquez comme ceci pour ajouter votre première période :
Choisissez un Nom, sélectionnez les Jours adéquats puis cliquez sur Suivant :
L’onglet de charge reprend le fuseau horaire du premier onglet et vous demande de renseigner les champs et de cliquer sur Suivant :
Heure de début : Sélectionnez une heure dans le menu déroulant pour commencer à préparer les VM pour les heures de charge
Algorithme d’équilibrage de charge : Microsoft recommande de choisir l’algorithme Breadth-first. Cela répartira les utilisateurs sur les VM existantes afin de maintenir des temps d’accès rapides
Pourcentage minimum de VM hôtes : Entrez ici le pourcentage d’hôtes de session que vous souhaitez conserver au minimum pendant les heures de montée et de pointe. Par exemple, si vous choisissez 10 % et que votre pool d’hôtes compte 10 hôtes de session, plan d’autoscaling gardera une hôte de session disponible pour les prochaines connexions utilisateur
Seuil de capacité : Saisissez ici le pourcentage d’utilisation du pool d’hôtes qui déclenchera le début des phases de charge et de pic. Par exemple, si vous choisissez 60 % pour un pool d’hôtes pouvant gérer 10 sessions à l’instant T, le plan d’autoscaling n’activera des hôtes supplémentaires que lorsque le pool d’hôtes dépassera 6 sessions
L’onglet de pic de charge reprend aussi le fuseau horaire du premier onglet et vous demande de renseigner les champs puis de cliquer sur Suivant :
Heure de début : Entrez une heure correspondante au moment où votre taux d’utilisation est le plus élevé pendant la journée. Cette heure sera également l’heure de fin de votre phase de charge
Equilibrage de charge : Sélectionnez Breadth-first ou Depth-first. Le premier distribue les nouvelles sessions utilisateur sur toutes les sessions disponibles dans le pool d’hôtes. Le second distribue les nouvelles sessions à l’ôte de session disponible ayant le plus grand nombre de connexions et n’ayant pas encore atteint sa limite de session.
Seuil de capacité : Valeur non modifiable
L’onglet de décharge vous demande de renseigner les mêmes champs que pour ceux des périodes de charge et de pic :
Heure de début
Equilibrage de charge
Pourcentage minimum d’hôtes (%)
Seuil de capacité (%)
Forcer la déconnexion des utilisateurs
Pour finir, l’onglet heures creuses vous demande de renseigner les mêmes champs suivants :
Heure de début
Equilibrage de charge
Seuil de capacité
Cliquez sur Ajouter une fois ce premier planning terminé :
Il est possible d’ajouter une second planning si besoin, mais uniquement sur les autres jours restants :
Sélectionnez-le ou les pools d’hôtes concernés et cliquez sur Suivant :
Renseignez les TAGs et lancez la Création :
Consultez la ressource Azure créée et dédiée au plan d’autoscaling d’Azure Virtual Desktop :
Etape IV : Test de la solution
Avant que mon script soit validé et en place, j’ai pris le soin d’éteindre l’ensemble des VMs (5) de mon pool d’hôtes AVD. Voici donc mon environnement de test :
Limite d’utilisateurs AVD par VM : 2 utilisateurs
Nombre de VMs AVD : 5 VMs
Nombre total de sessions AVD disponibles : 20 sessions, soit 4 par VM
Période A : Hors période du plan d’autoscaling
Période B : Charge : Algorithme : Breadth-first / Min : 25 % / Max : 60 %
Période C : Pic : Algorithme : Depth-first / Max : 60 %
Période D : Décharge : Algorithme : Depth-first / Min : 10 % / Max : 90 %
Période E : Creux : Algorithme : Depth-first / Max : 90 %
Période A – Hors période :
Seule une machine virtuelle s’allume après la validation du script car celui-ci est directement opérationnel :
Période B – Période de charge :
Nous entrons dans la période de charge de mon environnement Azure Virtual Desktop. Ayant paramétré le Pourcentage minimum de VM hôtes à 25% et disposant de 5 VMs AVD , une seconde VM s’allume automatiquement allumée à l’entrée dans cette phase :
25% x 5 (max nbr VMs) = 1 VM
Sans attendre la période de pic, je décide alors de connecter un premier utilisateur AVD, sachant que mon Seuil de capacité est de 60% et que le nombre d’utilisateurs AVD par VM est de 4.
De façon assez logique, aucune machine nouvelle virtuelle ne s’allume. Cela fait sens car deux VMs sont déjà opérationnelles. Je décide donc de connecter un second utilisateur. Même constat au niveau de VMs, toujours à cause de la règle des 60 % :
Je connecte donc un 3ème utilisateur AVD et ne constate toujours aucun allumage d’une nouvelle machine virtuelle. En effet la règle des 60 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :
60% x 4 (max nbr users) x 2 (VMs allumées) = 4.8 sessions utilisateurs
Je décide donc de continuer mon test et de rajouter un quatrième utilisateur. Toujours le même constat :
On finit avec la connexion du 5ème utilisateur. Cette fois-ci, cet ajout provoquera bien le démarrage d’une nouvelle et 3ème machine virtuelle AVD :
Curieusement, la connexion du 6ème utilisateur se ne retrouve pas sur cette nouvelle machine virtuelle sans utilisateur, mais bien sur la seconde, en contradiction avec l’algorithme de la période de charge :
Afin de tester toutes les caractéristiques de la période de charge, je décide de déconnecter l’ensemble des utilisateurs AVD. Aucune VM ne s’éteindra malgré 0 utilisateur connecté sur AVD :
Période C – Période de pic :
Nous quittons la période de charge pour entrer dans la période de pic d’AVD. Le but ici est de constater le changement d’algorithme Depth-first agissant sur la répartition des utilisateurs.
Aucune session utilisateur AVD n’est ouverte, 2 VMs restent allumées, même sans utilisateur :
Je connecte alors 4 utilisateurs AVD et je ne constate aucun démarrage de machines virtuelles AVD. L’assignation des utilisateurs se fait bien en Depth-first :
On continue avec la connexion du 5ème utilisateur. Cette fois-ci, cet ajout provoquera bien le démarrage d’une nouvelle et 3ème machine virtuelle AVD :
En effet la règle des 60 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :
60% x 4 (max nbr users) x 2 (VM allumée) = 4.8 sessions utilisateurs
Je décide de finir en connectant un 6ème utilisateur. L’algorithme Depth-first continue de bien s’appliquer bien comme précédement :
Au final, la période de pic se distingue de la période de charge par la présence systématique d’une machine virtuelle « d’avance », vide d’utilisateurs pour encaisser leur arrivée massive.
D’ailleurs, la déconnexion de l’ensemble des utilisateurs AVD nous ramène à deux machines virtuelles allumées :
Période D : Période de décharge :
Nous continuons l’analyse du plan d’autoscaling avec la période de décharge de mon environnement AVD. Aucune session AVD n’est active à ce moment précis. Comme la période de charge, seule une seule VM reste allumée :
Comme à chaque période, je connecte alors 3 utilisateurs AVD et je ne constate aucun démarrage de machines virtuelles AVD. L’assignation des utilisateurs se fait toujours en Depth-first :
Quand je connecte le 4ème utilisateur, je constate bien le démarrage d’une seconde machine virtuelle :
En effet la règle des 90 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :
90% x 4 (max nbr users) x 1 (VM allumée) = 3.6 sessions utilisateurs
Dès que je connecte les utilisateurs 5, 6 et 7, aucune nouvelle machine virtuelle ne s’allume :
Dès que j’arrive à l’utilisateur 8, les choses changent :
Cela s’explique encore par la règle des 90% ci-dessous :
90% x 4 (max nbr users) x 2 (VMs allumées) = 7.2 sessions utilisateurs
A noter que l’inactivité des utilisateurs AVD provoque le message d’alerte suivant :
D’ailleurs, la déconnexion de l’ensemble des utilisateurs AVD nous ramène à une machine virtuelle allumée :
Période E : Période de creux :
Nous sommes maintenant dans la dernière période, appelée aussi période creuse. Le but de celle-ci est de fonctionner en économie maximale. Notre point de départ est donc une seule session AVD d’ouverte et donc une seule machine virtuelle reste active :
On recommence donc par connecter 3 utilisateurs Azure Virtual Desktop. Aucune autre machine virtuelle ne s’allume :
90% x 4 (max nbr users) x 1 (VM allumée) = 3.6 sessions utilisateurs
De ce fait, la connexion du 4ème utilisateur ajoute une seconde machine virtuelle :
On continue par connecter les utilisateurs 5, 6 et 7. Aucun changement au niveau du nombre de VMs :
En effet et comme pour le cas du 4ème utilisateur, la règle des 90% qui s’applique ici n’est réalisée que si le nombre d’utilisateurs connectés dépasse l’entier supérieur :
90% x 4 (max nbr users) x 2 (VMs allumées) = 7.2 sessions utilisateurs
La connexion du 8ème utilisateur vérifie et valide cette théorie :
Pour finir la déconnexion de tous les utilisateurs entraîne l’arrêt des machines virtuelles AVD allumées, sauf une :
Fonctionnalités et annexes
Modification
Le plan d’autoscaling est pleinement modifiable après sa création en cliquant ici :
Désactivation
Si votre pool d’hôtes a besoin de repasser en fonctionnement manuel, rien de plus simple par la désactivation temporaire du plan d’autoscaling :
Sauvegarde des logs
Comme un grand nombre de ressources Azure, vous pouvez sauvegarder les logs pour une analyse plus fine :
Dans mon cas, je fais le choix d’utiliser Log Analytics Workspace :
Erreur rencontrées
Au fil de mes différents tests, j’ai reçu une ou deux fois des messages d’erreur lors de la connexion d’un nouvel utilisateur sur une machine virtuelle fraîchement démarrée.
Un nouvel essai de connexion a résolu le souci à chaque fois.
Conclusion
Disons-le tout de suite, cette fonctionnalité était déjà disponible depuis plusieurs mois via une la solution script proposée par Microsoft et basée sur Azure Logic Apps.
La nouvelle solution choisie par Microsoft d’intégrer une fonctionnalité d’autoscaling dans Azure Virtual Desktop est riche de sens et est plus que bienvenue. Pour ma part je trouve qu’elle remplace la fonctionnalité Démarrage des VMs à la demande, déjà existante mais qui ne permettait pas de tenir des plannings de charges et de décharges.
Malgré tout, le plan d’autoscaling manque encore de clarté sur son fonctionnement dans le besoin de démarrage de machines virtuelles. Je me suis en effet retrouvé à plusieurs reprises avec plusieurs VMs allumées malgré qu’elles soient vides d’utilisateurs.
Pour finir, un aperçu graphique du mode et des indices de charges actuels aurait été apprécié.
La fonctionnalité d’optimisation des performances multimédia sur Azure Virtual Desktop avait été annoncée il y a déjà quelques temps. Elle est maintenant accessible pour une phase de test publique. Pour en savoir plus, voici un lien vers la documentation officielle de Microsoft.
Dans cet article, nous allons installer et tester la fonctionnalité, étape par étape, afin de mesurer l’impact sur les performances sur un environnement Azure Virtual Desktop :
Contrôle de la version de Windows Desktop Client
Création d’un nouvel environnement AVD
Assignation des utilisateurs aux machines virtuelles d’AVD
Modification des paramètres RDP
Ajout des droits RBAC sur le groupe de ressources AVD
Création d’Azure Bastion
Installation de Google Chrome
Installation de Multimedia Redirector Service
Installation des extensions sur les navigateurs Internet
Test de la solution avec et sans optimisation
Etape I : Contrôle de la version de Windows Desktop Client
Une version minimale est nécessaire pour profiter de la redirection multimédia sur votre poste local : 1.2.2222. Vous pouvez retrouver la page de téléchargement ici. Voici également le lien vers le patchlog de l’outil Windows Remote Desktop.
Comme indiqué dans la documentation Microsoft, la machine locale doit disposer de performances minimales pour effectuer la redirection multimédia dans de bonnes conditions. Microsoft met donc à disposition une liste de recommandations matérielles pour Teams.
Il est également nécessaire d’intégrer la machine locale au programme Insider. Cette action s’effectue directement depuis le Registre Windows :
Une fois la modification du registre terminée, relancez Windows Remote Desktop pour constater qu’une nouvelle mise à jour est maintenant disponible :
Notre client Windows Remote Desktop est maintenant à jour. Retournez sur le portail Azure pour créer un nouvel environnement Azure Virtual Desktop. Passez ces étapes si vous disposez déjà d’un AVD fonctionnel sur une souscription Azure.
Etape II : Création d’un nouvel environnement AVD
Afin de faire un test de la solution sur un nouvel environnement, je vous remets ici tous les écrans de création d’AVD. Veuillez noter que nouvelles options sont apparues, nous prendrons le temps d’en parler lors de ce déploiement. Suivez si besoin ce guide étape par étape :
La création complète de l’environnement Azure Virtual Desktop commence en cliquant ici :
Le premier onglet d’options ci-dessous défini les options de mon environnement (Pool d’hôtes) :
Le second onglet est dédié aux machine virtuelles. Notez qu’il est nécessaire de créer au préalable un réseau virtuel dans la même région Azure que votre AVD. Le processus de création ne propose pas d’en créer un :
Le troisième onglet est consacré à l’espace de travail des utilisateurs :
Un nouvel onglet fait son apparition pour permettre le paramétrage des options de logs et de métriques. J’en ai donc profité pour créer un espace Log Analytics Workspace, avant le déploiement de ma solution AVD :
Une fois la configuration AVD terminée, comptez environ une bonne quinzaine de minutes pour que le déploiement se fasse :
Etape III : Assignation des utilisateurs aux machines virtuelles d’AVD
Dans le cadre de mon test, j’ai souhaité assigner manuellement les deux machines virtuelles à différents utilisateurs. Je dois donc faire les deux opérations moi-même.
Avant d’assigner les utilisateurs sur les machines virtuelles AVD, il est nécessaire de rajouter ces derniers sur le groupe d’applications AVD, créé automatiquement lors de l’étape précédente :
L’assignement des utilisateurs AVD sur les machines virtuelles peut se faire sans souci juste après :
Comme mon exemple est basé sur une intégration des machines virtuelles avec Azure AD, je suis dans l’obligation d’effectuer des étapes supplémentaires pour rendre pour AVD fonctionnel. Les étapes 4 et 5 sont donc dédiées au scénario AVD sans serveur Active Directory.
Etape IV : Modification des paramètres RDP
Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se font directement sur le pool d’hôtes d’AVD :
targetisaadjoined:i:1
Vous retrouverez ici la liste de toutes les options RDP possibles, dont seulement certaines sont compatibles avec Azure Virtual Desktop. Voici les arguments utilisés sur la copie d’écran ci-dessus :
Etape V : Ajouts des droits RBAC sur le groupe de ressources AVD
Afin d’autoriser les utilisateurs d’Azure AD à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se font assigner directement le groupe de ressources AVD :
Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD
L’étape suivante avec Azure Bastion permet d’administrer plus facilement les machines virtuelles d’Azure Virtual Desktop. Vous pouvez déployer ce service et en profiter pour toutes les machines virtuelles présentes dans le même réseau virtuel que ce dernier. Cela marche aussi pour les VMs sur des réseau virtuels appairés.
Etape VI : Création d’Azure Bastion
Azure Bastion est un service que vous déployez et qui vous permet de vous connecter à une machine virtuelle à l’aide de votre navigateur et du portail Azure. Cette étape est facultative dans notre démonstration, mais Azure Bastion nous facilite les opérations d’installation sur les machines virtuelles d’AVD.
La création d’Azure Bastion est très facile et se fait en seulement quelques minutes sur notre environnement de test :
Azure Bastion est maintenant installé. Dans le cadre de notre test, nous allons effectuer l’opération d’optimisation sur une seule des 2 machines virtuelles AVD. Le but étant de comparer le bénéfice de la solution, avec et sans la redirection multimédia. L’étape suivante est dédiée à l’installation de Google Chrome et se fera sur les 2 VMs.
Etape VII : Installation de Google Chrome
Connectez-vous via Azure Bastion sur la première machine virtuelle :
Voici ici le lien officiel pour installer Google Chrome.
Il faudra aussi installer Google Chrome sur la seconde machine virtuelle pour nos tests. Vous pouvez garder ouvert l’onglet d’Azure Bastion de la première machine virtuelle quand vous vous connectez à la seconde.
Etape VIII : Installation de Multimedia Redirector Service
Vous l’avez compris, l’installation du Multimedia Redirector service ne doit se faire que sur la première machine virtuelle. Vous pouvez le télécharger ici.
Etape IX : Installation des extensions sur les navigateurs internet
Si le navigateur Google Chrome est encore ouvert sur votre première machine virtuelle, vous devriez voir le message d’alerte suivant :
L’ouverture de Microsoft Edge après l’installation de Multimedia Redirector Service doit également remonter l’alerte suivante :
Etape X : Test de la solution avec et sans optimisation
A date, la fonctionnalité de redirection multimédia sur AVD n’est pas disponible via accès Web, mais uniquement via Windows Remote Desktop. Nous voilà donc prêts à tester notre solution :
Une fois connecté dans votre session AVD avec le compte de votre premier utilisateur de test, vérifiez l’état des extensions dans les 2 navigateurs Internet :
La version publique de la redirection multimédia pour Azure Virtual Desktop a limité la lecture sur YouTube. Pour tester YouTube dans le cadre du déploiement de votre organisation, vous devrez activer une extension.
Microsoft
Un tour sur YouTube permet de se rendre compte de l’impact des performances sur la machine virtuelle. Voici un lien vers une vidéo en 4K. Prenez le navigateur Internet de votre choix pour les tests :
Un petit tour dans les performances des 2 machines virtuelles pendant la lecture de cette vidéo à haute résolution montre l’impact sur les performances avec ou sans la redirection multimédia :
Sans redirection multimédia :
Avec redirection multimédia :
Conclusion
Avant tout, l’objectif premier de la redirection multimédia n’est pas de permettre à tous les utilisateurs d’Azure Virtual Desktop de lancer des vidéos 4K YouTube en simultané. Le but ici est bien d’alléger les sollicitations en performance des machines virtuelles AVD. Imaginez l’impact sur un environnement Azure Virtual Desktop, partagé par une douzaine d’utilisateurs utilisant Microsoft Teams.
La redirection multimédia vous permet d’obtenir une lecture vidéo fluide lorsque vous regardez des vidéos dans votre navigateur Azure Virtual Desktop. La redirection multimédia déplace l’élément multimédia du navigateur vers la machine locale pour un traitement et un rendu plus rapides.
Microsoft
Comme toujours, faites part de vos remarques sur la redirection multimédia d’Azure Virtual Desktop dans les commentaires ????
La mise en place d’Azure Windows Virtual Desktop s’accompagne de bonnes pratiques, dont plusieurs sont dédiées à Microsoft Teams. Dans cet article nous allons détailler l’installation de Microsoft Teams sur Azure Virtual Desktop, ainsi que la mise en pratique de quelques options pouvant améliorer l’expérience des utilisateurs.
Installation de Microsoft Teams
Une des premières bonnes pratiques concernant Azure Virtual Desktop est de travailler avec des images de l’OS. L’image de votre OS va vous permettre de maîtriser vos déploiements en les sécurisant et en les automatisant.
Il est donc conseillé d’installer Microsoft Teams sur votre image, avant de commencer le déploiement des ressources dédiées à AVD. Sachez que l’installation de Teams n’est pas comprise dans les images Windows 10 multisessions avec les applications Office 365, mises à disposition par Microsoft. Cette installation est donc systématiquement à part. Un lien vers la documentation Microsoft dédiée à ce sujet est toujours utile pour vous aider dans cette mise en place.
Etape 0 : PrérequistechniquesTeams
Comme indiqué par Microsoft, il est nécessaire d’installer sur Teams sur une machine virtuelle ayant à minima les performances suivantes :
Paramètre
Système d’exploitation de station de travail
vCPU
2 cœurs
Mémoire RAM
4 Go
Stockage
8 Go
Note : A contrario, il est également dit par Microsoft qu’Azure Virtual Desktop recommande des machines virtuelles à 4 coeurs.
Etape I : Activation de l’optimisation Teams pour AVD
Cette étape est essentielle dans l’installation de Teams dans un environnement Windows 10 multisessions. Les machines virtuelles d’AVD n’ont souvent peu de puissance graphique, ce qui signifie que l’exécution d’un chat vidéo entraînera une consommation élevée de CPU et conduira à des problèmes de performance.
Même en passant à un chat vocal, la qualité de l’appel peut encore être mauvaise et la consommation de CPU trop élevée. Les organisations déploient souvent AVD dans une capacité multi-utilisateurs. Cela signifie que plusieurs utilisateurs accèdent à une même machine virtuelle et qu’ils partagent donc un processeur. Les administrateurs informatiques peuvent aider à résoudre les problèmes liés à l’épuisement du processeur grâce à la redirection audiovisuelle (AV).
La redirection audiovisuelle utilise la puissance des appareils des utilisateurs finaux pour charger les chats vidéo et vocaux. Cela signifie que les utilisateurs s’appuieront sur le CPU et le GPU de leur appareil pour charger le chat et que la machine AVD n’aura plus une consommation CPU élevée. De plus, l’interface utilisateur sera considérablement améliorée car la qualité de l’audio-visuel sera presque la même que celle des équipes locales. Pour activer l’optimisation des médias pour Teams, ajouter la clé de registre suivante sur l’image AVD :
Vous pouvez déployer l’application de bureau Teams pour AVD en utilisant une installation par machine. Pour installer Microsoft Teams, le script ci-dessous va vous aider en installant les 3 composants suivants :
L’installation de Teams se termine et aucun redémarrage n’est nécessaire après l’exécution de ce script. Vous devriez pouvoir vous connecter directement à Teams et cliquer sur votre image pour vérifier sa bonne installation AVD.
Etape III : Optimisations possibles sur Teams
Certaines optimisations post-installation sur Teams peuvent intéressantes selon les souhaits de configuration ou si un manque de performances est constaté par vos utilisateurs.
Désactivation de l’accélération matérielle
Dans certains cas, il a été constaté que la désactivation de l’accélération matérielle augmentait les performances vidéo de Teams. Cette fonctionnalité est désactivable directement depuis les paramétrage de l’outil client, via une clé de registre ou encore via un règle GPO :
Seconde méthode, la clef de registre ci-dessous va désactiver la fonction quand sa valeur est égale à 1 :
Dernière méthode, la création de GPO pour FSLogix nécessite la récupération des fichiers ADMX et ADML. Vous pouvez effectuer cette étape d’installation via ce lien.
Désactivation du « receive segment coalescing » RSC sur la partie réseau
Dans d’autres cas, il a été constaté que la désactivation de l’option de recombinaison des paquets réseaux rétablissait les performances vidéo de Teams. Cette fonctionnalité est désactivable directement via une ligne de commande PowerShell :
Get-NetAdapterRSC
# Chercher le nom de l'adaptateur réseau primaire utilisé par AVD
Disable-NetAdapterRSC -Name "Nom de l'adaptateur réseau"
Redirection du cache Teams hors du profil utilisateur FSLogix
Note : Cette fonctionnalité n’est possible que si vous avez installé FSLogix au préalable sur votre image. Suivez l’étape ci-dessous si ce n’est pas encore le cas dans votre environnement. Si FSLogix est déjà en place et fonctionnel, passez à la suite.
Le script PowerShell ci-dessous installe et configure FSLogix. Vous pouvez retrouver toutes les options de la solution FSLogix ici. La variable $connectionString doit reprendre le nom du compte de stockage et le nom du file share. Voici un exemple dans un environnement où ebgkhbywivnfzjy est le nom de mon compte de stockage et profiles le nom de mon file share :
L’accès au file share aux les utilisateurs AVD va nécessiter l’application de droits RBAC et NTFS. L’opération dépend d’un certain nombre de facteurs, je vous conseille la documentation suivante pour un domaine Azure AD DS, et cette seconde documentation pour un domaine AD DS.
Une fois que Teams a été installé conformément aux directives d’installation et que l’utilisateur a démarré Teams pour la première fois, la taille du conteneur de profil augmente considérablement en quelques minutes.
Quelques minutes après l’ouverture de Teams montre que le profil grandit beaucoup !
Il est alors possible d’appliquer une optimisation sur Teams pour exclure la prise en charge du cache Teams. La mise en place de cette fonction va nécessiter plusieurs actions :
Ajout d’un fichier de configuration XML sur le compte de stockage utilisé pour FSLogix
Ajout d’une règle de registre dans la configuration FSLogix sur les machines virtuelles AVD
Le script ci-dessous est assez complet et nécessite de remplir un certain nombre de variables :
Identifiant de la souscription
Nom du groupe de ressources du compte de stockage FSLogix
Nom du compte de stockage FSLogix
Nom du file share FSLogix
Clef primaire ou secondaire du compte de stockage
# Step 1
# Variable to Modify
$SubscriptionId = ""
$ResourceGroupName = ""
# The Ressource Group of your storage Account
$StorageAccountName = ""
$AzufileShareName = ""
$StorageAccountKey = ""
# Step 2
# Module and Connection
Install-Module AZ
Import-Module AZ
Install-Module azuread
Import-Module azuread
# Connection Needed for Azure
Connect-AzAccount
Select-AzSubscription -SubscriptionId $SubscriptionId
# Connection Needed for Azure AD
Connect-AzureAD
# Step 3
# Variable to not modify"
$xmllocation= "\\$StorageAccountName.file.core.windows.net\$AzurefileShareName\$Directory"
# Step 4
# Run the code below to test the connection and mount the share
$connectTestResult = Test-NetConnection -ComputerName "$StorageAccountName.file.core.windows.net" -Port 445
if ($connectTestResult.TcpTestSucceeded)
{
net use T: "\\$StorageAccountName.file.core.windows.net\$AzufileShareName" /user:Azure\$StorageAccountName $StorageAccountKey
}
else
{
Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}
# Step 4 Directory Creation for Teams Exclusion
# Variable to not modify
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$DirectoryID= "T:\Teams"
$Directory= "Teams-Exclusion"
New-Item -Path $DirectoryID -ItemType Directory
# Step 5 Download the Xmlredirection
# Variable to not modify"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
$xmllocation= "\\$StorageAccountName.file.core.windows.net\$AzurefileShareName\$Directory"
$xmlurl= "https://raw.githubusercontent.com/Aldebarancloud/WVDCourse/main/redirections.xml"
$connectionString= "\\$StorageAccountName.file.core.windows.net\$AzurefileShareName\$Directory"
Invoke-WebRequest -Uri $xmlurl -OutFile $xmllocation
Une fois le script lancé, il est nécessaire d’ajouter sur l’image AVD une règle de registre pour FSLogix appellant ce fichier XML de configuration. Il faut donc remplacer les xxx par le nom de votre compte de stockage dans cette commande PowerShell :
Une fois la configuration finie, il faut penser à supprimer le profil de l’utilisateur sur le compte de stockage FSLogix afin de repartir sur une base « propre ». L’utilisateur peut alors lancer sa session AVD et Teams. Un rapide contrôle sur le compte de stockage nous permet de vérifier l’évolution de la taille sur profil utilisateur
Conclusion
Au final, Microsoft Teams reste un outil formidable de communication bien intégré dans la suite Office 365. Il mérite toute sa place dans Azure Virtual Desktop. Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????
Annoncé fin mars 2021 pour les environnements personnels Azure Virtual Desktop, Azure Preview propose maintenant cette même fonction pour les environnements AVD mutualisés (Pooled).
La vidéo de Dean met en oeuvre la solution sur un environnement AVD personnel, qui fonctionne aussi pour les environnements mutualisés, et applique les point suivants :
Activation de l’option « Start VM On Connect » sur le Host Pool
Création d’un rôle custom pour donner le droit à AVD de démarrer les VMs
Affectation du rôle custom à la souscription ou au groupe de ressources
Déconnexion des sessions inactives via GPO
Activation de l’arrêt automatique des machines virtuelles à une heure fixe
Mise en place : La mise en place de cette solution est bien expliquée dans la vidéo de Dean, vous pouvez aussi suivre la documentation de Microsoft juste ici.
Rappel : La fonction est encore en public preview pour les environnements AVD mutualisés, il faut donc utiliser le portail adéquat.
Testez vous-même
De mon côté, j’ai souhaité tester la solution sur différents cas de figure :
Test sur un AVD en mode personnalisé : OK
Test sur un AVD en mode mutualisé (Windows 10 multisession) : OK
Test sur un AVD en mode mutualisé (Windows Server 2019) : OK
J’ai aussi fait un test plus poussé dans le cadre d’un environnement AVD mutualisé comprenant plusieurs machines virtuelles :
Nombre de machines virtuelles : 2
Algorithme d’équilibrage de charge : Breadth-first
Nombre maximal de sessions : 5
Voici ce qui s’est passé au niveau des machines virtuelles :
J’ai donc refait un autre test en modifiant le nombre maximal de sessions :
Nombre de machines virtuelles : 2
Algorithme d’équilibrage de charge : Breadth-first
Nombre maximal de sessions : 1
Les premières étapes n’ont pas changé, mais j’ai bien eu autre chose lorsque le second utilisateur a tenté de se connecter :
Conclusion
Au final, la fonctionnalité est bien opérationnelle et s’adapte bien à différents cas d’architecture Azure Virtual Desktop. Seul petit bémol concernant la fonction Breadth-first qui demande encore quelques ajustements pour bien allumer les autres VMs afin de répartir les utilisateurs ????