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.

Microsoft Doc

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 :

Microsoft continue d’apporter des fonctionnalités directement intégrées à Azure Virtual Desktop. Après le démarrage machines des virtuelles à la demande ou encore leur intégration directe avec Azure AD sans domaine AD, Microsoft permet encore une fois d’optimiser l’architecture AVD en l’adaptant à la demande.

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 :

{
 "properties": {
 "roleName": "Autoscale",
 "description": "Friendly description.",
 "assignableScopes": [
 "/subscriptions/<SubscriptionID>"
 ],
  "permissions": [
   {
   "actions": [
"Microsoft.Insights/eventtypes/values/read",
"Microsoft.Compute/virtualMachines/deallocate/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/powerOff/action",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/read",
"Microsoft.DesktopVirtualization/hostpools/read",
"Microsoft.DesktopVirtualization/hostpools/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read",                   "Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read"
],
  "notActions": [],
  "dataActions": [],
  "notDataActions": []
  }
 ]
}
}

• Positionnez-vous au niveau de votre souscription Azure et cliquez sur le bouton d’Ajout d’un rôle personnalisé :

• Selectionnez la fonction JSON et cherchez votre fichier précédement créé, puis cliquez sur Suivant :

• Contrôlez la bonne présence des permissions suivantes, puis cliquez sur Suivant :

"Microsoft.Compute/virtualMachines/deallocate/action", 
"Microsoft.Compute/virtualMachines/restart/action", 
"Microsoft.Compute/virtualMachines/powerOff/action", 
"Microsoft.Compute/virtualMachines/start/action", 
"Microsoft.Compute/virtualMachines/read",
"Microsoft.DesktopVirtualization/hostpools/read",
"Microsoft.DesktopVirtualization/hostpools/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read",

• Supprimez le permiètre par défaut :

• Cliquez ici pour ajouter un nouveau périmètre :

• 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 :

Microsoft.Compute/virtualMachines/deallocate/action
Microsoft.Compute/virtualMachines/restart/action
Microsoft.Compute/virtualMachines/powerOff/action
Microsoft.Compute/virtualMachines/start/action
Microsoft.Compute/virtualMachines/read
Microsoft.DesktopVirtualization/hostpools/read
Microsoft.DesktopVirtualization/hostpools/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/read
Microsoft.DesktopVirtualization/hostpools/sessionhosts/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read

Etape III : Création du plan d’autoscaling

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

La création du plan d’autoscaling se fait directement sur la page d’Azure Virtual Desktop :

• Cliquez ici pour démarrer sa création :

• Remplissez le premier onglet avec vos informations de base 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 :

1. Contrôle de la version de Windows Desktop Client
2. Création d’un nouvel environnement AVD
3. Assignation des utilisateurs aux machines virtuelles d’AVD
4. Modification des paramètres RDP
5. Ajout des droits RBAC sur le groupe de ressources AVD
6. Création d’Azure Bastion
7. Installation de Google Chrome
8. Installation de Multimedia Redirector Service
9. Installation des extensions sur les navigateurs Internet
10. 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 :

drivestoredirect:s:;audiomode:i:0;videoplaybackmode:i:1;redirectclipboard:i:1;redirectprinters:i:1;devicestoredirect:s:;redirectcomports:i:1;redirectsmartcards:i:1;usbdevicestoredirect:s:*;enablecredsspsupport:i:1;use multimon:i:1;targetisaadjoined:i:1

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érequis techniques Teams

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 :

reg add "HKLM\SOFTWARE\Microsoft\Teams" /v IsWVDEnvironment /t REG_DWORD /d 1 /f

Etape II : Installation de Teams

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 :

• Installation de la composante C++ Runtime
• Installation du service WebRTC
• Installation de Microsoft Teams

#Variables
$CSource = "https://aka.ms/vs/16/release/vc_redist.x64.exe"
$RDWRedirectorSource = "https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4AQBt"
$TeamsSource = "https://statics.teams.cdn.office.net/production-windows-x64/1.4.00.8872/Teams_windows_x64.msi"
$Clocation = "C:\temp\vc_redist.x64.exe"
$RDWRedirectionLocation = "C:\temp\MsRdcWebRTCSvc_HostSetup_1.0.2006.11001_x64.msi"
$TeamsLocation = "C:\temp\Teams_windows_x64.msi"

#log store
[string]$temPAth = 'C:\temp\'

#Folder Creation
if (!(Test-Path -Path $temPAth))
{
    $paramNewItem = @{
        Path      = $temPAth
        ItemType  = 'Directory'
        Force     = $true
    }

    New-Item @paramNewItem
}

#Download C++ Runtime
invoke-WebRequest -Uri $Csource -OutFile $Clocation
Start-Sleep -s 5
#Download RDCWEBRTCSvc
invoke-WebRequest -Uri $RDWRedirectorSource -OutFile $RDWRedirectionLocation
Start-Sleep -s 5
#Download Teams 
invoke-WebRequest -Uri $TeamsSource -OutFile $TeamsLocation
Start-Sleep -s 5

#Install C++ runtime
Start-Process -FilePath $Clocation -ArgumentList '/q', '/norestart'
Start-Sleep -s 10
#Install MSRDCWEBTRCSVC
msiexec /i $RDWRedirectionLocation /q /n
Start-Sleep -s 10
# Install Teams
msiexec /i $TeamsLocation /l*v teamsinstall.txt ALLUSER=1 ALLUSERS=1 /q
Start-Sleep -s 10

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 :

HKEY_CURRENT_USER\Software\Microsoft\Office\nn.0\Common\Graphics
DWORD: DisableHardwareAcceleration
Value: 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 :

\\ebgkhbywivnfzjy.file.core.windows.net\profiles

######################
#    AVD Variables   #
######################

$LocalWVDpath = "c:\temp\wvd\"
$FSLogixURI  = "https://aka.ms/fslogix_download"
$FSInstaller = "FSLogixAppsSetup.zip"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$connectionString = "<your-share-path-here>" 

####################################
#    Test/Create Temp Directory    #
####################################

if((Test-Path c:\temp) -eq $false) {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "Create C:\temp Directory"
    Write-Host `
        -ForegroundColor Cyan `
        -BackgroundColor Black `
        "creating temp directory"
    New-Item -Path c:\temp -ItemType Directory
}
else {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "C:\temp Already Exists"
    Write-Host `
        -ForegroundColor Yellow `
        -BackgroundColor Black `
        "temp directory already exists"
}
if((Test-Path $LocalWVDpath) -eq $false) {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "Create C:\temp\WVD Directory"
    Write-Host `
        -ForegroundColor Cyan `
        -BackgroundColor Black `
        "creating c:\temp\wvd directory"
    New-Item -Path $LocalWVDpath -ItemType Directory
}
else {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "C:\temp\WVD Already Exists"
    Write-Host `
        -ForegroundColor Yellow `
        -BackgroundColor Black `
        "c:\temp\wvd directory already exists"
}
New-Item -Path c:\ -Name New-WVDSessionHost.log -ItemType File
Add-Content `
-LiteralPath C:\New-WVDSessionHost.log `
"
ProfilePath       = $connectionString
"
#################################
#    Download AVD Componants    #
#################################

Add-Content -LiteralPath C:\New-WVDSessionHost.log "Downloading FSLogix"
    Invoke-WebRequest -Uri $FSLogixURI -OutFile "$LocalWVDpath$FSInstaller"

##############################
#    Prep for AVD Install    #
##############################
Add-Content -LiteralPath C:\New-WVDSessionHost.log "Unzip FSLogix"
Expand-Archive `
    -LiteralPath "C:\temp\wvd\$FSInstaller" `
    -DestinationPath "$LocalWVDpath\FSLogix" `
    -Force `
    -Verbose
cd $LocalWVDpath 
Add-Content -LiteralPath C:\New-WVDSessionHost.log "UnZip FXLogix Complete"

#########################
#    FSLogix Install    #
#########################
Add-Content -LiteralPath C:\New-WVDSessionHost.log "Installing FSLogix"
$fslogix_deploy_status = Start-Process `
    -FilePath "$LocalWVDpath\FSLogix\x64\Release\FSLogixAppsSetup.exe" `
    -ArgumentList "/install /quiet" `
    -Wait `
    -Passthru


#######################################
#    FSLogix User Profile Settings    #
#######################################
Add-Content -LiteralPath C:\New-WVDSessionHost.log "Configure FSLogix Profile Settings"
Push-Location 
Set-Location HKLM:\SOFTWARE\
New-Item `
    -Path HKLM:\SOFTWARE\FSLogix `
    -Name Profiles `
    -Value "" `
    -Force
New-Item `
    -Path HKLM:\Software\FSLogix\Profiles\ `
    -Name Apps `
    -Force
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "Enabled" `
    -Type "Dword" `
    -Value "1"
New-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "VHDLocations" `
    -Value $connectionString `
    -PropertyType MultiString `
    -Force
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "SizeInMBs" `
    -Type "Dword" `
    -Value "30720"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "IsDynamic" `
    -Type "Dword" `
    -Value "1"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "VolumeType" `
    -Type String `
    -Value "vhdx"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "ConcurrentUserSessions" `
    -Type "Dword" `
    -Value "1"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "FlipFlopProfileDirectoryName" `
    -Type "Dword" `
    -Value "1" 
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "SIDDirNamePattern" `
    -Type String `
    -Value "%username%%sid%"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "SIDDirNameMatch" `
    -Type String `
    -Value "%username%%sid%" 
New-ItemProperty `
    -Path HKLM:\SOFTWARE\FSLogix\Profiles `
    -Name "DeleteLocalProfileWhenVHDShouldApply" `
    -PropertyType "DWord" `
    -Value 1
Pop-Location

##########################
#    Restart Computer    #
##########################
Add-Content -LiteralPath C:\New-WVDSessionHost.log "Process Complete - REBOOT"
Restart-Computer -Force 

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 :

Set-ItemProperty `
-Path HKLM:\Software\FSLogix\Profiles `
-Name "RedirXMLSourceFolder" `
-Type String `
-Value "\\xxx.file.core.windows.net\profiles\Teams-Exclusion"

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 ????