Les solutions de bureau à distance, telles qu’Azure Virtual Desktop et Windows 365, reposent sur des protocoles de transport pour offrir une expérience utilisateur fluide et réactive. Par défaut, UDP est souvent privilégié pour sa faible latence, mais dans certains environnements, la fiabilité et la stabilité offertes par TCP priment.
Cet article détaille les spécificités de chacun de ces protocoles, leurs avantages et inconvénients, et propose deux approches pour forcer l’usage de TCP : une modification côté serveur et une modification côté client, que ce soit directement via le registre ou en déployant une stratégie de groupe (GPO).
TCP et son rôle dans les solutions de bureau à distance :
Le Transmission Control Protocol (TCP) est un protocole orienté connexion qui assure la fiabilité des échanges. Il garantit que les paquets arrivent dans l’ordre et, en cas de perte, les retransmet automatiquement.
Avantages de TCP :
Fiabilité et intégrité des données : Chaque paquet est vérifié et retransmis en cas d’erreur ou de perte.
Contrôle d’erreur et ordonnancement : Les données arrivent dans le bon ordre, ce qui est essentiel pour des applications nécessitant une cohérence stricte.
Inconvénients de TCP :
Surcharge et latence accrue : Les mécanismes de contrôle (comme le handshake initial) ajoutent un certain délai.
Moins performant pour les applications ultra-réactives : La latence induite peut être un frein pour certaines applications en temps réel.
UDP et ses applications dans le Remote Desktop :Le User Datagram Protocol (UDP) est un protocole sans connexion qui envoie les paquets sans vérifier leur réception ni leur ordre. Cette approche permet une transmission rapide avec une latence très réduite, idéale pour des sessions interactives.
Avantages de UDP :
Faible latence : Parfait pour des sessions de Remote Desktop où la réactivité est cruciale.
Moindre surcharge : L’absence de contrôle d’erreur exhaustif accélère le transfert des données.
Inconvénients de UDP :
Fiabilité moindre : Sans retransmission automatique, la perte de paquets peut dégrader la qualité de la session.
Absence de contrôle d’erreur intégré : Dans des environnements instables, cela peut entraîner des distorsions.
Fort de cette comparaison, il apparaît que le choix du protocole doit être adapté au contexte réseau. Par exemple, dans des environnements à qualité réseau variable, forcer l’utilisation de TCP peut s’avérer judicieux pour garantir une meilleure stabilité des connexions.
Forcer le flux TCP côté serveur
Il est possible de forcer le serveur à n’accepter que des connexions TCP, ce qui est particulièrement utile dans des environnements où la stabilité prime. Pour cela, vous pouvez modifier le registre du serveur ou déployer une GPO.
Modification via Registre
Avant modification, le serveur accepte par défaut les connexions en UDP (comme indiqué par vos captures d’écran). Pour forcer TCP, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport.
Pour ce faire, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport :
Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :
« Use either UDP or TCP (default) » : Si la connexion UDP est possible, la majorité du trafic RDP l’utilisera.
« Use only TCP » : Toutes les connexions RDP se feront exclusivement via TCP.
Si cette stratégie n’est pas configurée ou est désactivée, RDP sélectionnera automatiquement le protocole optimal pour offrir la meilleure expérience utilisateur.
Testons maintenant la configuration côté client.
Forcer le flux TCP côté client
Passons à présent à la configuration côté client. Avant modification, le client se connecte en UDP, comme le montrent les captures d’écran. Pour forcer l’utilisation de TCP (via WebSocket, qui repose sur TCP), il suffit d’ajouter la clé de registre fClientDisableUDP.
Avant modification, le client fonctionnait en UDP, comme vous pouvez le constater sur la capture d’écran ci‑dessous.
Pour ce faire, la modification est simple : il suffit d’ajouter la clé de registre fClientDisableUDP.
Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :
Après modification, la connexion se fait exclusivement en TCP. Ce changement assure que le client ne tente plus d’établir une connexion via UDP :
Conclusion
Le choix entre TCP et UDP dans des environnements de bureau à distance comme Azure Virtual Desktop et Windows 365 se résume à un compromis entre rapidité et fiabilité :
UDP offre une faible latence, idéale pour des sessions interactives, mais peut souffrir de pertes de paquets dans des réseaux instables.
TCP, même via une couche WebSocket, garantit la transmission fiable des données, au prix d’un léger surcoût en latence.
Note technique : Forcer l’utilisation de TCP est particulièrement recommandé dans les environnements où la qualité du réseau est variable ou sujette à des perturbations. Dans ces situations, bien que TCP puisse introduire une latence légèrement supérieure, il offre une stabilité et une fiabilité accrues, assurant ainsi une expérience utilisateur plus homogène.
En forçant l’utilisation de TCP via une modification de registre côté serveur (ou via une GPO) et/ou côté client, vous pouvez améliorer la stabilité des connexions, particulièrement dans des environnements où la qualité de la connexion est incertaine.
Ces approches vous permettent de mieux contrôler la configuration de votre infrastructure de Remote Desktop, optimisant ainsi l’expérience pour vos utilisateurs.
La restriction du presse-papier Windows entre le poste local et une session Azure Virtual Desktop est déjà possible depuis la configuration du protocole RDP. Mais la personnalisation des restrictions peut être poussée encore d’un cran. Avec Intune, vous pouvez exiger que le fameux copier-coller ne fonctionne que dans un sens spécifique, ou même uniquement que pour certains types de donnée !
Comme annoncé en introduction, vous pouvez déjà configurer beaucoup de paramètres RDP pour Azure Virtual Desktop. La configuration du protocole RDP est directement disponible depuis la configuration de votre pool d’hôtes de session Azure Virtual Desktop.
Le protocole RDP (Remote Desktop Protocol) possède plusieurs propriétés que vous pouvez définir pour personnaliser le comportement d’une session à distance, par exemple pour la redirection d’appareil, les paramètres d’affichage, le comportement de session, etc.
Quelles sont les propriétés RDP prises en charges par AVD ?
Toutes les propriétés existantes au protocole RDP ne sont pas intégrées à Azure Virtual Desktop. Voici la liste de ceux compatibles avec AVD, et sont aussi disponibles sur la page officielle de Microsoft :
Propriété RDP
Description
encode redirected video capture
Active ou désactive l’encodage de la vidéo redirigée.
targetisaadjoined
Autorise les connexions aux hôtes de session joints à Microsoft Entra à l’aide d’un nom d’utilisateur et d’un mot de passe. Cette propriété s’applique uniquement aux clients non-Windows et aux appareils Windows locaux qui ne sont pas joints à Microsoft Entra. Elle est remplacée par la propriété enablerdsaadauth.
camerastoredirect
Configure les caméras à rediriger. Ce paramètre utilise une liste délimitée par des points-virgules des interfaces KSCATEGORYVIDEOCAMERA des caméras activées pour la redirection.
redirected video capture encoding quality
Contrôle la qualité de la vidéo encodée.
maximizetocurrentdisplays
Détermine l’affichage d’une session à distance utilisée pour l’écran plein écran lors de l’optimisation. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows et l’application Bureau à distance pour Windows.
drivestoredirect
Détermine les lecteurs fixes, amovibles et réseau sur l’appareil local qui seront redirigés et disponibles dans une session à distance.
devicestoredirect
Détermine les périphériques qui utilisent le protocole MTP (Media Transfer Protocol) ou le protocole PTP (Picture Transfer Protocol), comme une caméra numérique, sont redirigés d’un appareil Windows local vers une session à distance.
usbdevicestoredirect
Détermine les périphériques USB pris en charge sur l’ordinateur client qui sont redirigés à l’aide d’une redirection opaque de bas niveau vers une session distante.
bandwidthautodetect
Détermine s’il faut ou non utiliser la détection automatique de la bande passante réseau.
redirected clipboard
Détermine s’il faut rediriger le Presse-papiers.
smart sizing
Détermine si l’appareil local met à l’échelle le contenu de la session distante pour qu’il corresponde à la taille de la fenêtre.
autoreconnection enabled
Détermine si l’appareil local tente automatiquement de se reconnecter à l’ordinateur distant si la connexion est supprimée, par exemple en cas d’interruption de la connectivité réseau.
redirectlocation
Détermine si l’emplacement de l’appareil local est redirigé vers une session distante.
audiomode
Détermine si l’ordinateur local ou distant lit l’audio.
compression
Détermine si la compression en bloc est activée lors de la transmission de données à l’appareil local.
videoplaybackmode
Détermine si la connexion utilisera le streaming multimédia efficace par RDP pour la lecture vidéo.
networkautodetect
Détermine si la détection automatique des types de réseau est activée.
dynamic resolution
Détermine si la résolution d’une session distante est automatiquement mise à jour lorsque la fenêtre locale est redimensionnée.
use multimon
Détermine si la session distante utilise un ou plusieurs affichages à partir de l’appareil local.
enablerdsaadauth
Détermine si le client utilisera l’ID Microsoft Entra pour s’authentifier auprès du PC distant. Lorsqu’il est utilisé avec Azure Virtual Desktop, cela offre une expérience d’authentification unique. Cette propriété remplace la propriété targetisaadjoined.
enablecredsspsupport
Détermine si le client utilisera le fournisseur de support de sécurité des informations d’identification (CredSSP) pour l’authentification s’il est disponible.
redirectsmartcards
Détermine si les appareils de carte à puce sur l’appareil local sont redirigés et disponibles dans une session à distance.
keyboardhook
Détermine si les combinaisons de touches Windows (Windows, OngletAlt+) sont appliquées à une session à distance.
redirectprinters
Détermine si les imprimantes disponibles sur l’appareil local sont redirigées vers une session à distance.
redirectcomports
Détermine si les ports série ou COM sur l’appareil local sont redirigés vers une session distante.
redirectwebauthn
Détermine si les requêtes WebAuthn d’une session distante sont redirigées vers l’appareil local, ce qui permet d’utiliser des authentificateurs locaux (tels que des clés de sécurité et de Windows Hello Entreprise).
screen mode id
Détermine si une fenêtre de session distante s’affiche en plein écran lorsque vous lancez la connexion.
singlemoninwindowedmode
Détermine si une session distante à affichage multiple bascule automatiquement vers un affichage unique lors de la sortie de l’écran plein écran. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows et l’application Bureau à distance pour Windows.
audiocapturemode
Indique si la redirection d’entrée audio est activée.
desktopheight
Spécifie la hauteur de résolution (en pixels) d’une session distante.
desktopwidth
Spécifie la largeur de résolution (en pixels) d’une session distante.
desktopscalefactor
Spécifie le facteur d’échelle de la session distante pour rendre le contenu plus grand.
kdcproxyname
Spécifie le nom de domaine complet d’un proxy KDC.
selectedmonitors
Spécifie les affichages locaux à utiliser dans une session distante. Les affichages sélectionnés doivent être contigus. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows, l’application Bureau à distance pour Windows et l’application de connexion Bureau à distance de boîte de réception sur Windows.
desktop size id
Spécifie les dimensions d’un bureau de session à distance à partir d’un ensemble d’options prédéfinies. Ce paramètre est remplacé si les paramètres desktopheight et desktopwidth sont spécifiés.
alternate shell
Spécifie un programme à démarrer automatiquement dans une session distante en tant que shell au lieu de l’Explorateur.
Où les modifier ?
Certaines propriétés RDP sont en effet modifiables depuis ces écrans du pool d’hôtes :
Informations de connexion :
Comportement de la session :
Redirection de périphérique :
Comme vous pouvez le voir dans la copie d’écran ci-dessous, la configuration détermine si le presse-papiers de l’ordinateur client sera redirigé et disponible ou non dans la session distante, et vice versa :
Le presse-papiers de l’ordinateur local est disponible dans la session à distance (par défaut)
Le presse-papiers de l’ordinateur local n’est pas disponible dans la session à distance
Non configuré
Paramètres d’affichage
Avancé
Peut-on configurer le comportement de redirection du Presse-papiers plus finement ?
Oui, cela est possible grâce à l’une des 3 méthodes suivantes :
Via Microsoft Intune
Via une stratégie de groupe
Via une ou des clefs de registre dans la golden image
Travis vous explique en détail la fonctionnalité via les clefs de registre Windows :
Dans cet article, je vous propose de tester la méthode via Intune :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Peu de prérequis sont nécessaires pour réaliser ce test AVD sur les restrictions du presse-papier Windows :
Un tenant Microsoft
Une souscription Azure valide
Dans ce test, nous allons déployer un environnement Azure Virtual Desktop composé de 5 machines virtuelles individuelles. Ces 5 machines nous permettront de comparer les différentes configurations Intune afin de voir les changement dans le presse-papier :
Aucune restriction
Restriction complète
Restriction depuis le poste local
Restriction depuis AVD
Restriction sur le format de donné
Etape I – Préparation Azure Virtual Desktop :
Avant tout, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création par la barre de recherche :
Nommez celui-ci, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1minute :
Une fois le réseau virtuel déployé, 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 un pool d’hôtes de type personnel, puis cliquez sur Suivant :
Définissez le nombre de machines virtuelles créées ainsi que la région Azure, puis choisissez l’image OS :
Choisissez les caractéristiques techniques de vos machines virtuelles AVD, puis spécifiez le réseau virtuel adéquat :
Effectuez une joindre à Entra ID en incluant Intune ainsi que les informations d’identification du compte administrateur local, puis cliquez sur Suivant :
Définissez un nouvel 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 l’assignation des utilisateurs :
Assignez les 5 utilisateurs de test à votre groupe d’application AVD :
Assignez ces mêmes 5 utilisateurs de test AVD aux 5 machines virtuelles créés :
N’oubliez pas la configuration RDP suivante, puis Sauvegarder :
Notre environnement Azure Virtual Desktop est maintenant en place. La suite de la configuration des restriction passera par le portail Intune.
Etape II – Configuration Intune :
Rendez-vous sur le portail Intune afin de créer 4 groupes Entra ID qui serviront à tester tous les scénarios de restriction du presse-papier :
Pour chacun de ces groupes, ajoutez dans chacun d’eux une machine virtuelles AVD de test :
Consultez la liste des machines virtuelles inscrites sur Intune pour vérification :
Commencez par créer une première police de configuration Intune, par exemple la restriction maximale :
Choisissez les options suivantes, puis cliquez sur Créer :
Nommez votre profil de configuration Intune, puis cliquez sur Suivant :
Recherchez dans le catalogue les options suivantes afin de les activer, ce qui aura pour effet de bloquer dans les 2 sens le presse-papier pour tous les types de transfert, puis cliquez sur Suivant :
Cliquez sur Suivant :
Ajouter un des 4 groupes de machines virtuelles créé précédemment, puis cliquez sur Suivant :
Vérifiez les paramètres une dernière fois, puis cliquez sur Créer :
Créer les 3 autres polices en faisant varier les réglages liés au presse-papier :
Retournez sur le menu suivant afin de pousser les configurations sur les machines virtuelles AVD dès que possible :
Renseignez les champs suivants, puis cliquez sur Suivant :
Ajoutez les machines virtuelles AVD, puis cliquez sur Suivant :
Lancez la synchronisation Intune en cliquant sur Créer :
Attendez quelques minutes afin de constater l’application avec succès des différentes polices de configuration sur les machines virtuelles AVD :
Attendez quelques minutes, puis retournez sur le portail Azure afin de redémarrer les machines virtuelles AVD pour que les modifications soient prises en compte :
Constatez l’indisponibilité des machines virtuelles AVD pendant la phase de redémarrage :
Constatez la disponibilité des machines virtuelles AVD quelques minutes plus tard :
Notre environnement avec les 5 machines virtuelles AVD est prêt pour les différents tests. Dans mon cas, je vais utiliser l’application Remote Desktop afin d’exécuter en parallèle les 5 sessions de bureau à distance :
J’ai donc ouvert 5 sessions AVD pour mes 5 utilisateurs de test :
Commençons par un premier test sans aucune restriction sur le presse-papier.
Etape III – Test Presse-papier sans restriction :
Cette première machine virtuelle n’est pas présente dans groupe Entra ID et n’a donc aucune police de configuration associée :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
Aucune configuration n’est présente dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD fonctionne
Le copier-coller d’un fichier depuis AVD vers le poste local fonctionne
Continuons avec un second test avec une restriction complète du presse-papier.
Etape IV – Test Presse-papier avec restriction complète :
Cette seconde machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
2 configurations sont présentes dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
Continuons avec un troisième test avec une restriction sur le presse-papier depuis le poste local.
Etape V – Test Presse-papier avec restriction depuis le poste local :
Cette troisième machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
1 configuration est présente dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
Le copier-coller d’un fichier depuis AVD vers le poste local fonctionne
Continuons avec un quatrième test avec une restriction sur le presse-papier depuis AVD.
Etape VI – Test Presse-papier avec restriction depuis AVD :
Cette quatrième machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
1 configuration est présente dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD fonctionne
Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
Continuons avec un dernier test avec une restriction sur le format de donnée sur le presse-papier.
Etape VII – Test Presse-papier avec restriction sur le format de donné :
Cette dernière machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
2 configurations sont présentes dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
Le copier-coller d’un texte depuis AVD vers le poste local fonctionne
Le copier-coller d’une image depuis AVD vers le poste local fonctionne
Conclusion
La mise en place de restrictions sur le presse-papier via Intune renforcera la sécurité et son importance cruciale dans les environnements virtuels. En limitant le transfert de fichiers et certaines données sensibles, nous pouvons renforcer significativement la protection des informations.
Enfin, Intune permet de simplifier la gestion des politiques de sécurité Azure Virtual Desktop et Windows 365 via ses nombreuses règles disponibles sur étagère.
Microsoft vient d’annoncer lors de l’Ignite 2024 le plan de mise à l’échelle dynamique pour Azure Virtual Desktop. Mais qu’apporte donc cette nouvelle méthode dite dynamique à cette fonctionnalité déjà existante sur Azure Virtuel Desktop? C’est ce que nous allons voir ensemble dans cet article, encore dans un état de préversion à l’heure où ces lignes sont écrites.
Mais qu’est-ce que le plan de mise à l’échelle ?
La plan de mise à l’échelle, ou autoscaling en anglais, est déjà disponible pour les environnements AVD mutualisés et individuels depuis déjà quelques temps. Deux articles parlant de ce sujet sont déjà disponibles sur ce blog :
La mise à l’échelle automatique vous permet d’effectuer un scale-up ou un scale-down de vos hôtes de session de machines virtuelles dans un pool d’hôtes pour optimiser les coûts de déploiement.
Microsoft a mis à jour sa documentation afin d’expliquer en détail les 4 grandes fonctionnalités de la mise à l’échelle dans le cadre d’un environnement AVD partagé :
Voici d’ailleurs une représentation diapo de trois d’entre elles :
Comme le montre la première animation ci-dessus, la mise à l’échelle sur un environnement Azure Virtual Desktop partagé peut allumer progressivement des machines virtuelles quand une certaine limite d’utilisateurs est atteinte.
Comme le montre la seconde animation ci-dessus, la mise à l’échelle sur un environnement Azure Virtual Desktop partagé peut éteindre des machines virtuelles éteintes tant celles-ci ne sont pas exploitées.
Comme le montre la troisième animation ci-dessus, la mise à l’échelle sur un environnement Azure Virtual Desktop partagé peut forcer des utilisateurs à se déconnecter que si vous avez activé ce paramètre dans la phase de descente en charge uniquement.
Grâce à ces différents mécanismes, le plan de mise à l’échelle vous permet de moduler à la hausse ou à la baisse le nombre de VMs allumées à un moment précis selon les besoins.
Mais quelles sont les 4 phases du plan de mise à l’échelle?
Vous pouvez établir un plan de mise à l’échelle basé sur :
Des créneaux horaires exprimés en heures.
Des créneaux journaliers exprimés en jours.
Tous les plannings de mise à l’échelle AVD comprennent les 4 phases suivantes :
Montée en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se connecter aux hôtes de session. Par exemple, si votre bureau ouvre à 9h, vous pouvez prévoir que les utilisateurs commencent à se connecter entre 8h30 et 9h.
Période de pointe : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de connexion stable. Par exemple, entre 09h et 17h, la plupart des utilisateurs sont connectés et travaillent activement. De nouveaux utilisateurs peuvent se connecter, mais à un rythme plus lent que pendant la montée en charge.
Descente en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se déconnecter et à terminer leurs sessions pour la journée de travail. Par exemple, entre 17h et 18h, les utilisateurs commencent à se déconnecter. Dans cette phase, vous pouvez définir un pourcentage minimum plus bas d’hôtes actifs et une taille minimale de pool d’hôtes pour réduire le nombre de VM d’hôtes de session en état de fonctionnement ou arrêtées.
Hors-période : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de déconnexion stable. Par exemple, après 20h, la plupart des utilisateurs sont déconnectés. De nouveaux utilisateurs peuvent se connecter pour des scénarios d’urgence, mais ces cas peuvent être rares.
Azure Virtual Desktop propose également des graphiques afin de comprendre le gain et l’efficacité du mécanisme :
Mais qu’apporte la méthode dynamique du plan de mise à l’échelle ?
Peu importe la méthode choisie, les phases et les fonctionnalités d’un plan de mise à l’échelle restent les mêmes. Mais ce qui change concerne directement les machines virtuelles AVD :
Dans la méthode dite Gestion de l’énergie : la plan de mise à l’échelle peut allumer et éteindre des machines virtuelles AVD selon les usages et la programmation mise en place.
Dans la méthode dite dynamique : la plan de mise à l’échelle peut créer ou supprimer des machines virtuelles AVD selon les usages et la programmation mise en place.
La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de la machine virtuelle (VM) sous-jacente, l’image du système d’exploitation (OS) et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session. La mise à jour de l’hôte de session désalloue ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour. Cette méthode de mise à jour des hôtes de session est conforme à la suggestion de gestion des mises à jour au sein de l’image source principale, plutôt que de distribuer et d’installer les mises à jour sur chaque hôte de session individuellement selon un calendrier répété continu pour les maintenir à jour.
Voici les modifications que vous pouvez apporter lors d’une mise à jour :
Cette approche de création / suppression intégrée permet donc de réduire encore plus les coûts.
Couplée avec la mise à jour de l’hôte de session, la création et la suppression de machines virtuelles AVD devient d’autant plus simple, et assure de toujours disposer de ressources Azure Virtual Desktop dans leur dernière version.
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Il est également nécessaire de renseigner un nombre maximal de sessions AVD :
Commençons par ajouter des permissions RBAC nécessaires à la gestion des VMs AVD.
Etape I – Ajout des permissions RBAC :
Le traitement de création/suppression des machines virtuelles AVD a besoin de lire la configuration gérée par le nouvelle orchestrateur en chargement de votre pool d’hôtes. Il est pour l’instant nécessaire créer un rôle Azure personnalisé afin de pouvoir récupérer ces informations.
Pour cela, rendez-vous dans le portail Azure, puis commencez sa création depuis le groupe de ressources contenant votre environnement AVD :
Nommez votre nouveau rôle personnalisé, puis cliquez sur Suivant :
Recherchez la permission suivante, puis cliquez sur lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre rôle Azure personnalisé :
Toujours sur votre groupe de ressources AVD, assignez à l’application Azure Virtual Desktop les 3 rôles suivant, en plus de votre nouveau rôle personnalisé :
Contributeur de mise sous et hors tension de la virtualisation du Bureau
Contributeur à la machine virtuelle de la virtualisation des postes de travail
Utilisateur de Key Vault Secrets
Une fois les droits en place, il ne reste qu’à rajouter la mise à l’échelle dynamique sur notre environnement Azure Virtual Desktop.
Etape II – Création du plan de mise à l’échelle dynamique :
Comme avant, la création d’un plan de mise à l’échelle dynamique AVD apporte les avantages / restrictions suivants :
Le plan de mise à l’échelle dynamique est utilisable pour un ou plusieurs environnement Azure Virtual Desktop, à la condition que ces derniers nécessitent une gestion horaire identique
Ne pas associer le plan de mise à l’échelle dynamique avec d’autres solutions tierces de gestion des ressources Azure
Il n’est pas possible d’associer plusieurs plans de mise à l’échelle dynamique sur un seul environnement AVD
Le plan de mise à l’échelle dynamique est dépendant d’un seul fuseau horaire
Le plan de mise à l’échelle dynamique est configurable sur plusieurs périodes distinctes
Le plan de mise à l’échelle dynamique est opérationnel dès sa configuration terminée
Avant cela, prenez le temps de vérifier la configuration de l’hôte de session AVD déjà en place :
La création du plan de mise à l’échelle dynamique se fait directement sur la page d’Azure Virtual Desktop, cliquez ici pour démarrer sa création :
Remplissez le premier onglet avec vos informations de base et indiquez que votre environnement AVD est partagé :
Choisissez l’option le plan de mise à l’échelle dynamique, puis cliquez sur Suivant :
L’onglet suivant vous permet de définir quand le plan de mise à l’échelle dynamique s’active pour suivre les besoins de montée / descente en puissance tout au long de la journée.
Cliquez comme ceci pour ajouter votre première période :
Choisissez un Nom, puis sélectionnez les Jours adéquats (les valeurs par défaut qui s’affichent lorsque vous créez une planification sont les valeurs suggérées pour les jours de la semaine, mais vous pouvez les modifier selon vos besoins) :
Les informations ci-dessous de l’onglet Général ne servent qu’à définir les valeurs reprises dans les autres onglets :
Pourcentage minimum d’hôtes actifs :exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée :
Par exemple, si le pourcentage minimum d’hôtes actifs (%) est fixé à 10 et que la taille minimum du pool d’hôtes est fixée à 10, le plan de mise à l’échelle dynamiqueveillera à ce qu’un hôte de session soit toujours disponible pour accepter les connexions des utilisateurs.
Nombre min de VMs : nombre de machines virtuelles hôtes de session devant toujours faire partie du pool d’hôtes. Ces dernières peuvent être active ou à l’arrêt niveau OS.
Nombre max de VMs : nombre de machines virtuelles hôtes de session que le plan de mise à l’échelle dynamique ne dépassera pas. Ces dernières peuvent être active ou à l’arrêt niveau OS.
Puis cliquez sur Suivant :
Montée en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se connecter aux hôtes de session.
Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
Seuil de capacité : pourcentage de la capacité disponible du pool d’hôtes qui déclenchera une action de mise à l’échelle.
Puis cliquez sur Suivant :
Dans mon exemple, je n’ai pas modifié les 49% indiqués sur mon environnement avec un minimum 1 et maximum de 2 machines virtuelles. Cela force AVD a :
Si le nombre d’utilisateurs AVD reste sous la limite du nombres de sessions par VM :
Conserver une seule machine virtuelle créée et allumée
Si le nombre d’utilisateurs AVD dépasse la limite du nombres de sessions par VM :
Créer et allumer la seconde machine virtuelle
Période de pointe : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de connexion stable. Il n’est possible que de modifier :
Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
Puis cliquez sur Suivant :
Descente en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se déconnecter et à terminer leurs sessions pour la journée de travail. Il vous est possible de modifier les champs suivant :
Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
Seuil de capacité : pourcentage de la capacité disponible du pool d’hôtes qui déclenchera une action de mise à l’échelle.
Forcer la déconnexion des utilisateurs : Oui / non
Pourcentage minimum d’hôtes actifs :exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée :
Limite du nombre de machines virtuelles actives : exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée.
Nombre min de VMs : nombre de machines virtuelles hôtes de session devant toujours faire partie du pool d’hôtes. Ces dernières peuvent être active ou à l’arrêt niveau OS.
Nombre max de VMs : nombre de machines virtuelles hôtes de session que le plan de mise à l’échelle dynamique ne dépassera pas. Ces dernières peuvent être active ou à l’arrêt niveau OS.
Puis cliquez sur Suivant :
Hors-période : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de déconnexion stable. Il n’est possible que de modifier :
Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
Puis cliquez sur Ajouter :
Il est possible d’ajouter une second planning si besoin, mais uniquement sur les autres jours restants, sinon cliquez sur Suivant :
Sélectionnez le pool d’hôtes concerné et lancez la validation Azure :
Une fois la validation Azure réussie, lancez la Création :
Consultez le plan de mise à l’échelle dynamique :
Avant l’application du plan de mise à l’échelle dynamique, je retrouve bien 3 en nombre de machines virtuelles AVD :
Etape III – Test de suppression de VM :
Après l’application du plan de mise à l’échelle dynamique, je retrouve bien une seule machine virtuelle AVD :
Seule une machine virtuelle est bien encore présente dans mon environnement Azure :
Grâce à Azure Monitor, il est possible de consulter les actions faites par le plan de mise l’échelle dynamique :
Du côté des insights AVD, un nouvel onglet dédié au plan de mise à l’échelle a fait son apparition :
Etape IV – Test de création de VM :
Afin de vérifier la création automatique des machines virtuelles AVD, je décide de connecter un utilisateur à mon environnement afin de dépasser le seuil de capacité :
L’utilisateur est bien référencé comme connecté :
Un nouvel événement est alors visible dans la table et indiquant la création d’une seconde machine virtuelle :
Ce même événement est également visible depuis les insights AVD avec son explication textuelle :
Dans la liste des machines virtuelles de mon environnement, je retrouve bien la seconde VM en cours de création :
Azure Virtual Desktop met à jour au besoin les agents AVD sur la nouvelle machine rajoutée au pool d’hôtes :
La nouvelle machine virtuelle contient bien la dernière version disponible et son nom confirme la bonne jointure au domaine AD :
La nouvelle machine virtuelle devient alors disponible et prête à recevoir des utilisateurs AVD :
Etape V – Second test de création de VM :
Toujours dans la même phase je décide de connecter un second utilisateur AVD :
Ayant configuré un algorithme de répartition de la charge en Depth-first, le second utilisateur se retrouve sur la même machine virtuelle que le premier utilisateur :
Rien ne se passe malgré le dépassement de 50% du total car j’ai configuré un plafond de 2 machines virtuelles durant cette phase de mon plan de mise à l’échelle :
Cette analyse est confirmée ici par le 3ème événement :
Je décide néanmoins de modifier dans mon plan de mise à l’échelle dynamique les 2 valeurs suivantes :
La validation du plan de mise à l’échelle dynamique entraîne, comme attendu, la création immédiate d’une 3ème machine virtuelle AVD :
Cette analyse est confirmée par le 4ème événement :
La 3ème machine virtuelle AVD apparaît bien dans le pool d’hôtes avec un statut disponible :
Etape VI – Second test de suppression de VM :
Pour mon dernier test, je décide de déconnecter mes 2 utilisateurs de test AVD :
Les sessions Azure Virtual Desktop ouvertes disparaissent bien de la console Azure :
Et il ne reste plus aucune machine virtuelle Azure :
Cette analyse est confirmée par le 5ème événement :
A noter qu’un minimum de 0 sessions actives entraîne le message d’erreur suivant pour l’utilisateur :
Conclusion
En conclusion, nous avons découvert que ce plan permet une gestion flexible et efficace des ressources, assurant ainsi une optimisation des coûts et une disponibilité continue des services.
L’activation automatique d’une machine virtuelle supplémentaire en réponse à une demande accrue, ainsi que la réduction rapide du nombre de machines en cas de baisse d’activité, illustrent la capacité de ce service à s’ajuster en temps réel aux besoins des utilisateurs.
En somme, Azure Virtual Desktop, grâce à son plan de mise à l’échelle dynamique, propose une solution robuste pour la gestion des environnements de travail virtuels.
Avec la toute nouvelle fonctionnalité appelée Session host update d’Azure Virtual Desktop, Microsoft vient de lâcher une petite bombe dans la gestion des VMs AVD. Imaginez Azure Virtual Desktop remplaçant comme un grand des VMs obsolètes pour les remplacer par d’autres basées sur votre toute dernière image ? Vous ne rêvez pas, tout cela est maintenant disponible en préversion !
Comment faisait-on avant pour mettre à jour son AVD ?
Avant l’introduction de cette nouvelle fonctionnalité, la mise à jour des hôtes de session Azure Virtual Desktop (AVD) nécessitait une gestion manuelle plus intensive. Ce processus impliquait souvent plusieurs étapes, telles que :
Planification des mises à jour : Identifier les hôtes de session nécessitant des mises à jour et planifier les fenêtres de maintenance.
Exécution des mises à jour : Utiliser des scripts ou des outils pour appliquer les mises à jour sur chaque hôte de session.
Vérification et validation : S’assurer que les mises à jour ont été appliquées correctement et que les hôtes de session fonctionnent comme prévu.
Ces étapes pouvaient être chronophages et nécessitaient une surveillance constante pour minimiser les interruptions de service et garantir la conformité des systèmes.
Qu’est ce que les nouvelles Mises à jour AVD ?
La nouvelle fonctionnalité simplifie ce processus en automatisant la gestion des mises à jour, réduisant ainsi la charge administrative et améliorant l’efficacité opérationnelle.
Microsoft nous décrit cette toute nouvelle fonctionnalité AVD en seulement quelques phrases :
La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de la machine virtuelle (VM) sous-jacente, l’image du système d’exploitation (OS) et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session.
La mise à jour de l’hôte de session désalloue ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour.
Cette méthode de mise à jour des hôtes de session est conforme à la suggestion de gestion des mises à jour au sein de l’image source principale, plutôt que de distribuer et d’installer les mises à jour sur chaque hôte de session individuellement selon un calendrier répété continu pour les maintenir à jour.
Informations d’identification de jonction de domaine Active Directory
Inscription à Microsoft Intune
Informations d’identification de l’administrateur local
Script PowerShell de configuration personnalisé
Quid des machines virtuelles AVD éteintes ou avec le mode de drainage ?
L’état d’alimentation et le mode de drainage existants des hôtes de session sont respectés. Vous pouvez effectuer une mise à jour sur un pool d’hôtes où tous les hôtes de session sont désalloués pour réduire les coûts.
Existe-t-il des limitations ?
Encore en préversion Microsoft nous liste les principales limitations juste ici :
La mise à jour de l’hôte de session est uniquement disponible dans le cloud Azure global. Il n’est pas disponible dans d’autres clouds, tels qu’Azure US Government ou Azure exploité par 21Vianet.
Pour les hôtes de session créés à partir d’une image partagée Azure Compute Gallery disposant d’un plan d’achat, le plan n’est pas conservé lorsque les hôtes de session sont mis à jour. Pour vérifier si l’image que vous utilisez pour vos hôtes de session dispose d’un plan d’achat, vous pouvez utiliser Azure PowerShell ou Azure CLI.
La taille du disque du système d’exploitation ne peut pas être modifiée pendant une mise à jour. Le service de mise à jour utilise par défaut la même taille que celle définie par l’image de la galerie.
Lors d’une mise à jour, vous ne pouvez pas ajouter d’autres hôtes de session au pool d’hôtes.
Si une mise à jour échoue, le pool d’hôtes ne peut pas être supprimé tant que la mise à jour n’est pas annulée.
Si vous décidez de créer une image extraite d’un hôte de session existant que vous utilisez ensuite comme image source pour la mise à jour de votre hôte de session, vous devez supprimer le dossier C:\packages\plugin avant de créer l’image. Dans le cas contraire, ce dossier empêche l’exécution de l’extension DSC qui joint les machines virtuelles mises à jour au pool d’hôtes.
Si vous utilisez Azure Virtual Desktop Insights, l’agent Azure Monitor ou l’agent Log Analytics n’est pas automatiquement installé sur les hôtes de session mis à jour. Pour installer l’agent automatiquement, voici quelques options :
Évitez de modifier une configuration d’hôte de session dans un pool d’hôtes sans hôtes de session en même temps qu’un hôte de session est créé, car cela peut entraîner un pool d’hôtes avec des propriétés d’hôte de session incohérentes.
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Pour réaliser cet exercice de mise à jour de l’hôte de session pour Azure Virtual Desktop, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire d’effectuer une demande à Microsoft via le formulaire suivant, dont le point le plus important à retenir est :
Please note, the session hosts and host pools in this preview cannot be used for any type of production workload.
Autrement dit : pas de tests sur un environnement de production 😎
Etape I – Préparation du domaine AD :
Avant tout, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création par la barre de recherche :
Nommez celui-ci, puis cliquez sur Suivant :
Considérer au besoin les différents services de sécurité, puis cliquez sur Suivant :
Validez le plan d’adressage réseau et sous-réseau, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1minute :
Une fois le réseau virtuel déployé, recherchez le service Microsoft Entra Domain Services depuis la barre de recherche Azure :
Cliquez-ici pour créer ce service d’AD managé sur votre tenant :
Renseignez ses informations de base dont son nom et le SKU de type Standard, puis cliquez sur Suivant :
Validez les propriétés réseaux, puis cliquez sur Suivant :
Adaptez au besoin les membres du groupe d’administrateurs créé par défaut à votre domaine managé, puis cliquez sur Suivant :
Définissez le périmètre de synchronisation, puis cliquez sur Suivant :
Parcourez les options liées à la sécurité de votre domaine managé, puis lancez la validation Azure :
Cliquez sur Créer pour lancez sa création :
Lisez l’avertissement sur le blocage de modifications après sa création, puis cliquez sur OK :
Attendez environ 30 minutes la première phase de déploiement des ressources Azure :
Environ 30 minutes plus tard, cliquez-ici pour parcourir les ressources Azure liées à votre domaine managé :
Comme vous le constatez, une phase de post-déploiement prend le relai pendant encore 25 minutes environ :
Approximativement 25 minutes plus tard, la phase de post déploiement est maintenant terminée. Cliquez-sur le message ci-dessous pour corriger le problème lié aux enregistrements DNS de votre réseau virtuel :
Lancez-le diagnostique en cliquant sur Lancer :
Corrigez l’adressage DNS de votre réseau virtuel en cliquant sur Réparer :
Confirmez votre choix en cliquant à nouveau sur Réparer :
Vérifiez la disparition de la notification d’alerte sur votre domaine managé :
Retournez sur le réseau virtuel afin de vérifiez les adresses IP de votre service Entra Domain Services :
Le domaine AD managé est maintenant en place.
La nouvelle méthode de déploiement AVD exige le stockage des informations d’identification dans un Azure Key Vault. Avant de déployer notre environnement AVD de test, nous aurons donc besoin d’un coffre.
Etape II – Création du coffre Azure Key Vault :
Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :
Renseignez les informations de base, puis cliquez sur Suivant :
Activez les 2 options suivantes, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre coffre :
Attendez environ 2 minutes, puis cliquez-ici une fois le déploiement terminé :
Ajoutez les rôles RBAC suivants afin de pouvoir accéder à votre coffre ainsi qu’au service Azure Virtual Desktop via son application 9cdead84-a844-4324-93f2-b2e6bb768d07 :
Ajoutez également le rôle RBAC suivant pour l’application Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07) afin que cette dernière puisse créer et supprimer de nouvelles machines virtuelles :
Retournez dans votre coffre, puis cliquez sur le bouton suivant pour créer les différents secrets :
Créez les 4 secrets suivants un par un :
Compte de domaine (sous la forme admindomain@jlou.local)
Mot de passe du compte de domaine
Compte admin local VM
Mot de passe du compte admin local VM
Cela donne alors la liste de secrets suivante :
Tous les prérequis au déploiement sont maintenant en place. Nous allons pouvoir déployer un nouveau type d’AVD ayant un management automatisé.
Etape III – Déploiement de l’environnement AVD :
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 un pool d’hôtes de type partagé ainsi que le management automatisé, puis cliquez sur Suivant :
Définissez le nombre de machines virtuelles créées ainsi que la région Azure :
Choisissez l’image OS et les caractéristiques techniques de vos machines virtuelles AVD :
Spécifiez le réseau virtuel adéquat :
Reprenez les informations du Key Vault contenant les informations d’identification du compte de domaine :
Reprenez les informations du Key Vault contenant les informations d’identification du compte administrateur local, puis cliquez sur Suivant :
Définissez un nouvel 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 l’assignation des utilisateurs :
Assignez les utilisateurs de test AVD à votre groupe d’application créé :
Vérifiez le bon statut de disponibilité de vos hôtes de session créées :
Afin de s’assurer du bon fonctionnement de notre environnement AVD, connectez-vous à l’URL web d’Azure Virtual Desktop, authentifiez-vous avec un utilisateur de test, puis ouvrez une session AVD :
Cliquez sur Autoriser :
Renseignez les informations de compte de votre utilisateur AVD :
Vérifiez la bonne ouverture de session Windows :
Constatez la présence d’une session AVD ouverte sur une des VM présentes à votre pool d’hôtes :
L’environnement Azure Virtual Desktop est maintenant fonctionnel. La prochaine étape consiste à créer une mise à jour de l’image et donc de déclencher le processus de création de VM et le suppression des anciennes.
Etape IV – Déploiement d’une mise à jour AVD :
Tout commence par la création d’une nouvelle mise à jour AVD, pour cela cliquez-ici :
Définissez ici les options d’Azure Virtual Desktop sur les machines virtuelles :
La case à cocher détermine si AVD doit supprimer les anciennes machines virtuelles une fois ces dernières correctement substituées par de nouvelles.
Le pas de travail par AVD sur les machines virtuelles. Dans mon exemple :
AVD commencera par tester la mise à jour sur 1 seule machine virtuelle.
Si la mise à jour a fonctionné, AVD continuera par mettre à jour 2 VMs.
AVD terminera par mettre à jour les 2 dernière VMs
Définissez vos paramètres, puis cliquez sur Suivant :
Apportez les modifications de taille, d’image ou d’autres paramètres sur votre template AVD, puis cliquez sur Suivant :
Planifiez la mise à jour AVD immédiatement ou programmée par la suite, puis cliquez sur Suivant :
Personnalisez au besoin le message d’information reçu par les utilisateurs encore connectés, puis lancez la validation Azure :
Une fois la validation Azure réussie, retrouvez en gras les modifications apportées, puis lancez la mise à jour AVD :
Une fois la mise à jour enclenchée, l’écran des machines virtuelles AVD vous affiche 2 informations sur le traitement en-cours :
Le processus de mise à jour vient de démarrer, aucune VM n’a encore été remplacée, le pourcentage de progression est donc de 0.00 %.
La version actuellement en place sur les machine virtuelle AVD n’est plus la plus récente.
Après un rafraîchissement de la page, Azure Virtual Desktop commence sa mise à jour sur une première machine virtuelle AVD. Cela est visible par l’activation du mode de drainage sur une seule VM :
A ce même moment, une nouvelle machine virtuelle, dont la racine du nom reprend celle qui sera remplacée, fait son apparition et est en cours de création :
Une fois la nouvelle machine virtuelle créée, AVD nous informe que la VM déjà en place est en cours d’arrêt:
Cette information est confirmée dans la liste des machines virtuelles Azure :
Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle du pool d’hôtes AVD et du domaine Active Directory :
Juste après, Azure Virtual Desktop ajoute la nouvelle machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :
Azure Virtual Desktop met à jour au besoin les agents AVD sur la nouvelle machine rajoutée au pool d’hôtes :
La nouvelle machine virtuelle contient bien la dernière version disponible et son nom confirme la bonne jointure au domaine AD :
L’ancienne machine virtuelle est alors supprimée, comme demandé dans la configuration de la mise à jour AVD :
Le pourcentage de progression passe alors à 20.00 %, en adéquation avec le fait qu’1 machine virtuelle sur 5 est correctement mise à jour. AVD continue le traitement activant le mode de drainage sur 2 machines virtuelles :
A ce même moment, 2 nouvelles machine virtuelles, dont la racine du nom reprend celles qui seront remplacées, font leur apparition en cours de création :
Une fois les nouvelles machines virtuelles créés, AVD nous informe que les 2 VMs déjà en place sont en cours d’arrêt :
Cette information est confirmée dans la liste des machines virtuelles Azure :
Après cela, Azure Virtual Desktop retirent les 2 anciennes machines virtuelles du pool d’hôtes AVD et du domaine Active Directory :
Juste après, Azure Virtual Desktop ajoute les 2 nouvelles machines virtuelles au pool d’hôtes AVD et au domaine Active Directory :
Le pourcentage de progression passe alors à 60.00 %, en adéquation avec le fait que 3 machine virtuelle sur 5 sont correctement mises à jour. AVD continue le traitement activant le mode de drainage sur les 2 dernières machines virtuelles :
A ce même moment, 2 nouvelles VMs sont créées, l’ancienne VM sans session utilisateur est en cours d’arrêt, tandis que celle contenant une session utilisateur reste encore active :
Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle sans session du pool d’hôtes AVD, tandis que celle contenant une session utilisateur reste encore présente :
Un message d’information apparaît dans la session encore ouverte de l’utilisateur AVD :
Quelques minutes plus tard, la session AVD est terminée sans action de l’utilisateur :
Le pourcentage de progression passe alors à 80.00 %, en adéquation avec le fait qu’une seule machine virtuelle sur cinq n’est pas encore mise à jour :
Azure Virtual Desktop force la déconnexion afin de déclencher l’arrêt de la machine virtuelle AVD :
Après cela, Azure Virtual Desktop retire la dernière machine virtuelle du pool d’hôtes AVD :
Juste après, Azure Virtual Desktop ajoute la dernière machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :
Toutes les anciennes machines virtuelles AVD ont bien été supprimées :
La mise à jour est maintenant terminée car toutes les machines virtuelles ont maintenant et correctement été mise à jour :
L’utilisateur déconnecté peut alors tenter une reconnexion à AVD :
L’utilisateur constate alors le passage à une nouvelle version de son OS :
AVD ouvre la nouvelle session Windows sur 1 des 5 machines virtuelles du pool d’hôtes :
Conclusion
Cette fonctionnalité vous permet de maximiser l’efficacité et la flexibilité de votre infrastructure virtuelle. Grâce à des outils avancés et des stratégies éprouvées, vous pouvez améliorer la gestion de vos ressources, réduire les coûts opérationnels et offrir une expérience utilisateur optimisée. Découvrez par vous-même comment l’orchestration de votre AVD peut transformer votre environnement de travail virtuel.
Azure Virtual Desktop propose depuis longtemps la possibilité d’exploiter des machines virtuelles avec GPU pour des traitements graphiques plus ou moins gourmands. Mais des limitations persistaient, et notamment le nombre de FPS que l’utilisateur pouvait obtenir via sa connexion en bureau à distance. Et tout cela vient de changer avec une nouvelle préversion proposée par Microsoft !
H.265 vs H.264 ?
HEVC (High Efficiency Video Coding), également appelé H.265. Cela permet une compression de données de 25 à 50 % par rapport à AVC/H.264, pour la même qualité vidéo ou une meilleure qualité avec la même vitesse de transmission que si la vidéo était encodée avec AVC/H.264.
L’accélération GPU dans Azure Virtual Desktop améliore l’expérience utilisateur pour trois composants :
Rendu d’application accéléré par GPU : Le GPU aide à afficher des graphismes plus rapidement dans une session à distance. Par exemple, si vous utilisez une application de dessin, les images se dessineront plus vite et seront plus fluides.
Encodage d’images accéléré par GPU : Le protocole RDP (Remote Desktop Protocol) encode les graphismes pour les envoyer à votre appareil. Par exemple, si une partie de l’écran change souvent, comme une vidéo, elle est encodée avec le codec AVC (H.264) pour une transmission plus efficace.
Encodage de vidéos plein écran : Pour des applications exigeantes comme la modélisation 3D, le CAD/CAM, ou l’édition vidéo, un profil vidéo plein écran offre une meilleure qualité d’image et une fréquence d’images plus élevée. Cela utilise plus de bande passante et de ressources. Vous pouvez choisir d’encoder avec :
AVC/H.264 : Un codec standard pour la vidéo.
HEVC/H.265 : Un codec plus efficace qui compresse les données de 25 à 50 % mieux que l’AVC/H.264, offrant la même qualité vidéo avec moins de bande passante.
Caractéristique
H.264 (AVC)
H.265 (HEVC)
Efficacité de compression
Utilise des macroblocs (16×16 pixels)
Utilise des unités de codage (CTU) jusqu’à 64×64 pixels
Taille des fichiers
Plus volumineux
Réduit la taille des fichiers jusqu’à 50%
Compatibilité
Largement pris en charge par de nombreux appareils et plateformes
Moins largement pris en charge, mais le support est en croissance
Puissance de traitement
Nécessite moins de puissance de calcul pour le codage et le décodage
Nécessite plus de puissance de calcul pour le codage et le décodage
Cas d’utilisation
Streaming, disques Blu-ray, diffusions HDTV
Vidéos haute résolution (4K, 8K), scénarios avec bande passante et stockage limités
Qualité vidéo
Bonne qualité vidéo
Meilleure qualité vidéo au même débit binaire
Bande passante
Nécessite plus de bande passante
Nécessite moins de bande passante
Adoption
Universellement adopté
Gagne en popularité, mais fait face à des obstacles de licence
En résumé, si vous avez besoin d’une meilleure compression et travaillez avec des vidéos haute résolution, H.265 est la meilleure option. Cependant, pour une compatibilité plus large et des exigences de traitement plus faibles, H.264 reste un choix logique.
Quelles machines virtuelles Azure sont compatibles ?
La bonne nouvelle est que si vous activez l’accélération matérielle HEVC/H.265 et AVC/H.264, mais que HEVC/H.265 n’est pas disponible sur l’appareil local, alors AVC/H.264 sera alors utilisé à la place.
Microsoft vous liste sur son site les familles de machines virtuelles Azure supportant partiellement ou totalement H.265 :
Les machines virtuelles Azure des séries NC, NCv2, NCv3, ND et NDv2 ne sont généralement pas appropriées comme hôtes de session. Ces tailles de machine virtuelle sont adaptées aux outils de calcul ou de Machine Learning hautes performances spécialisés, comme ceux créés avec NVIDIA CUDA. Elles ne prennent pas en charge l’accélération GPU pour la plupart des applications ni pour l’interface utilisateur Windows.
Pour réaliser cet exercice de FPS sur Azure Virtual Desktop, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Commençons d’abord par vérifier en premier la compatibilité H.265 du poste local.
Etape I – Vérifications H.265 du poste local :
Sur votre poste, ouvrez Windows PowerShell, puis exécutez la commande suivante pour vérifier la présence du codec HEVC :
get-appxpackage *hevc*
Ouvrez maintenant au choix votre application Remote Desktop ou Windows App afin de vérifier les versions :
La configuration locale semble bonne, continuons maintenant sur Azure afin de mettre en place un environnement de test avec GPU.
Etape II – Création de l’environnement Azure Virtual Desktop :
Voici un rappel des familles de machines virtuelles dont les GPUs NVIDIA sont compatibles :
Avant de pouvoir déployer un environnement GPU pour Azure Virtual Desktop, nous avons donc besoin de disposer de quotas sur notre souscription. Pour cela, rendez-vous dans le portail Azure :
Pour mon exemple, j’ai choisi de créer mon environnement AVD sur une machine virtuelle de la familles NCasT4_v3, dont j’ai précédemment augmenté les quotas :
Une fois les quotas en place, nous avons besoin d’avoir un réseau virtuel Azure.
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 1minute :
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 :
Configurez-le comme ceci, puis cliquez sur Suivant :
Choisissez une image OS sous Windows 11 :
Choisissez une taille de VM GPU :
Joignez votre VM à votre réseau virtuel et à Microsoft Entra ID :
Définissez un administrateur local, 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 :
Définissez sur le groupe de ressources les droits RBAC suivants pour votre utilisateur de test AVD :
Notre environnement Azure Virtual Desktop GPU est maintenant en place. La prochaine étape consiste à installer la configuration graphique de base, afin que la carte NVIDIA soit reconnue par Windows et pleinement exploitée.
Etape III – Configuration GPU de l’environnement AVD :
Important :
Pour les tailles des machines virtuelles avec un GPU NVIDIA, seuls les pilotes NVIDIA GRID prennent en charge l’accélération GPU pour la plupart des applications et l’interface utilisateur Windows. Les pilotes NVIDIA CUDA ne prennent pas en charge l’accélération GPU pour ces tailles de machine virtuelle. Si vous souhaitez télécharger et découvrir comment installer le pilote, consultez Installer les pilotes GPU NVIDIA sur les machines virtuelles de série N exécutant Windows et n’oubliez pas d’installer le pilote GRID. Si vous installez le pilote en utilisant l’Extension de pilote GPU NVIDIA, le pilote GRID est automatiquement installé pour ces tailles de machine virtuelle. Pour l’accélération matérielle HEVC/H.265, vous devez utiliser le pilote GPU NVIDIA GRID 16.2 (537.13) ou version ultérieure.
Ouvrez l’application avec votre utilisateur de test AVD, puis lancez l’application de bureau à distance :
Acceptez la demande d’autorisation pour autoriser les connexion RDP vers la VM GPU AVD :
Depuis le menu Démarrer, ouvrez l’application FurMark 2 :
Démarrez le test GPU :
Pendant que FurMark 2 poursuit son test, contrôlez le protocole, l’utilisation du GPU, la bande passante disponible ainsi que le nombre de FPS :
La configuration actuelle limite actuellement le nombre de FPS à 30. Testons maintenant avec la configuration additionnelle.
Etape V – Test utilisateur AVEC :
Pour s’assurer que la fonction débridant les 60 FPS est correctement activée, les clés de registre suivantes doivent être définies sur chaque VM hôte de session.
Ouvrez Windows PowerShell, puis exécutez les commandes suivantes :
Ouvrez l’observateur d’événements Windows et accédez au journal suivant :
Journaux des applications et services
Microsoft
Windows
RemoteDesktopServices-RdpCoreCDV
Operational
Recherchez l’ID d’événement 162. Si vous voyez Initial Profile avec la valeur 32768, Alors la connexion de bureau à distance utilise HEVC, ce qui n’est pas encore le cas ici :
Fermez la session utilisateur d’Azure Virtual Desktop :
Relancez la session de bureau à distance :
Réouvrez l’observateur d’événements Windows, puis accédez au journal suivant :
Journaux des applications et services
Microsoft
Windows
RemoteDesktopServices-RdpCoreCDV
Operational
Recherchez à nouveau l’ID d’événement 162. Si vous voyez Initial Profile avec la valeur 32768, Alors la connexion de bureau à distance utilise bien HEVC, ce qui maintenant le cas ici :
Rouvrez l’application FurMark 2, et recontrôlez le protocole, l’utilisation du GPU, la bande passante disponible ainsi que le nombre de FPS :
Bravo ! Le nombre de FPS a fait un sacré bon !
Conclusion
Grâce à l’accélération GPU et à l’utilisation des codecs HEVC/H.265 et AVC/H.264, les utilisateurs peuvent désormais bénéficier d’une expérience graphique fluide et de haute qualité, même pour des applications exigeantes comme la modélisation 3D ou l’édition vidéo.
Cette mise à jour d’Azure Virtual Desktop marque un tournant pour les utilisateurs nécessitant des performances graphiques élevées, tout en offrant une meilleure compression et une utilisation plus efficace de la bande passante 😎💪
Microsoft vient d’annoncer il y a peu la disponibilité générale (GA) d’une nouvelle optimisation pour les communications Teams sur les environnements VDI (Azure Virtual Desktop, Windows 365) baptisée SlimCore. Nous allons voir dans cet article de quoi il en retourne, et comment la mettre en place.
Prenons un peu de temps pour resituer ce changement majeur pour la VDI.
Qu’est-ce que SlimCore ?
SlimCore est un moteur multimédia développé par Microsoft pour remplacer WebRTC (Web Real-Time Communication) dans certaines applications comme Microsoft Teams. Il gère l’audio, la vidéo et le partage d’écran dans le nouveau client Teams pour ordinateur, offrant de meilleures performances, qualité et fiabilité par rapport à WebRTC.
Les principaux avantages de SlimCore sont :
Parité des fonctionnalités et performances : SlimCore permet à Teams sur l’infrastructure de bureau virtuel (VDI) d’avoir des fonctionnalités et des performances similaires à celles du client Teams natif, ce qui facilite l’ajout rapide de nouvelles fonctionnalités et la réduction des écarts présents avec WebRTC.
Amélioration de la qualité des appels : SlimCore optimise les performances audio et vidéo, réduisant les problèmes tels que les interruptions d’appels et la latence.
Mises à jour automatiques : SlimCore est mis à jour automatiquement, garantissant que le moteur multimédia reste compatible avec les dernières fonctionnalités de Teams, sans nécessiter d’intervention manuelle ou de mises à jour d’infrastructure.
SlimCore vs WebRTC ?
SlimCore est plus performant et optimisé pour Microsoft Teams, en particulier dans des environnements VDI, avec des mises à jour transparente et une intégration plus poussée dans l’écosystème Microsoft, tandis WebRTC est une solution plus flexible et ouverte, utilisée dans de nombreuses plateformes, mais avec des performances parfois limitées dans des environnements plus complexes comme le VDI :
Caractéristique
SlimCore
WebRTC
Origine et usage
Moteur multimédia propriétaire développé par Microsoft pour Teams. Utilisé dans le client natif et les environnements VDI.
Standard ouvert largement utilisé pour les communications audio, vidéo et partage de données en temps réel via les navigateurs et applications.
Performances et qualité
Optimisé pour une qualité d’appel et de vidéo élevée, même en environnements VDI (réduction de la latence, des déconnexions, meilleure stabilité).
Performance variable selon les configurations réseau et navigateur. Moins optimisé pour les environnements complexes comme VDI.
Support des fonctionnalités
Permet à Microsoft de déployer plus rapidement des nouvelles fonctionnalités dans Teams, sans limitation des standards externes.
Les fonctionnalités sont limitées par le standard et peuvent évoluer plus lentement.
Mises à jour et compatibilité
Mises à jour automatiques et transparentes par Microsoft, sans intervention de l’utilisateur ou de l’administrateur.
Dépend des mises à jour des navigateurs et autres implémentations, ce qui peut entraîner des incompatibilités ou des retards.
Flexibilité et adoption
Spécifiquement intégré dans l’écosystème Microsoft, moins flexible en dehors de cet environnement.
Très flexible et largement adopté par de nombreuses plateformes, adapté à une grande variété d’applications.
Optimisation pour VDI
Conçu pour garantir une parité de performances entre le client natif Teams et Teams sur VDI.
Moins optimisé pour les environnements VDI, avec des écarts de performance par rapport aux clients natifs.
Déploiement des nouvelles fonctionnalités
Fonctionnalités déployées plus rapidement via SlimCore directement dans Teams.
Limité par les capacités de WebRTC, les fonctionnalités avancées peuvent prendre plus de temps à arriver.
Est-ce en rapport avec le nouveau Microsoft Teams ?
Cette évolution est en effet dans la suite de la refonte du client Teams de 2023, dont la GA date d’octobre de cette année-là. Voici quelques-unes des principales caractéristiques et avancées :
Performance améliorée : L’application est désormais deux fois plus rapide tout en consommant jusqu’à 50 % de ressources en moins.
Interface utilisateur simplifiée : Une interface plus soignée et réactive, facilitant la navigation et l’efficacité.
Notifications améliorées : Les notifications sont désormais entièrement gérées dans Teams, avec des paramètres plus personnalisables.
Comptes multiples : Vous pouvez facilement vous connecter à plusieurs comptes professionnels, scolaires et personnels sans avoir à vous déconnecter et vous reconnecter. Cela simplifie grandement la gestion des différents rôles et responsabilités.
Quels sont les quatre grands piliers de Teams VDI ?
C’est ici qu’intervient le remplacement de WebRTC, une technologie open-source utilisée pour le streaming audio et vidéo dans de nombreuses plateformes de collaboration, au profit de SlimCore, interne à Microsoft.
Microsoft en parle des avantages de ce changement juste ici :
Nouvelles fonctionnalités : SlimCore, un nouveau moteur multimédia, remplace WebRTC dans Teams. Cela permet à Teams sur ordinateur et sur VDI (bureau virtuel) d’avoir les mêmes fonctionnalités. Même si toutes les nouveautés ne sont pas disponibles immédiatement sur VDI, nous ne sommes plus limités par WebRTC, ce qui permet d’ajouter les nouvelles options plus rapidement.
Amélioration des performances : Les performances de Teams sur Windows sont maintenant disponibles pour VDI. Cela permet de rejoindre les réunions plus vite, de réduire les coupures d’appels et d’améliorer le succès lors des partages d’écran et des réunions, avec l’utilisation des codecs les plus récents.
Mises à jour automatiques : Microsoft met à jour SlimCore automatiquement sur l’ordinateur de l’utilisateur. Cela se fait sans interruption et sans redémarrage lorsque Teams sur VDI est mis à jour. Ce système permet d’éviter que des versions récentes de Teams interagissent avec des composants anciens, garantissant une meilleure qualité.
Support simplifié : Les administrateurs n’ont besoin de contacter que Microsoft pour tout problème avec Teams sur VDI, car nous gérons l’ensemble de la solution. Nous avons analysé les délais de résolution passés pour réduire la gravité et la fréquence des incidents, et nous investissons aussi dans des solutions de dépannage et d’auto-assistance avec des guides détaillés.
Quelles sont les fonctionnalités présentes dans cette optimisation ?
Microsoft propose une liste des nouvelles fonctionnalités liées à ce changement juste ici :
Fonctionnalité
Disponible
1080p
Oui
Accélération matérielle sur le point de terminaison
Oui
Vue Galerie 3×3 et 7×7
Oui
Qualité de service
Oui
Suppression du bruit
Oui
CACHÉ
Oui
Mode présentateur
Oui
Teams Premium
Oui (En attente : filigrane, mairies, décorer mon arrière-plan)
Effet d’arrière-plan chargé par l’utilisateur
Bientôt disponible
Zoom +/-
Bientôt disponible
Quelles sont les versions Apps ou OS supportant déjà SlimCore ?
L’architecture s’en retrouve principalement modifiée côté client via l’ajout d’un nouveau plugin appelé MsTeamsPlugin.dll :
Comment cela se traduit-il au niveau de son installation ?
Microsoft nous explique les choses assez simplement :
Une fois qu’un plugin est « arrivé » chez le client, Teams envoie des instructions sur la version spécifique du moteur média dont il a besoin et le plugin fait le reste : il contacte le CDN public de Microsoft, télécharge un paquet MSIX et l’installe/enregistre automatiquement sur l’appareil de l’utilisateur. Pas de redémarrage ni de privilèges d’administrateur !
Par défaut, MsTeamsPlugin télécharge et installe automatiquement la version appropriée du moteur multimédia SlimCore sans intervention de l’utilisateur ou d’un administrateur.
Voici ce que l’on retrouve au niveau local :
Get-AppXPackage *SlimCore*
Important : Microsoft stocke jusqu’à 12 versions de SlimCore VDI à des fins de compatibilité, et dans le cas où l’utilisateur accède à différents environnements VDI (par exemple, persistant, où les nouvelles mises à jour automatiques Teams se mettent à jour automatiquement et non persistants, où les nouvelles mises à jour automatiques Teams sont désactivées).
Enfin, la nouvelle solution pour VDI stocke des données spécifiques à l’utilisateur (journaux, les configurations et les modèles IA ou ML, …) sur le poste local au démarrage de Teams sur la session VDI :
Et quid d’une mise à jour Teams côté client ou VDI ?
Grâce à ce changement d’approche, Microsoft a là aussi prévu le coup :
Chaque fois que vous mettez à niveau Teams sur le serveur, une nouvelle version du moteur de médias est déployée sur le client. Plus aucune mise à jour n’est nécessaire sur votre pile VDI (serveur ou client). Les plugins sont compatibles en amont et en aval avec les versions de SlimCore, et les plugins nettoieront également les versions de SlimCore inutilisées ou obsolètes.
Utilisé pour les téléchargements SlimCore et les effets d’arrière-plan
127
Valeur par défaut requise
Non
*.skype.com
TCP : 443, 80
Comment vérifie-t-on si SlimCore est bien utilisé ?
Si toutes les exigences sont en place, SlimCore devrait être automatiquement utilisé dans Microsoft Team lors d’une session VDI. Un contrôle rapide est possible dans le client VDI.
Ouvrez votre client Teams sur votre session VDI, puis cliquez sur le bouton des paramètres :
Puis cliquez sur la fonctionnalité A Propos :
Conclusion
La mise en place de cette nouvelle optimisation Teams dédiée aux environnements VDI montre une priorisation chez Microsoft de ses produits VDI phares que son Azure Virtual Desktop et Windows 365.
La nouvelle optimisation basée sur SlimCore offre de meilleures performances, une configuration d’appel plus rapide, un partage d’écran plus fiable, moins de temps d’arrêt et des résolutions de cas plus rapides.
Offrant de meilleures performances et de nouvelles fonctionnalités telles que la vidéo en 1080p et les mises à jour automatiques, SlimCore a pour objectif est de réduire les problèmes techniques, d’améliorer la qualité des réunions et de simplifier la gestion pour les administrateurs IT.
Azure Virtual Desktop propose différentes options dans l’authentification Entra ID, comme le SSO, l’accès conditionnel, ou encore la combinaisons des 2 😎. Microsoft nous apporte justement une petite évolution sur ce mois de juin 2024. Annoncée via un email pour une partie d’entre-nous, je souhaitais refaire un point sur la configuration SSO et les différentes polices possibles dans l’accès conditionnel AVD.
Il y a quelques jours, certains ont peut-être reçu l’email suivant de la part de Microsoft Azure :
Upcoming change for conditional access policies that target the Microsoft Remote Desktop Entra ID cloud app for Azure Virtual Desktop single sign-on.
You’re receiving this notice because you have conditional access policies that explicitly include or exclude the Microsoft Remote Desktop Entra ID cloud app and use single sign-on.
This change timeline was initially targeted for April 2024. We’ve extended the timeline to 26 June 2024. Azure Virtual Desktop clients will transition to the Windows Cloud Login Entra ID cloud app for Windows authentication when single sign-on is enabled. Windows authentication will continue to work as expected when single sign-on isn’t enabled. Additionally, conditional access policies targeted towards the Azure Virtual Desktop Entra ID cloud applications will continue to be applied across resource retrieval, gateway authentication, and diagnostic processes.
Since you’re using single sign-on for Azure Virtual Desktop and have conditional access policies that specifically include or exclude the Microsoft Remote Desktop Entra ID cloud app you’ll need to update your policies to also include or exclude the Windows Cloud Login Entra ID cloud app.
Microsoft Remote Desktop Entra ID cloud app ID: a4a365df-50f1-4397-bc59-1a1564b8bb9c
Windows Cloud Login Entra ID cloud app ID: 270efc09-cd0d-444b-a71f-39af4910ec45
If you have existing conditional access policies targeting the Microsoft Remote Desktop Entra ID cloud app, action is required to ensure policies continue to be applied as intended.
Required action
We recommend you update any conditional access policies that specifically target the Microsoft Remote Desktop Entra ID cloud app to add the Windows Cloud Login Entra ID cloud app to ensure a smooth transition by 26 June 2024.
Reach out to your Azure Global Administrator for Azure Virtual Desktop to develop a plan for deploying these updates to your infrastructure.
Update your internal documentation as needed and if you have a helpdesk, you may want to make them aware of this change.
If you need help developing a plan for deploying the updates, contact your Azure global administrator for Azure Virtual Desktop.
If you have general questions, ask community experts in Microsoft Q&A. If you have a support plan and you need technical help, open a support case in the Azure portal and select the question mark icon at the top of the page.
————————————————————-
Voici en quelques mots de ce que l’on peut en dire sur ce changement sur les polices d’accès conditionnel destinés à Azure Virtual Desktop :
Vous recevez cet avis parce que vous avez des politiques d’accès conditionnel qui incluent ou excluent explicitement l’application cloud Microsoft Remote Desktop Entra ID et/ou utilisent l’authentification unique.
La date limite de transition est prévue pour le 26 juin 2024 :
Changement : Les clients Azure Virtual Desktop utiliseront l’application Windows Cloud Login Entra ID pour l’authentification Windows avec SSO.
Impact : Vos politiques d’accès conditionnel actuelles doivent inclure l’application Windows Cloud Login Entra ID en plus de Microsoft Remote Desktop Entra ID.
Les actions requises :
Mettre à jour vos politiques d’accès conditionnel pour inclure l’application Windows Cloud Login Entra ID.
Contactez votre administrateur global Azure pour planifier ces mises à jour.
Mettre à jour votre documentation interne et informer votre service d’assistance.
Le support :
Pour des questions, consultez la communauté Microsoft Q&A ou ouvrez un cas de support dans le portail Azure.
En relisant en détail la documentation Microsoft relative à la configuration SSO pour AVD, j’avais jusqu’à présent configuré le SSO sur des environnements Azure Virtual Desktop de manière incomplète : à savoir uniquement au niveau du pool d’hôtes AVD :
Malgré cette configuration SSO partielle, mes utilisateurs n’avaient aucun souci pour s’y connecter, avec quelques clics supplémentaires.
Je vous propose donc au travers de cet article sur la configuration SSO et les accès conditionnel AVD possibles :
Commençons donc par un rappel de l’expérience utilisateur sans configuration SSO dans le cadre d’un environnement AVD joint directement à Microsoft Entra ID.
Tâche I – Premier test AVD sans SSO :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de l’utilisateur AVD :
Confirmez votre choix en cliquant sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
Renseignez à nouveau votre identifiant et mot de passe utilisateur :
Confirmez à nouveau votre choix en cliquant sur Continuer :
Autoriser la connexion à la machine virtuelle AVD en cliquant sur Oui :
Microsoft nous informe sur le pourquoi de cette boite de dialogue ci-dessus :
Après avoir activé l’authentification Microsoft Entra pour RDP, vous devez configurer les groupes d’appareils cibles. Par défaut, lors de l’activation de l’authentification unique, les utilisateurs sont invités à s’authentifier auprès de Microsoft Entra ID et à autoriser la connexion Bureau à distance lors du lancement d’une connexion à un nouvel hôte de session. Microsoft Entra mémorise jusqu’à 15 hôtes pendant 30 jours avant de vous présenter une nouvelle invite. Si une boîte de dialogue pour autoriser la connexion Bureau à distance s’affiche, sélectionnez Oui pour vous connecter.
L’expérience réalisée nous montre que le SSO n’est pas opérationnel. Microsoft nous explique qu’il est possible de l’améliorer :
Vous pouvez masquer cette boîte de dialogue et fournir l’authentification unique pour les connexions à tous vos hôtes de session en configurant une liste d’appareils approuvés. Vous devez créer un ou plusieurs groupes dans Microsoft Entra ID qui contient vos hôtes de session, puis définir une propriété sur les principaux de service pour les mêmes applications Bureau à distance Microsoft et Connexion au cloud Windows, telles qu’elles sont utilisées dans la section précédente, pour le groupe.
Tâche IV – Configuration AVD pour activer l’authentification unique:
Finissons par l’activation de l’option SSO depuis les propriétés RDP de votre pool d’hôtes AVD :
Il ne reste qu’à refaire un test utilisateur depuis votre client Microsoft Remote Desktop :
Tâche V – Second test AVD avec SSO :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de cet utilisateur :
Confirmez votre choix en cliquant sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
Plus aucune authentification supplémentaire n’est nécessaire, la session de bureau à distance AVD s’ouvre directement :
La fonctionnalité SSO est maintenant en place sur notre environnement Azure Virtual Desktop. Continuons maintenant avec l’accès conditionnel AVD.
Tâche VI – Accès conditionnel actuel AVD (Portail) :
Pour rappel, j’utilise déjà cet accès conditionnel pour protéger l’accès à Azure Virtual Desktop. Voici ma configuration actuelle de la police d’accès conditionnel AVD :
Comme vous pouvez le voir, l’application ciblée est Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07)
Voici l’impact sur l’utilisateur AVD quand cette première police est activée :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de ce premier utilisateur AVD :
L’accès conditionnel AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :
Saisissez votre code PIN :
Touchez physiquement la clef FIDO2 :
Cliquez sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
L’ouverture de la session AVD de ce premier utilisateur se fait automatiquement :
Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :
Continuons avec un second test d’accès conditionnel ciblant cette fois les 2 applications indiquées dans l’email de Microsoft :
Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
Tâche VII – Accès conditionnel actuel AVD (VM) :
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de ce second utilisateur AVD :
Aucune MFA renforcée n’est exigée, mais confirmez votre choix en cliquant sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
Renseignez à nouveau les identifiants Cloud de l’utilisateur AVD :
L’accès conditionnel à la VM d’AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :
Saisissez votre code PIN :
Touchez physiquement la clef FIDO2 :
Cliquez sur Continuer :
L’ouverture de la session AVD de ce second utilisateur se fait dans la foulée du challenge MFA :
Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :
Terminons les tests par une combinaison de 2 polices d’accès conditionnels ciblant les 3 applications AVD.
Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :
Renseignez les identifiants Cloud de cet utilisateur :
L’accès conditionnel Portail fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :
Saisissez votre code PIN :
Touchez physiquement la clef FIDO2 :
Cliquez sur Continuer :
L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :
L’ouverture de la session AVD de ce troisième utilisateur se fait automatiquement sans repasser par un challenge MFA de la police VM :
Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :
Conclusion
Ce mail d’information Microsoft m’a donc permis de correctement configurer le SSO AVD. Il nous explique également la mise à jour nécessaires des polices d’accès conditionnel pour garantir la continuité du service et la sécurité des connexions avec Azure Virtual Desktop.
En intégrant l’application Windows Cloud Login Entra ID avant le 26 juin 2024, vous assurerez une transition fluide et éviterez toute interruption de service 🤘
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.
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 :
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 1minute :
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 :
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 😎🙏.
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 😎🤘
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 :
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 I – Utilisation 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.
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 II – Utilisation 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 optimisations
Front Door Standard
Front Door Premium
Livraison et accélération
Remise de fichiers statiques
Oui
Oui
Livraison de site dynamique
Oui
Oui
Domaines et certificats
Domaines personnalisés
Oui – Validation de domaine basée sur un enregistrement TXT DNS
Oui – Validation de domaine basée sur un enregistrement TXT DNS
Prise en charge de HTTPS
Oui
Oui
HTTPS sur un domaine personnalisé
Oui
Oui
Apportez votre propre certificat
Oui
Oui
Versions prises en charge de TLS
TLS1.2, TLS1.0
TLS1.2, TLS1.0
Mise en cache
Mise en cache des chaînes de requête
Oui
Oui
Gestion du cache (vidage, règles et compression)
Oui
Oui
Purge rapide
No
Non
Préchargement de ressources
No
Non
Paramètres de comportement du curseur
Oui à l’aide du moteur de règles standard
Oui à l’aide du moteur de règles standard
Routage
Équilibrage de charge d’origine
Oui
Oui
Routage basé sur le chemin
Oui
Oui
Moteur de règles
Oui
Oui
Variable de serveur
Oui
Oui
Expression régulière dans le moteur de règles
Oui
Oui
Redirection/Réécriture d’URL
Oui
Oui
Double pile IPv4/IPv6
Oui
Oui
Assistance HTTP/2
Oui
Oui
Préférence de routage non mesurée
Non 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’origine
Tous les ports TCP
Tous les ports TCP
Moteur de distribution de contenu personnalisable et basé sur des règles
Oui
Oui
Règles pour appareils mobiles
Oui
Oui
Sécurité
Règles personnalisées du pare-feu d’applications web
Oui
Oui
Ensemble de règles managées Microsoft
Non
Oui
Protection des bots
Non
Oui
Connexion de liaison privée à l’origine
Non
Oui
Géofiltrage
Oui
Oui
Jeton d’authentification
No
Non
Protection DDOS
Oui
Oui
Analytique et création de rapports
Surveillance Métriques
Oui (plus de métriques que Classic)
Oui (plus de métriques que Classic)
Analyses avancées/rapports intégrés
Oui
Oui – comprend le rapport WAF
Journaux bruts – journaux d’accès et journaux WAF
Oui
Oui
Journal des sondes d’intégrité
Oui
Oui
Simplicité d’utilisation
Intégration facile avec les services Azure, tels que le stockage et les applications Web
Oui
Oui
Gestion via REST API, .NET, Node.js ou PowerShell
Oui
Oui
Types MIME de compression
Configurable
Configurable
Encodages de compression
gzip, brotli
gzip, brotli
Intégration d’Azure Policy
No
Non
Intégration des conseils Azure
Oui
Oui
Identités managées avec Azure Key Vault
Oui
Oui
Tarification
Tarification simplifiée
Oui
Oui
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 🥳
Un premier article avait déjà été écrit sur ce blog à propos d’Azure Stack HCI. La solution proposée par Microsoft vous permet de disposer d’une infrastructure hyperconvergée basée sur les technologies Azure :
Peut-on tester Azure Stack HCI sans investir dans du matériel physique ?
La réponse est oui grâce à Azure Arc Jumpstart ! Vous pouvez recréer un cluster Azure Stack HCI directement dans Azure. L’article précédemment écrit proposait la même approche, mais Jumpstart simplifie grandement le processus.
Qu’est-ce qu’Azure Arc Jumpstart ?
Il s’agit de solutions de type bac à sable proposées par Microsoft :
L’univers de l’Arc Jumpstart. Vous souhaitez explorer plusieurs environnements et découvrir toute l’étendue de Jumpstart ? Obtenez des scénarios automatisés de zéro à héros pour les serveurs compatibles avec Arc, Kubernetes compatible avec Arc, et plus encore. Parcourez les scénarios. Explorez des scénarios du cloud à la périphérie conçus pour répondre à des besoins sectoriels spécifiques.
Comme le montre la page suivante, beaucoup de scénarios y sont proposés :
Mais qu’est-ce qu’HCIBox ?
En quelques mots : il vous permet d’essayer Azure Stack HCI directement dans Azure :
HCIBox est une solution clé en main qui fournit un bac à sable complet pour explorer les capacités d’Azure Stack HCI et l’intégration du cloud hybride dans un environnement virtualisé. HCIBox est conçu pour être complètement autonome au sein d’un seul abonnement Azure et d’un seul groupe de ressources, ce qui permettra à un utilisateur de se familiariser facilement avec Azure Stack HCI et la technologie Azure Arc sans avoir besoin de matériel physique.
Les ressources HCIBox entraînent des frais de consommation Azure, qui dépendent des ressources Azure sous-jacentes telles que le calcul central, le stockage, le réseau.
Voici une idée de ce que peut représenter une HCIBox fonctionnant en 24/7 pendant 31 jours et hébergée en Suisse :
Enfin, une FAQ de la HCIBox est disponible juste ici.
Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice Azure Virtual Desktop fonctionnant grâce à un Azure Stack HCI construit dans une HCIBox elle-même hébergée sur Azure :
Pour réaliser cet exercice, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Etape I – Préparation de l’environnement Azure :
Afin de pouvoir déployer les ressources Azure liées à la HCIBox, il est nécessaire d’avoir un quota CPU suffisant pour une famille particulière de machines virtuelles.
Pour cela, ouvrez votre souscription Azure, puis rendez-vous sur le menu suivant afin de vérifier que le quota de la famille ESv5 est au minimum de 32 cœurs :
Note : Si cela n’est pas le cas, le stylo à droite vous permet de créer une demande de modification de quota. Cette demande sera traitée automatiquement ou génèrera un ticket de support chez Microsoft.
Ouvrez ensuite Azure Cloud Shell via le bouton situé dans la barre en haut de votre portail Azure :
Si l’ouverture d’Azure Cloud Shell est une première sur votre environnement Azure, il vous sera demandé de créer un compte de stockage comme le montre l’exemple ci-dessous :
Une fois Azure Cloud Shell ouvert en PowerShell, exécuter la commande suivante afin de recréer le référentiel Azure Arc Jumpstart sur votre compte de stockage :
Vérifiez la version installée d’Azure CLI avec la commande ci-dessous. Celle-ci doit être supérieure ou égale à la version 2.56.0 :
az --version
Dans le cas où plusieurs souscriptions Azure sont en place sur votre tenant, utilisez la commande suivante afin d’identifier la souscription actuellement sélectionnée :
az account list --query "[?isDefault]"
Utilisez la commande suivante et disponible ici pour changer au besoin la souscription :
az account set
Utilisez la commande suivante afin de vérifier le bon changement de sélection :
az account list --query "[?isDefault]"
Utilisez la commande suivante afin de vérifier que les quotas liés à la région Azure et à la famille de VMs soient suffisants :
az vm list-usage --location westeurope --output table
Créez un principal de service Azure (SP) disposant d’un contrôle d’accès (RBAC) de propriétaire sur la souscription Azure, prenez soin de sauvegarder les 3 valeurs en sortie :
az ad sp create-for-rbac -n "JumpstartHCIBox" --role "Owner" --scopes /subscriptions/$subscriptionId
Vérifiez cette création depuis la page des droits RBAC de votre souscription Azure :
Profitez-en pour Enregistrer le fournisseur de ressources suivant sur votre souscription Azure :
Le statut du fournisseur de ressources change durant cette phase :
Environ 30 secondes plus tard, le statut du fournisseur de ressources change encore une fois :
De retour sur Azure Cloud Shell, mettez à jour la dernière version de Bicep
az bicep upgrade
Récupérez l’identifiant d’objet du fournisseur de ressources Azure Stack HCI de votre tenant :
az ad sp list --display-name "Microsoft.AzureStackHCI Resource Provider"
Votre environnement est maintenant configuré pour commencer le déploiement des ressources Azure de votre HCIBox.
Etape II – Déploiement des ressources Azure :
Pour cela, récupérez le template au format JSON disponible à cette adresse afin de modifier les informations suivantes :
spnClientId : Votre identifiant de principal de service Azure
spnClientSecret : Votre secret de principal de service Azure
spnTenantId : Votre identifiant de tenant Azure
spnProviderId : Votre identifiant de fournisseur de ressources Azure Stack HCI
WindowsAdminUsername : Nom d’utilisateur de l’administrateur
windowsAdminPassword : Mot de passe de l’administrateur
logAnalyticsWorkspaceName : Nom unique pour l’espace de travail HCIBox Log Analytics
deployBastion : Option pour déployer ou non Azure Bastion
Téléversez le fichier template au format JSON modifié sur Azure :
Déplacez le fichier template dans le dossier Bicep :
Lancez la commande suivante afin de créer un groupe de ressources dans la région Azure de votre choix :
az group create --name "jlohci" --location "westeurope"
Lancez la commande suivante afin de déployer les ressources Azure de votre HCIBox :
az deployment group create -g "jlohci" -f "main.bicep" -p "main.parameters.json"
Suivez le déploiement des ressources Azure depuis le nouveau groupe de ressources créé :
Environ 30 minutes plus tard, les ressources Azure de votre HCIBox sont enfin déployées :
Les ressources Azure servant à votre HCIBox sont maintenant en place :
L’étape suivante va consister à déployer différents serveurs nécessaires à votre Cluster Azure Stack HCI. Pour cela, nous utiliserons un script PowerShell déjà préparé.
Etape III – Déploiement des nœudsconnectés via Azure Arc :
Pour lancer ce script, nous devrons ouvrir une session RDP sur la machine virtuelle hôte. Pour cela recherchez la machine virtuelle suivante, puis cliquez sur celle-ci :
Démarrez une session RDP via le service Azure Bastion en utilisant les identifiants renseignés dans le template JSON :
Une fois que vous vous êtes connecté en RDP, le script PowerShell s’ouvre automatiquement :
Note : Une fois terminé, la fenêtre PowerShell du script se fermera automatiquement :
Ce script prendra au total entre 1 et 2 heures avec 10 différentes étapes.
Téléchargement des fichiers VHDX de l’OS Azure Stack HCI :
Configuration de la virtualisation :
Création de la VM de management sous Hyper-V :
Création des 2 VMs représentants les 2 nœuds Azure Stack HCI :
Démarrage des 3 machines virtuelles :
Configurations réseaux et stockages :
A l’intérieur même de la machine virtuelle de management, déploiement d’une autre VM dédiée au réseau :
Finalisation du déploiement de l’infrastructure Azure Stack HCI dont l’enrôlement de nos 2 serveurs sur Azure via Azure Arc:
Comme indiqué plus haut, le script PowerShell se ferme automatiquement à la fin :
Si le script vous affiche une ou plusieurs erreurs, différents journaux d’évènements sont disponibles dans le dossier suivant :
C:\HCIBox\Logs\
Il existe également une page officielle de Troubleshoot juste ici :
Log file
Description
C:\HCIBox\Logs\Bootstrap.log
Output from the initial bootstrapping script that runs on HCIBox-Client.
C:\HCIBox\Logs\New-HCIBoxCluster.log
Output of New-HCIBoxCluster.ps1 which configures the Hyper-V host and builds the HCI cluster, management VMs, and other configurations.
C:\HCIBox\Logs\Generate-ARM-Template.log
Log output of the script that builds the hci.json and hci.parameters.json file
C:\HCIBox\Logs\HCIBoxLogonScript.log
Log output from the orchestrator script that manages the install
C:\HCIBox\Logs\Tools.log
Log output from tools installation during bootstrap
Afin de bien vérifier la connexion à Azure, recherchez le service Azure Arc via la barre du portail Azure :
Vérifiez que les deux nœuds HCI sont présents dans Azure Arc :
Vérifiez que les deux nœuds ont correctement installé avec succès les trois extensions suivantes :
TelemetryAndDiagnostics
AzureEdgeLifecycleManager
AzureEdgeDeviceManagement
Vérifiez également sur le second nœud la présence de ces 3 extensions :
Enfin comme le montre l’image ci-dessous, votre Cluster Azure Stack HCI n’est pas encore déployé :
Azure Stack HCI utilise un processus en 2 étapes pour valider et déployer des clusters Azure Stack HCI dans Azure à l’aide d’un modèle ARM.
Etape IV – Déploiement du cluster Azure Stack HCI :
Avant cela, commencez par ajouter à votre compte Entra ID les 2 rôles Entra ID suivants :
Administrateur Key Vault
Contributeur au compte de stockage
Retournez sur la session RDP ouverte via Azure Bastion, ouvrez l’explorateur de fichiers, faites un clic droit sur le dossier HCIBox, puis ouvrez-le dans VSCode :
Cliquez-ici pour continuer :
Vérifiez que le fichier hci.parameters.json est correct et sans valeurs de paramètre -staging :
Toujours sur la machine virtuelle hôte, ouvrez le portail Azure avec votre identifiant Entra ID, puis rechercher le service suivant :
Sélectionnez Construire votre propre modèle dans l’éditeur :
Collez le contenu du fichier hci.json dans l’éditeur, puis cliquez sur Enregistrer :
Cliquez sur Editer les paramètres :
Collez le contenu de hci.parameters.json dans l’éditeur, puis cliquez sur Enregistrer :
Renseignez votre groupe de ressources, puis lancez la validation Azure :
Une fois la validation Azure réussie, exécutez le template ARM :
Attendez que ce dernier soit terminé :
Environ 15 minutes plus tard, cliquez-ici pour ouvrir à nouveau votre groupe de ressources :
Cliquez sur la nouvelle ressource Azure représentant votre cluster Azure Stack HCI :
Un bandeau vous indique que la validation est réussie mais que le déploiement n’est pas encore effectué. Cliquez-ici pour le lancer :
La mise en place du template ARM vous amène directement sur l’onglet suivant, lancez la validation Azure :
Une fois la validation Azure réussie, lancez le déploiement des ressources, puis attendez :
Suivez l’avancement du déploiement du cluster Azure Stack HCI via le menu suivant :
Environ 2 heures plus tard, cette même page vous indique la fin du déploiement du cluster Azure Stack HCI :
Retournez sur la page principale de votre cluster Azure Stack HCI afin de lancer au besoin les mises à jour disponibles (2402) :
Suivez l’avancement de la mise à jour de votre cluster via le menu suivant :
Environ 2 heures plus tard, cette même page doit vous indiquer la fin de la mise à jour sur de votre cluster Azure Stack HCI :
Votre cluster Azure Stack HCI est enfin installé et à jour. Nous allons maintenant pouvoir nous intéresser à son contenu, à savoir :
les images OS
les réseaux logiques
Etape V – Images OS et réseaux logiques d’Azure Stack HCI :
Avant de pouvoir créer des machines virtuelles sur votre cluster HCI à partir du portail Azure, vous devez créer des images de VM qui peuvent être utilisées comme base. Ces images peuvent être importées de la place de marché Azure ou fournies directement par l’utilisateur.
Cliquez-ici pour importer une image à partir de la Marketplace d’Azure :
Dans mon exemple, j’importe les deux images OS suivantes :
Windows 11 Enterprise multisession + Microsoft 365 Apps, version 23H2
Windows Server 2022 Datacenter: Azure Edition
La première étape consiste à télécharger sur votre cluster les deux images OS :
Environ 2 heures plus tard, le téléchargement des 2 images est terminé :
Comme nous le rappelle Azure Arc Jumpstart, Le réseau de la HCIBox comprend un sous-réseau 192.168.200.0/24 étiqueté VLAN200 :
Network details
Subnet
192.168.200.0/24
Gateway
192.168.200.1
VLAN Id
200
DNS Server
192.168.1.254
Ce réseau est conçu pour être utilisé avec les VMs Arc sur HCIBox. Pour utiliser ce réseau préconfiguré, vous devez créer une ressource réseau logique qui correspond à ce sous-réseau.
Depuis la VM hôte ouverte en RDP, ouvrez le script PowerShell suivant afin de créer le réseau logique sur votre cluster Azure Stack HCI :
Une fois le script correctement exécuté, le réseau logique est visible sur le portail Azure juste ici :
Les information de sous-réseau, de passerelle et de serveur DNS sont bien reprises :
Tous les éléments de configuration sont maintenant en place pour commencer la création de machines virtuelles dans votre cluster Azure Stack HCI.
Avant de déployer un environnement Azure Virtual Desktop, je vous propose de créer une machine virtuelle fonctionnant sous Windows Server 2022.
Etape VI – Déploiement d’une machine virtuelle Windows Server 2022 :
Depuis la page de votre cluster Azure Stack HCI, cliquez-ici pour créer votre première machine virtuelle :
Choisissez un groupe de ressources, donnez un nom à votre VM, puis sélectionnez Standard pour le type de sécurité :
Sélectionnez l’image Windows Server que vous avez téléchargée précédemment, puis définissez sa taille et sa mémoire :
Cochez la case suivant, puis définissez un compte administrateur local :
Joignez la VM au domaine AD créé pour votre Azure Stack HCI, puis cliquez sur Suivant :
Inutile d’ajouter d’autres disques de données, cliquez sur Suivant :
Cliquez-ici pour ajouter une carte réseau :
Nommez la carte réseau, sélectionnez le réseau logique créé précédemment, choisissez la méthode d’allocation sur Automatique, puis cliquez sur Ajouter :
Cliquez sur Suivant :
Ajoutez au besoin des tags, puis cliquez sur Suivant :
Cliquez sur Créer :
Comme pour une ressource Azure classique, vous pouvez suivre toutes les étapes du déploiement :
Environ 20 minutes plus tard, cliquez-ici pour apercevoir les propriétés de votre VM :
Copiez l’adresse IP privée de votre nouvelle VM :
Depuis la session ouverte via Azure Bastion, ouvrez une session Hyper-V sur la machine virtuelle de management :
Utilisez le compte suivant :
Ouvrez une session RDP via l’adresse IP privée de votre nouvelle VM tout en utilisant un compte de domaine :
Constatez la bonne ouverture de session sur votre machine virtuelle Windows Server 2022 :
Le test d’une machine virtuelle individuelle fonctionne bien. Il ne nous reste plus qu’à tester le déploiement d’un environnement Azure Virtual Desktop sur votre cluster Azure Stack HCI.
Etape VII – Déploiement d’Azure Virtual Desktop :
Avant de pouvoir déployer votre environnement Azure Virtual Desktop. Il est conseillé de synchroniser les identités Active Directory avec Entra ID.
Pour cela, ouvrez une session Hyper-V à votre contrôleur de domaine de démonstration :
Utilisez le compte de domaine suivant :
Créez une nouvelle OU, des utilisateurs de test et un groupe dédié à Azure Virtual Desktop :
Depuis la page des utilisateurs d’Entra ID, vérifiez la bonne synchronisation de vos utilisateurs et votre groupe AVD :
Retournez sur la page de votre cluster Azure Stack HCI, puis cliquez-ici pour déployer votre environnement Azure Virtual Desktop :
Renseignez les informations de base de votre pool d’hôtes Azure Virtual Desktop, puis cliquez sur Suivant :
Ajoutez un ou des VMs Azure Stack HCI à votre AVD en reprenant l’image Windows 11 Enterprise multisession :
Définissez sa taille, sa mémoire et son réseau logique :
Joignez-la au domaine Active Directory, renseignez le compte d’administrateur local, 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 :
Attendez environ 1 heure :
L’image ci-dessous vous montre l’apparition des VMs AVD :
Seulement, et contrairement au déploiement de la première VM sous Windows Server 2022, le management invité n’est pas automatiquement installée sur les VMs AVD :
Afin d’éviter un échec de votre déploiement AVD, actualiser la page de votre machine virtuelle AVD régulièrement afin d’activer le management invité dès que cela est possible :
Attendez environ 2 minutes le temps de la préparation :
Copiez le script suivant pour sa mise en place :
Récupérez l’adresse IP privée de votre VM AVD :
Depuis la VM de management, ouvrez une session RDP avec le compte administrateur local :
Collez le script sur la VM AVD :
Sur le portail Azure, activez le management invité de votre VM dès que cela est possible :
Suivez l’activation du management invité par le menu suivant :
Rafraichissez la page plusieurs fois si nécessaire :
Environ 30 minutes plus tard, le déploiement de votre AVD doit se terminer :
Consultez votre pool d’hôtes AVD depuis le portail Azure :
Vérifiez également la bonne apparition de vos VMs AVD dans votre Active Directory :
Ajoutez votre groupe Entra ID synchronisé à votre AVD en tant qu’utilisateurs AVD :
Démarrez votre client Remote Desktop, puis ouvrez une session AVD sur un utilisateur de test :
Renseignez à nouveau le mot de passe de votre utilisateur :
Attendez quelques secondes l’ouverture de votre session Azure Virtual Desktop :
Conclusion
Grâce à la HCIBox, nous avons rapidement et facilement pu se rendre compte de l’écosystème hybride proposé par Microsoft pour une de leurs solutions phares : Azure Virtual Desktop.
Important : Attention tout de même à ne pas trop dépenser de crédits pour votre HCIBox. pensez à supprimer ou éteindre vos ressources une fois vos tests terminés :
Ce rappel des coûts de la HCIBox m’amène à une autre question :
Est-il rentable de faire fonctionner Azure Virtual Desktop sur Azure Stack HCI quand d’autres solutions on-premise existent également ?
Les avis de la communauté sont partagés, comme l’article écrit par PureRDS :
Plusieurs coûts sont en effet présents pour un Azure Virtual Desktop hébergé sur Azure Stack HCI.
Coûts licences utilisateurs :
Coûts licences infra :
Enfin voici quelques vidéos pour vous faire votre propre opinion 😎 :
