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

Assignez votre utilisateur AVD de test à une des machines virtuelles :

Etape IV – Test de l’environnement AVD :

Avant de déployer la solution de configuration d’arrêt dynamique, testez le bon fonctionnement de l’accès à votre environnement AVD avec votre utilisateur de test.

Depuis votre poste local, connectez-vous à l’URL suivante, puis renseignez vos identifiants :

Ouvrez la session de bureau à distance AVD :

Acceptez la fin de la configuration SSO :

Attendez que la session Windows s’ouvre :

Une fois connecté, fermez la session utilisateur :

Depuis votre portail Azure, éteignez la machine virtuelle AVD :

Relancez la même connexion AVD depuis la page web de votre utilisateur de test :

Constatez la présence du message du démarrage de la machine virtuelle, vous invitant à patienter :

Attendez quelques minutes et constatez l’ouverture de la session Windows AVD :

Si tout fonctionne correctement pour vous, continuez la suite de cet article pour configurer l’arrêt dynamique AVD.

Etape V – Configuration des composants Azure

Pour cela, créez un compte Azure Automation :

Une fois la validation terminée, lancez sa création :

Une fois la ressource créée, allez dans le service appelé Azure Monitor :

Ajoutez une Règle d’alerte d’état de santé comme ceci :

Cochez uniquement les 4 conditions suivantes de cette façon :

Créez un nouveau Groupe d’action :

Rattachez le Groupe d’action à votre compte Azure Automation précédemment créé :

Lancez la création de votre Groupe d’action :

Nommez votre Règle d’alerte :

Lancez la création de votre Règle d’alerte :

L’étape suivante concerne maintenant la configuration Windows des machines virtuelles AVD. Il est possible de l’établir cela par :

des Polices locales sur chaque VM AVD
des GPOs créées sur un Active Directory

N’ayant pas d’Active Directory dans mon environnement de test, nous allons créer des polices locales sur la machine AVD de test. C’est aussi votre cas si les machines virtuelles AVD sont jointes à Azure AD.

Etape VI – Configuration des composants Windows

Comme votre utilisateur de test est considéré comme un administrateur local, ouvrez le Planificateur de tâche Windows depuis le menu Démarrer :

Créez une nouvelle Tâche planifiée :

Nommez la Tâche planifiée, puis cochez les cases suivantes :

Ajoutez un déclencheur sur le second onglet :

Choisissez le motif de déconnexion avec un délai de 30 minutes :

Sur l’onglet des actions, ajoutez le lancement du programme Shutdown avec les arguments suivants:

/f /s /t 0

Validez la création de la Tâche planifiée, puis lancez la création d’une seconde Tâche planifiée :

Choisissez le démarrage de la Tâche planifiée avec l’ouverture d’une session utilisateur :

Sur la VM AVD, créez un nouveau fichier texte avec les lignes ci-dessous :

@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.

Windows 11 + AVD + Azure AD

Je vous avais déjà parlé il a quelque temps de la jointure possible entre des machines virtuelles Azure Virtual Desktop et Azure AD ici. Cela offre la possibilité de se passer d’un Active Directory pour environnement AVD et permet d’envisager certains projets avec une architecture 100% Cloud.

Avec l’arrivée prochaine de Windows 11, il me paraissait intéressant de tester cette combinaison avec le nouvel OS de Microsoft.

Point important : Comme précédemment, nous sommes toujours dans l’attente d’une prise en charge de FSLogix dans ce scénario. L’utilisation d’un partage de fichier nécessite une authentification SMB, non possible pour l’instant via la seule gestion des identités Azure AD.

Rappel des prérequis

Comme pour tout déploiement dans Azure, des prérequis sont nécessaires :

Un tenant Microsoft
Une souscription Azure
Un réseau virtuel
Des licences pour les utilisateurs AVD, comprenant Azure Virtual Desktop

La liste est donc beaucoup plus courte qu’avec un domaine classique ????.

Déploiement de la solution

Une fois votre réseau virtuel en place, la création de l’ensemble pourra se faire directement depuis Azure Virtual Desktop. Dans le cadre d’un environnement de production, la création d’une image en amont reste l’étape indispensable pour installer les applications nécessaires à vos utilisateurs !

Sur le portail Azure, recherchez Azure Virtual Desktop dans la barre de recherche et sélectionnez Azure Virtual Desktop dans les suggestions :

Sur l’écran d’Azure Virtual Desktop, choisissez Créer un Pool d’hôtes :

Renseignez les informations de base sur votre pool d’hôtes puis cliquez sur Suivant : Machines virtuelles :

Renseignez les principales caractéristiques de vos machines virtuelles AVD :

L’image de Windows 11 n’est pas forcément proposée dans la liste. Il vous faudra alors la chercher dans la marketplace Azure :

Renseignez les informations réseaux :

Prenez le temps de considérer les options concernant le domaine à joindre :

Type de domaine à joindre : Choisissez Azure Active Directory
Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, qu’elles soient dédiées ou partagées entre utilisateurs

Il est toujours demandé de créer un compte administrateur local :

Cliquez sur Suivant et créez un nouvel espace de travail :

Enfin lancez la création quand Azure a validé votre configuration :

Environ 10-15 minutes plus tard, le déploiement doit se finir sur une note positive :

Contrôlez quelques minutes après la bonne disponibilité des machines virtuelles dans le pool d’hôtes AVD :

Pensez à assigner le groupe d’utilisateurs AVD sur l’application créée par le pool d’hôtes :

Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se fait directement sur le pool d’hôtes d’AVD :

Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se fait directement sur le groupe de ressources AVD :

Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD

Il ne reste plus qu’à tester la solution avec un utilisateur AVD. Cela se fait en téléchargeant le client Windows Remote Desktop PC dédié à Azure Virtual Desktop (téléchargeable ici), ou via l’accès web multi-plateformes (accessible là). J’ai choisi dans mon cas Windows Remote Desktop :

Une seconde demande d’authentification est affichée pour accéder à la machine virtuelle via le protocole RDP :

Une fois le mot de passe saisi, l’ouverture d’une fenêtre RDP donne l’accès au bureau Windows 11 d’AVD. A noter que la jointure AVD apporte également le Seamless Sign on, rendant l’expérience utilisateur encore plus agréable :

Regardez en détail cette jointure avec Azure AD grâce à la commande :

dsregcmd /status

Vérifiez que les machines virtuelles Windows 11 Azure Virtual Desktop sont bien présentes dans la section Devices d’Azure AD. Cet ajout est réalisé lors de la jointure des machines virtuelles à Azure AD :

Vérifiez, si vous avez coché Intune, que vous retrouvez bien mes machines virtuelles dans la console :

Si vous rencontrez des erreurs lors du déploiement, Microsoft met à votre disposition cette page d’aide. Voici une des erreurs possibles :

Erreur de mot de passe de l’ouverture de la session RDP : “The logon attempt failed”

Si vous rencontrez une erreur indiquant que la tentative de connexion a échoué à l’invite des informations d’identification de sécurité Windows, vérifiez les éléments suivants :

Vous êtes sur un appareil qui est joint à Azure AD ou à Azure AD hybride au même locataire Azure AD que l’hôte de session OU
Vous êtes sur un appareil exécutant Windows 10 2004 ou version ultérieure qui est Azure AD enregistré auprès du même locataire Azure AD que l’hôte de session
Le protocole PKU2U est activé à la fois sur le PC local et sur l’hôte de session

La dernière hypothèse est fortement probable dans ce cas. Il faut donc penser à vérifier cette option sur la machine locale ET sur la machine virtuelle AVD, grâce à la commande secpol.msc :

Conclusion

Windows 11 s’intègre de plus en plus dans l’environnement Azure. Azure Virtual Desktop va grandement bénéficier de ce nouvel OS pour accroitre son utilité dans les solutions de bureau à distance. Comme pour Windows 10, on attend toujours la prise en charge de la solution FSLogix dans ce scénario de jointure avec Azure AD.

Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????

Windows 11 + Azure Virtual Desktop = 1

Ayant récemment abordé l’ajout d’images Windows 11 sous Azure ici, je me devais également de faire un nouvel article sur l’installation de machines virtuelles W11 au sein d’un environnement Azure Virtual Desktop.

Dans cet article nous allons tester différentes manières d’associer des machines virtuelles Windows 11 à AVD. Chaque méthode apporte des avantages et un niveau d’automatisation différent. Comme à chaque fois, il faut disposer au préalable d’un tenant et d’une souscription Azure sur laquelle vous déploierez les ressources Azure.

Etape 0 : Prérequis Licenses + Azure

A la différence d’un environnement RDS, Azure Virtual Desktop ne nécessite pas de licence côté serveur dans le cadre d’un environnement Windows 10/11. Cela n’est pas le cas si votre AVD est basé sur Windows Server. Vous pouvez accéder à Windows 10 et Windows 7 avec Azure Virtual Desktop si vous possédez l’une des licences suivantes par utilisateur :

Microsoft 365 E3/E5
Microsoft 365 A3/A5/Student Use Benefits
Microsoft 365 F3
Microsoft 365 Business Premium
Windows 10 Entreprise E3/E5
Windows 10 Éducation A3/A5
Windows 10 VDA par utilisateur

Comme indiqué précédemment, nous allons commencer les déploiements en partant des prérequis suivants :

Un tenant Microsoft
Une souscription Azure
Un réseau virtuel
Un contrôleur de domaine (VM AD + Azure AD Connect ou Azure AD DS)
Un compte de stockage, paramétré pour FSLogix
Un pool d’hôtes Azure Virtual Desktop
Un espace de travail Azure Virtual Desktop

*Voici une liste des ressources Azure déjà en place sur ma souscription, avant la mise en place de Windows 11.*

Les points listés sont les mêmes pour un environnement Azure Virtual Desktop en Windows 10. Une fois en place, nous allons déployer des machines virtuelles en Windows 11 via les méthodes suivantes :

Méthode 1 : Déploiement direct depuis le pool d’hôtes AVD
Méthode 2 : Création d’une VM, puis enrôlement manuel dans le pool d’hôtes AVD
Méthode 3 : Création d’une VM puis enrôlement automatique via une extension script
Méthode 4 : Utilisation d’un template entièrement automatique et hébergé GitHub

Méthode 1 : Déploiement depuis le host pool

Dans cette méthode, nous allons simplement créer et ajouter une machine virtuelle Windows 11 sur notre environnement Azure Virtual Desktop.

Sur le portail Azure, recherchez Azure Virtual Desktop dans la barre de recherche et sélectionnez Azure Virtual Desktop dans les suggestions :

Sur l’écran d’Azure Virtual Desktop, choisissez Pool d’hôtes puis cliquez sur celui déjà créé précédemment dans votre environnement :

Si vous avez créé le vôtre sans machine virtuelle comme le mien, vous devriez avoir le chiffre 0 dans le nombre total de machines virtuelles. Cliquez dessus pour en ajouter :

Cliquez sur Ajouter :

Le premier onglet est grisé, car ces informations sont dédiées au pool d’hôtes. Cliquez sur le bouton Suivant pour ajouter la machine virtuelle :

Après avoir renseigné les premiers champs, cherchez l’image de Windows 11 en cliquant pour voir toutes les images disponibles dans la marketplace Azure :

Utilisez la barre de recherche pour retrouver l’image Windows 11, puis choisissez l’image avec les applications Microsoft 365 Gen 2 :

*Cliquez ici pour obtenir plus d’information sur Windows 11 Gen 2 (bas de l’article)*.

Choisissez la puissance et le nombre de machines virtuelles ainsi que la performance du disque OS :

*Microsoft recommande toujours les disques Premium SSD pour les environnements AVD de production*.

Sélectionnez le réseau virtuel et le sous-réseau correspondant :

*Il est vivement conseiller de créer un sous-réseau propre à AVD.*

Continuez avec les informations du domaine :

Les éléments de jointure sont importants car ils peuvent faire échouer le déploiement Azure.
Prenez le temps de bien vérifier ces informations.

Finissez avec les informations d’administration des machines virtuelles, puis cliquez pour valider la création :

Une fois la validation passée, vous pouvez déclencher la création de la ou les machines virtuelles :

La création ne prendra alors que quelques minutes seulement :

Retournez sur votre pool d’hôtes pour bien constater l’apparition et la bonne disponibilité des VMs :

Enfin, pensez bien à affecter un groupe d’utilisateurs AVD, issu de votre domaine AD sur le groupe d’application de bureau à distance :

Lancez Windows Remote Desktop avec un utilisateur AVD pouvant lancer la session de bureau à distance :

Une dernière authentification est alors demandée pour ouvrir la session Windows 11 à l’utilisateur :

Ca y est, on dispose enfin de notre premier bureau Windows 11 sous AVD !!!

Il ne reste plus qu’à rajouter les informations de registre pour finaliser la configuration FSLogix :

#Variables
$storageAccountName = "fslogixjl"
$fileshare = "userprofiles"

#Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

#Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$fileshare" -PropertyType String -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null

#Display script completion in console
Write-Host "Script Executed successfully"

Contrôlez alors dans votre partage de fichier créé pour FSLogix la présence du VHD :

En conclusion, la méthode habituelle de déploiement d’un Azure Virtual Desktop ne diffère en rien avec Windows 11. Nous allons nous intéresser à d’autres méthodes possibles de déploiement de Windows 11 pour AVD.

Méthode 2 : Création d’une VM puis enrôlement manuel

Quel que soit l’OS désiré, il est possible de créer une machine virtuelle par la méthode classique puis de l’enrôler manuellement via l’installation de la solution RD Agent.

Dans le cadre de l’installation de Windows 11 avec le Trusted Launch (encore en Preview), il faut alors utiliser ce portail Azure. La création de la machine virtuelle est alors des plus classiques :

Ajoutez provisoirement une adresse IP publique afin de pouvoir installer l’agent AVD :

Dans l’onglet Avancée, l’utilisation d’une image Gen 2 vous permet alors de profiter de toutes les fonctionnalités du Trusted Launch :

Connectez-vous en RDP sur la machine virtuelle nouvellement créée et suivez le processus suivant :

Joignez la machine virtuelle Windows 11 au domaine AD :

Téléchargez l’agent Azure Virtual Desktop et exécutez le programme d’installation
Lorsque le programme d’installation vous demande le jeton d’inscription, entrez la clef d’enregistrement disponible dans le pool d’hôtes AVD

*Retrouvez la clef d’enregistrement AVD directement sur le pool d’hôtes AVD.*

*Copiez la clef récupérée dans le programme d’installation d’AVD.*

Téléchargez l’agent de démarrage d’Azure Virtual Desktop et exécutez le programme d’installation
Télécharger et installez FSLogix puis ajoutez via PowerShell la configuration FSLogix :

#Variables
$storageAccountName = "fslogixjl"
$fileshare = "userprofiles"

#Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

#Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$fileshare" -PropertyType String -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null

#Display script completion in console
Write-Host "Script Executed successfully"

Redémarrez la machine virtuelle

La nouvelle machine rejoint alors celle de la première méthode :

Testez la connexion à Azure Virtual Desktop via l’accès HTML 5 depuis cette URL :

Contrôlez sur le compte de stockage l’apparition du second profil utilisateur :

En conclusion, la seconde méthode de déploiement d’un Azure Virtual Desktop par la création d’une VM, puis son enrôlement fonctionne très bien Windows 11. Nous allons maintenant nous intéresser à la création d’une VM dans AVD par l’ajout d’un script en extension.

Méthode 3 : Création d’une VM puis enrôlement automatique via une extension script

La 3ème méthode est très proche de la seconde méthode, à savoir qu’elle se fait par le déploiement d’une machine virtuelle. La différence va porter par l’utilisation d’une extension, appelant un script en PowerShell. Nous devons ce script à Dean Cefola, de l’Azure Academy. Ce script a connu les évolutions suivantes :

# 09/15/2019                     1.0        Intial Version
# 09/16/2019                     2.0        Add FSLogix installer
# 09/16/2019                     2.1        Add FSLogix Reg Keys 
# 09/16/2019                     2.2        Add Input Parameters 
# 09/16/2019                     2.3        Add TLS 1.2 settings
# 09/17/2019                     3.0        Chang download locations to dynamic
# 09/17/2019                     3.1        Add code to disable IESEC for admins
# 09/20/2019                     3.2        Add code to discover OS (Server / Client)
# 09/20/2019                     4.0        Add code for servers to add RDS Host role
# 10/01/2019                     4.2        Add all FSLogix Profile Container Reg entries for easier management
# 10/07/2019                     4.3        Add FSLogix Office Container Reg entries for easier management
# 10/16/2019                     5.0        Add Windows 7 Support
# 07/20/2020                     6.0        Add WVD Optimize Code from The-Virtual-Desktop-Team
# 10/27/2020                     7.0        Optimize FSLogix settings - Remove Office Profile Settings
# 02/01/2021                     7.1        Add RegKey for Screen Protection
# 05/22/2021                     7.2        Multiple changes to WVD Optimization code (remove winversion, Add EULA, Add Paramater for Optimize All
# 06/30/2021                     7.3        Add RegKey for Azure AD Join

Renseignez les paramètres de la machine virtuelle de manière classique, et cliquez sur l’ajout d’une extension à installer dans l’onglet Avancé :

Cherchez dans la liste celle appelée Custom Script Extension :

Puis cliquez sur Créer:

L’extension doit être stockée sur un compte de stockage de type Blob, vous pouvez la chercher ici :

Sélectionnez un compte de stockage si vous en disposez d’un. Si non, il vous faudra en créer un :

Créez un nouveau container pour stocker le script PowerShell :

Nommez-le et cliquez sur Créer :

Rentrez dans celui-ci et cliquez sur Upload :

Renseignez l’URL suivante dans le nom du fichier et cliquez sur Ouvrir :

https://raw.githubusercontent.com/DeanCefola/Azure-WVD/master/PowerShell/New-WVDSessionHost.ps1

Cliquez ensuite sur Upload :

Enfin cliquez sur Sélectionner :

Vous devrez ensuite renseigner deux paramètres pour que l’extension fonctionne correctement :

Profilepath : nom du partage SMB où doivent être stockés les profiles FSLogix
RegistrationToken : Clef d’enregistrement des machines dans le pool d’hôtes Azure Virtual Desktop

Ce qui donne dans mon cas les paramètres suivants :

-ProfilePath \\fslogixjl.file.core.windows.net\userprofiles -RegistrationToken eyJhbGciOiJSUzI1NiIsImtpZCI6Ijk3NkE4Q0I1MTQwNjkyM0E4MkU4QUQ3MUYzQjE4NzEyN0Y2OTRDOTkiLCJ0eXAiOiJKV1QifQ.eyJSZWdpc3RyYXRpb25JZCI6IjY2N2RhOGUyLWMxMDAtNGU1Ni1hMTIyLWZmOGFkMTE3YjdmMyIsIkJyb2tlclVyaSI6Imh0dHBzOi8...

Pensez encore une fois à activer toutes les fonctionnalités du Trusted Launch sur le même onglet Avancé :

Lancez la création de la machine virtuelle. Quelques minutes plus tard, vous devriez constater l’apparition de la machine virtuelle dans votre pool d’hôtes Azure Virtual Desktop :

La machine restera en indisponible tant que cette dernière n’est pas jointe au domaine Active Directory. Pour cela, vous devrez vous connecter en RDP à cette dernière avec le compte administrateur renseigné lors de sa création. Une fois connecté il ne vous restera qu’à rejoindre le domaine :

Un redémarrage plus tard, vous devriez constater que la machine virtuelle est bien passée en Disponible dans Azure Virtual Desktop :

Un lancement d’une session AVD utilisera les paramètres FSLogix que vous avez renseigné et le dossier sera bien créé sur le compte de stockage :

En conclusion, cette 3ème méthode est pratique, mais demande encore quelques opérations manuelles. La dernière méthode de cet article, elle aussi créée par Dean, est encore plus automatisée.

Méthode 4 : Utilisation d’un template GitHub

Cette 4ème et dernière méthode nous amène sur GitHub et ses liens de déploiement vers Azure. La page GitHub de Dean se trouve ici. Sur cette page se trouve ce qui nous intéresse :

Cliquez sur ce lien pour emporter le template sur votre portail Azure. Renseignez les champs selon les paramètres de votre environnement AVD et Validez :

Le template va alors se déployer en quelques minutes :

Vérifiez alors la bonne jointure des VMs avec Azure Virtual Desktop via le pool d’hôtes :

Comme à chaque fois, un lancement d’une session AVD utilisera les paramètres FSLogix que vous aviez renseigné et le dossier sera bien créé sur le compte de stockage :

En conclusion, cette 4ème et dernière méthode est certainement la plus pratique de toutes et en plus très rapide, même si certaines options de machines virtuelles ne sont alors plus disponibles au moment de la configuration.

Conclusion

Windows 11 est maintenant bien présent sur Azure Virtual Desktop. Sa sortie très prochaine nous amène à considérer cet OS dans de futurs projets de bureau à distance. Je suis sûr que Microsoft continuera à nous apporter encore plus de fonctionnalités dans les mois qui viennent. Pour vous aider dans les tests de ces différentes méthodes, vous trouverez ci-dessous la vidéo YouTube mis en ligne par Dean sur ce sujet et qui m’a aidé à préparer mon article :

Enfin n’hésitez pas à faire part de vos remarques sur Windows 11 sur AVD dans les commentaires ????

Windows 11 sous Azure

Bonne nouvelle, Windows 11 est maintenant disponible en préversion depuis plusieurs semaines et on ne parle plus que de lui ! Afin de vous faire la main sur le nouvel OS proposé par Microsoft, vous pouvez dès à présent le tester sur Azure.

Dans cet article, nous allons créer ensemble une nouvelle machine virtuelle sur Windows 11 prenant le temps de parler des options possibles lors de la création, en évolution constante.

Comme à chaque fois que vous souhaitez ajouter de nouvelles ressources, vous devez préalablement disposer d’une souscription Azure. Si cela n’est pas votre cas, sachez que Microsoft propose des crédits Azure gratuits, 130 € environ, à utiliser pendant 30 jours. Cela sera largement suffisant pour créer et tester Windows 11. Vous pouvez donc profiter de cette offre en cliquant ici.

Etape I : Création de la machine virtuelle

Une fois votre souscription en place et connecté à votre portail Azure, la création de la VM peut commencer. Le bouton de création de ressource va vous aider à trouver rapidement Windows 11 :

La recherche « Windows 11 » sur la marketplace d’Azure vous indiquera différentes images disponibles pour Windows 11, selon que vous soyez en version Pro, Enterprise ou que vous construisez un environnement multisessions pour Azure Virtual Desktop :

*Dans notre exemple, choisissez Windows 11 Enterprise, encore en préversion à date où cet article est écrit.*

Comme pour toutes les machines virtuelles créées sur Azure, des informations de bases sont systématiquement demandées :

Onglet I : Informations de base

Souscription : rattachement de la ressource à l’arborescence Azure. La souscription correspond à une « ligne de crédit » auprès de Microsoft (CB, CSP, EA, …).
Groupe de ressources : Container logique très utile et maintenant obligatoire pour organiser les ressources Azure. De plus, une ressource ne peut pas être présente dans plusieurs groupes de ressources à la fois.
Nom de la machine virtuelle : Nom de la machine virtuelle ^^ aussi utilisé pour le nom de machine dans l’OS.
Région : Localisation physique de la machine virtuelle dans le Cloud Microsoft. Voici ici la liste de toutes les régions Azure existantes.
Option de disponibilité : permet par exemple de répartir plusieurs machines virtuelles sur différents datacenters Azure ou dans différents racks au sein d’un même datacenter. Très pratique pour créer des architectures résilientes.
Image : bibliothèque d’images préconstruites par Microsoft, ISV ou constuites par vous-mêmes via des images personnalisées.
Azure Spot instance : Apporte une réduction significative du prix en exploitant des ressources non utilisées par Azure. Ne surtout pas prendre pour des services critiques sans interruption possible !
Taille : Détermine la puissance de la machine virtuelle (CPU, mémoire vive, performances et nombre de disques) et donc le prix.
Compte administrateur : Utilisateur et mot de passe pour administrer localement la machine virtuelle.

Ports publics entrants : Restriction ou autorisation de ports ouverts sur la machine virtuelle.
Ports entrants : Propose l’ouverture des ports de management habituels (HTTP, HTTPS, SSH ou RDP).
Licence : Case déclarative sur la juste possession de licence Windows 10, autorisant son exploitation sur plusieurs périphériques.

Onglet II : Disque(s)

Nous pouvons ici modifier la performance du disque OS, mais aussi ajouter si besoin des disques secondaires selon le besoin d’espace. Le nombre de disque dépendra aussi du SKU choisi pour cette machine virtuelle. Dans notre exemple, nous n’allons rien changer ici :

*Rappel :* Microsoft propose quatre types de disque, chaque type étant destiné à des scénarios clients spécifiques.

Onglet III : Réseau

Cet onglet a son importance car il définit les interactions réseaux possibles avec la nouvelle machine virtuelle. Plusieurs options ici vont donc potentiellement créer, ou non, de nouvelles ressources Azure :

Réseau virtuel : La machine virtuelle doit obligatoirement être sur un réseau virtuel, même si ce dernier ne comporte aucune autre ressource.
Sous-réseau : Le réseau virtuel doit comporter au minimum un sous-réseau. Le sous-réseau sera utile pour segmenter et sécuriser une infrastructure. Besoin de comprendre l’adresse IP ? Cliquez-ici !
IP publique : L’IP publique n’est pas une ressource obligatoire et doit être évitée dans un grand nombre de cas pour des questions de sécurité. Dans notre exemple, cette IP publique nous sera utile pour nous connecter à cette nouvelle machine Windows 11.
Groupe de sécurité réseau : Ce composant réseau d’Azure est très pratique pour filtrer les accès entrants et sortants sur un sous-réseau. Il ne s’agit pas ici d’une solution Firewall, mais d’un filtrage par sources, ports et protocoles.
Ports publics entrants : A la différence du premier onglet, la restriction ou l’autorisation de ports ouverts définie ici concerne le groupe de sécurité réseau.
Ports entrants : Propose là encore l’ouverture des ports de management habituels (HTTP, HTTPS, SSH ou RDP)
Accélération réseau : Avec la mise en réseau accélérée, le trafic réseau arrive directement à l’interface réseau de la VM.
Equilibreur de charge : Propose d’intégrer la nouvelle machine virtuelle derrière un équilibreur de charge existant. Très pratique pour augmenter et répartir le volume de requêtes pour un site web frontal.

Onglet IV : Management

Cet onglet apporte des outils complémentaires concernant la gestion de la machine virtuelle. Cela est utile pour diagnostiquer ou résoudre les problèmes :

Diagnostiques de démarrage : Comme son nom l’indique, il est possible de conserver un journal du démarrage de la machine virtuelle, qui pourra être exploité si un jour la machine virtuelle ne démarre pas correctement.
Diagnostiques invités de l’OS : Remonte des métriques additionnelles sur de la machine virtuelle vers un compte de stockage Azure.
Identité managée : Créé et gère une identité propre à la machine virtuelle. Cette dernière pourra avoir des droits sur d’autres ressources Azure, dans le but d’éviter la création d’un mot de passe qui serait stocké sur celle-ci.
Connexion via Azure AD : Combinaison intelligente pour permettre l’authentification via Azure AD. Cela passe aussi par l’ajout de rôles sur la ressource Azure pour autoriser ou non la connexion des utilisateurs.
Arrêt automatique : Programmation d’un arrêt OS de la machine virtuelle selon un horaire, lui-même défini selon un fuseau horaire. Très pratique pour diminuer la consommation Azure et donc le coût si la machine n’est pas utilisée en 24/7. Attention, le démarrage n’est pas automatique et devra donc passer par l’ajout d’un traitement batch.
Reprise après sinistre : Même dans un Cloud, on n’est jamais à l’abri d’une panne globale d’un centre de données. La réplication d’une machine virtuelle dans une seconde région Azure est alors possible et gérée par un service dédié : Recovery Services Vault.
Mises à jour invités de l’OS : Apporte l’automatisation périodique des mises à jour Windows.

Onglet V : Options avancées

En plus des options de management, d’autres fonctionnalités sont encore disponibles avant la création de la machine virtuelle :

Extension : les extensions sont un moyen rapide d’apporter une couche de configuration supplémentaire. Certaines sont disponibles via la bibliothèque d’extensions, mais il est aussi possible de travailler avec des scripts personnalisées.
Données personnalisées : Propose d’ajouter des données en plus de l’image déployée. Dans le cadre d’une image Windows, ces données seront stockées dans %SYSTEMDRIVE%\AzureData\CustomData.bin.
Données utilisateurs : Les données utilisateur sont une nouvelle version des données personnalisées et offrent des avantages supplémentaires.

Hôtes dédiés : Comme indiqué sur cette page, l’hôte dédié vous donne l’assurance que seules les machines virtuelles de votre abonnement se trouvent sur l’hôte physique, donc isolées des autres. La facturation se fait alors par hôte dédié et non par machines virtuelles créées.
Groupe de placement de proximité : Regroupement logique utilisé pour s’assurer que les ressources Azure se trouvent proches les unes des autres. Les groupes de placements de proximité sont utiles pour les charges de travail où une latence faible est requise.
Génération de machine virtuelle : La génération 2 existe maintenant depuis plusieurs années. Le choix de la génération va dépendre de l’OS choisi. Ce dernier apporte des fonctionnalités comme le Secure Boot, la prise en charge d’un disque OS supérieur à 2 To…

Note :

Il est maintenant possible de créer une machine virtuelle GEN 2 bénéficiant du Trusted Launch. Pour bénéficier de cette option encore en préversion, il est nécessaire de passer par ce lien spécifique du portail Azure. Vous aurez alors accès aux options suivantes :

*Attention, le Trusted lunch n’est pas accessible sur toutes les images d’OS* ou en GEN1
Windows 11 PRO -> KO
Windows 11 Enterprise -> OK

Pour rappel, celui fonctionne uniquement sur les machines virtuelles de seconde génération. Concrètement, ce démarrage sécurisé de la VM repose sur une version virtualisée du TPM :

Merci à Dean pour cette vidéo ????.

Onglet VI : Tags

Le tags est une information facultative mais fort pratique pour la classification des ressources Azure. Un tag est composé d’une paire nom/valeur. Il précise des informations sur les projets, les responsables, les durées de vie des ressources ou encore les utilisateurs finaux. Une ressource Azure peut contenir jusqu’à 50 tags.

Etape II : Déploiement de la machine virtuelle

Une fois toutes les options renseignées et la création déclenchée, il ne reste plus qu’à patienter quelques minutes. Il n’est pas nécessaire de rester sur la page de déploiement pendant le traitement. Une notification vous avertira du succès ou de l’échec de celui-ci.

*Cette copie d’écran ci-dessus nous présente en détail les ressources créées* pour cette machine virtuelle.

Un aperçu des mêmes ressources dans le groupe de ressources Azure nous indique une 6ème ressource :

Le disque OS est bien une ressource à part de la machine virtuelle.
Il peut être détaché au besoin de cette dernière.

Etape III : Connexion à la machine virtuelle

Dans notre exemple, la connexion est RDP est ouverte sur notre machine virtuelle Windows 11 car nous avons autorisé l’accès RDP sur la machine, mais également sur la partie réseau d’Azure. Voici ci-dessous une vue des règles, entrantes et sortantes, ouvertes sur le groupe de sécurité, rattaché ici à la carte réseau de la VM :

*L’avertissement indiqué sur la règle entrante pour le port RDP est présent pour vous alerter sur ce risque possible d’intrusion, car ouvert sur Internet.*

L’accès RDP est possible directement depuis la fonction présente dans la barre d’action. Il est aussi possible d’utiliser l’adresse IP publique rattachée à la machine virtuelle :

*Bastion est un autre moyen d’accès beaucoup plus sécurisé car il ne demande pas d’adresse IP publique pour chaque VM.*
Plus d’informations ici.

Le téléchargement et le lancement du fichier de connexion de bureau à distance vous affichera l’alerte de sécurité suivante :

Il ne vous restera alors qu’à renseigner les codes administrateurs renseignés sur le premier onglet lors de la création de la machine virtuelle :

Enfin vous y êtes ! Vous voici dans votre nouvelle machine virtuelle Azure, tourant sur Windows 11 ????

Conclusion

Pour un utilisateur déjà habitué aux machines virtuelles sur Azure, aucune différence lors de la création d’un Windows 11 sur Azure. En attendant le passage de Windows 11 en disponibilité générale, prévu pour le 05 octobre prochain, voici un article détaillé sur les nouveautés présentes dans le nouvel OS de Microsoft. Enfin voici également un test de celui-ci en vidéo :

Il ne me reste qu’à vous souhaiter une bonne lecture. N’hésitez pas à faire part de vos remarques sur Windows 11 dans les commentaires ????