AVD Solo : Start and Stop !

Azure Virtual Desktop est souvent associé aux environnements mutualisés. Mais on oublie souvent qu’AVD propose également à des environnements individuels, comme peut aussi le faire Windows 365. Comme toujours, les produits estampillés Azure apportent de la flexibilité dans la configuration et des optimisations possibles. Par exemple, des machines virtuelles équipées de puissantes cartes graphiques.

Aujourd’hui, Azure Virtual Desktop continue d’évoluer et propose maintenant l’arrêt automatique des VMs pour les environnements individuels.

En effet, il est déjà possible depuis un certains de temps faire automatiquement démarrer la machine virtuelle AVD d’utilisateur quand celui-ci s’y connecte. Cela s’appelle le Start on connect et j’en avait déjà parlé juste ici. Bien pratique et facile à configurer, cette fonction avait pour défaut de ne jamais arrêter la VM quand l’utilisateur n’en avait plus besoin.

Rappelons-le : une machine virtuelle éteinte au niveau OS continue de coûter de l’argent car des ressources Azure lui sont toujours allouées.

Des parades existent déjà depuis quelques temps déjà, mais elles nécessitent bien souvent une configuration annexe :

J’avais d’ailleurs écrit un article sur ce sujet. Mais depuis, les choses se compliquent car certaines fonctionnalités des comptes Azure Automation vont bientôt être dépréciées…

Bref, je suis bien content que Microsoft ait rajouté cette fonctionnalité d’arrêt automatique des VMs dans Azure Virtual Desktop.

Qu’est-ce que la mise à l’échelle automatique ?

La mise à l’échelle automatique vous permet d’effectuer un scale-up ou un scale-down de vos hôtes de session de machines virtuelles dans un pool d’hôtes pour optimiser les coûts de déploiement.

Microsoft Learn

La mise à l’échelle automatique, ou autoscaling, est déjà disponible pour les environnements AVD mutualisés. Un autre article en parle juste ici.

Comme indiqué dans le titre, la grande nouveauté concerne les environnements AVD individuels. La documentation Microsoft en parle déjà : la mise à l’échelle automatique pour les pools d’hôtes individuels est actuellement en préversion.

Voici donc un petit exercice pour tester cette fonctionnalité :

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

Pour déployer un environnement AVD, commencez par déployer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail d’Azure et utilisez la barre de recherche :

Renseignez tous les champs, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création de votre réseau virtuel :

Attendez environ une minute que le déploiement se termine :

Utilisez encore une fois la barre de recherche Azure pour créer votre environnement AVD :

Cliquez-ici pour créer un nouvel environnement AVD :

Renseignez tous les champs en prenant soin de choisir un type d’environnement individuel :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Renseignez les champs liés aux machines virtuelles AVD de votre environnement :

Choisissez la taille et le nombre de VMs AVD, ainsi que le réseau virtuel créé précédemment :

Dans notre environnement, une jointure des VMs à Azure Active Directory suffira. N’oubliez pas de joindre également vos VMs à Intune pour terminer cet exercice, puis cliquez sur Suivant :

Renseignez les champs pour créer un espace de travail AVD, puis lancez la validation Azure :

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

Une fois le déploiement terminé, cliquez-ici pour terminer la configuration de votre AVD :

Cochez l’option pour activer le SSO sur Azure Virtual Desktop. Cela évite de devoir s’authentifier deux fois pour arriver sur le bureau de la VM AVD :

Afin de pouvoir tester notre environnement AVD, il est nécessaire de rajouter des rôles à nos utilisateurs de test :

  • Desktop Virtualization User
  • Virtual Machine User Login

Enfin, mon environnement AVD de test nécessite d’assigner des utilisateurs aux VMs AVD. Pour cela, rendez-vous sur cet écran pour les assigner manuellement :

Comme je dispose de 2 VMs dans mon environnement AVD, j’ai assigné à chacune d’entre-elles un utilisateur de test :

Vérifiez que les machines virtuelles sont bien présentes et disponibles :

Ouvrez le client Remote Desktop, ou installez-le depuis ce lien si cela n’est pas encore le cas :

Utilisez la fonction suivante pour faire apparaître les machines AVD :

Vous pouvez répéter cette opération avec votre second utilisateur de test :

Cliquez sur l’icône de bureau à distance :

Authentifiez-vous une seconde fois pour activer la fonction SSO :

Autorisez-les connections de bureau à distance à partir de l’identité Azure AD de votre utilisateur de test :

Attendez que le bureau à distance Windows 11 s’ouvre :

Une fois la session AVD ouverte, fermez cette dernière en utilisant la déconnexion habituelle de Windows :

Votre environnement AVD est prêt et fonctionnel. Notre objectif est maintenant d’ajouter la fonction d’allumage et d’extinction automatique des VMs.

Etape II – Configuration de l’allumage et de l’extinction automatique :

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

Ajoutez le rôle RBAC suivant au niveau du groupe de ressources Azure contenant votre environnement AVD :

Retournez dans le menu Azure Virtual Desktop afin d’ajouter le scaling plan qui pilotera les VMs individuelles selon les besoins de connexion, puis cliquez sur Créer :

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

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

Sélectionnez les jours de la semaine correspondant à vos besoins, puis cliquez sur Suivant :

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

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

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

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

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

Cliquez sur Suivant pour continuer :

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

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

Attendez quelques minutes que la configuration soit déployée :

Votre environnement individuel AVD est enfin géré par un planning de démarrage et d’arrêt automatique.

Nous allons maintenant effectuer différents tests pour voir le comportement d’Azure Virtual Desktop d’un point de vue utilisateur.

Etape III – Test de l’allumage et de l’extinction automatique :

Dans mon environnement de démonstration AVD, les machines virtuelles individuelles sont bien arrêtées.

Test A – Fermeture de la session utilisateur en Phase 1 :

A 9h22, j’ouvre un navigateur web afin de me rendre sur la page de connexion AVD. Une fois authentifié avec un utilisateur de test, j’ouvre une session de bureau à distance :

Comme la machine virtuelle affectée à cet utilisateur est arrêtée, Azure Virtual Desktop la démarre et ce message s’affiche :

Le statut de la machine virtuelle change bien dans Azure :

Une fois la machine démarrée, le message d’attente change également :

Peu après, le bureau virtuel Windows apparaît bien. Je décide donc d’effectuer une fermeture de session Windows par le menu Démarrer :

Environ 15 minutes plus tard, la machine virtuelle retrouve bien son précédent état :

Le premier test est concluant. Effectuons maintenant un second test en ne fermant pas la session AVD, mais en utilisant la croix pour simuler une déconnexion :

Test B – Déconnexion utilisateur en Phase 2 :

J’ouvre à nouveau une session de bureau à distance :

Comme la machine virtuelle affectée s’était précédemment arrêtée, Azure Virtual Desktop est obligé de la redémarrer à nouveau :

Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :

Peu après, le bureau virtuel Windows apparaît bien. Je décide donc déconnexion de la session par la croix, en haut de la fenêtre AVD :

La session est bien marquée comme déconnectée dans l’écran de contrôle du pool d’hôtes AVD :

A 10h56, la VM est déjà éteinte depuis quelques temps :

Cette information est confirmée par le journal d’audit de la machine virtuelle :

Les fonctions de déconnexion de l’utilisateur et de fermeture de session sont bien prises en compte dans le processus d’arrêt des machines virtuelles par Azure Virtual Desktop.

Prenons maintenant le temps de vérifier le respect des paramétrages renseignés dans la configuration.

Test C – Fermeture de la session utilisateur en Phase 3 :

A 11h01, j’ouvre à nouvelle fois une session Windows :

Encore une fois, Azure Virtual Desktop est obligé de redémarrer la machine virtuelle de l’utilisateur :

Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :

Je décide donc d’effectuer à nouveau une fermeture de session Windows par le menu Démarrer :

A 11h25, soit exactement 20 minutes après la fermeture de session, la machine virtuelle AVD change de statut pour s’éteindre :

Cela confirme bien le paramétrage de temps renseigné dans cette phase :

Je décide de continuer mon test en vérifiant mon raisonnement en phase 4, dans laquelle j’ai configuré un arrêt de la VM seulement 5 minutes après la fermeture ou déconnexion de la session.

Test D – Fermeture de la session utilisateur en Phase 4 :

A 12h01, j’ouvre à nouvelle fois une session Windows :

Encore une fois, Azure Virtual Desktop est obligé de redémarrer la machine virtuelle de l’utilisateur :

Le statut de la machine virtuelle rechange bien une nouvelle fois dans Azure :

Je décide donc d’effectuer à nouveau une fermeture de session Windows par le menu Démarrer :

A 12h08, soit exactement 5 minutes après la fermeture de session, la machine virtuelle AVD change de statut pour s’éteindre à nouveau :

Cela confirme bien le respect du paramétrage selon la phase dans laquelle l’utilisateur se trouve :

Le paramétrage de démarrage et d’arrêt des machines virtuelles individuelles AVD fonctionne bien.

Afin d’aller plus loin dans le test, je décide d’y intégrer une session de déconnexion des sessions inactives, passé un certain temps.

Pour cela, je vais utiliser Intune pour déployer une police de configuration Windows sur les sessions de bureau à distances inactives.

Etape IV – Configuration log off Windows via Intune :

Afin de déployer une configuration Intune, démarrez les machines virtuelles AVD via la fonction suivante :

Sur la page d’Azure AD, créez un nouveau groupe et ajoutez-y les machines virtuelles AVD :

Rendez-vous dans la console Intune afin de créer un nouveau profil de configuration Windows comme ceci :

Choisissez le type de profil suivant, puis cliquez sur Créer :

Nommez votre profil de configuration, puis cliquez sur Suivant :

A droite, recherchez l’option suivante afin de l’ajouter et de la configurer sur la partie gauche de l’écran, puis cliquez sur Suivant :

Les Tags ne sont pas utilisés dans notre test, cliquez sur Suivant :

Ajoutez le groupe précédemment créé et contenant les machines virtuelles AVD, puis cliquez sur Suivant :

Vérifiez une dernière fois les options de votre profil de configuration, puis cliquez sur Créer :

Attendez environ 15-30 minutes que le profil de configuration soit bien déployée sur vos VMs AVD :

Ma configuration Intune et maintenant en place. Maintenant, nous allons pouvoir tester la combinaison des deux configurations.

Test E – Combinaison AVD + Intune :

Rouvrez une nouvelle fois une session AVD :

Comme la machine virtuelle AVD est déjà démarrée, la session s’ouvre bien plus rapidement :

Environ 15 minutes plus tard et sans avoir rien fait, un premier message d’avertissement apparaît sur la session AVD m’indiquant que la session sera déconnecté dans environ 2 minutes :

Environ 2 minutes plus tard et n’ayant toujours rien touché, le message suivant apparaît :

Là encore, la session est bien marquée comme déconnectée dans l’écran de contrôle du pool d’hôtes AVD :

Environ 5 minutes après la déconnexion de la session, la machine virtuelle AVD change encore de statut pour s’éteindre une nouvelle fois :

Cette dernière démonstration montre bien la combinaison habille entre la nouvelle fonctionnalité AVD et la configuration Windows installée via une police de configuration Intune.

Conclusion :

Comme toujours, les nouveautés sur Azure Virtual Desktop font plaisir. Elles sont pratiques et vous ferons gagner du temps dans la configuration et dans la mise en place.

Voici d’ailleurs quelques une des dernières nouveautés AVD que j’ai pu tester récemment :

Bonne lecture 😎

Bodybuildez votre AVD !

Azure Virtual Desktop n’en finit plus d’évoluer ! Aujourd’hui est une grande journée pour l’automatisation des environnements AVD. Jusqu’à présent, Azure proposait peu de solutions adéquates pour AVD pour faciliter le processus de gestion des images des VMs. Pour enfoncer le clou(d), d’autres solutions tierces faisaient déjà mieux et rendaient le travail IT beaucoup plus léger.

Microsoft vient donc de sortir une nouvelle fonctionnalité à son produit AVD, encore en préversion à ce jour, mais attendue depuis fort longtemps : Custom image templates, ou Modèles d’images personnalisés pour les francophones.

Aucun doute que les administrateurs d’AVD vont aimer !

Pourquoi doit-on gérer des images avec Azure Virtual Desktop ?

La gestion des applications et des mises à jour d’un environnement AVD reste très proche d’un environnement RDS traditionnel. De temps à autre, il vous faut penser à :

  • Les applications doivent être mises à jour
  • Les mises à jour correctives ou sécuritaires doivent être appliquées
  • Les besoins logiciels des utilisateurs évoluent
  • De nouvelles optimisations sont disponibles

Toutes ces raisons et encore d’autres font que les machines virtuelles d’un environnement Azure Virtual Desktop doivent être mises à jour régulièrement, et si possible, avec un mode opératoire le plus automatisé.

Que proposait Azure Virtual Desktop avant cette fonctionnalité ?

En cherchant un peu, on retrouvait déjà plusieurs méthodes qui avaient déjà fait leurs preuves :

  • Gestion 100% manuelle via Golden Image / Sysprep / Snapshot :
  • Gestion 50% manuelle via l’utilisation d’un Template d’Azure Image Builder :
  • Solutions tierces, comme par exemple la très connue Nerdio :

Sur quoi repose la fonction Custom image templates d’AVD ?

Disons-le tout de suite, Custom image templates fonctionne toujours avec Azure Image Builder.

Mais tout est maintenant intégré dans la console Azure Virtual Desktop. Et le meilleur dans tout ça :

l’intégration d’optimisations est gérée dans le template, qu’elles soient préconstruites par Microsoft ou créées par vos soins !

C’est tout le processus de préparation qui peut alors s’intégrer dans la seule étape de création du template. Fini les aller et retours !

Bref, ne perdons pas de temps, et testons ensemble cette fonctionnalité.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les templates d’Azure Virtual Desktop, encore en préversion, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de ne pas rendre cet article trop long, j’ai déjà préparé un environnement Azure. Je vous liste dans l’étape suivante tous les composants déjà mis en place sur mon environnement avant de démarrer le test.

Etape I – Préparation de votre environnement Azure Virtual Desktop :

J’ai créé un premier groupe de ressources Azure, dans lequel j’ai déployé 2 VMs :

  • Une première machine virtuelle Windows Server avec des rôles AD DS / DNS
  • Une seconde machine virtuelle Windows Server avec Azure AD Connect

J’ai également déployé dans un second groupe de ressources pour :

  • Un réseau virtuel pour l’ensemble de mon infrastructure AD DS / AVD :
  • Un service Azure Bastion pour me connecter aux différentes machines de mon domaine

Dans ce réseau virtuel Azure, nous retrouvons les sous-réseaux suivants :

  • Sous-réseau pour la partie domaine / Azure AD Connect
  • Sous-réseau pour les machines virtuelles AVD
  • Sous-réseau dédié au service Azure Bastion

Je n’ai pas oublié non plus de renseigner l’adresse IP locale de mon AD en tant que DNS de premier niveau sur mon réseau virtuel :

J’ai également déployé une Azure Compute Gallery, dans laquelle se trouvent une définition de base d’une image pour mon environnement AVD :

Grâce à la mise en place du domaine Active Directory et d’Azure AD Connect, j’ai pu synchroniser deux utilisateurs AD vers Azure AD :

J’ai également créé un compte de stockage Azure. Grâce à la tâche 6 de cet article, j’ai configuré ce compte de stockage pour être joint à mon Active Directory.

J’ai également créé un partage de fichier pour la gestion des profiles en itinérance via FSLogix :

Je n’ai pas oublié de rajouter les rôles Azure RBAC spécifiques au partage SMB FSLogix :

J’ai également transposé ces droits Azure RBAC en droits NTFS sur ce même partage FSLogix :

J’ai enfin vérifié, au niveau de ma souscription Azure, le bon enregistrement des fournisseurs de ressources suivants :

  • Microsoft.VirtualMachineImages
  • Microsoft.KeyVault

Si cela n’est pas fait, voici la procédure qui vous prendra à peine deux minutes :

Votre environnement de départ est enfin prêt pour commencer la mise en place de Modèles d’images personnalisés pour AVD.

L’étape suivante est donc consacré à la mise en place d’une identité managée pour Azure VM Image Builder.

Etape II – Azure VM Image Builder :

VM Image Builder est un service Azure complètement managé qui est accessible aux fournisseurs de ressources Azure. Les fournisseurs de ressources le configurent en spécifiant une image source, une personnalisation à effectuer et l’emplacement où la nouvelle image doit être distribuée.

Microsoft Learn

Pour que Azure VM Image Builder gère des images AVD, il est nécessaire de lui créer une identité managée Azure. Celle-ci disposera des autorisations nécessaires pour lire et écrire des images :

Microsoft.Compute/images/write
Microsoft.Compute/images/read
Microsoft.Compute/images/delete
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/images/read
Microsoft.Compute/galleries/images/versions/read
Microsoft.Compute/galleries/images/versions/write

Au niveau de votre souscription Azure, rendez-vous dans le menu suivant pour commencer la création d’un rôle personnalisé :

Donnez-lui un nom, puis cliquez sur Suivant :

Parcourez la liste des permissions disponibles afin d’ajouter celles ci-dessous :

Dean met aussi à disposition sur son GitHub un template JSON contenant ces permissions.

Définissez le périmètre de la souscription Azure pour ce nouveau rôle :

Lancez la création en cliquant sur Créer :

Sur votre portail, recherchez dans la barre du haut le services des Identités Managées :

Cliquez-ici pour créer votre Identité Managée dédiée à Azure VM Image Builder :

Nommez celle-ci, puis lancez la validation :

Une fois la validation passée, cliquez sur Créer :

Retournez au niveau de la souscription Azure pour assigner le rôle personnalisé à votre nouvelle identité managée :

Recherchez le rôle personnalisé en utilisant le filtre :

Cliquez ici pour rechercher dans Azure AD votre nouvelle identité managée :

Lancez la validation de votre affectation :

Une fois la validation passée, cliquez sur Assigner :

Toutes les étapes préparatoires à la création d’un modèle d’image personnalisé sont maintenant terminées. Nous allons pouvoir maintenant commencer la création de notre template AVD.

Comme le rappelle Dean durant sa vidéo, d’autres options seront prochainement rajoutées par la suite.

Etape III – Création d’un modèle d’image personnalisé :

Recherchez le service Azure Virtual Desktop en utilisant la barre du haut :

Dans le menu Modèle d’image personnalisés, cliquez-ici pour ajouter votre premier template :

Nommez votre template, choisissez sa localisation, reprenez l’identité managée créée et affectée précédemment, puis cliquez sur Suivant :

Comme il s’agit de votre premier template, cliquez sur Non à la question d’importation :

Sélectionnez votre image source, en utilisant par exemple la Marketplace Microsoft :

Attention à la génération rattachée à votre Image.
Celle-ci devra également utiliser des tailles de VM compatibles.

Concernant le stockage de votre template AVD, deux destinations sont possibles avec Azure VM Image Builder :

  • Image managée : utilisable pour AVD ou Windows 365
  • Azure Compute Gallery : utilisable pour AVD

Cochez la cible Azure Compute Gallery, renseignez les informations nécessaires, puis cliquez sur Suivant :

L’option Latest sera un choix intéressant pour positionner l’image en dernière version à déployer.

Azure VM Image Builder a besoin de quelques informations durant le processus de fabrication :

  • Timeout : à définir si besoin. Si vide, alors 240 minutes
  • Taille de la VM : taille sans rapport direct avec les futures VMs AVD
  • Taille du disque OS : taille avec rapport direct sur celui des futures VMs AVD
  • Groupe de ressources temporaire : Si laissé vide, le groupe sera créé par Azure
  • Réseau Virtuel : champs facultatifs

Puis cliquez sur Suivant :

Azure VM Image Builder vous propose d’exécuter à votre place des traitements post-déploiement. Vous pouvez lancer vos propres scripts, ou piochez dans la longue liste mise à disposition par Microsoft.

Cliquez-ici pour ajouter votre propre script, si besoin :

Cliquez-ici pour consulter la liste des scripts dédiés à AVD et construits par Microsoft :

Choix dans la liste les options voulues, puis sauvegardez :

Vérifier une dernière fois les options choisies, puis cliquez sur Suivant :

Ajoutez les étiquettes pour une meilleure classification de vos ressources Azure, puis cliquez sur Suivant :

Lancez la création de votre template en cliquant sur Créer :

Environ quelques secondes plus tard, le processus de création du template se lance, le statut passe alors en Création :

La création d’un template est assez rapide, le statut doit alors changer en Succès et le nom du groupe de ressources temporaire doit apparaître.

Cliquez dessus pour voir la première ressource créée :

Seul un compte de stockage est pour l’instant créé, cliquez dessus :

Un premier conteneur Blob est créé, dans lequel se trouvent les optimisations de votre template AVD :

Retournez sur les Modèles d’images personnalisés, puis cliquez sur le groupe de ressources de votre template :

Constatez la présence de votre template :

Le template, ou la recette de votre VM AVD, est maintenant prêt. Un second processus doit être lancé pour créer l’image AVD en elle-même. Azure VM Image Builder va réaliser les actions suivantes :

  • Créer une machine virtuelle à partir de la marketplace
  • Lui appliquer votre configuration personnalisée
  • La capturer et la stocker dans votre Azure Compute Gallery

Etape IV – Préparation de l’image AVD :

Ce processus peut prendre beaucoup de temp. Celui-ci dépendra également des personnalisations choisies à appliquer.

Cliquez-ici pour démarrer le processus de construction de votre image :

Le statut de construction change comme ceci :

Deux nouveaux conteneurs sont créés sur votre compte de stockage temporaire :

  • packerlogs : Journal d’évènements d’Azure VM Image Builder
  • vhds : fichier VHD de votre image créé par Azure VM Image Builder

Cliquez sur le premier conteneur afin de consulter, si besoin, le journal de log d’Azure VM Image Builder :

Rafraichissez cette page afin de voir le changement de statut :

Rafraichissez également cette seconde page afin de voir les changements de date de modification du journal d’évènements :

Environ 2 heures plus tard, le statut est enfin passé à Succès :

Vérifiez que la définition de votre image est bien stockée dans votre Azure Compute Gallery :

La version de l’image est également visible dans le groupe de ressources cible :

Notre image est enfin prête à intégrer un environnement Azure Virtual Desktop.

L’étape suivante consiste donc à créer un premier pool AVD en choisissant comme source cette nouvelle image personnalisée.

Etape V – Création de l’environnement AVD :

Sur la page Azure Virtual Desktop, commencez la création de votre environnement Azure Virtual Desktop comme ceci :

Définissez les options de base de votre pool d’hôtes :

Ajoutez une ou plusieurs machines virtuelles en prenant le soin de choisir l’image créée et stockée dans votre Azure Compute Gallery :

Renseignez les informations réseaux pour que votre VMs AVD se trouve sur le même réseau virtuel que votre AD :

Renseignez les informations liées à votre AD et les identifiants pour disposer d’un compte administrateur local, puis cliquez sur Suivant :

Créez un nouvel Espace de travail, puis lancez la validation :

Une fois la validation terminée, cliquez sur Créer :

Attendez environ 5 à 10 minutes, le temps que la création de votre environnement AVD se termine, puis cliquez ici :

Changez l’option d’authentification d’Azure AD, puis sauvegardez :

Cliquez sur le groupe d’applications AVD :

Ajoutez vos utilisateurs ou votre groupe d’utilisateurs de test :

C’est enfin fini ! Toutes les configurations sont faites ! Il ne vous reste plus qu’à tester votre nouvel environnement Azure Virtual Desktop.

Etape VI – Test de connexion à votre environnement AVD :

Pour cela, utilisez le client Remote Desktop disponible ici, ou l’URL suivante pour une connexion en HTLML5 via le navigateur internet.

Ouvrez votre application, souscrivez à un nouvel espace de travail, puis authentifiez-vous avec un compte utilisateur de test :

Réauthentifiez-vous une seconde fois, localement :

Attendez que la session de bureau à distance s’ouvre :

Vérifiez quelques paramétrages personnalisés, comme la langue ou les applications installées :

Les choses semblent pas mal pour moi sauf le pays et encore l’heure de la VM :

Vérifiez également sur votre compte de stockage dédié à FSLogix que l’ouverture de session AVD génère bien la création d’un profil itinérant :

On peut dire qu’on est pas mal, non ? 😎

Conclusion :

L’intégration Azure VM Image Builder dans la console Azure Virtual Desktop, mais aussi l’ajout direct de personnalisations, proposées par Microsoft, est un véritable pas en avant concernant la simplification !

Azure Virtual Desktop conserve malgré tout la caractéristique de pouvoir être personnalisé manuellement, mais apporte en parallèle une couche d’automatisme pour les petits environnements.

Nul doute que tout cela sera très fortement apprécié !

Allégez vos profils FSLogix !

Dans la plupart des environnements Azure Virtual Desktop, la gestion des profils utilisateurs est gérée grâce à la solution FSLogix. Pour rappel, FSLogix est une solution Microsoft très performante dans la gestion des profils utilisateurs Windows dans les environnements VDI. Azure Virtual Desktop est d’ailleurs le bon exemple, vous pouvez retrouver un article sur sa mise en place juste ici.

Bien souvent, il sera nécessaire d’effectuer par moment des opérations de routine, comme les mises à jour FSLogix, mais aussi dans sa configuration ou encore dans son stockage. En effet, les profils ont tendance à grossir avec le temps. Pour y remédier, plusieurs pistes existent, dont la redirection du cache.

Microsoft en parle d’ailleurs dans deux articles de Microsoft Learn :

Qu’est-ce que la redirection FSLogix ?

Un profil utilisateur contient de la donnée brute, mais aussi de la donnée de cache, issue d’un stockage externe, comme les outils 365. Pour faire simple, les produits comme OneDrive, Teams, Exchange, … stockent vos données dans le Cloud, et en copient une partie sous forme de cache local, pour des questions de performances VDI.

Les profils utilisateurs ont donc tendance à conserver ce cache et grossir avec le temps. FSLogix propose donc de faire de la redirection ciblée de ce cache pour alléger le profil utilisateur :

FSLogix redirections.xml fournit des fonctionnalités qui permettent d’exclure certaines parties du profil d’un utilisateur du conteneur d’un utilisateur

Microsoft Learn

Dans cet article, nous allons prendre de temps de tester deux configurations FSLogix (avec / sans la redirection) afin de mesurer le gain d’espace en résultant.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur FSLogix , il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Déploiement du domaine managé Azure AD DS :

Il est possible d’effectuer ce test avec un domaine Active Directory ou via le service managé Azure AD DS. N’oubliez pas qu’il est pas encore possible de faire du roaming profile uniquement basé sur Azure AD, car l’intégration d’un compte de stockage Azure nécessite encore et toujours un environnement hybride.

Dans mon cas, j’ai choisi de déployer un Azure AD DS, que vous retrouvez dans le menu suivant :

Configurez-le de manière avant de pouvoir le déployer :

Lancez le déploiement, puis attendez une bonne heure que la configuration se termine entièrement :

Une fois le service Azure AD DS entièrement déployé, pensez à corriger les serveurs de DNS sur votre réseau virtuel Azure :

Profitez-en pour créer d’autres sous-réseaux selon les besoins de votre test :

Déployez également un Azure Bastion afin de vous connecter plus facilement sur les machines virtuelles Azure sans ouvrir de port RDP :

Complétez tous les champs pour créer votre Azure Bastion sur votre réseau virtuel :

Une fois la validation passée, cliquez sur Créer :

Afin de configurer notre domaine AD et de créer des GPOs FSLogix, nous allons avoir besoin d’une machine virtuelle de management.

En effet, les machines gérant le service Azure AD DS ne vous sont pas accessible. Rien ne nous empêche de gérer votre domaine grâce à une autre machine virtuelle disposant des fonctionnalités adéquates.

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

N’attendez pas la fin de la création d’Azure Bastion pour créer votre machine virtuelle sur Azure. Un article dédié à la création de votre première machine virtuelle se trouve juste ici.

Renseignez tous les champs du premier onglet, puis cliquez sur Suivant :

Sur le second onglet, cliquez sur Suivant :

Reprenez votre réseau virtuel déjà en place, choisissez le bon sous-réseau, retirez l’adresse IP publique inutile, puis lancez sa création :

N’attendez pas la fin de la création de votre machine virtuelle de management pour créer un premier compte de stockage.

Etape III – Créations de deux comptes de stockage :

Le compte de stockage va vous servir pour stocker les profils FSLogix.

Cliquez-ici pour commencer sa création :

Donnez-lui un nom unique, les autres caractéristiques importent peu pour notre test, puis cliquez sur Suivant :

Cliquez sur Suivant pour passer au troisième onglet :

Restreignez l’accès public en spécifiant le réseau virtuel et les sous-réseaux adéquats pour nos tests FSLogix :

Une fois la validation passée, cliquez sur Créer :

Une fois la création terminée, retournez sur votre compte de stockage pour y ajoutez votre IP publique dans les règles de réseau :

Cliquez ici pour créer un partage de fichier sur ce compte de stockage :

Nommez le nom de ce partage et conservez la capacité provisionnée par défaut :

Cliquez-ici pour joindre votre compte de stockage à votre domaine Azure AD DS :

Dans le cadre d’un domaine Azure AD DS, choisissez l’option se trouvant au milieu :

Cochez la case ci-dessous, puis Sauvegarder :

Quelques secondes plus tard, le statut Active Directory change. Cliquez sur le nom de votre partage réseau :

Assignez des rôles RBAC à vos utilisateurs via le menu suivant :

Commencez par assigner un administrateur avec le rôle ci-dessous :

Choisissez l’administrateur adéquat dans votre Azure AD, puis validez l’assignation :

Refaite une seconde opération d’assignation, avec le rôle suivant, pour votre utilisateur de test AVD :

Choisissez l’utilisateur AVD adéquat dans votre Azure AD, puis validez l’assignation :

Une fois les assignations correctement faites, vérifiez que celles-ci sont bien présentes :

Comme nous souhaitons disposer deux environnements AVD, l’un avec la redirection et l’autre sans, refaites à nouveau l’étape du compte de stockage pour en créer un second, configuré de la même façon :

Etape IV – Configuration du serveur de management :

Connectez-vous à votre machine virtuelle de management grâce au service Azure Bastion :

Renseignez les identifiants d’administrateur local renseignés lors de la création de la VM :

Dans la console Server Manager, cliquez sur WORKGROUP pour joindre cette machine au domaine Azure AD DS :

Cliquez-ici pour modifier la configuration de domaine :

Saisissez le nom de votre domaine Azure AD DS, puis cliquez sur OK :

Renseignez les identifiants d’un compte de votre Azure AD et répliqué sur Azure AD DS :

Cliquez sur OK :

Redémarrez votre machine virtuelle de management :

Une fois redémarrée, dans la console Server Manager, vérifiez la bonne jointure du domaine Azure AD DS :

Cliquez-ici pour ajouter les fonctionnalités de gestion du domaine AD :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cochez les cases des fonctionnalités suivantes :

  • Group Policy Management
  • Remote Server Administration Tools

Puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Cliquez sur Fermer :

Fermez la session Windows de votre administrateur local

Sur le portail Azure, retournez sur le partage de fichier de votre premier compte de stockage dédié à FSLogix :

Récupérez la commande PowerShell pour créer un lecteur réseau Z, grâce à la clef du compte de stockage :

$connectTestResult = Test-NetConnection -ComputerName jlostoprem.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    # Save the password so the drive will persist on reboot
    cmd.exe /C "cmdkey /add:`"jlostoprem.file.core.windows.net`" /user:`"localhost\jlostoprem`" /pass:`"odE9TV8+6IzIYVezHtzS2xcESUL2oegoqjEqhcQcBPAPIKMuZsNob0UErXTGyGU2d986MuhWPQme+AStVF/ofA==`""
    # Mount the drive
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\jlostoprem.file.core.windows.net\fslogix-profile" -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."
}

Retournez sur la machine virtuelle de management, puis ouvrez à nouveau une session RDP avec un compte d’administration Azure AD DS :

Ouvrez PowerShell ISE, collez la requête précédemment récupérée sur le compte de stockage, puis lancez-là :

Un premier lecteur réseau apparaît alors dans le poste de travail :

Modifiez la propriété de sécurité de ce lecteur réseau via la fonction Avancé :

Ajoutez un droit pour le compte administrateur Azure AD DS avec la configuration suivante :

Ajoutez un droit pour votre utilisateur de test AVD avec la configuration suivante :

Le résultat des droits sur le partage réseau devrait correspondre à cela :

Refaites les mêmes opérations sur le second compte de stockage :

  • Commande PowerShell pour monter le disque réseau Y
  • Propriété – Sécurité pour les deux utilisateurs

Etape V – Configurations des GPOs FSLogix :

Retournez sur la console Server Manager, puis cliquez-ici :

Désactivez la protection renforcée d’Internet Explorer, puis cliquez sur OK :

Depuis le menu Démarrer, ouvrez Microsoft Edge :

Rendez-vous à l’adresse internet suivante pour télécharger la configuration ADMX pour FSLogix :

https://learn.microsoft.com/en-us/fslogix/how-to-install-fslogix#download-fslogix

Cliquez-ici pour démarrer le téléchargement sous format ZIP :

Ouvrez l’archive ZIP précédemment téléchargée :

Copiez le fichier fslogix.admx dans le dossier suivant :

%SYSTEMROOT%\PolicyDefinitions

Copiez le fichier fslogix.adml dans le dossier suivant :

%SYSTEMROOT%\PolicyDefinitions\en-US

Toujours sur la console Server Manager, ouvrez le gestionnaire des GPOs :

Créez une première nouvelle OU pour notre environnement contenant la redirection FSLogix :

Cliquez comme ceci pour ajouter une GPO à cette première OU nouvellement créée :

Nommez cette GPO :

Cliquez ici pour configurer cette nouvelle police :

Descendez dans l’arborescence suivante :

  • Computer Configuration
    • Policies
      • Administrative templates
        • FSLogix
          • Profile Containers

Activez et configurez les options suivantes :

Renseignez le chemin utilisé pour le montage de votre premier disque réseau Z :

\\jlostoprem.file.core.windows.net\fslogix-profile

Descendez d’un niveau dans l’arborescence :

Activez et configurez les options suivantes :

Comme ce premier environnement va contenir la redirection FSLogix, positionnez-vous sur l’arborescence suivante :

Activez et configurez l’option suivante :

Renseignez le même chemin utilisé pour le montage de votre premier disque réseau Z :

\\jlostoprem.file.core.windows.net\fslogix-profile

Copiez le fichier de redirection « redirections.xml » à la racine du dossier précédemment indiqué, afin de le rendre accessible à tous.

Voici pour rappel la configuration utilisée pour mon test :

<?xml version="1.0"  encoding="UTF-8"?>
<FrxProfileFolderRedirection ExcludeCommonFolders="0">
<Excludes>
<Exclude Copy="0">AppData\Roaming\Microsoft\Teams\media-stack</Exclude>
<Exclude Copy="0">AppData\Local\Microsoft\Teams\meeting-addin\Cache</Exclude>
<Exclude Copy="0">AppData\Local\Microsoft\Outlook</Exclude>
<Exclude Copy="0">AppData\Local\Microsoft\OneDrive</Exclude>
<Exclude Copy="0">AppData\Local\Microsoft\Edge</Exclude>
</Excludes>
<Includes>
<Include>AppData\Local\Microsoft\Edge\User Data</Include>
</Includes>
</FrxProfileFolderRedirection>

Afin de tester la redirection FSLogix, pensez à rajoutez une seconde OU en la liant à une nouvelle police FSLogix, avec exactement la même configuration, à l’exception de la redirection FSLogix :

Nous allons maintenant pouvoir tester l’impact de la configuration FSLogix, avec et sans la redirection XML.

Etape VI – Configurations des 2 Azure Virtual Desktop :

Pour cela, créez votre premier environnement AVD :

Cliquez sur Créer :

Renseignez les champs du premier onglet, puis cliquez sur Suivant :

Ajoutez une ou plusieurs machines virtuelles AVD, en les joignant à la première OU votre domaine Azure AD DS, puis cliquez sur Suivant :

Ajoutez un Espace de travail à votre environnement AVD, puis lancez la validation :

Une fois la validation passée, cliquez sur Créer :

Une fois votre premier environnement AVD correctement créé, lancez la création d’un second AVD, en joignant cette fois ci les VMs à la seconde OU votre domaine Azure AD DS :

Sur les deux pools d’hôtes AVD, ajoutez votre utilisateur de tests AVD afin de l’autoriser à s’y connecter :

Les deux environnements AVD sont enfin prêts, il vous reste plus qu’à vous connectez sur les deux environnement AVD en simultané.

Etape VII – Tests des 2 Azure Virtual Desktop :

Sur la session Azure Bastion de la machine de management d’Azure AD DS, ouvrez deux explorateurs de fichier pour constater la variation de taille sur les profils FSLogix :

Sur votre poste, ouvrez un navigateur privé, puis rendez-vous sur l’URL AVD suivante :

aka.ms/wvdarmweb

Renseignez les identifiants de votre utilisateur AVD de test :

Ouvrez, une par une, les deux sessions AVD disponibles :

Sur la machine virtuelle FSLogix avec la redirection, ouvrez l’explorateur Windows sur le chemin suivant :

C:\ProgramData\FSLogix\Logs\Profile

Ouvrez le fichier de log ci-dessous :

Recherchez le mot « redirections« , puis vérifiez juste en-dessous la bonne prise en compte de votre configuration XML :

Sur deux machines virtuelles de test AVD, notez pour l’utilisateur de test la présence systématique deux dossiers suivants :

De retour sur votre portail Azure, retournez sur la session Azure Bastion, puis constatez l’apparition des 2 dossiers de profil :

Détaillez les 2 dossiers, puis comparez la taille identique des 2 fichiers VHDX :

Sur chacune des sessions AVD, configurer le même compte Outlook :

Attendez quelques minutes le chargement complet d’Outlook :

Quelques minutes plus tard, retournez sur la session Azure Bastion et constatez l’écart de taille entre les deux profils FSLogix :

Continuez l’exercice avec la configuration du même compte OneDrive sur les deux sessions AVD :

L’écart continue encore de se creuser :

Lancez une synchronisation OneDrive forcée sur les deux sessions AVD :

Les 2 profiles grossissent fortement, quelques minutes plus tard, l’écart est proportionnellement moins important que précédemment :

Finissions la comparaison avec l’ouverture de Microsoft Teams sur les 2 sessions AVD :

Là encore les deux profils AVD continuent de grossir fortement :

Conclusion

Suite aux différents tests menés précédemment, il existe bien un gain dans la taille du profile FSLogix une fois la redirection configurée. Cela reste malgré tout modeste par profil, mais cela sera très conséquent pour plusieurs dizaines d’utilisateurs AVD.

Enfin, comme Dean le rappelle dans la vidéo ci-dessous :

  • Les profils FSLogix peuvent grossier sans limite, mais la réduction n’est plus possible
  • Il est important bien configurer la redirection en tenant compte des compatibilités !
  • La désactivation de la redirection est impossible mais prendra du temps pour s’appliquer sur tous les profils

Sécurisez votre AVD grâce au Watermarking

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 :

Créez votre Log Analytics workspace dédié à votre environnement AVD :

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.

Endormez vos VMs AVD inutilisées

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

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 :

@echo off
schtasks /change /tn  Deconnexion /disable
schtasks /change /tn  Deconnexion /enable
exit

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.

Peut-on booster les FPS de votre Azure Virtual Desktop ?

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
  • Environnement 3 : augmentation FPS + priorité + configuration du décoding graphique

Etape 0 – Rappel des prérequis :

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 l’éditeur de registre Windows :

Saisissez l’arborescence suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations

Créez une nouvelle clef DWORD

Donnez-lui le nom suivant :

DWMFRAMEINTERVAL

Assignez-lui la valeur décimale suivante, puis cliquez sur OK :

A la place, voici la même commande pour ajouter la clef au registre :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DWMFRAMEINTERVAL  /t REG_DWORD /d 15 /f

Fermez la session de votre utilisateur AVD.

Rouvrez la session sur la même machine AVD.

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 :

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVC444ModePreferred  /t REG_DWORD /d 1 /f

Fermez la session de votre utilisateur AVD :

Rouvrez la session sur la même machine AVD :

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 :

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVCHardwareEncodePreferred  /t REG_DWORD /d 1 /f

Fermez la session de votre utilisateur AVD :

Rouvrez la session sur la même machine AVD :

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 :

Enfin, j’ai réalisé la configuration suivante uniquement sur l’environnement 6 :

  • Lancement des 3 modifications précédentes par des clefs de registre :
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v bEnumerateHWBeforeSW  /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVC444ModePreferred  /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v AVCHardwareEncodePreferred  /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DWMFRAMEINTERVAL  /t REG_DWORD /d 15 /f
gpupdate.exe /force 

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.

Réduisez les coûts de votre AVD

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 :

Il ne s’agit pas de solutions 100% équivalentes en termes de fonctionnalités, chacune apporte une plus-value selon le scénario AVD souhaité.

Quelles sont les économies possibles ?

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.
Tarification Azure Virtual Desktop

Quelles sont les économies possibles ?

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 :

Quelles sont les économies possibles ?

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

Prenons en exemple la sécurité sur Azure AD :

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éfautAzure AD Free – Administrateurs généraux uniquementOffice 
365
Azure AD Premium P1Azure 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 ????????

Azure Virtual Desktop ❤️ FIDO2

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.

FIDO Alliance

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 uniquementOffice 
365
Azure AD Premium P1Azure 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égieParamètres de sécurité par défautAccès conditionnelAuthentification 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 :

FournisseurBiométrieUSBNFCBLECertifié FIPSContact
AuthenTrendyyyynhttps://authentrend.com/about-us/#pg-35-3
Cirightnnynnhttps://www.cyberonecard.com/
Ensurityyynnnhttps://www.ensurity.com/contact
Excelsecuyyyynhttps://www.excelsecu.com/productdetail/esecufido2secu.html
Feitianyyyyyhttps://shop.ftsafe.us/pages/microsoft
Fortinetnynnnhttps://www.fortinet.com/
Giesecke + Devrient (G+D)yyyynhttps://www.gi-de.com/en/identities/enterprise-security/hardware-based-authentication
GoTrustID Inc.nyyynhttps://www.gotrustid.com/idem-key
HIDnyynnhttps://www.hidglobal.com/contact-us
Hypersecunynnnhttps://www.hypersecu.com/hyperfido
IDmelon Technologies Inc.yyyynhttps://www.idmelon.com/#idmelon
Kensingtonyynnnhttps://www.kensington.com/solutions/product-category/why-biometrics/
KONA Iynyynhttps://konai.com/business/security/fido
NeoWavenyynnhttps://neowave.fr/en/products/fido-range/
Nymiynynnhttps://www.nymi.com/nymi-band
Octatcoyynnnhttps://octatco.com/
OneSpan Inc.nynynhttps://www.onespan.com/products/fido
Swissbitnyynnhttps://www.swissbit.com/en/products/ishield-fido2/
Thales Groupnyynyhttps://cpl.thalesgroup.com/access-management/authenticators/fido-devices
Thetisyyyynhttps://thetis.io/collections/fido2
Token2 Switzerlandyyynnhttps://www.token2.swiss/shop/product/token2-t2f2-alu-fido2-u2f-and-totp-security-key
Solutions TrustKeyyynnnhttps://www.trustkeysolutions.com/security-keys/
VinCSSnyn