Il s’agit d’un article que je voulais sortir il y a quelques temps déjà. Fin janvier, Microsoft a rajouté une fonctionnalité de Watermarking, encore en préversion, à son service Azure Virtual Desktop. En quelques mots, le Tatouage numérique date des années 90 : il permet de tracer la source de l’information ayant fuitée.
Ce procédé a d’ailleurs beaucoup été utilisé dans le monde du cinéma pour essayer d’endiguer le phénomène du piratage, sans grand succès.
Dans le cadre d’Azure Virtual Desktop, un filigrane est apposé sur le bureau de session utilisateur AVD. Ce filigrane comporte un QR code comportant des informations utiles aux équipes IT pour retrouver la session et donc l’utilisateur à l’origine d’une fuite de données sensibles.
Avec cette fonctionnalité, quelles sont les contraintes pour les utilisateurs ?
Quand cette fonctionnalité est mise en place sur votre environnement Azure Virtual Desktop, la connexion pourra être refusée car la connexion au bureau à distance nécessite un client supportant le watermarking (supérieure à 1.2.3317).
En revanche :
La connexion aux applications publiées ne passera pas par le watermarking.
Les connections directes aux machines virtuelles via l’application MSTSC ne sont pas impactées par le watermarking.
Comment installe-t-on cette fonctionnalité ?
Il est encore nécessaire de passer par une police locale ou via une police de groupe Active Directory. Voici d’ailleurs un lien vers le fichier de modèle administratif pour Azure Virtual Desktop.
Est-il possible de le faire via Intune ?
Ayant récemment sorti un article sur les GPOs via Intune, je me suis dit qu’il serait intéressant d’en faire de même pour mettre en place le Watermarking sur un environnement AVD.
J’ai donc testé cette idée avec le fichier ADMX correspondant :
J’ai sélectionné les fichiers ADMX et ADML de l’archive précédemment téléchargée sur mon poste :
Tout semblait bon, alors j’ai donc cliqué sur Créer :
Impossible de charger le fichier : une erreur de liée à une dépendance est apparue 🤷♂️
J’ai donc fait de même avec TerminalServer.admx, mais une autre dépendance est venue gâcher la fête :
La dépendance Windows.admx est bien passée sur Intune, mais la réinstallation de TerminalServer.admx bloqua toujours :
The given key was not present in the dictionary
A ce jour, je n’ai pas encore trouvé de méthode pour contourner cette erreur. Donc non, ce n’est pas encore possible de passer par Intune pour les GPOs AVD.
Afin d’en savoir un peu plus sur la mise en place du Watermarking, je vous propose une autre manière de tester cette nouvelle fonctionnalité d’AVD.
Mon environnement de test est donc basé sur un domaine managé (Azure Active Directory Domain Services).
Rappel des prérequis :
Pour réaliser cet exercice sur Azure Virtual Desktop, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure active
Afin de tester la fonctionnalité voulue, j’ai déjà déployé un certain nombre de ressources dans mon environnement Azure.
Voici d’abord les ressources liées au service Azure Active Directory Domain Services :
J’ai également créé une machine virtuelle de jump, pour créer et configurer mes GPOs dans mon Azure AD DS :
J’ai ensuite créé un service Azure Virtual Desktop, composé de 3 machines virtuelles individuelles. Ces 3 VMs sont liées à mon domaine Active Directory managé :
J’ai aussi créé le service Azure Bastion afin de me connecter plus facilement aux machines virtuelles sans passer par une IP publique :
Etape I – Mise en place d’un Log Analytics workspace :
La configuration du QR code sur les sessions utilisateurs d’AVD ne nécessite pas directement de Log Analytics workspace. Seulement, la conversion de celui-ci en UPN utilisateur nécessite justement de stocker cette information quelque part.
Pour cela, recherchez dans votre portail le service Log Analytics workspace :
Remplissez les champs pour sa création, puis lancez sa validation :
Attendez quelques minutes que la ressource se créée :
Retournez sur votre environnement Azure Virtual Desktop pour commencer la configuration vers le Log Analytics workspace, La configuration doit bien se faire sur les 3 éléments que compose tout environnement AVD :
Pool d’hôtes
Espace de travail
Machines virtuelles
Cliquez comme-ceci pour configurer les 3 éléments à la suite :
En commençant par le Pool d’hôtes, choisissez le Log Analytics workspace créé précédemment, puis cliquez sur Configurer :
Cliquez sur Déployer pour installer la configuration du LAW au Pool d’hôtes :
Continuez la configuration du LAW avec l’Espace de travail :
Cliquez sur Déployer pour installer la configuration du LAW à l’Espace de travail :
Continuez la configuration du LAW avec les machines virtuelles AVD en les ajoutant :
Cliquez sur Déployer pour installer la configuration du LAW des machines virtuelles :
Ajoutez les métriques de Performances Windows :
Cliquez sur Déployer pour installer la configuration du LAW des métriques de Performances Windows :
Ajoutez les Evènements journalisés de Windows :
Cliquez sur Déployer pour installer la configuration du LAW des Evènements journalisés de Windows :
Quelques minutes plus tard, l’onglet Insights commence à s’alimenter en données de votre environnement AVD :
Etape II – Configuration de la Jump VM :
Afin de mettre en place une GPO pour notre environnement AVD, il est nécessaire de passer par l’Éditeur de stratégie de groupe dans notre domaine.
Pour cela, ajoutez les fonctionnalités liées aux GPOs, mais aussi les outils RSAT pour l’Active Directory :
Une fois l’installation des fonctionnalités terminée, lancez le gestionnaire AD de vos utilisateurs et machines :
Créez si besoin une OU contenant vos machines virtuelles AVD :
Toujours sur la même machine de Jump, pensez à désactiver le contrôle renforcé d’internet :
Rendez-vous ensuite sur le lien suivant, puis téléchargez le dernier fichier de modèles administratifs Azure Virtual Desktop :
Extrayez le contenu du fichier .cab et de l’archive .zip selon votre cas :
Si vous utilisez le magasin central pour la stratégie de groupe :
Copiez terminalserver-avd.admx dans le magasin central de stratégies de groupe de votre domaine, par exemple \contoso.com\SYSVOL\contoso.com\Policies\PolicyDefinitions,
Copiez ensuite le fichier terminalserver-avd.adml dans le sous-dossier en-us.
Si non :
Copiez et collez le fichier terminalserver-avd.admx dans le dossier PolicyDefinitions à %windir%\PolicyDefinitions.
Copiez ensuite le fichier terminalserver-avd.adml dans le sous-dossier en-us.
Dans mon cas, voici ce que cela donne :
Ouvrez le Gestionnaire de la stratégie de groupe :
Sur votre OU contenant vos machines virtuelles AVD, créez une nouvelle GPO :
Nommez votre GPO, puis cliquez sur OK :
Editez votre GPO pour configurer le Watermarking AVD :
Rendez-vous dans le menu suivant :
Computer Configuration
Administrative Templates
Windows Components
Remote Desktop Services
Remote Desktop Session Host
Azure Virtual Desktop
Cliquez sur la configuration de Watermarking :
Activez-là :
D’autres options sont également configurables si besoin :
Etape III – Testez la solution de Watermarking :
De retour sur votre portail Azure, redémarrer les machines virtuelles AVD pour prendre en compte la nouvelle GPO qui leur a été attribuée :
Suivez le redémarrage de celles-ci depuis la console AVD :
Un nouveau statut Eteint a d’ailleurs fait son apparition.
Quelques minutes plus tard, vérifiez que toutes vos machines AVD sont bien redémarrées et accessibles :
Ouvrez le client Windows Remote Desktop, dont la version est en 1.2.3317 ou ultérieure :
Entrez les identifiants d’un utilisateur AVD de test :
Constatez la présence immédiate du QR code au chargement du bureau à distance AVD :
La présence des QR codes continue également durant toute la durée de vie de la session AVD :
Etape IV – Identifiez la session AVD :
Une fois l’image contenant un QR Code en votre possession, il ne vous reste qu’à la scanner pour en obtenir l’identifiant de connexion AVD :
Pour votre test, utilisez votre smartphone ou un site gratuit comme celui-ci :
Copiez la valeur obtenue dans votre presse-papier :
Sur votre portail Azure, recherchez le service Azure Monitor :
Allez dans le menu Logs, puis lancez la requête suivante :
WVDConnections
| where CorrelationId contains "<connection ID>"
Constatez le résultat par vous-même :
Conclusion :
Cette fonctionnalité de Watermarking pourra prévenir la capture d’informations sensibles sur les sessions AVD. Sa mise en place facile et rapide permet de récupérer l’ID de connexion d’une session à distance, utile pour les administrateurs afin de tracer la session.
Azure Virtual Desktop propose deux types d’environnement virtualisé en fonction des usages attendus. Voici une méthode simple de les différencier :
Environnement partagé : plusieurs utilisateurs sur une machine virtuelle
Environnement individuel : un utilisateur par machine virtuelle
Seulement ces types d’environnement ne conviennent pas à tous les usages. Par exemple, des besoins variés entre les utilisateurs, des droits d’administrateurs ou encore une fréquence d’utilisation ponctuelle d’Azure Virtual Desktop correspondent plus à un environnement AVD individuel.
Dans cet article, nous allons justement nous intéresser aux environnements AVD individuels. La configuration de ces machines mono-utilisateur permet de diminuer les coûts quand ces dernières sont uniquement démarrées si leur utilisateur a en réellement besoin.
Justement, que propose Azure pour allumer et éteindre les machines AVD ?
Pour les environnements AVD partagés, le démarrage et l’arrêt des machines virtuelles est configurable dynamiquement grâce à la nouvelle fonction d’autoscalling : un article est déjà disponible sur ce blog juste ici.
En quelques mots, la fonction de mise à l’échelle automatique (autoscalling) vous permet de démarrer des machines virtuelles Azure Virtual Desktop, en modulant à la hausse ou à la baisse leur nombre selon les besoins à l’instant T.
Est-ce aussi compatible pour les environnements AVD individuels ?
Oui pour le démarrage des machines virtuelle. Appelé démarrage à la demande, sa mise en place est très simple. Un autre article de ce blog en parle juste ici.
En quelques mots, l’utilisateur se connecte et attend quelques minutes, si la machine est éteinte, le temps qu’Azure démarre sa machine virtuelle AVD. Voici également une vidéo de Dean qui en parle très bien :
Quand s’éteindra alors sa machine individuelle AVD ?
Concernant l’arrêt de sa machine virtuelle individuelle AVD, il n’existe pas encore d’option native qui agit dynamiquement. Par défaut, l’arrêt d’une machine virtuelle Azure est :
Manuel : réalisé par script ou depuis le portail Azure.
Programmé : via la fonction auto-shutdown, configurable individuellement sur chaque VM.
Cette seconde option pose un souci dans un environnement AVD : l’absence de corrélation entre un auto-shutdown à heure fixe durant l’utilisation d’AVD risque de déconnecter à tort des utilisateurs.
Est-il envisageable de laisser l’utilisateur éteindre sa propre machine virtuelle ?
Cela vous oblige à lui donner des droits sur une ressource Azure : sa machine virtuelle ????♀️
Que peut-on faire pour gérer dynamiquement l’arrêt des machines virtuelles individuelles AVD ?
Azure est une chose flexible ???? Une combinaison de services est possible pour arriver à cet objectif. Soyons clair, je n’ai rien trouvé n’y inventé, mais je me suis appuyé sur cette excellente documentation Microsoft.
Comme le montre le schéma ci-dessous, différentes étapes sont présents pour arriver à l’arrêt complet du service Azure :
Premier déclencheur = déconnecte l’utilisateur inactif
Second déclencheur = éteint l’OS de la machine virtuelle
Troisième déclencheur = désalloue la ressource Azure
Un mécanisme anticipe le retour de l’utilisateur avant l’arrêt de l’OS.
Différents composants sont nécessaires pour réaliser toutes ces étapes :
Ressources Azure :
Automation Account / Runbook / Identité managé
Alertes journalisées / Groupe d’action
Ressources Windows :
GPOs ou Polices locales
Tâches planifiées
Scripts
Etape 0 – Rappel des prérequis :
Des prérequis sont nécessaires pour réaliser ce test sur un environnement individuel AVD :
Un tenant Microsoft
Une souscription Azure valide
Etape I – Déploiement de l’environnement AVD :
Pour déployer rapidement un environnement AVD joint à Azure AD, déployez un réseau virtuel Azure :
Continuez en déployant un environnement individuel AVD :
Ajoutez une ou plusieurs machines virtuelles pour les tests :
Renseignez les informations de réseau et un identifiant / mot de passe pour l’administrateur local :
Créez votre espace de travail AVD :
Une fois validation terminée, lancez la création des ressources Azure Virtual Desktop :
Attendez que le déploiement de votre AVD se termine :
Etape III – Finalisation de la configuration initiale :
Quelques opérations sont nécessaires pour finaliser l’installation de l’environnement AVD.
Ajoutez les 3 rôles Azure RBAC suivants sur votre groupe de ressources AVD :
Contributeur à la mise en route de la virtualisation des postes de travail : permet à l’application AVD de démarrer une machine virtuelle éteinte.
Utilisateur de la virtualisation du poste de travail : assigne l’utilisateur au groupe d’applications AVD.
Connexion de l’administrateur de la machine virtuelle : autorise l’utilisateur à se connecter à distance sur sa machine virtuelle avec les droits d’administrateur local.
Activez cette option pour mettre en route la fonction d’authentification SSO entre Azure AD la machine virtuelle AVD (expliquée juste ici) :
Activez la fonction de démarrage à la demande (expliquée juste ici et documentée officiellement là) :
Assignez votre utilisateur AVD de test à une des machines virtuelles :
Etape IV – Test de l’environnement AVD :
Avant de déployer la solution de configuration d’arrêt dynamique, testez le bon fonctionnement de l’accès à votre environnement AVD avec votre utilisateur de test.
Depuis votre poste local, connectez-vous à l’URL suivante, puis renseignez vos identifiants :
Ouvrez la session de bureau à distance AVD :
Acceptez la fin de la configuration SSO :
Attendez que la session Windows s’ouvre :
Une fois connecté, fermez la session utilisateur :
Depuis votre portail Azure, éteignez la machine virtuelle AVD :
Relancez la même connexion AVD depuis la page web de votre utilisateur de test :
Constatez la présence du message du démarrage de la machine virtuelle, vous invitant à patienter :
Attendez quelques minutes et constatez l’ouverture de la session Windows AVD :
Si tout fonctionne correctement pour vous, continuez la suite de cet article pour configurer l’arrêt dynamique AVD.
Etape V – Configuration des composants Azure
Pour cela, créez un compte Azure Automation :
Une fois la validation terminée, lancez sa création :
Une fois la ressource créée, allez dans le service appelé Azure Monitor :
Ajoutez une Règle d’alerte d’état de santé comme ceci :
Cochez uniquement les 4 conditions suivantes de cette façon :
Créez un nouveau Groupe d’action :
Rattachez le Groupe d’action à votre compte Azure Automation précédemment créé :
Lancez la création de votre Groupe d’action :
Nommez votre Règle d’alerte :
Lancez la création de votre Règle d’alerte :
L’étape suivante concerne maintenant la configuration Windows des machines virtuelles AVD. Il est possible de l’établir cela par :
des Polices locales sur chaque VM AVD
des GPOs créées sur un Active Directory
N’ayant pas d’Active Directory dans mon environnement de test, nous allons créer des polices locales sur la machine AVD de test. C’est aussi votre cas si les machines virtuelles AVD sont jointes à Azure AD.
Etape VI – Configuration des composants Windows
Comme votre utilisateur de test est considéré comme un administrateur local, ouvrez le Planificateur de tâche Windows depuis le menu Démarrer :
Créez une nouvelle Tâche planifiée :
Nommez la Tâche planifiée, puis cochez les cases suivantes :
Ajoutez un déclencheur sur le second onglet :
Choisissez le motif de déconnexion avec un délai de 30 minutes :
Sur l’onglet des actions, ajoutez le lancement du programme Shutdown avec les arguments suivants:
/f /s /t 0
Validez la création de la Tâche planifiée, puis lancez la création d’une seconde Tâche planifiée :
Choisissez le démarrage de la Tâche planifiée avec l’ouverture d’une session utilisateur :
Sur la VM AVD, créez un nouveau fichier texte avec les lignes ci-dessous :
Enregistrez-le sous le nom reset.cmd dans le dossier C:\Windows\System32 :
Appelez-le dans l’action de la Tâche planifiée :
Validez la création de la Tâche planifiée :
Ouvrez le Gestionnaire de police locale :
Naviguez dans l’arborescence suivante :
Configuration utilisateur
Paramètres Windows
Scripts (Logon/Logoff)
Cliquez sur le script suivant :
Cliquez sur Ajouter :
Ajoutez le nom de script suivant :
C:\Windows\System32\tsdiscon.exe
Validez ce script en cliquant sur OK :
Toujours dans le Gestionnaire de police locale, naviguez dans la seconde arborescence suivante :
Configuration utilisateur
Modèle administratif
Composants Windows
Services de bureau à distance
Hôte de session de bureau à distance
Limite de temp de session
Cliquez sur la configuration suivante :
Configurez comme ceci, puis validez vos modifications :
Etape VII – Test de la configuration
Il ne reste qu’à tester tout ça ???????? Voici un rappel des temps de phase configurés :
Avant la première authentification de mon utilisateur AVD, la VM qui lui est attitrée est désallouée, comme le montre le portail Azure ci-dessous :
Je connecte mon utilisateur de test au bureau AVD. Comme sa machine virtuelle est en statut désalloué, je dois attendre quelques minutes pour accéder à son bureau Windows :
Quelques minutes plus tard, la session Windows s’ouvre sans autre action de sa part ni de la mienne :
Le statut de la machine virtuelle AVD a lui aussi changé dans Azure :
Son horloge Windows indique 19:31, j’attends donc les 30 minutes nécessaires, sans effectuer aucune activité sur la session AVD. Environ 30 minutes plus tard, le message suivant apparaît sur sa session AVD :
Si rien n’est fait pendant ces deux minutes, la suite logique est la déconnexion de cet utilisateur :
A ce moment-là, Le portail Azure nous affiche que la machine virtuelle est toujours bien fonctionnelle :
Par contre, AVD reconnait bien que sa session AVD est bien en statut déconnecté :
Environ 30 minutes après la déconnexion de l’utilisateur de test, sa machine virtuelle AVD passe en statut arrêté :
La machine virtuelle devient alors indisponible pour le service AVD :
Environ 5 minutes plus tard , la machine virtuelle passe en statut désalloué :
Une nouvelle tentative d’ouverture AVD depuis le portail utilisateur relancera le démarrage de sa machine virtuelle :
Conclusion
La mise en place de la configuration de déconnexion des sessions inactives fonctionne très bien dans les environnements individuels d’Azure Virtual Desktop. Cette approche va sans nul doute diminuer les coûts liés au Cloud pour des besoins spécifiques et/ou périodiques, sans avoir à se soucier du démarrage et de l’arrêt des machines virtuelles individuelles.
Il sera même intéressant de combiner cette approche avec des instances réservées. Le nombre d’instances réservées approprié dépendra du plancher constant d’utilisateurs AVD connectés.
L’amélioration de l’expérience utilisateur est une tâche constante. Azure Virtual Desktop simplifie et sécurise grandement l’accès aux ressources de l’entreprise. Mais AVD reste un environnement de bureau à distance. A caractéristiques égales, une ressource IT distante a un désavantage en comparaison avec une ressource locale de même grandeur : plusieurs paramètres rentrent en ligne de compte, comme le choix des réseaux (performances, types, …) ou encore le protocole de transmission utilisé.
Azure Virtual Desktop se doit donc de continuer d’évoluer. Plusieurs améliorations consacrées à l’expérience utilisateur ont déjà fait l’objet d’articles sur ce blog :
Concernant ce dernier point, je viens de faire remarque intéressante sur la généralisation du protocole UDP sur les réseaux publics pour un environnement AVD, dont je vous partage l’info juste ici.
Dernièrement, Microsoft propose quelques améliorations pour augmenter la fréquence du nombre d’images sur une session AVD. Cette donnée est importante pour la fluidité des animations ou des vidéos.
Je tiens à remercier Alexandre Moreaux pour son aide précieuse dans la réalisation des tests nécessaire à la rédaction de cet article !
Voici un site web montrant différents exemples de fréquence d’affichage sur un poste local :
M’appuyant sur cette vidéo de Dean, j’ai souhaité mettre en pratique ses conseils.
Pour avoir une meilleure idée sur le sujet, cet article va comparer différentes configurations pour en mesurer l’impact sur les FPS.
Plusieurs environnements Azure Virtual Desktop sont donc nécessaires. Les 4 premiers sont basés sur une machine virtuelle de type D8s v5 et vont servir à effectuer les tests suivants :
Environnement 0 : témoin de base, aucune modification
Environnement 1 : augmentation de la limite FPS pour les connexions RDS
Environnement 2 : augmentation FPS + priorité du décoding graphique
Des prérequis sont nécessaires pour réaliser ces tests sur AVD :
Un tenant Microsoft
Une souscription Azure valide
4 réseaux virtuels Azure, un par environnement AVD
4 machines virtuelles AVD jointes à Azure AD
Vous pouvez créer rapidement et simplement les environnements AVD en suivant cet article. Voici quelques copies d’écran d’un des 4 environnements AVD créés pour mes tests :
N’oubliez pas de configurer les éléments suivants pour rendre accessible vos environnements AVD :
Rôle RBAC Connexion de l’utilisateur de la machine virtuelle à votre utilisateur de test
Rôle RBAC Connexion de l’administrateur de la machine virtuelle à votre utilisateur admin
Assignation du groupe d’application AVD à votre utilisateur de test + utilisateur admin
Etape I – Test sur votre poste local
Afin de se faire une meilleure idée de l’impact d’une session ouverte via RDP, rendez-vous sur la page suivante depuis votre poste physique. Vous devriez obtenir généralement les 3 fréquences FPS suivantes : 60 / 30 / 15.
Dans cet ordre de grandeur, l’œil humain distingue assez facilement l’impact du nombre d’images par seconde. Il est temps de comparer le poste physique avec la première machine AVD.
Etape II – Test de l’environnement témoin :
Connectez-vous à votre premier environnement AVD, appelé témoin :
Réouvrez cette même page de test FPS sur la session AVD via un navigateur internet. Le plafonnement devrait être aux alentours de 30 FPS :
Un clic sur l’icône d’information de connexion RDP vous indique également le nombre d’image traitées et le protocole utilisé :
Les sessions à distance par le protocole RDP sont en effet limité par défaut sur le nombre maximal d’images.
L’étape suivante va vous permettre de modifier cette limite et de recomparer le rendu sur les deux environnements AVD.
Etape III – Test de la modification de la limite FPS
Pour bien différencier ce premier changement, connectez-vous sur votre seconde machine AVD de test :
Cet article sur Microsoft Learn explique comment augmenter la limite de fréquence d’images dans une session à distance :
Depuis le menu Démarrer, cherchez puis ouvrez l’exécuteur de ligne de commande en mode administrateur :
Renseignez le compte d’un administrateur local ou d’un compte Azure AD ayant le rôle Connexion de l’administrateur de la machine virtuelle :
Ouvrez la même page de test FPS que sur la première machine AVD. Le plafonnement devrait être maintenant aux alentours de 60 FPS :
Avons-nous donc maintenant 60 FPS ?
Un nouveau contrôle sur l’icône d’information de connexion RDP vous indique en revanche un nombre bien plus faible pour le nombre d’image traitées, malgré la grandeur du débit disponible par le protocole UDP.
Continuons les tests en suivant toujours les conseils de Microsoft.
Etape IV – Test de la modification de la limite FPS + Priorité au décoding
Ce nouveau test reprend la modification de registre apportée par l’étape III et rajoute en plus la priorité au décoding graphique. Vous pouvez donc reprendre la même machine AVD précédemment utilisée, ou repartir sur une nouvelle machine avec les deux modifications :
Modification de la limite FPS (Etape III)
Priorité au décoding
Pour ce second point, cherchez puis ouvrez l’exécuteur de ligne de commande en mode administrateur :
Renseignez le compte d’un administrateur local ou d’un compte Azure AD ayant le rôle Connexion de l’administrateur de la machine virtuelle :
Ouvrez l’Éditeur de stratégie de groupe locale :
Ouvrez l’arborescence suivante :
Computer Configuration
Administrative Templates
Windows Components
Remote Desktop Services
Remonte Desktop Session Host
Remote Session Environment
Ouvrez la police suivante :
Activez-là et cliquez sur OK pour sauvegarder :
A la place, voici la même commande pour ajouter la clef au registre :
Ouvrez la même page de test FPS que précédemment. Le plafonnement devrait être toujours aux alentours de 60 FPS :
Un nouveau contrôle sur l’icône d’information de connexion RDP vous indique toujours un nombre bien plus faible de FPS :
Continuions notre troisième test avec en ajout la configuration du décoding graphique.
Etape V – Test limite FPS + Priorité au décoding + Configuration du décoding
Ce troisième reprend les deux modifications apportées par les étape III et IV, et ajoute en plus la configuration du décoding graphique. Vous pouvez donc reprendre la même machine AVD précédemment utilisée, ou repartir sur une nouvelle machine avec les trois modifications suivantes :
Modification de la limite FPS (Etape III)
Priorité au décoding (Etape IV)
Configuration du décoding
Pour configurer ce troisième point, cherchez puis ouvrez l’exécuteur de ligne de commande en mode administrateur :
Renseignez le compte d’un administrateur local ou d’un compte Azure AD ayant le rôle Connexion de l’administrateur de la machine virtuelle :
Ouvrez l’Éditeur de stratégie de groupe locale :
Ouvrez l’arborescence suivante :
Computer Configuration
Administrative Templates
Windows Components
Remote Desktop Services
Remonte Desktop Session Host
Remote Session Environment
Ouvrez la police suivante :
Activez-là et cliquez sur OK pour sauvegarder :
A la place, voici la même commande pour ajouter la clef au registre :
Ouvrez la même page de test FPS que précédemment. Le plafonnement devrait encore et toujours être aux alentours de 60 FPS :
Un nouveau contrôle sur l’icône d’information de connexion RDP vous indique encore et toujours un nombre bien plus faible de FPS :
Que faire alors ? Sommes-nous bloqués quoi que nous fassions avec 30 FPS sur Azure Virtual Desktop ?
Etape VI – Test sur une machine virtuelle graphique
J’ai donc décidé d’aller un peu plus loin en testant AVD sur une machine virtuelle graphique disponible sur Azure. J’ai choisi de prendre la taille Standard_NV6 de la série des NV, elle dispose d’une puissance graphique bien plus conséquente que les machines de la famille D :
Comme ces machines graphiques ne supporte pas le GEN 2, j’ai choisi sur une image en Windows 10 en GEN 1:
Comme lors de la précédente salve de tests, j’ai utilisé deux environnements de même configuration pour mesurer l’impact ou non des modifications Microsoft sur les FPS :
Environnement 5 : Environnement graphique de base
Environnement 6 : Environnement graphique de base + modifications
Sur les deux environnements graphiques, j’ai commencé par mettre à jour les pilotes de la carte graphique à jour grâce au compte d’administrateur local :
J’ai continué par configurer l’outil de configuration GPU spécifique à Nvidia :
nvidia-smi.exe -fdm 0 -g 00000001:00:00.0
J’ai effectué par la suite un redémarrage nécessaire des deux VMs.
J’ai ensuite installé sur les deux environnements graphiques les applications suivantes :
Un dernier redémarrage de la machine virtuelle de l’environnement 6 est encore nécessaire.
J’ai lancé Fraps suivi d’une nouvelle partie de jeu Age of Empires II. Sans plus attendre, voici les résultats FPS donnés par FRAPS et par la connexion RDP :
Environnement 5 : Graphique sans modification :
Environnement 6 : Graphique avec modifications :
Dans les deux environnements, Fraps indique un nombre très conséquent de 120 FPS. Cela s’explique par la faible exigence graphique Age of Empires II et de la performance graphique de ces machines virtuelles.
Concernant les FPS relevés par la connexion RDP, un écart se creuse d’environ 10 FPS entre les deux environnements tests. L’environnement 6 est meilleur, sans pour autant rapprocher le nombre de FPS généré par la carte graphique de machine virtuelle AVD.
Conclusion
Tous ces tests montrent l’importance relative de la configuration des FPS sur des machines classiques d’AVD et pour des tâches de bureautique. 30 FPS suffisent à beaucoup d’actions. On pourra néanmoins être gêné si le volume d’utilisateurs est important, et que des besoins graphiques (Teams ?) sont présents.
Les machines graphiques disponibles sur Azure montre de belles performances et peuvent convenir dans bien des scénarios graphiques quand elles sont combinées avec Azure Virtual Desktop.
Beaucoup d’articles sur ce blog parlent déjà d’Azure Virtual Desktop ????. Au fil des mois, nous avons constaté ses améliorations, la simplification du déploiement, l’augmentation de sa sécurité, de ses performances ou encore une meilleure compatibilité. Un point important n’a pas encore été abordé : l’optimisation des coûts sur AVD.
D’ailleurs, plusieurs articles parlant des coûts sur Azure sont déjà disponibles sur ce blog :
C’est un premier pas vers la compréhension de la facturation de Microsoft selon vos usages. Ce modèle de facturation, basé sur la consommation est la norme pour les principaux fournisseurs de Cloud.
Quels sont les principaux coûts d’Azure Virtual Desktop ?
Avant de parler d’optimisations sur les coûts, il est nécessaire de lister les principales charges d’une architecture Azure Virtual Desktop. Certains coûts sont systématiques, tandis que d’autres sont optionnels :
Gestion des identités : Azure Virtual Desktop repose sur une gestion des utilisateurs, de même que pour l’OS, les fichiers ou encore certaines applications. Plusieurs options sont disponibles : Azure AD, Active Directory ou le service managé Azure AD DS.
Machine virtuelle : Que l’environnement AVD soit composé pour des machines individuelles ou partagées, elles représentent toujours un coût important dans l’infrastructure AVD.
Stockage : Plusieurs types de stockage sont nécessaires dans une architecture AVD. Un premier stockage est déjà présent sur chaque machine virtuelle pour stocker l’OS, les applications, … Un second est créé pour stocker les données et les informations de session des utilisateurs AVD.
Licence : Que l’environnement AVD fonctionne sur Windows 10/11 ou Windows Server, des licences Microsoft sont nécessaires. Le choix de l’OS pour AVD repose sur les besoins applicatifs ou la méthode de gestion du parc souhaitée.
Réseau : Toute donnée sortante du Cloud Microsoft est facturée. Chaque utilisateur d’AVD génère un petit coût lorsqu’il ouvre et utilise sa session de bureau à distance. Cette somme varie selon le volume de Gio envoyés en dehors du Cloud, en sachant que le protocole RDP n’est pas réputé comme gourmand en traffic.
Gestion de la sécurité : Toute infrastructure IT a besoin de mesures de protection. Ces coûts ne sont pas obligatoirement liés à Microsoft, mais ils doivent être pris en compte dans l’enveloppe finale.
Sauvegarde : La sauvegarde de certaines données est indispensable pour se prémunir d’un accident ou d’une fraude. Le volume de donnée à sauvegarder, la fréquence ou la redondance de la sauvegarde influent sur son prix.
Plan de reprise d’activité : Le PRA n’est pas un système de sauvegarde au premier sens du terme. Il n’est pas non plus obligatoire. Mais il doit être perçu comme un point majeur dans la protection de services critiques, afin qu’ils continuent à fonctionner. Sur Azure, un doublement de certaines ressources AVD est envisageable dans une seconde région du Cloud.
Et le coût d’un AVD dans tout ça ?
Il n’existe pas de prix fixe pour Azure Virtual Desktop. La liste des éléments précédemment listés vous montre les principaux axes de coûts, mais le choix de chaque composant dépend du projet AVD.
Il existe un objet Azure Virtual Desktop dans le Calculateur de prix Azure, mais je trouve que celui-ci passe très vite sur certains points et oublie d’en mentionner d’autres.
Alors, comment procède-t-on pour estimer le prix d’un projet AVD ?
Aucune baguette magique n’existe ! Comme pour toute infrastructure IT, il est conseillé de récolter quelques métriques sur les besoins utilisateurs pour commencer à composer. Voici quelques exemples de questions qui me paraissent essentielles pour démarrer un projet AVD :
Nombre d’utilisateurs totaux
Nombre d’utilisateurs simultanés
Horaires de travail
Nature des besoins (Répartition des utilisateurs selon des types de population)
Exigences OS de l’équipe IT / des applications
Ont-ils déjà des licences 365 en place ?
Préférence géographique sur Azure ?
Volonté d’engagement dans la durée ?
Perspective de croissance des besoins AVD
Ressources IT locales à interconnecter
Ces données sont utiles pour estimer les principaux coûts listés précédemment.
Et si l’on ne souhaite pas réaliser tous ces calculs ?
Azure facture sur la consommation mensuellement. Le but sur Azure n’est pas de produire un coût fixe mensuel. Si cela n’est pas votre souhait, Microsoft a aussi pensé à vous et propose également une solution clef en main, appelé Windows 365 au tarif mensuel fixe.
Windows 365 est proche d’un système de licence comme pour Office 365, pour le provisionnement d’un PC Cloud. La puissance de ce PC dépend du prix de la licence Windows 365 choisie. Un premier article sous la solution est disponible juste ici
Bien que basé sur la même technologie, Windows 365 est un service hautement managé. Cela réduit donc la configuration possible sur certaines fonctionnalités, comme le montre ce tableau ci-dessous :
Êtes-vous êtes toujours là ? ????
Je vous propose de reprendre les 6 principaux coûts Azure Virtual Desktop et d’envisager des économies possibles.
Coût I – Gestion des identités :
Azure Virtual Desktop fonctionne avec les 3 systèmes de gestion identitaire suivants :
L’économie consiste à prendre la bonne gestion identitaire à votre projet. Voici un classement croissant par ordre de prix et des usages les plus courants :
Azure AD : Azure AD de base est gratuit ! Évidemment, certaines fonctionnalités sont bridées, mais cela allège déjà un peu la facture. La gestion identitaire par Azure AD est conseillé pour les petits environnements ne disposant pas d’infrastructure IT on-premise.
Azure AD DS : Solution intermédiaire en termes de coûts, de fonctionnalités et de management. Il s’agit d’un domaine géré par Microsoft et donc partiellement restreint. Azure AD DS est lui aussi conseillé pour les petits environnements ne disposant pas d’infrastructure IT on-premise.
Active Directory : idéalement utilisé si l’on souhaite avoir la main complète sur les paramétrages du domaine AD, ou si un domaine AD existe déjà en on-premise. Il est alors possible d’étendre l’AD local à Azure via une liaison Azure VPN et une machine ayant le rôle d’AD dans Azure.
Coût II – Machine virtuelle :
Comme annoncé plus haut, les machines virtuelles représentent une part importante du coût total de l’architecture Azure Virtual Desktop. Bien souvent, il est difficile d’estimer au mieux le nombre et la puissance des machines virtuelles AVD. Les métriques de l’environnement actuel, un cahier des charges précis et des phases de POC sont de vrais facilitateurs.
De mon côté, j’essaie d’imaginer, selon mes expériences antérieures, les possibilités de machines virtuelles AVD adaptées aux besoins des utilisateurs. Je compile alors le tout dans un tableau Excel : le nombre d’utilisateurs par population et différents scénarios où les ressources allouées varient :
Quelles sont les économies possibles ?
Trois économies sont possibles sur les coûts des machines virtuelles AVD :
Adaptez la puissance de vos machines virtuelles : cela risque de ne pas plaire aux utilisateurs AVD, ou pas. Des machines correctement dimensionnées selon les usages diminuent fortement les coûts. Il est important d’analyser le nombre d’utilisateurs maximal que la machine supporte sans que l’expérience utilisateur ne soit dégradée.
Réservez vos machines virtuelles pendant 1 ou 3 ans : Deux méthodes de facturations sont disponibles sur Azure. Prendre un engagement sur une machine virtuelle est une méthode pratique pour diminuer les coûts quand l’utilisation de la ressource est en 24/7.
Privilégiez Windows 10/11 quand cela est possible : Une licence Windows Server + CAL RDS coûtent toujours plus cher que des licences ayant des droits d’accès utilisateur, comme Microsoft 365 Business Premium ou Microsoft E3/E5.
Coût III – Stockage :
Il existe deux principaux coûts au stockage sur Azure. La taille du stockage et les transactions influent sur le montant :
Taille du stockage : Un disque managé Azure est facturé toutes les heures au niveau supérieur le plus proche de sa taille. Autrement dit, un disque de 120 Go coûte autant qu’un disque de 128 Go, que la machine virtuelle soit allumée ou non.
Transactions : Sont appelées transaction, les lectures, les écritures, … effectuées par le disque, elles sont facturées par paquet de 10 000 transactions. Certains types de disque, comme les disques Premium ou Ultra, incluent le coût des transactions dans leur tarification les coûts sont alors plus prévisibles et mieux maîtrisés.
Voici une brève comparaison tarifaire pour un disque de 128 Go en Europe de l’Ouest, selon Azure Pricing Calculator :
Premium SSD : 20.13 CHF / mois
Premium SSD v2 : 11.49 CHF / mois
Standard SSD : 12.63 CHF / mois
Standard HDD : 6.39 CHF / mois
Ultra disk : 88.73 CHF / mois
Quelles sont les économies possibles ?
Le type de disque le moins cher n’est pas forcément le plus économe. Les transactions risquent de faire exploser le coût du stockage des machines virtuelles ou des partages de fichiers.
Surveillez les consommations d’espace : un espace réservé et inutilisé est facturé par Azure. Ajustez la taille et les performances selon les besoins.
Coût IV – Licence :
Azure Virtual Desktop nécessite des licences adéquates en fonction de l’environnement choisi, Windows 10/11 ou Windows Server :
Windows 10/11 : On licencie les utilisateurs et non les machines virtuelles.
Windows Server: On licencie les machines virtuelles (+ CAL RDS) et non les utilisateurs.
Pour moi, la meilleure économie possible est de partir sur une licence Microsoft 365 Business Premium pour chaque utilisateur AVD. Cette dernière comprend entre autres :
Azure AD Premium P1
Les droits d’utilisation d’Azure Virtual Desktop sous environnement Windows 10/11
Les principaux outils de la suite bureautique d’Office 365
Et encore bien d’autres fonctionnalités de sécurité
Si le choix de partir sur un environnement AVD sous Windows Server est non négociable, privilégiez Azure Hybrid Benefit grâce à l’achat de licences Windows Server et CAL RDS en mode souscription CSP. La rentabilité est atteignable en 1 ou 2 mois seulement !
Coût V – Réseau :
Pensez à consulter régulièrement l’excellent site m365maps pour vous aider à choisir la meilleure licence selon vos besoins.
Les services hébergés dans le cloud sont accessibles depuis une architecture on-premise ou pour des utilisateurs simplement connectés à internet. Le schéma réseau ci-dessous montre les étapes de mise en place du bureau à distance AVD pour un utilisateur se connectant depuis internet :
Vous l’avez compris, l’utilisation d’Azure AD et du protocole HTTPS inversé apportent une couche de sécurité dans le transfert de données entre l’infrastructure AVD et l’utilisateur.
Dans beaucoup de scénarios, il n’est pas systématiquement nécessaire d’exiger un accès VPN. Ce service est payant dans Azure, et son prix dépend principalement de son débit.
Enfin, les volumes de bande passante sortante ne sont pas élevés pour un environnement AVD. Il est donc inutile d’acheter un circuit ExpressRoute en formule illimité :
Coût VI – Gestion de la sécurité :
Une série d’articles dédiée à la sécurité est disponible juste ici. Pour éviter de vous endormir lors de longues lectures d’hiver et pour rester focalisé sur Azure Virtual Desktop, je vous conseille ces deux articles là :
Azure AD est gratuit ! ???? Azure Active Directory est bien proposé en quatre éditions : Gratuite, Applications Office 365, Premium P1 et Premium P2. Pour des questions de sécurité, je recommande de licencier vos utilisateurs AVD avec une licence Azure AD Premium P1.
Grâce à lui, l’accès conditionnel sur votre AVD apporte des mesures de restriction et bloque les connexions suspectes :
Fonctionnalité
Azure AD Free – Paramètres de sécurité par défaut
Azure AD Free – Administrateurs généraux uniquement
Office 365
Azure AD Premium P1
Azure AD Premium P2
Accès conditionnel
●
●
Accès conditionnel basé sur les risques
●
Quelles sont les économies possibles ?
Je pense qu’il n’est pas nécessaire de s’orienter vers une licence Azure AD Premium P2 pour vos utilisateurs AVD. Ses fonctionnalités sont certes très intéressantes, mais ce besoin n’est pas utile pour des « utilisateurs lambda ».
Conclusion :
Aucun doute qu’il existe plein d’autres optimisations possibles pour un environnement AVD. Un exercice que je conseille est de suivre régulièrement les évolutions de Microsoft sur les services Cloud. Le blog officiel et les vidéos disponibles sur YouTube vous donneront toujours des informations et des astuces auxquelles vous n’avez pas pensées.
Enfin n’oubliez pas de suivre et d’analyser la consommation Azure grâce au Cost Management ????????
Rassurez-vous, Azure Virtual Desktop propose depuis longtemps une intégration avec l’accès conditionnel disponible sur Azure AD. Ce billet, datant déjà de 2019, écrit par Freek Berson, nous montre bien l’intégration entre AVD et FIDO2.
Je souhaitais malgré tout vous écrire un article en français pour détailler le processus de mise en place FIDO2 et les possibilités intéressantes avec AVD.
Qu’est-ce que FIDO2 (Fast IDentity Online 2) ?
La réponse de l’industrie au problème des mots de passe.
Exit donc l’utilisation d’un simple du mot de passe pour valider un processus d’authentification. FIDO2 a été développé par la FIDO Alliance et est à ce jour leur dernière norme.
FIDO2 est bâti sur des spécifications Web Authentication, ou WebAuthn, du World Wide Web Consortium (W3C), donc universel mais disposant de capacités supplémentaires.
Cette vidéo en français explique plusieurs de ces avantages :
USB-A ou C ou encore NFC
Absence de donnée personnelle sur la clef
Code PIN de protection
Zone de contact pour valider une présence physique
Utilisation pour plusieurs comptes
Bon conseil : toujours avoir deux clefs ????.
Puis-je utiliser une clef FIDO2 pour m’authentifier sur Azure AD ?
Oui, Azure AD supporte un grand nombre de méthodes renforcées pour sécuriser l’authentification des utilisateurs. Vous pouvez retrouver cette liste ici, ou dans le portail Azure, via la page des Méthodes d’authentification :
D’une manière générale, Microsoft déconseille l’utilisation unique de mot de passe pour authentifier un compte (Voir tableau ci-dessous). Azure AD propose à ce jour différentes méthodes dans le cadre d’un processus d’authentification multifacteur :
Windows Hello Entreprise
Microsoft Authenticator
Clés de sécurité FIDO2
Ai-je besoin d’une licence particulière pour utiliser FIDO2 ?
FIDO2 n’exige pas de licence particulière, mais l’accès conditionnel en demandera une. En effet, pour intégrer FIDO2 dans une ou plusieurs polices d’accès conditionnel, il vous faudra une licence Azure Premium P1 ou P2 pour tous les utilisateurs concernés.
Fonctionnalité
Azure AD Free – Paramètres de sécurité par défaut
Azure AD Free – Administrateurs généraux uniquement
Office 365
Azure AD Premium P1
Azure AD Premium P2
Accès conditionnel
●
●
Accès conditionnel basé sur les risques
●
Il ne faut pas confondre l’accès conditionnel qui vient en remplacement, car plus abouti et personnalisable que la MFA de base ou les paramètres de sécurité par défaut :
Stratégie
Paramètres de sécurité par défaut
Accès conditionnel
Authentification multifacteur par utilisateur
Gestion
Ensemble standard de règles de sécurité pour garantir la sécurité de votre entreprise
●
Activé/désactivé en un clic
●
Inclus dans la gestion des licences Office 365
●
●
Modèles préconfigurés dans l’assistant Centre d’administration Microsoft 365
●
●
Flexibilité de la configuration
●
Fonctionnalité
Exempter les utilisateurs de la stratégie
●
●
Authentification par appel téléphonique ou SMS
●
●
S’authentifier par Microsoft Authenticator et jetons logiciels
●
●
●
Authentification par FIDO2, Windows Hello Entreprise et les jetons matériels
●
●
Bloque les protocoles d’authentification hérités
●
●
●
Les nouveaux employés sont automatiquement protégés
●
●
Déclencheurs MFA dynamiques en fonction des événements à risque
●
Stratégies d’authentification et d’autorisation
●
Configurable en fonction de l’emplacement et de l’état de l’appareil
●
Prise en charge du mode « Rapport seul »
●
Où peut-on se procurer des clefs FIDO2 ?
Microsoft met à disposition cette liste de fournisseur proposant justement des clefs FIDO2 :
Pour effectuer mes tests sur mon environnement Azure, j’ai décidé d’acheter deux clefs USB-A sous forme de pack auprès de Token2 Switzerland, au prix de 23€, frais de port compris :
Comment procède-t-on pour intégrer FIDO2 à Azure Virtual Desktop ?
Le processus d’installation est très simple, il vous faudra néanmoins quelques prérequis pour arriver à une intégration complète. Dans ce tutoriel, nous allons mettre en place une clef FIDO2 pour un utilisateur et créer deux polices d’accès conditionnel dédiées à AVD :
Etape 0 – Rappel des prérequis :
Les prérequis suivants sont nécessaires pour réaliser cette démonstration avec AVD :
Un poste sous Windows 10 (1903) ou supérieur
Un tenant Microsoft
Une souscription Azure valide
Un environnement AVD déployé (je vous conseille de suivre ce tutoriel)
Une licence Azure AD Premium Plan 1 ou Plan 2
Si votre tenant ne dispose d’aucune licence Azure AD Premium, vous pouvez activer une licence Azure AD Premium Plan 2 en version d’essai directement depuis le portail Azure AD :
Une fois la version d’essai activée, pensez à affecter une licence Azure AD Premium Plan 2 à un utilisateur votre tenant.
Etape I – Configuration du code PIN :
Azure AD exige que les clés de sécurité soient protégées par un code PIN. Insérer votre clef FIDO2 dans un port USB et allez dans les paramètres de votre poste pour le définir :
Cliquez ici pour configurer la clef :
Touchez la zone prévue à cet effet pour continuer :
Définissez un code PIN et confirmez-le :
Etape II – Activation de FIDO2 sur Azure AD :
Sur le portail d’Azure AD, consulter les paramètres de Sécurité via le menu suivant :
Cliquez sur Méthodes d’authentification :
Cliquez sur la ligne FIDO2 :
Activez la fonctionnalité FIDO2, puis cliquez sur Configurer :
Sauvegardez-là avec les options de base :
Quelques minutes sont parfois nécessaire pour continuer sur la configuration FIDO2 au niveau de l’utilisateur. Ne vous inquiétez pas si les écrans suivants ne sont pas encore identiques au tutoriel.
Etape III – Enrôlement d’une clef FIDO2 sur un compte Azure AD :
Comme dit précédemment, la clef FIDO2 n’embarque aucune information personnelle sur les comptes associés à celle-ci. Vous pouvez donc sans souci utiliser la même clef pour plusieurs comptes Azure AD.
Dans mon cas, j’ai créé un nouvel utilisateur pour retester un enrôlement complet.
Rendez-vous sur la page myaccount de Microsoft avec votre utilisateur de test, puis cliquez les Informations de sécurité :
Cliquez ici pour ajouter la première clef FIDO2 :
Dans mon cas, Azure m’avertit que mon utilisateur de test ne dispose d’aucune autre méthode MFA, j’en profite donc pour mettre en place le SMS comme seconde méthode :
Une fois terminé, recommencez le processus pour arriver sur cet écran :
Azure AD entame une communication avec la clef FIDO2 :
Plusieurs messages d’information de Windows 10 vont se succéder :
Renseignez le PIN de votre clef FIDO2, puis continuez :
Touchez la zone prévue à cet effet pour terminer :
Il ne vous reste plus qu’à donner un nom à cette première clef FIDO2 :
Comme il est fortement conseillé, recommencer la même opération avec une seconde clef FIDO2, utilisable en cas de secours :
Etape IV – Test de FIDO2 :
Avant d’aller plus loin dans l’intégration avec Azure Virtual Desktop, je vous conseille de tester l’authentification utilisateur avec sa clef FIDO2. Pour cela ouvrez le navigateur de votre choix en mode privé et allez sur la page web office.com.
Cliquez-ici pour vous authentifier :
Au lieu de saisir le mot de passe du compte de test, cliquez comme ceci :
Renseignez le code PIN de votre clef FIDO2 :
Touchez la zone prévue à cet effet pour confirmer l’authentification :
Cliquez enfin sur Non :
Et vous voilà correctement authentifié sur le portail Office365 ????
Etape V – Création d’une méthode d’authentification renforcée :
En faisant différents tests, je me suis rendu compte que l’on pouvait intégrer le mécanisme FIDO2 à plusieurs niveaux d’AVD.
Encore en préversion à ce jour, connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :
Ouvrez le menu Sécurité :
Cliquez sur Méthodes d’authentification :
Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle :
Terminez la création de celle-ci :
Etape VI – Test de l’accès conditionnel au premier niveau :
Toujours dans votre portail Azure AD, retournez dans la section Sécurité puis cliquez sur Accès conditionnel :
Créez votre nouvelle Police :
Saisissez un nom à votre police et sélectionnez votre utilisateur de test :
Ajoutez l’application Azure Virtual Desktop :
Terminez la configuration en autorisant l’accès sous réserve de satisfaire votre nouvelle méthode d’authentification renforcée :
Attendez quelques minutes et ouvrez votre client Windows d’Azure Virtual Desktop pour tester votre première police d’accès conditionnel :
Renseignez le compte Azure de votre utilisateur de test et constatez la présence de ce message :
Touchez la zone prévue à cet effet pour terminer l’authentification :
Félicitations ! Votre accès AVD est bien protégé par la clef FIDO2 ????.
Etape VII – Test de l’accès conditionnel au second niveau :
En parcourant les fonctionnalités de l’accès conditionnel d’Azure AD, j’ai remarqué une seconde application du Cloud Azure très intéressante :
J’ai donc créé une seconde règle d’accès conditionnel, avec les mêmes autres paramètres pour intégrer un mécanisme FIDO2 au moment de l’ouverture de session Windows d’AVD :
Sur votre application Azure Virtual Desktop, cliquez sur l’icône pour ouvrir une session AVD :
Attendez que le processus continue :
Choisissez le compte autorisé à AVD et disposant d’une clef FIDO2 :
Renseignez le code PIN de votre clef FIDO2 :
Touchez la zone prévue à cet effet pour confirmer l’authentification :
Attendez que la session AVD s’ouvre :
Conclusion
Cette combinaison AVD + AD + FIDO2 fut très intéressante à tester, et assez simple à mettre en place. Cette flexibilité nous montre aussi l’infinité de scénarios possibles pour augmenter la sécurité des utilisateurs sans pour autant rendre le quotidien lourd ou invivable.
Enfin, profitez-en pour sécuriser un peu plus vos comptes à vous ????
Azure Virtual Desktop continue encore d’évoluer et s’associe maintenant avec un autre service réseau du cloud Microsoft : Azure Private Link. En ce début du mois de novembre, Microsoft vient de l’ouvrir en préversion publique pour tester cette fonctionnalité. L’idée est donc de sécuriser d’avantage, par une restriction encore plus poussée, l’accès au service Azure Virtual Desktop.
Pourquoi restreindre un service Cloud ?
Pour répondre à une demande provenant de certaines entreprises. Beaucoup d’entre-elles ont même des exigences légales et ne souhaitent donc pas faire passer un flux réseau à travers internet, quand bien même il s’agirait de communications en HTTPS.
Il paraissait donc important que Microsoft propose ce type de fonctionnalité pour permettre à au service à Azure Virtual Desktop d’être 100% en dehors du web.
Pour parvenir à la mise en place de cette fonctionnalité, Microsoft met déjà à disposition plusieurs documentations, disponibles uniquement en anglais pour l’instant :
En deux mot, Azure Private Link vous permet d’accéder aux services Azure PaaS (par exemple du stockage Azure, compte le compte de stockage ou encore une base de données SQL) depuis votre réseau virtuel :
Voici une vidéo qui aborde le sujet dans son entièreté :
Comment va fonctionner Azure Virtual Desktop avec Private Link ?
Comme pour les autres services proposant cette association, le trafic entre le réseau virtuel et Azure Virtual Desktop transitera par le réseau « dorsal » de Microsoft, ce qui signifie que vous n’aurez plus besoin d’exposer votre AVD à l’Internet.
En termes de sécurité, transiter son trafic dans le réseau « connu » et sécurisé de Microsoft renforcera toujours un peu plus la protection de vos données.
A quel moment intervient le Private Link dans le chemin de connexion entre l’utilisateur et AVD ?
Il peut intervenir à plusieurs niveaux. En effet, la connexion est décomposée en différentes étapes et avec plusieurs composants. Il est alors possible de choisir quelles connexions ont le droit ou non de transiter par internet.
C’est d’ailleurs pour cela que plusieurs options sont présentes dans la configuration réseau d’AVD :
La première option se charge d’autoriser ou non l’accès au service AVD des utilisateurs depuis internet. Autrement la partie frontale de la connexion AVD.
La seconde option se charge d’autoriser ou non l’accès au service AVD des machines virtuelles AVD depuis internet. Autrement la partie arrière-plan de la connexion AVD.
Peut-on utiliser à la fois les fonctionnalités Private Link et RDP Shortpath ?
Durant cette phase de préversion, cela n’est pas possible. Pour rappel RDP Shortpath est une méthode habile d’Azure Virtual Desktop qui établit un transport direct basé sur le protocole UDP entre le client Remote Desktop et l’hôte de session. Tout y est expliqué ici.
Etape 0 – Rappel des prérequis
Pour arriver à la démonstration de l’association entre Azure Virtual Desktop et Private Link, je dispose d’un environnement comprenant des composants déjà en place :
Poste Windows 10 avec Azure VPN
Environnement AVD avec jointure Azure AD
On retrouve ainsi mon premier réseau virtuel comprenant :
La machine virtuelle faisant office de poste utilisateur distant sous Windows 10
Le service Azure Bastion pour m’y connecter plus facilement
J’ai également déployé un second réseau virtuel. Celui-ci comprend
Mon environnement Azure Virtual Desktop
Une passerelle VPN pour assurer la connection entre le poste Windows 10 et AVD
La connexion VPN Point à Site est bien fonctionnelle :
L’accès direct à une des machines virtuelles AVD répond bien.
Comme vous pouvez le voir sur la configuration d’Azure Virtual Desktop, une nouvelle section dédiée au réseau a fait son apparition :
Avant d’aller plus loin, il est donc nécessaire d’activer la fonctionnalité, encore en préversion à l’heure où ces lignes sont écrites.
Etape I – Activation de la fonction de préversion d’Azure Private Link
Comme beaucoup de fonctionnalités encore en préversion, il est nécessaire de l’activer depuis le portail Azure. Pour cela, effectuer l’opération suivante via ce lien :
N’oubliez pas de sélectionner la bonne souscription Azure.
Une fois enregistrée, attendez environ 15 minutes.
Retournez sur la section réseau de votre Azure Virtual Desktop pour constater le déblocage des fonctionnalités réseaux :
Dans cette configuration par défaut, avec les 2 cases de cochées, la connexion réseau transite via internet dans sa totalité :
Entre le client et le service Azure Virtual Desktop
Entre le service Azure Virtual Desktop et les machines virtuelles AVD
Un test, avec le VPN désactivé, montre que la connexion se fait toujours via internet :
Etape II – Restreindre la communication entre le service AVD et le pool d’hôtes au réseau virtuelAzure
La première étape consiste donc à restreindre la communication entre le service Azure Virtual Desktop et les machines virtuelles AVD au réseau virtuel. Pour cela décochez la case suivante et sauvegardez :
Un nouvel essai de connexion utilisateur vous montre le blocage immédiat de cette méthode en passant par internet :
Comme dit plus haut, l’utilisateur n’en est pas responsable : Le service Azure Virtual Desktop est incapable de communique avec la machine virtuelle AVD.
Pour arriver rétablir l’accès au service AVD, nous avons besoin de créer un premier private endpoint en cliquant sur le second onglet de la section réseau :
Pour réactiver les connexions, vous devrez créer un private endpoint pour chaque pool d’hôtes AVD que vous souhaitez autoriser.
Donnez-lui un nom, puis passez à l’onglet suivant :
Laissez cet onglet comme ceci avec le type connexion et passez sur le suivant.
Pour information, il existe différents types de sous-resource cible, ils auront une importance et seront utilisés par la suite :
Type de resource
Type de sous-resource
Quantité
Microsoft.DesktopVirtualization/workspaces
global
Un pour tous les déploiements Azure Virtual Desktop
Microsoft.DesktopVirtualization/workspaces
feed
Un par workspace
Microsoft.DesktopVirtualization/hostpools
connection
Un par pool d’hôtes
Renseignez le réseau / sous réseau de votre environnement Azure Virtual Desktop :
Pour votre information, plusieurs adresses IP privées seront alors allouées pour les services suivants :
Sur l’onglet suivant, une zone DNS privée va être créé pour le private endpoint :
Lancez la création puis attendez :
Une fois créé, la carte réseau du private endpoint nouvellement créé vous montre que chaque service dispose bien d’une adresse IP dédiée :
Important : Pour les gros environnement AVD, prévoir un second sous-réseau pour éviter un souci d’adressage.
Un redémarrage de machines virtuelles AVD plus tard : la connexion AVD depuis le poste client refonctionne sans souci :
Veuillez noter que la copie d’écran ci-dessus montre bien que le VPN d’Azure est toujours déconnecté. Cela montre bien que nous n’avons pas encore influencé la partie frontale du service AVD.
Pour bien comprendre ce qui s’est passé, un test intéressant est de
Créer un groupe de sécurité réseau (NSG)
Y ajouter une restriction d’accès au service publique d’Azure Virtual Desktop
L’associer au sous-réseau contenant les machines virtuelles AVD
Ce test créé une contrainte qui n’empêche pas notre test de fonctionner, car la connexion entre le service Azure Virtual Desktop et les machines AVD transite par le private endpoint nouvellement créé.
J’ai également fait un autre test de retirer le private endpoint. Les machines virtuelles AVD apparaissent alors bien comme étant injoignables pour le service Azure Virtual Desktop :
Maintenant, la seconde étape est de restreindre également l’accès au service Azure Virtual pour les postes connectés uniquement à internet.
Etape IIIa – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel
La première étape consiste donc à restreindre la communication entre le service AVD et les utilisateurs via internet. Pour cela, décochez la case suivante et sauvegardez :
Un nouvel essai de connexion à AVD nous montre le blocage immédiat de cette méthode en passant par internet :
Un rafraichissement de l’espace de travail AVD montre maintenant un refus d’affichage de celui-ci :
Pour terminer la configuration, nous avons besoin de créer deux autres private endpoints.
Pour cela, allez sur l’espace de travail AVD, allez dans la section réseau, décochez la case et sauvegardez :
Comme précédemment, commencez par créer un private endpoint comme ceci :
Nommez-le différemment du premier private endpoint créé durant l’étape précédente :
Choisissez cette fois-ci la sous-resource cible de type Feed :
Renseignez le réseau / sous réseau où votre environnement Azure Virtual Desktop :
Là encore, des adresses IP privées seront allouées pour les services suivants :
Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le second private endpoint, rattaché à votre espace de travail :
Lancez la création puis attendez :
Une fois créé, retournez sur la page d’Azure Virtual Desktop pour créer le troisième private endpoint de type Global.
Etape IIIb – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel
Microsoft conseille d’isoler ce private endpoint sur un espace de travail dédié au réseau. En effet, ce private endpoint unique de type Global pourrait service servir à tous les réseaux virtuels appairés.
Pour cela, créez un nouvel espace de travail AVD :
Nommez-le et lancez sa création :
Une fois créé, retournez-y, décochez là encore l’option réseau, puis sauvegardez.
Créez ici le troisième private endpoint et remplissez le premier onglet comme les 2 précédentes fois :
Choisissez le type de sous-resource cible Global :
Choisissez un réseau en relation directe avec votre environnement AVD :
Pour information, une adresse IP privée sera là-encore allouée pour le service suivant :
Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le troisième private endpoint, rattaché à ce nouvel espace de travail :
Lancez la création puis attendez :
Etape IV : Configuration du réseau on-premise
Pour que la connexion restreinte à Azure Virtual Desktop fonctionne bien, il est nécessaire d’apporter les enregistrements DNS créés précédemment sur le réseau on-premise.
Comme mon réseau on-premise est virtuellement créé sur Azure, j’ai choisi de créer une seconde zone DNS privée avec le même nom et de la rattacher à mon réseau on-premise :
Reprenez tous les enregistrements présents dans la zone DNS créée par les private endpoints.
Si comme moi votre réseau on-premise est dans Azure, associez cette zone DNS privée à celui-ci.
Etape V : Test de la connexion via Azure VPN Point à Site
Sur le poste on-premise de test, effectuez un premier test de connexion à l’URL d’Azure Virtual Desktop tout en ayant la connexion VPN de stoppée :
Constatez avant tout que la page n’est dorénavant plus joignable :
Démarrez votre connexion VPN grâce au client Azure VPN :
Recharger la page web du service Azure Virtual Desktop et renseignez vos identifiants de l’utilisateur de test :
Cliquez sur l’icône de bureau à distance :
Renseignez une seconde fois son mot de passe :
Et vus voilà dans votre session AVD !
Un test de déconnexion de la connexion VPN affectera immédiatement la session utilisateur d’AVD :
Réactiver la connexion VPN pour retrouver la session AVD.
Etape VI : Résumé des ressources Azure créées
Afin d’apporter plus de clarté à toutes ces opérations de déploiement, voici un récapitulatif du travail effectué dans cet article sur mon environnement Azure :
3 private endpoints :
3 cartes réseaux :
2 zones DNS privées :
1 second espace de travail AVD :
Etape VI : Aide à la résolution
Si l’installation s’est déroulée sans accro, mais que vous n’arrivez toujours pas à vous reconnecter à votre environnement Azure Virtual Desktop, voici quelques pistes qui peuvent vous aider :
Absence du premier private endpoint sur le pool d’hôtes AVD.
Connexion VPN non démarrée.
Authentification correcte, mais absence d’enregistrements DNS www, rdweb et client sur le réseau on-premise.
Authentification correcte, mais absence d’enregistrements DNS .rdweb sur le réseau on-premise.
Authentification correcte, mais absence d’enregistrements DNS gateway sur le réseau on-premise.
Conclusion
Par cette nouvelle fonctionnalité, Microsoft apporte encore plus de liberté dans la manière d’utiliser son environnement AVD, avec toujours plus d’exigences de sécurité. La possibilité de restreindre le service AVD à différents types de connexions sécurisées, comme les VPNs ou encore Azure ExpressRoute était attendue depuis longtemps.
Comme toujours, Dean de l’Azure Academy a préparé une vidéo très explicative de la mise en route ????
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 :
La conteneurisation applicative est accessible sur Azure Virtual Desktop depuis plusieurs mois. L’attachement via MSIX permet de fournir des applications à des machines virtuelles sans aucune installation locale. Cependant, Il est ici différent du format MSIX normal, car celui-ci est spécialement conçu pour AVD. Pour en savoir plus sur MSIX, consultez la page web Présentation de MSIX.
Pourquoi faire de la conteneurisation applicative pour Azure Virtual Desktop ?
Azure Virtual Desktop est principalement conçu pour délivrer une expérience utilisateur commune et partagée. Il arrive fréquemment que certains utilisateurs travaillent sur des applications spécifiques. Dans ce cas, il est possible de leur délivrer cet attendu de plusieurs manières :
Gestion de applications requises dans une image OS spécifiquement dédiée
Utilisation de solution de type Intune pour un déploiement distribué
Approvisionnement d’applications via des solutions tierces (Liquidware Flexapp, Citrix AppLayering)
Utilisation d’applications conteneurisées
Dans cet article, nous allons démontrer ensemble la dernière possibilité.
Etape 0 : Rappel des prérequis
Comme pour chaque déploiement réalisé sur ce blog, des prérequis sont nécessaires avant de pouvoir se concentrer sur MSIX AppAttach :
Un tenant Microsoft (AAD)
Une souscription Azure active
Un domaine Active Directory Domain Services (AD DS)
Un espace de stockage Azure joint au domaine AD DS
Un agent Azure AD Connect installé et synchronisé avec votre Azure AD
Un environnement Azure Virtual Desktop (Pool d’hôtes – Groupe d’application – Espace de travail – VMs)
Facultatif : un Azure Bastion pour faciliter les connexions RDP
Une fois votre environnement Azure en place, plusieurs étapes sont nécessaires pour arriver à la mise à disposition des applications conteneurisées.
Etape I : Déployer une nouvelle VM Azure Windows 10
Cette nouvelle machine virtuelle vous nous être utile pour créer différents composants nécessaires :
Création d’un certificat pour signature des packages MSIX
Création du package MSIX
Configuration des VMS AVD pour supporter la couche conteneur
Création de l’image VHD
Dépose de l’image VHD sur le partage de fichier
J’ai ici repris la même image Windows 10 que celle utilisée pour AVD.
Pas besoin d’adresse IP publique dans mon cas grâce à Azure Bastion.
Patientez quelques minutes une fois la création lancée :
Une fois cette VM créée, utilisez Azure Bastion pour vous connecter en RDP sur votre machine virtuelle :
Joignez cette machine virtuelle au domaine AD DS, puis redémarrez-là :
Etape II : Préparation du certificat
Reconnectez à votre VM MSIX via Azure Bastion, puis lancez Windows PowerShell ISE, en mode administrateur :
Exécutez la commande PowerShell suivante pour générer un certificat auto-signé sur votre domaine (JLOUDEV), et stockez le dans le dossier Personal des certificats locaux :
Exécutez certlm.msc pour ouvrir la console des certificats locaux :
Lancez la commande d’Export sur ce nouveau certificat :
Cliquez sur Suivant :
Sélectionnez l’option Oui, exporter la clé privée, puis cliquez sur Suivant :
Cochez la case Exporter toutes les propriétés étendues, décochez la case Activer la confidentialité des certificats, puis cliquez sur Suivant :
Cochez la case Mot de passe, renseignez les deux champs dessous, puis cliquez sur Suivant :
Créez un nouveau dossier, par exemple celui-ci :
C:\MSIX
Renseignez le chemin de destination, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser le processus :
Etape III : Déploiement du certificat sur les machines virtuelles AVD
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour déployer le certificat nouvellement généré dans Trusted People des machines virtuelles AVD :
Un tour rapide grâce à Azure Bastion sur une des machines virtuelles AVD nous confirme la bonne présence du certificat :
Etape IV : Téléchargements de l’application Mozilla Firefox
Dans notre démonstration, nous allons télécharger la dernière version de Mozilla Firefox. Nous prendrons l’installation au format MSI, disponible ici.
Lancez le téléchargement depuis la machine virtuelle MSIX comme ceci :
Copiez le fichier téléchargé dans le dossier C:\MSIX :
Etape V : Préparation avant création
Avant de lancer la création, exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour désactiver le service de recherche de Windows :
Pour continuer, vous aurez besoin de MSIX Packaging Tool, que vous trouverez dans le Microsoft Store. Lancez le téléchargement de ce dernier, toujours depuis la machine virtuelle MSIX :
Une fois le téléchargement terminé, lancez l’application.
Sur la page d’accueil, sélectionnez Application package afin de lancer la création d’un nouveau paquet :
Vous aurez peut-être besoin de redémarrer la machine pour continuer.
Sur la page suivante, cochez la case Créer le paquet sur cet ordinateur, puis cliquez sur Suivant :
Attendez l’installation du pilote de l’outil de conditionnement MSIX, puis cliquez sur Suivant :
Sélectionnez Parcourir pour accéder au fichier d’installation de Firefox au format MSI :
C:\MSIX\Firefox Setup 95.0.msi
Dans la liste déroulante Préférence de signature, sélectionnez Signer avec un certificat (.pfx).
Recherchez le certificat C:\MSIX\jloudev.tk.pfx, saisissez le mot de passe Demo!pass123, puis cliquez sur Suivant :
Examinez et modifiez si besoin le nom du paquet, vérifiez que le nom de l’éditeur est défini sur CN=JLOUDEV, puis cliquez sur Suivant :
Cela déclenche alors l’installation de Mozilla Firefox de manière encapsulée :
Une fois l’installation terminée, vous retrouvez le message ci-dessous, cliquez sur Suivant :
Cliquez alors sur Suivant.
Lorsque le système vous demande Avez-vous terminé ?, sélectionnez Oui :
Vérifiez dans l’écran ci-dessous qu’aucun service n’est nécessaire, puis cliquez sur Suivant :
Changez le fichier et le dossier de destination :
C:\MSIX\Firefox\Firefox
Une fois la création terminée, cliquez sur Fermer :
Retrouvez les fichiers MSIX et XML suivants dans votre dossier C:\MSIX\Firefox :
Copiez seulement le fichier MSIX dans le dossier racine C:\MSIX :
Etape VII : Installation des fonctionnalités d’Hyperviseur
Maintenant, vous allez activer la fonctionnalité d’Hyperviseur sur l’ensemble des machines virtuelles Azure Virtual Desktop, mais également sur la machine MSIX :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour commencer l’activation sur les VMs AVD :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour installer Hyper-V et ses outils de gestion sur les VMs AVD :
Chaque hôte AVD doit redémarrer pour prendre en compte les modifications : cliquez sur Oui :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour installer Hyper-V et ses outils de gestion sur la machine virtuelle MSIX :
La machine virtuelle MSIX doit elle aussi redémarrer :
Reconnectez-vous sur machine virtuelle MSIX, avec le même compte utilisateur qu’utilisé précédement :
Etape VIII : Créer une image jointe à une application MSIX
Ouvrez Microsoft Edge et rendez-vous sur la page suivante pour télécharger msixmgr.zip.
Dans l’Explorateur de fichiers, accédez au dossier Téléchargements, ouvrez le fichier compressé et copiez le dossier x64 dans le dossier C:\MSIX :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer le fichier VHD qui servira d’image jointe de l’application MSIX :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell IS, en mode administrateur , pour monter le fichier VHD nouvellement créé :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer une nouvelle partition, la formater, et lui attribuer la première lettre de lecteur disponible :
Cliquez sur Annuler pour ne pas formater à nouveau ce disque :
Le nouveau disque image est déjà présent dans l’explorateur de fichiers :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer une structure de dossier qui hébergera les fichiers MSIX :
Constatez la présences des fichiers dans le nouveau disque :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour démonter le fichier VHD qui servira d’image MSIX :
Etape IX : Configurer le groupe Active Directory contenant les hôtes AVD
Retournez sur votre contrôleur de domaine via Azure Bastion :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour créer un groupe AD DS qui sera synchronisé avec Azure AD :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour ajouter les machines virtuelles AVD en tant que membres du groupe que vous avez créé à l’étape précédente :
Ce nouveau groupe doit faire partie des synchronisations vers Azure AD. Pour cela, vérifiez dans votre configuration Azure AD Connect que cette OU est bien synchronisée :
Contrôlez après 30 minutes que le nouveau groupe remonte bien dans Azure AD :
Pour que les machines virtuelles Azure Virtual Desktop remontent bien dans ce groupe, il est nécessaire de reconfigurer également Azure AD Connect.
Retournez dans ce dernier pour activer la fonctionnalité Hybrid Azure AD Join :
Une fois les identifiants d’administrateur global renseignés, choisissez l’option ci-dessous :
Cochez la case pour remonter les machines Windows 10 et ultérieures :
Renseignez un compte Enterprise Administrator :
Une fois la configuration d’Azure AD Connect terminée :
Redémarrez les machines virtuelles AVD
Utilisez Azure Bastion pour vous connecter sur chaque VM AVD avec le compte avdadmin1@jloudev.tk
Retournez sur votre contrôleur de domaine via Azure Bastion (ou sur la machine virtuelle sur laquelle est installé Azure AD Connect), puis saisissez la commande PowerShell suivante en mode administrateur :
Start-ADSyncSyncCycle -PolicyType Initial
Attendez quelques minutes et contrôler la présence des machines virtuelles AVD dans le groupe AD sur Azure AD :
Etape X : Ajout des droits pour les VMs AVD sur le compte de stockage
Afin de mettre à disposition l’application packagée, nous allons créer un nouveau partage de fichier sur le compte de stockage existant.
Retournez sur votre portail Azure et rendez-vous sur le compte de stockage utilisé pour FSLogix :
Cliquez sur ce nouveau partage de fichier pour rajouter les 3 droits d’accès suivants :
Option
Valeur
Rôle
Storage File Data SMB Share Elevated Contributor
Assign access to
Group
Select
avd-admins
Option
Valeur
Rôle
Storage File Data SMB Share Elevated Contributor
Assign access to
Group
Select
avd-hosts
Option
Valeur
Rôle
Storage File Data SMB Share Reader
Assign access to
Group
Select
avd-group
Une fois les droits en place, retournez sur votre machine virtuelle MSIX avec le compte avdadmin1 via Azure Bastion, pour connecter ce nouveau partage de fichier grâce à la commande suivante :
$connectTestResult = Test-NetConnection -ComputerName jlosto.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
# Mount the drive
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\jlosto.file.core.windows.net\msixvhds" -Persist
} 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."
}
Exécutez les commandes suivantes via le programme CMD pour accorder les permissions NTFS requises :
Exécutez le script PowerShell suivant depuis votre fenêtre Windows PowerShell ISE, en mode administrateur, pour recopier le fichier VHD vers le partage de fichiers Azure :
Un contrôle dans l’explorateur de fichier nous permet de vérifier la bonne présence de ce dernier :
Etape XI : Ajout de l’application MSIX sur l’environnement Azure Virtual Desktop
On arrive presque au bout ! Il ne nous reste maintenant qu’à rajouter notre application MSIX sur notre pool d’hôtes Azure Virtual Desktop. Pour cela, retournez sur votre portail Azure et cherchez votre pool d’hôtes, cliquez sur MSIX packages, puis sur Ajouter :
Saisissez le chemin suivant pour chercher le package nouvellement généré :
Renseignez les champs ci-dessous de la façon suivante, puis cliquez sur Ajoutez :
Vérifiez la bonne présence de votre application dans l’écran des applications :
Rendez-vous maintenant dans la section groupe d’applications, puis cliquez sur Ajouter :
Renseignez un nom à votre groupe d’applications, puis cliquez sur Suivant :
Sur le second onglet, cliquez sur Ajouter des applications :
Renseignez les champs ci-dessous, puis cliquez sur Sauvegarder et passez à l’onglet suivant :
Ajoutez votre groupe d’utilisateurs AVD puis passez sur l’onglet suivant :
Reprenez votre espace de travail existant puis validez les derniers onglets pour lancer la création :
Quelques minutes plus tard, la création se termine :
Etape XII : Test du package MSIX
Pour cela rien de plus simple, ouvrez l’application Remote Desktop. Voici le lien vers la page Microsoft si vous avez besoin de la télécharger :
Une fois installée, cliquez sur Souscrire :
Renseignez les identifiants d’un utilisateur présent dans votre groupe d’utilisateurs AVD :
Décochez la case et cliquez sur Non :
Constatez la présence de l’icône de bureau à distance et du nouvel icône pour Firefox :
Cliquez sur Firefox et renseignez le mot de passe de l’utilisateur AVD :
Firefox s’ouvre bien comme une application publiée sur votre poste local !!!
Le petit icône spécial dans la barre des tâches vous montre bien qu’il s’agit d’une application publiée et non locale :
Conclusion
Félicitations ! Vous avez réussi votre premier package applicatif via MSIX sur votre environnement Azure Virtual Desktop. On ne va pas se mentir, les premières opérations de mise en place demandent de la vigilance. Mais à force de pratiquer, les choses deviennent plus simples. Nul doute que tout cela peut vous faire gagner un temp considérable dans la mise à jour des applications dans de larges environnements Azure Virtual Desktop.
Comme toujours, faites part de vos remarques dans les commentaires ????
Microsoft vient tout juste de l’annoncer en préview : vous pouvez maintenant gérer les identités d’un partage de fichiers Azure PaaS directement avec Azure AD !
C’est une excellente nouvelle, attendue depuis plusieurs mois par de nombreux utilisateurs d’Azure Virtual Desktop, notamment pour mettre en place des solutions comme FSLogix, déjà utilisée pour la gestion des profils utilisateurs, sans serveur AD DS. Par contre, il y a encore une petite mauvaise nouvelle :
Cette fonctionnalité nécessite actuellement que les utilisateurs aient des identités hybrides, gérées dans Active Directory.
Cette contrainte d’avoir un environnement hybride, qui sous-entend donc la présence d’un domaine AD, n’est pas forcément une mauvaise chose. Il s’agit ici d’une avancée technique intermédiaire. Nul doute que ce prérequis ne sera plus nécessaire à moyen terme.
Dans cet article, nous allons donc tester cette nouvelle fonctionnalité. Le but de tester cette préview de gestion des tickets Kerberos par Azure AD est de mesurer les avancées Microsoft. Vous pouvez suivre la documentation leur officielle ici.
Etape 0 : Rappel des prérequis
Comme vous allez travailler avec des tickets Kerberos spécifiques à Azure AD, il est obligatoire que les postes ayant accès au partage de fichiers PaaS disposent de l’un des OS suivants :
Windows 11 Enterprise mono ou multisession
Windows 10 Enterprise mono ou multisession, en version 2004 ou ultérieure avec la mise à jour KB5007253
Windows Server, version 2022 avec la dernière mise à jour KB5007254
Dans mon cas, j’ai utilisé l’environnement suivant :
une VM Windows Server 2022 pour jouer le contrôleur de domaine
Une environnement AVD composé de VMs en Windows 11 Enterprise multisession
Comme annoncé avant, les postes en accès au partage de fichier doivent donc être joints à Azure AD ou en mode hybride (Active Directory + Azure AD). Néanmoins, les utilisateurs doivent être « hybrides », il est donc nécessaire de passer par Azure AD Connect pour y arriver. Le choix du domaine managé Azure AD DS n’est donc pas possible ici :
Azure Active Directory Domain Services (Azure AD DS) : Azure AD DS fournit des services de domaine managé avec un sous-ensemble de fonctionnalités AD DS traditionnelles, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos/NTLM.
Active Directory Domain Services (AD DS) : serveur LDAP (Lightweight Directory Access Protocol) qui fournit des fonctionnalités clés telles que l’identité et l’authentification, la gestion des objets, la stratégie de groupe et les approbations.
Au final, les prérequis sont donc les suivants :
Un tenant Microsoft (Azure AD)
Des licences comprenant Windows 10 Entreprise pour vos utilisateurs AVD
Une souscription Azure active avec le rôle de propriétaire :
Un domaine Active Directory Domain Services (AD DS) :
Etape II : Configuration de l’authentification Azure AD
Vous allez utiliser plusieurs nouvelles fonctionnalités, il est donc préférable de réinstaller des modules PowerShell sur votre poste. Ouvrez PowerShell ISE en mode administrateur et lancez la commande suivante :
Cette clef n’est pas contre pas visible sur le portail Azure.
Etape III : Création d’une identité principal de service
L’activation des droits d’Azure AD sur le compte de stockage n’est pas encore possible via le portail Azure. Commencez par générer un mot de passe, basé sur la nouvelle clef Kerberos de votre compte stockage, et stocker le dans une variable grâce à la commande PowerShell suivante :
Etape IV : Définir les autorisations API sur l’application nouvellement créée
Comme indiqué dans la documentation Microsoft, la suite du processus peut se faire dans le portail Azure. Ouvrez votre portail Azure Active Directory :
Dans vos Enregistrement d’applications, cliquez sur Toutes les applications, puis enfin sélectionnez l’application dont le nom correspond à votre compte de stockage :
Dans les autorisations API dans le volet de gauche, ajoutez une autorisation comme ceci :
Sélectionnez Microsoft Graph, puis choisissez délégation des permissions :
Dans la section OpenID, sélectionnez Profile :
Descendez plus bas dans la liste pour retrouver la section User. Cochez alors User.Read et cliquez sur Ajouter :
Une fois sur retourné sur l’écran des permissions, cliquez ci-dessous pour ajouter le consentement global à tout votre tenant :
Constatez la bonne application de celui-ci grâce au statut à droite :
Etape V : Création du partage de fichier
Retournez sur votre compte de stockage pour créer un nouveau partage de fichier comme ceci :
Etape VI : Jointure du partage de fichier Azure au domaine Active Directory
Pour l’instant, le partage de fichier Azure nécessite encore l’attribution de droits RBAC aux utilisateurs Azure Virtual desktop. Dans votre cas cette fonctionnalité nécessite d’activer l’authentification AD DS sur le compte de stockage.
Commencez par télécharger sur GitHub la version la plus récente du module PowerShell AzFilesHybrid.zip :
Décompressez les fichiers sur le disque C sur une VM, jointe à votre domaine :
Démarrez Windows PowerShell ISE en tant qu’administrateur et exécutez ce qui suit pour supprimer le flux de données alternatif Zone.Identifier, qui a une valeur de 3, indiquant qu’il a été téléchargé à partir d’Internet :
Vous pouvez aussi contrôler la bonne activation sur le compte de stockage :
Restez sur votre compte de stockage pour assigner le rôle Storage File Data SMB Share Contributor à votre utilisateurs Azure Virtual Desktop :
Dans notre démonstration, nous allons seulement autoriser le groupe d’utilisateurs Azure Virtual Desktop.
Etape VII : Attribution des autorisations
Pour empêcher les utilisateurs d’accéder aux profils utilisateurs d’autres utilisateurs, vous devez également attribuer des autorisations au niveau du répertoire.
Le système que vous utilisez pour configurer les permissions doit répondre aux exigences suivantes :
La poste a une version de Windows répond aux exigences des systèmes d’exploitation des prérequis
Le poste doit être joint à Azure AD ou à Hybrid Azure AD à Azure AD
Le poste est relié au contrôleur de domaine
Installez ou importez si besoin sur le poste le module PowerShell ActiveDirectory. Dans mon cas, je n’ai pas eu à faire cette opération car j’ai tout exécuté depuis mon contrôleur de domaine :
Import-module ActiveDirectory
Azure AD ne prenant pas actuellement en charge la configuration des listes de contrôle d’accès dans Shell, il doit s’appuyer sur Active Directory. Pour configurer Shell sur votre compte de stockage, exécutez la commande suivante dans PowerShell ISE en tant qu’administrateur :
Lancez enfin la commande net use pour monter le lecteur réseau et vérifiez le bon fonctionnement :
net use Z: \\jloaadjoin2.file.core.windows.net\avdfileshare
Il arrive par moment que la commande échoue la première fois.
On retrouve bien le disque réseau dans l’explorateur Windows :
En retournant sur les tickets Kerberos, un nouveau CIFS a fait son apparition :
Etape IX : Configuration de FSLogix
Une fois l’architecture en place, on peut combiner cette dernière pour la gestion des profils utilisateurs via FSLogix. Pour cela, il nous faut rajouter la configuration FSLogix et une règle de registre en plus pour Azure AD.
L’ouverture d’une nouvelle session utilisateurs d’AVD vous affiche bien la mention FSLogix :
Un tour dans le partage de fichier du compte de stockage montre bien la présence du dossier du profil utilisateur géré par FSLogix :
Conclusion
La gestion des tickets Kerberos par Azure AD est une belle avancée. Bien évidemment, le processus de prise en charge complète d’un compte de stockage de manière native n’est pas encore là, mais nous y sommes en bonne voie ???? Comme à chaque fois, n’hésitez pas à utiliser les commentaires pour exprimer de vos retours ????
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 :
L’algorithme du pool d’hôtes n’a pas d’importance car le plan d’autoscaling dispose de sa propre option.
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 :
Merci à Seyfallahpour cette explication très claire ????.
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 :
Le champ dédié au TAG exclu permet de « sortir » des VMs du plan d’autoscaling.
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 % :
La répartition des utilisateurs se fait bien selon l’algorithme Breadth-first.
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 :
Ce chrono et le message indiqué ici est paramétré dans le plan d’autoscaling.
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é.
