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

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

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

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

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

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

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

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

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

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

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

Microsoft Learn

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

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

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

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

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

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

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

Choisissez une image OS sous Windows 11 :

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

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

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

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

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

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

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

Cliquez sur le nombre de machines AVD hôtes :

Cliquez sur le premier hôte AVD :

Cliquez sur la machine virtuelle AVD correspondante :

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

Vérifiez les caractéristiques du disque :

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

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

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

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

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

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

Choisissez une machine virtuelle de type D8ds_v3 :

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

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

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

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

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

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

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

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

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

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

Cochez la case, puis cliquez sur Suivant :

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

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer :

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

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

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

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

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

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

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

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

Lancez la validation Azure :

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

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

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

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

dsregcmd /status

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

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

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

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

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

Choisissez une machine virtuelle de type D8ds_v5 :

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

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

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

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

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

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

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

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

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

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

Cochez la case, puis cliquez sur Suivant :

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

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer

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

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

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

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

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

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

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

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

Lancez la validation Azure :

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

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

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

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

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

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

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

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

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

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

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

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

Sur chacune des 3 sessions AVD :

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

Machine virtuelle AVD avec disque OS Premium SSD :

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

Le disque temporaire est bien de 300 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS CACHE :

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

Le disque temporaire est bien de 64 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS TEMPORAIRE :

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

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

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

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

Etape V – Synthèse des résultats :

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

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

Conclusion

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

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

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

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

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

Changez l’URL de votre AVD

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

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

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

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

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

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

Etape 0 – Rappel des prérequis :

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

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

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

Méthode IUtilisation d’une Static Web App :

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

George Markou

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

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

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

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

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

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

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

Attendez quelques secondes que le traitement de copie se termine :

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

Créez votre Static Web App en cliquant ici :

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

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

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

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

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

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

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

Modifiez la ligne 31 comme ceci :

Avant :

app_location: "/" # App source code path

Après :

app_location: "/src" # App source code path

Cliquez sur Commit changes :

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

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

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

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

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

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

Confirmez votre création d’enregistrement DNS :

Attendez quelques secondes l’actualisation de vos enregistrements DNS :

Retournez sur le portail Azure afin de cliquer sur Ajouter :

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

Une fois le domaine validé, cliquez sur Fermer :

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

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

Constatez apparition rapide du message de transfert suivant :

Constatez le changement d’URL :

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

Attendez quelques secondes l’établissement de la connexion :

Attendez quelques secondes l’ouverture de la session :

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

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

Méthode IIUtilisation d’Azure Front Door :

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

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

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

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

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

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

Ajoutez la règle de configuration suivante :

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

Choisissez une route, puis cliquez sur Suivant :

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

Attendez environ une minute la fin de l’association :

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

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

  • A
  • AAAA
  • TXT

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

Constatez le changement d’URL :

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

Attendez quelques secondes l’ouverture de la session :

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

Conclusion

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

FSLogix sont nos amis 🙏!

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

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

La solution FSLogix en quelques mots & vidéos :

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

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

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

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

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

Mais aussi d’autres sources non-Microsoft :

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

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

Etape 0 – Contexte :

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

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

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

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

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

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

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

Voici une vue de l’environnement Azure Virtual Desktop :

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

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

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

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

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

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

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

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

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

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles

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

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

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

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

Je renseigne les identifiants :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Je lance toutes les mises à jour Windows 11 disponibles :

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

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

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

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

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

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

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

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

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

Et la suite se passe de commentaire 🤣.

Etape III – Identification de la cause :

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

Et je tombe sur celui-ci 😎 :

Microsoft propose également une résolution juste ici :

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

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

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

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

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

Sysprep /generalize /oobe /mode:vm /shutdown

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

Hibernez votre AVD ⛄❄️

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

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

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

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

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

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

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cliquez sur Suivant pour continuer :

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

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

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

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

Etape III – Test de l’hibernation :

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion :

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

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

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

AVD : Protocole UDP pour tous !

Ce nouvel article est focalisé sur la partie réseau d’AVD, il reste dans la continuité de celui déjà consacré à RDP Shortpath, écrit il y a plusieurs mois déjà. Azure Virtual Desktop est capable d’établir des connexions de bureau à distance via deux protocoles : TCP et UDP. L’utilisation du second permet d’améliorer les performances grâce à un débit plus important et une gestion différente des paquets.

Pour vous remettre dans le bain, voici un rappel de l’excellente vidéo de Dean à ce sujet :

Pourquoi doit-on se préoccuper du protocole UDP ?

L’impact du protocole dans un environnement dédié au bureau à distance est majeur. Denis Gundarev nous explique avec simplicité l’inadéquation entre le protocole TCP dans le cadre d’une connexion RDP :

TCP est un excellent protocole pour la livraison garantie de petites quantités de données. Les applications telles que les navigateurs ou les clients de messagerie se contentent d’envoyer les données et de les oublier. Le protocole assure la cohérence et l’ordre des paquets et relance la transmission si la livraison échoue. Cependant, RDP utilise des connexions de longue durée et les connexions TCP de longue durée sont problématiques.

Le protocole TCP est idéal pour les réseaux locaux, mais pas pour l’Internet. Oui, si le paquet est perdu, il sera retransmis. La disponibilité de la bande passante est un facteur essentiel. Malheureusement, les algorithmes de contrôle de congestion TCP limitent la possibilité de saturer le réseau.

Pour vous donner une meilleure idée, voici une vidéo comparative montrant visuellement l’impact du protocole si une partie de paquets est perdue :

Pourquoi refaire un article sur ce sujet ?

En faisant différents tests sur des environnements Azure Virtual Desktop, je me suis rendu compte « par hasard » de l’activation quasi systématique du protocole UDP lors des ouvertures de session, sans aucune action ni configuration de ma part.

J’ai donc effectué différents tests sur 3 environnements AVD distincts :

  • VM : Standard D8s v3 (8 vCPU, 32 GiB memory) / OS : Windows 10 21H2
  • VM : Standard D2s v3 (2 vCPU, 8 GiB memory) / OS : Windows 11 22H2
  • VM : Standard D8s v3 (8 vCPU, 32 GiB memory) / OS : Windows 11 21H2

Dans les 3 environnements, j’ai constaté exactement le même mécanisme :

  • Première ouverture de session en TCP
  • Seconde ouverture de session en UDP

Aucune configuration via la règle de registre ICEControl, pour activer le RDP Shortpath, n’a été mise en place avant ces tests :

Comment cela est-ce possible ?

Tout simplement car la fonctionnalité UDP a été déployée sur l’ensemble des environnements AVD, de production et de validation : RDP Shortpath for public networks in Azure Virtual Desktop – Microsoft Community Hub.

Comme l’indique ce billet Microsoft , la disponibilité générale du routage via le protocole UDP pour les connexions transitant via un réseau public est disponible depuis la date du 6 septembre dernier. Ils recommandent même de retirer la précédente clef de registre.

A noter que certaines ouvertures de sessions se sont malgré faites tout en TCP. Bien souvent, la fermeture / réouverture de la session m’a permis de retrouver un protocole UDP. Je pense que certains éléments influent sur cela, sans vraies certitudes.

Peut-on désactiver le protocole UDP afin de rester systématiquement en TCP ?

Cela est parfaitement possible et nécessaire dans certains scénarios. Microsoft propose 3 méthodes pour retrouver l’état initial en TCP :

  • Désactivation au niveau de la machine virtuelle AVD
  • Désactivation au niveau du client AVD
  • Désactivation via Intune

Pour la première méthode, il est nécessaire d’intervenir au niveau de la machine AVD, ou de l’implémenter via une GPO.

Connectez-vous sur la machine virtuelle AVD avec un compte administrateur.

Ouvrez l‘Editeur de groupes polices locales :

Rendez-vous dans le menu suivant :

Computer Configuration > Administration Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Host > Connections

Ouvrez le paramètre ci-dessous :

Cochez les options comme ceci, puis fermez la session et rouvrez là :

Constatez bien que votre connexion RDP utilise le protocole TCP :

La configuration et le résultat sont identiques pour les machines en Windows 10.

Annexe

Durant ces tests j’ai également remarqué que mes environnements Azure Virtual Desktop fonctionnaient très bien malgré l’absence de l’argument RDP targetisaadjoined dans les propriétés RDP du pool d’hôtes AVD :

Avant :

Maintenant :

C’est toujours appréciable d’avoir une chose de moins à penser dans la configuration ????.

Conclusion

Microsoft continue d’améliorer son outil et facilite sa configuration. La simplification et l’automatisation du protocole UDP améliore les performances et donc l’expérience utilisateur. Nul doute que Microsoft va continuer à travailler dans ce domaine pour accroitre le nombre d’utilisateurs sur un de leurs produits phares.