Microsoft Ignite est une conférence annuelle organisée par Microsoft pour les développeurs et les professionnels de l’informatique. Pour la seconde fois en 2021, cette nouvelle édition a commencé aujourd’hui, et se tiendra jusqu’au 04 novembre.
Rappel des points importants
Voici une courte liste, mais pratique, des liens utiles pour ne rien louper de cet événement :
Comme à chaque fois, Microsoft propose à tous de passer des challenges techniques, dans le but d’obtenir des vouchers pour des certifications Microsoft gratuitement. Voici le lien pour s’inscrire et le second lien vers la page des règles officielles.
Liste assez longue et variée des challenges disponibles :
Teams Admin Challenge
Teams Voice Engineer Challenge
Desktop and Device Management Challenge
Dynamics 365 Sales Consultant Challenge
Power Platform Developer Challenge
Azure Admin Challenge
Azure Developer Challenge
Azure Database Admin Challenge
Windows Server Hybrid Admin Challenge
Dynamics 365 Supply Chain Management Challenge
Security Operations Analyst Challenge
Identity + Information Protection Challenge
Pour recevoir ce voucher gratuit :
Finir au moins un challenge durant la fenêtre suivante : du 2 au 30 novembre 2021
Utiliser une adresse mail valide pour recevoir le voucher. Idéalement votre adresse mail utilisée pour votre compte Microsoft Learn
Des restrictions sont bien sûr présentes :
Vous ne pouvez prétendre qu’à une seule offre par personne, quel que soit le nombre de défis relevés
La date d’expiration de cette offre d’examen ne peut en aucun cas être prolongée
Cette offre d’examen ne peut pas être remboursée ou échangée contre de l’argent, un crédit ou un remboursement
Cette offre d’examen n’est pas transférable et est nulle si vous la modifiez, la révisez ou la transférez de quelque façon que ce soit
Une fois le voucher reçu, vous ne pourrez l’utiliser que les pour les examens suivants :
MS-700 : Gestion de Microsoft Teams
MS-720 : Ingénieur vocal Microsoft Teams
MD-100 : Windows 10
MD-101 : Gestion des ordinateurs de bureau modernes
MB-210 : Microsoft Dynamics 365 Sales
PL-400 : Développeur Microsoft Power Platform
AZ-104 : Administrateur Microsoft Azure
AZ-204 : Développement de solutions pour Microsoft Azure
DP-300 : Administration de bases de données relationnelles sur Microsoft Azure
AZ-800 : Administration de l’infrastructure de base de Windows Server Hybrid
AZ-801 : Configuration des services avancés de Windows Server Hybrid
MB-330 : Microsoft Dynamics 365 Supply Chain Management (gestion de la chaîne d’approvisionnement)
SC-200 : Analyste des opérations de sécurité Microsoft
SC-300 : Administrateur des identités et des accès Microsoft
SC-400 : Administrateur de la protection des informations Microsoft
Profitez bien pour enrichir vos connaissances et prenez le temps de suivre quelques lives ????????
La haute disponibilité consiste à éliminer les points de défaillance, ce qui implique donc de mettre en place de la redondance. En contrepartie, la reprise après sinistre prend le relais là où la haute disponibilité a échoué. Ce second sujet avait déjà été abordé dans l’article Mettre en place un Disaster Recovery sur Suisse Ouest.
Dans cet article, je souhaite vous parler des zones de disponibilité, déjà présentes dans plusieurs régions Azure, permettant de simplifier les architectures demandant une haute disponibilité. Avant d’aller plus loin, voici un rappel de plusieurs définitions Azure :
Schéma expliquant l’architecture locale d’Azure.
Qu’est-ce qu’une zone géographique ?
Une zone géographique Azure désigne une zone du monde contenant au moins une région Azure. Les zones géographiques définissent un marché discret, qui contient généralement deux régions ou plus qui préservent la résidence des données et les limites de conformité.
En termes simples, une région Azure est un ensemble de centres de données reliés par un réseau dédié à faible latence. Combien de datacenters une région contient-elle ? Eh bien, nous n’avons pas de nombre fixe. Il varie. Il existe des régions de différentes tailles. Une région peut être composée d’un seul ou de plusieurs centres de données. Le fait est qu’une région Azure est un groupe d’un ou plusieurs centres de données Azure.
Les zones de disponibilité sont des emplacements physiquement séparés au sein de chaque région Azure qui tolèrent les défaillances locales. Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue grâce à la redondance et à l’isolation logique des services Azure. Pour garantir la résilience, au moins trois zones de disponibilité distinctes sont présentes dans toutes les régions qui ont des zones de disponibilité.
Azure est composé de plus de 200 centres de données physiques, organisés en régions et liés par l’un des plus grands réseaux interconnectés du monde.
Comment faire de la haute disponibilité sur Azure ?
Sur Azure, la redondance des services est possible grâce à la multiplication des centres de données à travers le monde. Pour les données stockées sur le Cloud, elles sont systématiquement copiées au minimum 3 fois (Il ne s’agit pas ici des sauvegardes utilisateurs).
Certains services Azure apporte donc une haute disponibilité en étant réparti sur plusieurs régions, zones de disponibilité ou même groupes de disponibilité. A ne pas confondre avec d’autres services (ex. Azure AD) fonctionnant de manière globale ou régionale (ex. réseaux virtuels), où la haut disponibilité est automatiquement assurée par Microsoft. Un lien par service est disponible ici.
Peut-on faire de la haute disponibilité avec de la récupération d’urgence ?
Deux sujets connexes, mais souvent confondus, entrent en jeu dans l’architecture des systèmes qui atténuent les risques de défaillance : la haute disponibilité (HA) et la reprise après sinistre (DR) :
La haute disponibilité consiste à éliminer les points de défaillance uniques
La reprise après sinistre est le processus consistant à remettre un système dans un état opérationnel lorsqu’il est rendu inopérant
La vidéo ci-dessous vous permet de bien comprendre les différents scénarios possibles pour envisager une récupération d’urgence sur Azure en fonction de deux objectifs très précis :
Objectif de temps de rétablissement (RTO) : durée maximale pendant laquelle un système peut être hors service avant d’être rétabli dans un état opérationnel. Pour certains systèmes, cet objectif de temps de récupération peut être mesuré en heures, voire en jours, mais pour les systèmes plus critiques, les objectifs de temps de récupération sont généralement mesurés en secondes.
Objectif de point de récupération (RPO) : quantité de perte de données, mesurée en temps, qui est tolérable en cas de catastrophe. Pour certains systèmes, la perte d’une journée de données peut être acceptable, tandis que pour d’autres, elle peut se limiter à quelques minutes ou secondes.
Les durées RTO et RPO ont de grand impacts sur la manière dont les plans de reprise après sinistre sont mis en œuvre :
Actuellement : Annoncées en 2019 , deux régions Azure fonctionnent en mode jumelé sur le territoire helvétique :
Suisse Nord (Région de Zurich)
Suisse Ouest (Région de Genève)
Qu’est-ce qu’une paire de régions Azure ?
Une paire régionale est constituée de deux régions au sein de la même zone géographique. Azure sérialise les mises à jour de plateforme (maintenance planifiée) à travers les paires régionales, garantissant ainsi qu’une seule région de chaque paire est mise à jour à la fois. Si une panne touche plusieurs régions, au moins l’une des régions de chaque paire est prioritaire pour la récupération.
La région Suisse Ouest n’a pas vocation à être accessible à tous les scénarios. Comme l’indique la copie d’écran ci-dessous, la région est encore restreinte aux scénarios de récupération d’urgence :
Dans la configuration actuelle sur Suisse, il est malgré tout possible de faire la haute disponibilité via du multi régions. Les schémas ci-dessous montrent plusieurs architectures Azure, dont un AKS à haute disponibilité grâce au mode actif/actif :
Et si je souhaite malgré tout envisager une récupération d’urgence ?
Certains services, comme Azure Site Recovery, apportent des solutions de réplications des données et des ressources. Par exemple, le lien suivant donne la marche à suivre pour activer cette fonctionnalité sur une machine virtuelle Azure.
Cette solution est efficace mais présentes quelques désavantages :
Cela n’est pas une solution HA, mais un DR
Le fonctionnement d’un DR est généralement Actif / Passif
La réplication des données est asynchrone
Le coût Azure en sera probablement supérieur (services + transfert des données)
Avant fin 2021 : Microsoft a profité de l’Ignite 2021, organisé en mars dernier, pour nous annoncer l’arrivée des zones de disponibilité (availability zones) pour l’ensemble des zones géographiques Azure :
La bonne nouvelle annoncée pour la Suisse est, selon Microsoft, toujours dans les cartons de 2021. On s’attend à ce que les zones de disponibilités pour Suisse Nord arrivent pour cette fin d’année.
Une fois ces zones ouvertes au public, nous pourrons alors déployer des services Azure sur ces dernières et ainsi accroître certaines SLAs :
Exemple d’architecture
Pour illustrer mon propos, voici en détail les SLA en vigueur pour les machines virtuelles Azure :
Pour toutes les machines virtuelles dont deux ou plusieurs instances sont déployées dans deux ou plusieurs zones de disponibilité de la même région Azure, nous garantissons que la connectivité de la machine virtuelle à au moins une instance sera assurée au moins 99,99 % du temps.
Pour toutes les machines virtuelles dont deux instances ou plus sont déployées dans le même set de disponibilité ou dans le même groupe d’hôtes dédiés, nous garantissons que vous aurez la connectivité de la machine virtuelle à au moins une instance au moins 99,95 % du temps.
Pour toute machine virtuelle à instance unique utilisant des disques SSD Premium ou Ultra Disk pour tous les disques du système d’exploitation et les disques de données, nous garantissons une connectivité de la machine virtuelle d’au moins 99,9 %.
Pour toute machine virtuelle à instance unique utilisant des disques gérés SSDstandard pour les disques du système d’exploitation et les disques de données, nous garantissons une connectivité de la machine virtuelle d’au moins 99,5 %.
Pour toute machine virtuelle à instance unique utilisant des disques gérés HDD standard pour les disques du système d’exploitation et les disques de données, nous garantissons une connectivité de la machine virtuelle d’au moins 95 %.
Cela est toujours bienvenu pour l’optimisation des coûts.
Encore en préversion, vous pouvez déjà tester cette fonctionnalité depuis plusieurs jours en suivant la documentation Microsoft. Dans cet article, je vais mettre en place cette fonctionnalité étape par étape. Nous allons voir ensemble son impact sur un environnement AVD.
La fonction de mise à l’échelle automatique (ou plan d’autoscaling) vous permet de mettre en route des machines virtuelles (VM) Azure Virtual Desktop, en modulant à la hausse ou à la baisse leur nombre.
Cela permet d’optimiser les coûts de déploiement en fonction de vos besoins. Vous pouvez établir un plan d’autoscaling basé sur :
Créneaux horaires
Jours de la semaine
Plafond du nombre de sessions utilisateurs
Etape 0 : Rappel des prérequis
Cette fonctionnalité AVD nécessite de disposer d’un environnement Azure Virtual Desktop déjà en place. Voici donc la liste des composants déjà présents sur mon tenant Azure :
Domaine Active Directory Domain Services (AD DS)
Pool d’hôtes Azure Virtual Desktop
Espace de travail AVD
Groupe d’applications AVD
5 machines virtuelles D4s_v4, déjà jointes à AVD
Point important : Il est nécessaire de définir un nombre maximal de sessions utilisateurs par VM dans la configuration de votre pool d’hôtes :
L’algorithme du pool d’hôtes n’a pas d’importance car le plan d’autoscaling dispose de sa propre option.
Etape I : Création d’un nouveau rôle RBAC
Comme l’indique la documentation Microsoft, il est nécessaire de créer un nouveau rôle RBAC pour assurer la gestion automatique des VMs.
Besoin d’en savoir un peu plus sur les rôles Azure ? Voici une vidéo en français qui devrait vous aider :
Merci à Seyfallahpour cette explication très claire ????.
Vous pouvez suivre la création du rôle personnalisé via cette aide Microsoft, ou en répétant les étapes suivantes :Copiez le code JSON suivant et enregistrez le dans un fichier (ex. AVD-custom-role.json) sur votre PC :
Selectionnez le type Souscription puis choisissez celle voulue, puis cliquez sur Suivant :
Contrôlez cet onglet et cliquez sur Suivant :
Lancez la création de votre rôle personnalisé :
Etape II : Création d’un nouveau rôle RBAC
Une fois le nouveau rôle créé, il ne nous reste qu’à assigner le service Azure Virtual Desktop à celui-ci. Cela s’effectue directement sur le périmètre, qu’on souhaite lui assigner.
Cherchez donc ici la Souscription Azure de votre AVD puis cliquez ici :
Utilisez la barre de recherche pour retrouver plus facilement votre rôle personnalisé :
Cliquez ici pour ajouter le service Azure Virtual Desktop :
Utilisez encore une fois la barre de recherche pour retrouver le service AVD sous son ancien nom et Sélectionnez-le :
Cliquez sur Suivant :
Lancez l’Assignation du rôle :
Vérifiez la présence de l’assignation d’AVD sur la souscription, puis cliquez sur le rôle :
Vous retrouvez ici toutes les permissions nécessaire à la fonctionnalité d’Autoscale :
La création d’un plan d’autoscaling AVD apporte les avantages / restrictions suivants :
Le plan d’autoscaling est utilisable pour un ou plusieurs environnement Azure Virtual Desktop, à la condition que ces derniers nécessitent une gestion horaire identique
Ne pas associer le plan d’autoscaling avec d’autres solutions tierces de gestion des ressources Azure
Il n’est pas possible d’associer plusieurs plans d’autoscaling sur un seul environnement AVD
Le plan d’autoscaling est dépendant d’un seul fuseau horaire
Le plan d’autoscaling est configurable sur plusieurs périodes distinctes
Le plan d’autoscaling est opérationnel dès sa configuration terminée
Le plan d’autoscaling ne tient pas compte du « Drain mode » activé sur les VMs si aucun TAG n’est pas renseigné
Le plan d’autoscaling n’est pas en interaction avec la méthode de répartition des utilisateurs configuré sur votre pool d’hôtes
Remplissez le premier onglet avec vos informations de base puis cliquez sur Suivant :
Le champ dédié au TAG exclu permet de « sortir » des VMs du plan d’autoscaling.
L’onglet suivant vous permet de définir quand le plan d’autoscaling s’active pour suivre les besoins de montée / descente en puissance tout au long de la journée.
Dans chaque phase de la planification, autoscale n’éteint les machines virtuelles que lorsqu’un hôte de session n’a plus de sessions actives.
Les valeurs par défaut qui s’affichent lorsque vous créez une planification sont les valeurs suggérées pour les jours de la semaine, mais vous pouvez les modifier selon vos besoins.
Cliquez comme ceci pour ajouter votre première période :
Choisissez un Nom, sélectionnez les Jours adéquats puis cliquez sur Suivant :
L’onglet de charge reprend le fuseau horaire du premier onglet et vous demande de renseigner les champs et de cliquer sur Suivant :
Heure de début : Sélectionnez une heure dans le menu déroulant pour commencer à préparer les VM pour les heures de charge
Algorithme d’équilibrage de charge : Microsoft recommande de choisir l’algorithme Breadth-first. Cela répartira les utilisateurs sur les VM existantes afin de maintenir des temps d’accès rapides
Pourcentage minimum de VM hôtes : Entrez ici le pourcentage d’hôtes de session que vous souhaitez conserver au minimum pendant les heures de montée et de pointe. Par exemple, si vous choisissez 10 % et que votre pool d’hôtes compte 10 hôtes de session, plan d’autoscaling gardera une hôte de session disponible pour les prochaines connexions utilisateur
Seuil de capacité : Saisissez ici le pourcentage d’utilisation du pool d’hôtes qui déclenchera le début des phases de charge et de pic. Par exemple, si vous choisissez 60 % pour un pool d’hôtes pouvant gérer 10 sessions à l’instant T, le plan d’autoscaling n’activera des hôtes supplémentaires que lorsque le pool d’hôtes dépassera 6 sessions
L’onglet de pic de charge reprend aussi le fuseau horaire du premier onglet et vous demande de renseigner les champs puis de cliquer sur Suivant :
Heure de début : Entrez une heure correspondante au moment où votre taux d’utilisation est le plus élevé pendant la journée. Cette heure sera également l’heure de fin de votre phase de charge
Equilibrage de charge : Sélectionnez Breadth-first ou Depth-first. Le premier distribue les nouvelles sessions utilisateur sur toutes les sessions disponibles dans le pool d’hôtes. Le second distribue les nouvelles sessions à l’ôte de session disponible ayant le plus grand nombre de connexions et n’ayant pas encore atteint sa limite de session.
Seuil de capacité : Valeur non modifiable
L’onglet de décharge vous demande de renseigner les mêmes champs que pour ceux des périodes de charge et de pic :
Heure de début
Equilibrage de charge
Pourcentage minimum d’hôtes (%)
Seuil de capacité (%)
Forcer la déconnexion des utilisateurs
Pour finir, l’onglet heures creuses vous demande de renseigner les mêmes champs suivants :
Heure de début
Equilibrage de charge
Seuil de capacité
Cliquez sur Ajouter une fois ce premier planning terminé :
Il est possible d’ajouter une second planning si besoin, mais uniquement sur les autres jours restants :
Sélectionnez-le ou les pools d’hôtes concernés et cliquez sur Suivant :
Renseignez les TAGs et lancez la Création :
Consultez la ressource Azure créée et dédiée au plan d’autoscaling d’Azure Virtual Desktop :
Etape IV : Test de la solution
Avant que mon script soit validé et en place, j’ai pris le soin d’éteindre l’ensemble des VMs (5) de mon pool d’hôtes AVD. Voici donc mon environnement de test :
Limite d’utilisateurs AVD par VM : 2 utilisateurs
Nombre de VMs AVD : 5 VMs
Nombre total de sessions AVD disponibles : 20 sessions, soit 4 par VM
Période A : Hors période du plan d’autoscaling
Période B : Charge : Algorithme : Breadth-first / Min : 25 % / Max : 60 %
Période C : Pic : Algorithme : Depth-first / Max : 60 %
Période D : Décharge : Algorithme : Depth-first / Min : 10 % / Max : 90 %
Période E : Creux : Algorithme : Depth-first / Max : 90 %
Période A – Hors période :
Seule une machine virtuelle s’allume après la validation du script car celui-ci est directement opérationnel :
Période B – Période de charge :
Nous entrons dans la période de charge de mon environnement Azure Virtual Desktop. Ayant paramétré le Pourcentage minimum de VM hôtes à 25% et disposant de 5 VMs AVD , une seconde VM s’allume automatiquement allumée à l’entrée dans cette phase :
25% x 5 (max nbr VMs) = 1 VM
Sans attendre la période de pic, je décide alors de connecter un premier utilisateur AVD, sachant que mon Seuil de capacité est de 60% et que le nombre d’utilisateurs AVD par VM est de 4.
De façon assez logique, aucune machine nouvelle virtuelle ne s’allume. Cela fait sens car deux VMs sont déjà opérationnelles. Je décide donc de connecter un second utilisateur. Même constat au niveau de VMs, toujours à cause de la règle des 60 % :
La répartition des utilisateurs se fait bien selon l’algorithme Breadth-first.
Je connecte donc un 3ème utilisateur AVD et ne constate toujours aucun allumage d’une nouvelle machine virtuelle. En effet la règle des 60 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :
60% x 4 (max nbr users) x 2 (VMs allumées) = 4.8 sessions utilisateurs
Je décide donc de continuer mon test et de rajouter un quatrième utilisateur. Toujours le même constat :
On finit avec la connexion du 5ème utilisateur. Cette fois-ci, cet ajout provoquera bien le démarrage d’une nouvelle et 3ème machine virtuelle AVD :
Curieusement, la connexion du 6ème utilisateur se ne retrouve pas sur cette nouvelle machine virtuelle sans utilisateur, mais bien sur la seconde, en contradiction avec l’algorithme de la période de charge :
Afin de tester toutes les caractéristiques de la période de charge, je décide de déconnecter l’ensemble des utilisateurs AVD. Aucune VM ne s’éteindra malgré 0 utilisateur connecté sur AVD :
Période C – Période de pic :
Nous quittons la période de charge pour entrer dans la période de pic d’AVD. Le but ici est de constater le changement d’algorithme Depth-first agissant sur la répartition des utilisateurs.
Aucune session utilisateur AVD n’est ouverte, 2 VMs restent allumées, même sans utilisateur :
Je connecte alors 4 utilisateurs AVD et je ne constate aucun démarrage de machines virtuelles AVD. L’assignation des utilisateurs se fait bien en Depth-first :
On continue avec la connexion du 5ème utilisateur. Cette fois-ci, cet ajout provoquera bien le démarrage d’une nouvelle et 3ème machine virtuelle AVD :
En effet la règle des 60 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :
60% x 4 (max nbr users) x 2 (VM allumée) = 4.8 sessions utilisateurs
Je décide de finir en connectant un 6ème utilisateur. L’algorithme Depth-first continue de bien s’appliquer bien comme précédement :
Au final, la période de pic se distingue de la période de charge par la présence systématique d’une machine virtuelle « d’avance », vide d’utilisateurs pour encaisser leur arrivée massive.
D’ailleurs, la déconnexion de l’ensemble des utilisateurs AVD nous ramène à deux machines virtuelles allumées :
Période D : Période de décharge :
Nous continuons l’analyse du plan d’autoscaling avec la période de décharge de mon environnement AVD. Aucune session AVD n’est active à ce moment précis. Comme la période de charge, seule une seule VM reste allumée :
Comme à chaque période, je connecte alors 3 utilisateurs AVD et je ne constate aucun démarrage de machines virtuelles AVD. L’assignation des utilisateurs se fait toujours en Depth-first :
Quand je connecte le 4ème utilisateur, je constate bien le démarrage d’une seconde machine virtuelle :
En effet la règle des 90 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :
90% x 4 (max nbr users) x 1 (VM allumée) = 3.6 sessions utilisateurs
Dès que je connecte les utilisateurs 5, 6 et 7, aucune nouvelle machine virtuelle ne s’allume :
Dès que j’arrive à l’utilisateur 8, les choses changent :
Cela s’explique encore par la règle des 90% ci-dessous :
90% x 4 (max nbr users) x 2 (VMs allumées) = 7.2 sessions utilisateurs
A noter que l’inactivité des utilisateurs AVD provoque le message d’alerte suivant :
Ce chrono et le message indiqué ici est paramétré dans le plan d’autoscaling.
D’ailleurs, la déconnexion de l’ensemble des utilisateurs AVD nous ramène à une machine virtuelle allumée :
Période E : Période de creux :
Nous sommes maintenant dans la dernière période, appelée aussi période creuse. Le but de celle-ci est de fonctionner en économie maximale. Notre point de départ est donc une seule session AVD d’ouverte et donc une seule machine virtuelle reste active :
On recommence donc par connecter 3 utilisateurs Azure Virtual Desktop. Aucune autre machine virtuelle ne s’allume :
90% x 4 (max nbr users) x 1 (VM allumée) = 3.6 sessions utilisateurs
De ce fait, la connexion du 4ème utilisateur ajoute une seconde machine virtuelle :
On continue par connecter les utilisateurs 5, 6 et 7. Aucun changement au niveau du nombre de VMs :
En effet et comme pour le cas du 4ème utilisateur, la règle des 90% qui s’applique ici n’est réalisée que si le nombre d’utilisateurs connectés dépasse l’entier supérieur :
90% x 4 (max nbr users) x 2 (VMs allumées) = 7.2 sessions utilisateurs
La connexion du 8ème utilisateur vérifie et valide cette théorie :
Pour finir la déconnexion de tous les utilisateurs entraîne l’arrêt des machines virtuelles AVD allumées, sauf une :
Fonctionnalités et annexes
Modification
Le plan d’autoscaling est pleinement modifiable après sa création en cliquant ici :
Désactivation
Si votre pool d’hôtes a besoin de repasser en fonctionnement manuel, rien de plus simple par la désactivation temporaire du plan d’autoscaling :
Sauvegarde des logs
Comme un grand nombre de ressources Azure, vous pouvez sauvegarder les logs pour une analyse plus fine :
Dans mon cas, je fais le choix d’utiliser Log Analytics Workspace :
Erreur rencontrées
Au fil de mes différents tests, j’ai reçu une ou deux fois des messages d’erreur lors de la connexion d’un nouvel utilisateur sur une machine virtuelle fraîchement démarrée.
Un nouvel essai de connexion a résolu le souci à chaque fois.
Conclusion
Disons-le tout de suite, cette fonctionnalité était déjà disponible depuis plusieurs mois via une la solution script proposée par Microsoft et basée sur Azure Logic Apps.
La nouvelle solution choisie par Microsoft d’intégrer une fonctionnalité d’autoscaling dans Azure Virtual Desktop est riche de sens et est plus que bienvenue. Pour ma part je trouve qu’elle remplace la fonctionnalité Démarrage des VMs à la demande, déjà existante mais qui ne permettait pas de tenir des plannings de charges et de décharges.
Malgré tout, le plan d’autoscaling manque encore de clarté sur son fonctionnement dans le besoin de démarrage de machines virtuelles. Je me suis en effet retrouvé à plusieurs reprises avec plusieurs VMs allumées malgré qu’elles soient vides d’utilisateurs.
Pour finir, un aperçu graphique du mode et des indices de charges actuels aurait été apprécié.
C’est ici que Nerdio intervient. Nerdio Manager est une solution disponible sur la marketplace d’Azure, qui va vous simplifier la gestion de votre environnement AVD. Voici une vidéo sur le sujet part le CEO de Nerdio, Vadim Vladimirskiy :
La nombre de vidéos disponibles concernant AVD sur leur chaîne Youtube est impressionnant !
Le portail Azure apporte en effet une grande facilité de déploiement d’un environnement Azure Virtual Desktop. Mais tout cela devient assez lourd quand on doit manager la solution durant toute sa période d’exploitation.
Alors imaginez avec plusieurs centaines d’utilisateurs sur plusieurs pools d’hôtes …
Comme vous allez le voir une fois en place, Nerdio propose de simplifier et d’automatiser les opérations courantes sur l’environnement AVD. On pourra gérer les images OS, les cycles de mise à jour, optimiser les ressources Azure selon les besoins et les pics de charge, et bien d’autres encore…
Dans ce premier article sur Nerdio, nous allons nous occuper ici de l’installation de la solution sur votre environnement Azure.
Etape 0 : Rappel des prérequis
Comme pour tout déploiement dans Azure, des prérequis sont nécessaires :
Un tenant Microsoft (AAD)
Des licences comprenant Windows 10 Entreprise pour vos utilisateurs AVD
Une souscription Azure active
Un domaine Active Directory Domain Services (AD DS)
Un espace de stockage sur Azure pour les profils utilisateurs via FSLogix, provenant d’un serveur de fichiers ou d’un compte de stockage Azure + partage de fichier
Si un des points listés est absent de votre environnement, pas de panique, Vadim vous explique tout ici :
Au final, Nerdio se focalise avant tout sur les composants Azure Virtual Desktop, afin de pouvoir l’intégrer sans difficulté dans un grand nombre d’environnements existants.
Etape I : Déploiement de la solution
Tout commence donc depuis la marketplace. Avant de pouvoir jouer avec Nerdio, il faut en effet commencer à déployer les premières ressources Azure.
Cliquez ci-dessous pour créer votre Nerdio :
Tapez Nerdio dans la barre de recherche et sélectionnez Nerdio Manager for Enterprise :
Créez un nouveau groupe de ressources et choisissez la localisation qui vous convient :
Une fois la validation passée, lancez la création :
Une fois le déploiement terminé, cliquez sur Outputs pour récupérer l’URL de votre application web Nerdio :
En effet, le groupe de ressources créé par Nerdio a généré plusieurs ressources dont une application web :
Ouvrez cette URL dans un nouvel onglet de votre navigateur Internet :
Comme indiqué sur cette page web, vous avez déjà déployé les composants nécessaires à Nerdio. Maintenant, Nerdio va avoir besoin de s’installer.
Pour cela, suivez les indications en ouvrant Azure Cloud Shell avec un compte disposant du rôle d’administrateur global de votre tenant, mais aussi d’un rôle de propriétaire sur la souscription Azure :
Qu’est-ce qu’Azure Cloud Shell ?
Azure Cloud Shell est un interpréteur de commandes interactif, authentifié et accessible par navigateur qui permet de gérer les ressources Azure. Il vous donne la possibilité de choisir l’expérience d’interpréteur de commandes la plus adaptée à votre façon de travailler, qu’il s’agisse de Bash ou de PowerShell.
Lors de l’ouverture de ce nouvel onglet, Azure Cloud Shell vous demandera éventuellement de créer ou de rattacher à un compte de stockage + partage de fichier pour stocker les logs :
Azure Cloud Shell va vous permettre d’exécuter des commandes en PowerShell ou en Azure CLI. Restez en PowerShell et coller le script donné sur la page web Nerdio :
Script correctement terminé après plusieurs minutes.
Une fois le script terminé, vous pouvez retourner sur la page web Nerdio et rafraîchir. Si vous n’avez pas conservé cette page, pas de panique ! Vous pouvez la retrouver comme ceci :
Retournez sur le groupe de ressources créé par l’application Nerdio, puis cliquez sur le service d’application :
Copiez l’URL de l’application :
Collez l’URL dans un nouvel onglet de votre navigateur :
Pour que Nerdio puisse fonctionner, vous allez devoir le configurer sur votre environnement actuel. Voici, étape par étape, les points à paramétrer :
Les informations du tenant et de la souscription Azure sont déjà renseignés et donc non modifiable :
Ensuite, enregistrez votre application auprès des serveurs Nerdio :
Un environnement Azure Virtual Desktop nécessite aussi un contrôleur de domaine dans la majorité des scénarios. Une gestion via Nerdio n’échappe pas à cette règle et demande alors le réseau virtuel où se trouve l’AD et FSLogix :
Le menu déroulant propose automatiquement les ressources Azure se trouvant dans la même souscription que Nerdio. Cliquez sur OK pour continuer la configuration :
Nerdio vous demande de spécifier un groupe de ressources pour Azure Virtual Desktop. Il propose par défaut le même que celui utilisé pour son installation, mais reste modifiable :
Un conseil, créez un groupe de ressources dissocié pour les ressources AVD afin de gagner en clarté. Retournez alors sur votre premier onglet (Portail Azure) pour créer le groupe de ressources AVD.
Une fois créé, revenez sur la page de configuration.
Cliquez sur le groupe de ressources et changez-le par votre nouveau groupe, puis cliquez sur OK :
Le paramètre suivant concerne Active Directory. Nerdio a besoin de connaître plusieurs paramètres pour connecter les machines virtuelles AVD au domaine :
Directory : Choisissez selon votre annuaire entre Active Directory ou Azure AD DS
AD Domain : Spécifiez le domaine Active Directory au format FQDN pour les machines virtuelles hôtes de session à rejoindre
AD Username : Spécifiez un utilisateur admin au format FQDN avec l’autorisation de créer des objets « ordinateurs«
AD Password : Mot de passe du compte admin
Organisation Unit : Spécifiez l’unité d’organisation (OU) au format DN où toutes les machines virtuelles hôtes de session seront créées par défaut
Une fois les champs renseignés, cliquez sur OK :
Le compte de stockage est utilisé pour stocker les profils via FSLogix. Ce dernier doit exister au préalable, comme pour le partage de fichier, qui doit être joint au domaine AD renseigné plus haut :
Plusieurs options possibles sur cet écran :
Vous pouvez passer la configuration du compte de stockage pour y revenir plus tard si nécessaire
Vous pouvez activer la fonction Cloud Cache de FSLogix. Cela permet de conserver sur le profil utilisateur sur plusieurs compte de stockage Azure, hébergés dans différentes régions pour augmenter sa résiliance.
Cliquez sur OK une fois les champs renseignés :
Le portail de gestion Nerdio offre aussi la possibilité de gérer des machines Windows 365. Cela s’avère pratique pour centraliser la gestion des bureaux à distance dans une seule console.
Pour cela, vous devez autoriser l’application Nerdio sur votre environnement. Cliquez sur OK si vous êtes d’accord :
Enfin, choisissez le modèle de gestion AVD au sein de Nerdio. Prenez ici Spring 2020 Update -ARM (GA) et cliquez sur Done :
Avant de pouvoir laisser Nerdio procéder, il faut lui donner un consentement de l’administrateur global. Cliquez sur le lien donné dans le nom du domaine :
Saisissez les identifiants appropriés pour vous identifier:
La liste d’autorisations est assez longue. Prenez le temps de la regarder et acceptez si vous êtes d’accord :
Un message d’information apparaît alors pour vous confirmer le succès de l’opération :
Fermez l’onglet et retournez sur l’onglet de configuration Nerdio pour cocher la case et cliquez sur OK :
Le processus vous emmène alors directement sur le portail de management Nerdio :
Vous allez maintenant pouvoir créer votre premier environnement Azure Virtual Desktop. Nerdio dispose d’un grand nombre de personnalisations. Nous ne ferons que les opérations de base dans ce premier article. D’autres articles suivront pour des sujets précis.
Etape II : Création d’un environnement Azure Virtual Desktop
Vous voilà sur votre portail de gestion Nerdio. Indispensable dans toute structure AVD, l’espace de travail est un composant créé par Nerdio. Cliquez sur Workspaces, puis Add Workspace :
Renseignez les options de votre espace de travail et cliquez sur OK :
Chaque tâche Nerdio est visible dans l’historique, très précis avec ses statuts actualisés automatiquement :
Faites un tour dans votre portail Azure pour constater la création de la première ressource :
Cliquez votre espace de travail Nerdio pour le configurer :
Cliquez sur Static host pools dans le sous-menu à gauche, puis sur Add static host pool :
Renseignez les champs de votre pool d’hôtes AVD et cliquez sur OK. Voici mes options :
Desktop Experience : vous permet de choisir entre un environnement mono-utilisateur ou multi-utilisateurs
Répertoire : reprend par défaut l’AD DS ou l’Azure AD DS renseigné pendant la configuration Nerdio
FSLogix : reprend par défaut le compte de stockage utilisé pour FSLogix renseigné
Initial host count : nombre initial de machine virtuelles AVD créées avec le pool d’hôtes
Name Préfix : préfixe du nom utilisé pour la création des machines virtuelles AVD
Desktop image : propose une liste d’images Windows 10/11 disponibles sur Azure, mais aussi des images personnalisées et créées dans le menu Desktop image de Nerdio
VM size : offre plusieurs choix de puissance pour les VMs AVD
OS Disk : Taille et puissance du disque OS installé sur chaque VM AVD
Resource group : groupe de ressources Azure pour la création des VMs AVD et du pool d’hôtes
Quick assign : Annuaire des groupes et des utilisateurs d’Azure AD
Une fois la création du pool d’hôtes lancée, vous pouvez suivre toutes les étapes grâce au système de tâches Nerdio :
Après que toutes les tâches sont terminées, ouvrez un portail Azure pour constater les créations dans le groupe de ressources AVD :
Cliquez sur le pool d’hôtes créé par Nerdio et constatez la présence de VMs disponibles aux utilisateurs AVD :
Pour tester la solution, ouvrez un navigateur en mode privé pour vous rendre sur la page d’accueil AVD :
aka.ms/wvdarmweb
Utilisez les identifiants d’un utilisateur faisant parti du groupe AVD assigné lors de la création sur Nerdio et cliquez sur OK :
Recherchez le bon espace de travail créé par Nerdio et cliquez sur l’icône RDP :
Saisissez une nouvelle fois le mot de passe de l’utilisateur AVD et cliquez sur Submit :
Vous voilà enfin sur votre bureau Windows 11 !
Faites un tour sur votre compte de stockage FSLogix via votre portail Azure :
Cliquez sur le partage de fichiers correspond à celui renseigné dans la configuration Nerdio :
Constatez la présence d’un dossier créé par FSLogix pour le stockage du profil utilisateur au format VHDX :
Etape III : Suppression de l’environnement de test AVD
Dans le cadre d’un environnement de test, vous pouvez également supprimer très facilement les composants Azure créés par Nerdio.
Commencez par les machines virtuelles AVD :
Continuez par le pool d’hôtes :
Et finissez par supprimer l’espace de travail :
Conclusion
Au final la mise en place d’un environnement de test pour Azure Virtual Desktop via Nerdio a été très simple et très facile. Plusieurs remarques à ce sujet :
Nerdio ne vous dispense pas de mettre en place les prérequis propres à un environnement AVD
Le présent article ne montre pas toutes les fonctionnalités très utiles et présentes dans la console Nerdio. Plusieurs articles suivront par la suite
Quel est le coût de Nerdio ?
La société propose plusieurs modèles de licence après le premier mois d’essai gratuit :
Nerdio for Managed Service Providers (MSPs)
Nerdio manager for Enterprise :
A cela s’ajoute aussi le coût des ressources Azure déployées par Nerdio, dont voici les estimations au bout de quelques jours :
En conclusion, la solution s’avère assez prometteuse sur la gestion des environnements d’Azure Virtual Desktop par un grand nombre d’automatismes ou de customisations, à travers un seul et unique portail.
Comme à chaque fois Dean Ceola, de la Cloud Academy, a également fait une très bonne vidéo juste ici :
Enfin et comme toujours, pensez à partager votre propre expérience dans les commentaires ????
Bonne nouvelle pour le Cloud en Suisse, les prix baisses sur Azure en octobre !!!
A partir d’un 1er octobre 2021, une baisse des prix est appliquée sur la consommation Azure dans les 2 régions Suisse. La vérification peut simplement se faire grâce à l’outil d’estimation des coûts de Microsoft : Azure Pricing Calculator.
Lancées en 2019, les régions Azure Suisse Nord et Suisse Ouest étaient plus chères que leurs homologues en Europe. L’écart entre ces régions tend maintenant à diminuer. Beaucoup de projets d’hébergement repose en effet sur une demande de stockage des données sur le territoire helvétique.
Voici quelques exemples pour vous donner une idée de la baisse des prix sur des architectures Azure :
Quote A : Architecture Pay As You Go
L’architecture est hébergée sur Suisse Nord et comporte les éléments suivants :
1 Domaine managé Azure AD DS
1 Serveur Application
1 Serveur Azure Virtual Desktop
1 Compte de stockage pour gestion des profils FSLogix
1 Coffre de sauvegarde pour la machine virtuelle et le compte de stockage
1 Accès VPN + Bande passante
Au final, l’architecture ci-dessus, refaite en octobre 2021, est 10% moins chère que celle créée en septembre 2021. La vérification est facile à faire si vous utilisez la fonction partager dans le calculateur Azure et que vous conservez les liens HTML générés le mois précédent :
Quote B : Architecture Azure Virtual Desktop (Pay As You Go)
Ce second exemple est dédié à une architecture plus conséquente, utilisée pour un environnement Azure Virtual Desktop d’environ 180 utilisateurs et avec un mode de facturation en Pay As You Go :
2 Machines virtuelles pour le contrôleur de domaine AD
6 Machines virtuelles Azure Virtual Desktop
1 Compte de stockage pour gestion des profils FSLogix
1 Coffre de sauvegarde pour les AD et le compte de stockage
1 Accès VPN + Bande passante
La baisse de prix reste aux alentours des 12%, proche de l’architecture A. L’impact sera plus fort compte tenu du nombre de machines virtuelles employées dans cette seconde quote.
Quote C : Architecture Azure Virtual Desktop (Instances réservées)
Dernier exemple, on reprend l’architecture Azure Virtual Desktop utilisée pour les 180 utilisateurs et on optimise les coûts avec l’achat d’instances réservées pour les machines virtuelles. Petite rappel de ce qu’est une instance réservée sur Azure :
Si vous utilisez les ressources d’une façon systématique adaptée aux réservations, l’achat d’une réservation vous offre l’opportunité de réduire vos coûts. Par exemple, si vous exécutez en permanence des instances d’un service sans réservation, vous êtes facturé au tarif du paiement à l’utilisation. Quand vous achetez une réservation, vous bénéficiez immédiatement de la remise sur réservation. Les ressources ne sont plus facturées au tarif du paiement à l’utilisation.
Ce graphique montre l’impact financier en couplant l’optimisation des machines virtuelles grâce à Azure Hybrid Benefit et les instances réservées.
Voici d’ailleurs le lien expliquant le bénéfice financier à s’engager sur des instances réservées de 1 ou 3 ans. La liste des composants Azure ne change donc entre la quote B et C, simplement l’ajout d’instances réservées 3 années pour l’ensemble des machines virtuelles :
2 Machines virtuelles pour le contrôleur de domaine AD
6 Machines virtuelles Azure Virtual Desktop
1 Compte de stockage pour gestion des profils FSLogix
1 Coffre de sauvegarde pour les AD et le compte de stockage
1 Accès VPN + Bande passante
La baisse de prix sera alors beaucoup plus faible ici (2%) car les machines virtuelles représentent le gros de la quote et que les instances réservées font déjà un gros rabais dessus.
Conclusion
Les baisses de prix sont toujours des bonnes nouvelles. On ne peut que s’en réjouir sur Suisse, car ces deux régions sur considérées comme premium par Microsoft. Quelques analyses faites entre septembre et octobre me permettent enfin de constater les baisses de prix les plus fortes sur :
Machine virtuelle non réservées
Sauvegarde de machine virtuelles
Sauvegarde de partage de fichiers d’un compte de stockage
Disques managés pour VM
Par ailleurs, je n’ai vu par contre aucune baisse de prix pour la partie réseau (VPN ou encore bande passante). Enfin et comme toujours, pensez à partager votre expérience sur les quotes Azure dans les commentaires ????
Je vous avais déjà parlé il a quelque temps de la jointure possible entre des machines virtuelles Azure Virtual Desktop et Azure AD ici. Cela offre la possibilité de se passer d’un Active Directory pour environnement AVD et permet d’envisager certains projets avec une architecture 100% Cloud.
Avec l’arrivée prochaine de Windows 11, il me paraissait intéressant de tester cette combinaison avec le nouvel OS de Microsoft.
Point important : Comme précédemment, nous sommes toujours dans l’attente d’une prise en charge de FSLogix dans ce scénario. L’utilisation d’un partage de fichier nécessite une authentification SMB, non possible pour l’instant via la seule gestion des identités Azure AD.
Rappel des prérequis
Comme pour tout déploiement dans Azure, des prérequis sont nécessaires :
La liste est donc beaucoup plus courte qu’avec un domaine classique ????.
Déploiement de la solution
Une fois votre réseau virtuel en place, la création de l’ensemble pourra se faire directement depuis Azure Virtual Desktop. Dans le cadre d’un environnement de production, la création d’une image en amont reste l’étape indispensable pour installer les applications nécessaires à vos utilisateurs !
Sur le portail Azure, recherchez Azure Virtual Desktop dans la barre de recherche et sélectionnez Azure Virtual Desktop dans les suggestions :
Sur l’écran d’Azure Virtual Desktop, choisissez Créer unPool d’hôtes :
Renseignez les informations de base sur votre pool d’hôtes puis cliquez sur Suivant : Machines virtuelles :
Renseignez les principales caractéristiques de vos machines virtuelles AVD :
L’image de Windows 11 n’est pas forcément proposée dans la liste. Il vous faudra alors la chercher dans la marketplace Azure :
Renseignez les informations réseaux :
Prenez le temps de considérer les options concernant le domaine à joindre :
Type de domaine à joindre : Choisissez Azure Active Directory
Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, qu’elles soient dédiées ou partagées entre utilisateurs
Il est toujours demandé de créer un compte administrateur local :
Cliquez sur Suivant et créez un nouvel espace de travail :
Enfin lancez la création quand Azure a validé votre configuration :
Environ 10-15 minutes plus tard, le déploiement doit se finir sur une note positive :
Contrôlez quelques minutes après la bonne disponibilité des machines virtuelles dans le pool d’hôtes AVD :
Pensez à assigner le groupe d’utilisateurs AVD sur l’application créée par le pool d’hôtes :
Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se fait directement sur le pool d’hôtes d’AVD :
Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se fait directement sur le groupe de ressources AVD :
Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD
Il ne reste plus qu’à tester la solution avec un utilisateur AVD. Cela se fait en téléchargeant le client Windows Remote Desktop PC dédié à Azure Virtual Desktop (téléchargeable ici), ou via l’accès web multi-plateformes (accessible là). J’ai choisi dans mon cas Windows Remote Desktop :
Une seconde demande d’authentification est affichée pour accéder à la machine virtuelle via le protocole RDP :
Une fois le mot de passe saisi, l’ouverture d’une fenêtre RDP donne l’accès au bureau Windows 11 d’AVD. A noter que la jointure AVD apporte également le Seamless Sign on, rendant l’expérience utilisateur encore plus agréable :
Regardez en détail cette jointure avec Azure AD grâce à la commande :
dsregcmd /status
Vérifiez que les machines virtuelles Windows 11 Azure Virtual Desktop sont bien présentes dans la section Devices d’Azure AD. Cet ajout est réalisé lors de la jointure des machines virtuelles à Azure AD :
Vérifiez, si vous avez coché Intune, que vous retrouvez bien mes machines virtuelles dans la console :
Si vous rencontrez des erreurs lors du déploiement, Microsoft met à votre disposition cette page d’aide. Voici une des erreurs possibles :
Erreur de mot de passe de l’ouverture de la session RDP : “The logon attempt failed”
Si vous rencontrez une erreur indiquant que la tentative de connexion a échoué à l’invite des informations d’identification de sécurité Windows, vérifiez les éléments suivants :
Vous êtes sur un appareil qui est joint à Azure AD ou à Azure AD hybride au même locataire Azure AD que l’hôte de session OU
Vous êtes sur un appareil exécutant Windows 10 2004 ou version ultérieure qui est Azure AD enregistré auprès du même locataire Azure AD que l’hôte de session
Le protocole PKU2U est activé à la fois sur le PC local et sur l’hôte de session
La dernière hypothèse est fortement probable dans ce cas. Il faut donc penser à vérifier cette option sur la machine locale ET sur la machine virtuelle AVD, grâce à la commande secpol.msc :
Conclusion
Windows 11 s’intègre de plus en plus dans l’environnement Azure. Azure Virtual Desktop va grandement bénéficier de ce nouvel OS pour accroitre son utilité dans les solutions de bureau à distance. Comme pour Windows 10, on attend toujours la prise en charge de la solution FSLogix dans ce scénario de jointure avec Azure AD.
Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????
Ayant récemment abordé l’ajout d’images Windows 11 sous Azure ici, je me devais également de faire un nouvel article sur l’installation de machines virtuelles W11 au sein d’un environnement Azure Virtual Desktop.
Dans cet article nous allons tester différentes manières d’associer des machines virtuelles Windows 11 à AVD. Chaque méthode apporte des avantages et un niveau d’automatisation différent. Comme à chaque fois, il faut disposer au préalable d’un tenant et d’une souscription Azure sur laquelle vous déploierez les ressources Azure.
Etape 0 : Prérequis Licenses + Azure
A la différence d’un environnement RDS, Azure Virtual Desktop ne nécessite pas de licence côté serveur dans le cadre d’un environnement Windows 10/11. Cela n’est pas le cas si votre AVD est basé sur Windows Server. Vous pouvez accéder à Windows 10 et Windows 7 avec Azure Virtual Desktop si vous possédez l’une des licences suivantes par utilisateur :
Microsoft 365 E3/E5
Microsoft 365 A3/A5/Student Use Benefits
Microsoft 365 F3
Microsoft 365 Business Premium
Windows 10 Entreprise E3/E5
Windows 10 Éducation A3/A5
Windows 10 VDA par utilisateur
Comme indiqué précédemment, nous allons commencer les déploiements en partant des prérequis suivants :
Un tenant Microsoft
Une souscription Azure
Un réseau virtuel
Un contrôleur de domaine (VM AD +Azure AD Connect ou Azure AD DS)
Voici une liste des ressources Azure déjà en place sur ma souscription, avant la mise en place de Windows 11.
Les points listés sont les mêmes pour un environnement Azure Virtual Desktop en Windows 10. Une fois en place, nous allons déployer des machines virtuelles en Windows 11 via les méthodes suivantes :
Méthode 1 : Déploiement direct depuis le pool d’hôtes AVD
Méthode 2 : Création d’une VM, puis enrôlement manuel dans le pool d’hôtes AVD
Méthode 3 : Création d’une VM puis enrôlement automatique via une extension script
Méthode 4 : Utilisation d’un template entièrement automatique et hébergé GitHub
Méthode 1 : Déploiement depuis le host pool
Dans cette méthode, nous allons simplement créer et ajouter une machine virtuelle Windows 11 sur notre environnement Azure Virtual Desktop.
Sur le portail Azure, recherchez Azure Virtual Desktop dans la barre de recherche et sélectionnez Azure Virtual Desktop dans les suggestions :
Sur l’écran d’Azure Virtual Desktop, choisissez Pool d’hôtes puis cliquez sur celui déjà créé précédemment dans votre environnement :
Si vous avez créé le vôtre sans machine virtuelle comme le mien, vous devriez avoir le chiffre 0 dans le nombre total de machines virtuelles. Cliquez dessus pour en ajouter :
Cliquez sur Ajouter :
Le premier onglet est grisé, car ces informations sont dédiées au pool d’hôtes. Cliquez sur le bouton Suivant pour ajouter la machine virtuelle :
Après avoir renseigné les premiers champs, cherchez l’image de Windows 11 en cliquant pour voir toutes les images disponibles dans la marketplace Azure :
Utilisez la barre de recherche pour retrouver l’image Windows 11, puis choisissez l’image avec les applications Microsoft 365 Gen 2 :
Cliquez ici pour obtenir plus d’information sur Windows 11 Gen 2 (bas de l’article).
Choisissez la puissance et le nombre de machines virtuelles ainsi que la performance du disque OS :
Microsoft recommande toujours les disques Premium SSD pour les environnements AVD de production.
Sélectionnez le réseau virtuel et le sous-réseau correspondant :
Il est vivement conseiller de créer un sous-réseau propre à AVD.
Continuez avec les informations du domaine :
Les éléments de jointure sont importants car ils peuvent faire échouer le déploiement Azure. Prenez le temps de bien vérifier ces informations.
Finissez avec les informations d’administration des machines virtuelles, puis cliquez pour valider la création :
Une fois la validation passée, vous pouvez déclencher la création de la ou les machines virtuelles :
La création ne prendra alors que quelques minutes seulement :
Retournez sur votre pool d’hôtes pour bien constater l’apparition et la bonne disponibilité des VMs :
Enfin, pensez bien à affecter un groupe d’utilisateurs AVD, issu de votre domaine AD sur le groupe d’application de bureau à distance :
Lancez Windows Remote Desktop avec un utilisateur AVD pouvant lancer la session de bureau à distance :
Une dernière authentification est alors demandée pour ouvrir la session Windows 11 à l’utilisateur :
Ca y est, on dispose enfin de notre premier bureau Windows 11 sous AVD !!!
Il ne reste plus qu’à rajouter les informations de registre pour finaliser la configuration FSLogix :
Contrôlez alors dans votre partage de fichier créé pour FSLogix la présence du VHD :
En conclusion, la méthode habituelle de déploiement d’un Azure Virtual Desktop ne diffère en rien avec Windows 11. Nous allons nous intéresser à d’autres méthodes possibles de déploiement de Windows 11 pour AVD.
Méthode 2 : Création d’une VM puis enrôlement manuel
Quel que soit l’OS désiré, il est possible de créer une machine virtuelle par la méthode classique puis de l’enrôler manuellement via l’installation de la solution RD Agent.
Dans le cadre de l’installation de Windows 11 avec le Trusted Launch (encore en Preview), il faut alors utiliser ce portail Azure. La création de la machine virtuelle est alors des plus classiques :
Ajoutez provisoirement une adresse IP publique afin de pouvoir installer l’agent AVD :
Dans l’onglet Avancée, l’utilisation d’une image Gen 2 vous permet alors de profiter de toutes les fonctionnalités du Trusted Launch :
Connectez-vous en RDP sur la machine virtuelle nouvellement créée et suivez le processus suivant :
Joignez la machine virtuelle Windows 11 au domaine AD :
Téléchargez l’agent Azure Virtual Desktop et exécutez le programme d’installation
Lorsque le programme d’installation vous demande le jeton d’inscription, entrez la clef d’enregistrement disponible dans le pool d’hôtes AVD
Retrouvez la clef d’enregistrement AVD directement sur le pool d’hôtes AVD.
Copiez la clef récupérée dans le programme d’installation d’AVD.
Téléchargez l’agent de démarrage d’Azure Virtual Desktop et exécutez le programme d’installation
Télécharger et installez FSLogix puis ajoutez via PowerShell la configuration FSLogix :
La nouvelle machine rejoint alors celle de la première méthode :
Testez la connexion à Azure Virtual Desktop via l’accès HTML 5 depuis cette URL :
Contrôlez sur le compte de stockage l’apparition du second profil utilisateur :
En conclusion, la seconde méthode de déploiement d’un Azure Virtual Desktop par la création d’une VM, puis son enrôlement fonctionne très bien Windows 11. Nous allons maintenant nous intéresser à la création d’une VM dans AVD par l’ajout d’un script en extension.
Méthode 3 : Création d’une VM puis enrôlement automatique via une extension script
La 3ème méthode est très proche de la seconde méthode, à savoir qu’elle se fait par le déploiement d’une machine virtuelle. La différence va porter par l’utilisation d’une extension, appelant un script en PowerShell. Nous devons ce script à Dean Cefola, de l’Azure Academy. Ce script a connu les évolutions suivantes :
# 09/15/2019 1.0 Intial Version
# 09/16/2019 2.0 Add FSLogix installer
# 09/16/2019 2.1 Add FSLogix Reg Keys
# 09/16/2019 2.2 Add Input Parameters
# 09/16/2019 2.3 Add TLS 1.2 settings
# 09/17/2019 3.0 Chang download locations to dynamic
# 09/17/2019 3.1 Add code to disable IESEC for admins
# 09/20/2019 3.2 Add code to discover OS (Server / Client)
# 09/20/2019 4.0 Add code for servers to add RDS Host role
# 10/01/2019 4.2 Add all FSLogix Profile Container Reg entries for easier management
# 10/07/2019 4.3 Add FSLogix Office Container Reg entries for easier management
# 10/16/2019 5.0 Add Windows 7 Support
# 07/20/2020 6.0 Add WVD Optimize Code from The-Virtual-Desktop-Team
# 10/27/2020 7.0 Optimize FSLogix settings - Remove Office Profile Settings
# 02/01/2021 7.1 Add RegKey for Screen Protection
# 05/22/2021 7.2 Multiple changes to WVD Optimization code (remove winversion, Add EULA, Add Paramater for Optimize All
# 06/30/2021 7.3 Add RegKey for Azure AD Join
Renseignez les paramètres de la machine virtuelle de manière classique, et cliquez sur l’ajout d’une extension à installer dans l’onglet Avancé :
Cherchez dans la liste celle appelée Custom Script Extension :
Puis cliquez sur Créer:
L’extension doit être stockée sur un compte de stockage de type Blob, vous pouvez la chercher ici :
Sélectionnez un compte de stockage si vous en disposez d’un. Si non, il vous faudra en créer un :
Créez un nouveau container pour stocker le script PowerShell :
Nommez-le et cliquez sur Créer :
Rentrez dans celui-ci et cliquez sur Upload :
Renseignez l’URL suivante dans le nom du fichier et cliquez sur Ouvrir :
Pensez encore une fois à activer toutes les fonctionnalités du Trusted Launch sur le même onglet Avancé :
Lancez la création de la machine virtuelle. Quelques minutes plus tard, vous devriez constater l’apparition de la machine virtuelle dans votre pool d’hôtes Azure Virtual Desktop :
La machine restera en indisponible tant que cette dernière n’est pas jointe au domaine Active Directory. Pour cela, vous devrez vous connecter en RDP à cette dernière avec le compte administrateur renseigné lors de sa création. Une fois connecté il ne vous restera qu’à rejoindre le domaine :
Un redémarrage plus tard, vous devriez constater que la machine virtuelle est bien passée en Disponible dans Azure Virtual Desktop :
Un lancement d’une session AVD utilisera les paramètres FSLogix que vous avez renseigné et le dossier sera bien créé sur le compte de stockage :
En conclusion, cette 3ème méthode est pratique, mais demande encore quelques opérations manuelles. La dernière méthode de cet article, elle aussi créée par Dean, est encore plus automatisée.
Méthode 4 : Utilisation d’un template GitHub
Cette 4ème et dernière méthode nous amène sur GitHub et ses liens de déploiement vers Azure. La page GitHub de Dean se trouve ici. Sur cette page se trouve ce qui nous intéresse :
Cliquez sur ce lien pour emporter le template sur votre portail Azure. Renseignez les champs selon les paramètres de votre environnement AVD et Validez :
Le template va alors se déployer en quelques minutes :
Vérifiez alors la bonne jointure des VMs avec Azure Virtual Desktop via le pool d’hôtes :
Comme à chaque fois, un lancement d’une session AVD utilisera les paramètres FSLogix que vous aviez renseigné et le dossier sera bien créé sur le compte de stockage :
En conclusion, cette 4ème et dernière méthode est certainement la plus pratique de toutes et en plus très rapide, même si certaines options de machines virtuelles ne sont alors plus disponibles au moment de la configuration.
Conclusion
Windows 11 est maintenant bien présent sur Azure Virtual Desktop. Sa sortie très prochaine nous amène à considérer cet OS dans de futurs projets de bureau à distance. Je suis sûr que Microsoft continuera à nous apporter encore plus de fonctionnalités dans les mois qui viennent. Pour vous aider dans les tests de ces différentes méthodes, vous trouverez ci-dessous la vidéo YouTube mis en ligne par Dean sur ce sujet et qui m’a aidé à préparer mon article :
Enfin n’hésitez pas à faire part de vos remarques sur Windows 11 sur AVD dans les commentaires ????
Bonne nouvelle, Windows 11 est maintenant disponible en préversion depuis plusieurs semaines et on ne parle plus que de lui ! Afin de vous faire la main sur le nouvel OS proposé par Microsoft, vous pouvez dès à présent le tester sur Azure.
Dans cet article, nous allons créer ensemble une nouvelle machine virtuelle sur Windows 11 prenant le temps de parler des options possibles lors de la création, en évolution constante.
Comme à chaque fois que vous souhaitez ajouter de nouvelles ressources, vous devez préalablement disposer d’une souscription Azure. Si cela n’est pas votre cas, sachez que Microsoft propose des crédits Azure gratuits, 130 € environ, à utiliser pendant 30 jours. Cela sera largement suffisant pour créer et tester Windows 11. Vous pouvez donc profiter de cette offre en cliquant ici.
Etape I : Création de la machine virtuelle
Une fois votre souscription en place et connecté à votre portail Azure, la création de la VM peut commencer. Le bouton de création de ressource va vous aider à trouver rapidement Windows 11 :
La recherche « Windows 11 » sur la marketplace d’Azure vous indiquera différentes images disponibles pour Windows 11, selon que vous soyez en version Pro, Enterprise ou que vous construisez un environnement multisessions pour Azure Virtual Desktop :
Dans notre exemple, choisissez Windows 11 Enterprise, encore en préversion à date où cet article est écrit.
Comme pour toutes les machines virtuelles créées sur Azure, des informations de bases sont systématiquement demandées :
Onglet I : Informations de base
Souscription : rattachement de la ressource à l’arborescence Azure. La souscription correspond à une « ligne de crédit » auprès de Microsoft (CB, CSP, EA, …).
Groupe de ressources : Container logique très utile et maintenant obligatoire pour organiser les ressources Azure. De plus, une ressource ne peut pas être présente dans plusieurs groupes de ressources à la fois.
Nom de la machine virtuelle : Nom de la machine virtuelle ^^ aussi utilisé pour le nom de machine dans l’OS.
Région : Localisation physique de la machine virtuelle dans le Cloud Microsoft. Voici ici la liste de toutes les régions Azure existantes.
Option de disponibilité : permet par exemple de répartir plusieurs machines virtuelles sur différents datacenters Azure ou dans différents racks au sein d’un même datacenter. Très pratique pour créer des architectures résilientes.
Image : bibliothèque d’images préconstruites par Microsoft, ISV ou constuites par vous-mêmes via des images personnalisées.
Azure Spot instance : Apporte une réduction significative du prix en exploitant des ressources non utilisées par Azure. Ne surtout pas prendre pour des services critiques sans interruption possible !
Taille : Détermine la puissance de la machine virtuelle (CPU, mémoire vive, performances et nombre de disques) et donc le prix.
Compte administrateur : Utilisateur et mot de passe pour administrer localement la machine virtuelle.
Ports publics entrants : Restriction ou autorisation de ports ouverts sur la machine virtuelle.
Ports entrants : Propose l’ouverture des ports de management habituels (HTTP, HTTPS, SSH ou RDP).
Licence : Case déclarative sur la juste possession de licence Windows 10, autorisant son exploitation sur plusieurs périphériques.
Onglet II : Disque(s)
Nous pouvons ici modifier la performance du disque OS, mais aussi ajouter si besoin des disques secondaires selon le besoin d’espace. Le nombre de disque dépendra aussi du SKU choisi pour cette machine virtuelle. Dans notre exemple, nous n’allons rien changer ici :
Cet onglet a son importance car il définit les interactions réseaux possibles avec la nouvelle machine virtuelle. Plusieurs options ici vont donc potentiellement créer, ou non, de nouvelles ressources Azure :
Réseau virtuel : La machine virtuelle doit obligatoirement être sur un réseau virtuel, même si ce dernier ne comporte aucune autre ressource.
Sous-réseau : Le réseau virtuel doit comporter au minimum un sous-réseau. Le sous-réseau sera utile pour segmenter et sécuriser une infrastructure. Besoin de comprendre l’adresse IP ? Cliquez-ici !
IP publique : L’IP publique n’est pas une ressource obligatoire et doit être évitée dans un grand nombre de cas pour des questions de sécurité. Dans notre exemple, cette IP publique nous sera utile pour nous connecter à cette nouvelle machine Windows 11.
Groupe de sécurité réseau : Ce composant réseau d’Azure est très pratique pour filtrer les accès entrants et sortants sur un sous-réseau. Il ne s’agit pas ici d’une solution Firewall, mais d’un filtrage par sources, ports et protocoles.
Ports publics entrants : A la différence du premier onglet, la restriction ou l’autorisation de ports ouverts définie ici concerne le groupe de sécurité réseau.
Ports entrants : Propose là encore l’ouverture des ports de management habituels (HTTP, HTTPS, SSH ou RDP)
Accélération réseau : Avec la mise en réseau accélérée, le trafic réseau arrive directement à l’interface réseau de la VM.
Equilibreur de charge : Propose d’intégrer la nouvelle machine virtuelle derrière un équilibreur de charge existant. Très pratique pour augmenter et répartir le volume de requêtes pour un site web frontal.
Onglet IV : Management
Cet onglet apporte des outils complémentaires concernant la gestion de la machine virtuelle. Cela est utile pour diagnostiquer ou résoudre les problèmes :
Diagnostiques de démarrage : Comme son nom l’indique, il est possible de conserver un journal du démarrage de la machine virtuelle, qui pourra être exploité si un jour la machine virtuelle ne démarre pas correctement.
Diagnostiques invités de l’OS : Remonte des métriques additionnelles sur de la machine virtuelle vers un compte de stockage Azure.
Identité managée : Créé et gère une identité propre à la machine virtuelle. Cette dernière pourra avoir des droits sur d’autres ressources Azure, dans le but d’éviter la création d’un mot de passe qui serait stocké sur celle-ci.
Connexion via Azure AD : Combinaison intelligente pour permettre l’authentification via Azure AD. Cela passe aussi par l’ajout de rôles sur la ressource Azure pour autoriser ou non la connexion des utilisateurs.
Arrêt automatique : Programmation d’un arrêt OS de la machine virtuelle selon un horaire, lui-même défini selon un fuseau horaire. Très pratique pour diminuer la consommation Azure et donc le coût si la machine n’est pas utilisée en 24/7. Attention, le démarrage n’est pas automatique et devra donc passer par l’ajout d’un traitement batch.
Reprise après sinistre : Même dans un Cloud, on n’est jamais à l’abri d’une panne globale d’un centre de données. La réplication d’une machine virtuelle dans une seconde région Azure est alors possible et gérée par un service dédié : Recovery Services Vault.
En plus des options de management, d’autres fonctionnalités sont encore disponibles avant la création de la machine virtuelle :
Extension : les extensions sont un moyen rapide d’apporter une couche de configuration supplémentaire. Certaines sont disponibles via la bibliothèque d’extensions, mais il est aussi possible de travailler avec des scripts personnalisées.
Données personnalisées : Propose d’ajouter des données en plus de l’image déployée. Dans le cadre d’une image Windows, ces données seront stockées dans %SYSTEMDRIVE%\AzureData\CustomData.bin.
Données utilisateurs : Les données utilisateur sont une nouvelle version des données personnalisées et offrent des avantages supplémentaires.
Hôtes dédiés : Comme indiqué sur cette page, l’hôte dédié vous donne l’assurance que seules les machines virtuelles de votre abonnement se trouvent sur l’hôte physique, donc isolées des autres. La facturation se fait alors par hôte dédié et non par machines virtuelles créées.
Groupe de placement de proximité : Regroupement logique utilisé pour s’assurer que les ressources Azure se trouvent proches les unes des autres. Les groupes de placements de proximité sont utiles pour les charges de travail où une latence faible est requise.
Génération de machine virtuelle : La génération 2 existe maintenant depuis plusieurs années. Le choix de la génération va dépendre de l’OS choisi. Ce dernier apporte des fonctionnalités comme le Secure Boot, la prise en charge d’un disque OS supérieur à 2 To…
Note :
Il est maintenant possible de créer une machine virtuelle GEN 2 bénéficiant du Trusted Launch. Pour bénéficier de cette option encore en préversion, il est nécessaire de passer par ce lien spécifique du portail Azure. Vous aurez alors accès aux options suivantes :
Attention, le Trusted lunch n’est pas accessible sur toutes les images d’OS ou en GEN1 Windows 11 PRO -> KO Windows 11 Enterprise -> OK
Pour rappel, celui fonctionne uniquement sur les machines virtuelles de seconde génération. Concrètement, ce démarrage sécurisé de la VM repose sur une version virtualisée du TPM :
Merci à Dean pour cette vidéo ????.
Onglet VI : Tags
Le tags est une information facultative mais fort pratique pour la classification des ressources Azure. Un tag est composé d’une paire nom/valeur. Il précise des informations sur les projets, les responsables, les durées de vie des ressources ou encore les utilisateurs finaux. Une ressource Azure peut contenir jusqu’à 50 tags.
Etape II : Déploiement de la machine virtuelle
Une fois toutes les options renseignées et la création déclenchée, il ne reste plus qu’à patienter quelques minutes. Il n’est pas nécessaire de rester sur la page de déploiement pendant le traitement. Une notification vous avertira du succès ou de l’échec de celui-ci.
Cette copie d’écran ci-dessus nous présente en détail les ressources créées pour cette machine virtuelle.
Un aperçu des mêmes ressources dans le groupe de ressources Azure nous indique une 6ème ressource :
Le disque OS est bien une ressource à part de la machine virtuelle. Il peut être détaché au besoin de cette dernière.
Etape III : Connexion à la machine virtuelle
Dans notre exemple, la connexion est RDP est ouverte sur notre machine virtuelle Windows 11 car nous avons autorisé l’accès RDP sur la machine, mais également sur la partie réseau d’Azure. Voici ci-dessous une vue des règles, entrantes et sortantes, ouvertes sur le groupe de sécurité, rattaché ici à la carte réseau de la VM :
L’avertissement indiqué sur la règle entrante pour le port RDP est présent pour vous alerter sur ce risque possible d’intrusion, car ouvert sur Internet.
L’accès RDP est possible directement depuis la fonction présente dans la barre d’action. Il est aussi possible d’utiliser l’adresse IP publique rattachée à la machine virtuelle :
Bastion est un autre moyen d’accès beaucoup plus sécurisé car il ne demande pas d’adresse IP publique pour chaque VM. Plus d’informations ici.
Le téléchargement et le lancement du fichier de connexion de bureau à distance vous affichera l’alerte de sécurité suivante :
Il ne vous restera alors qu’à renseigner les codes administrateurs renseignés sur le premier onglet lors de la création de la machine virtuelle :
Enfin vous y êtes ! Vous voici dans votre nouvelle machine virtuelle Azure, tourant sur Windows 11 ????
Conclusion
Pour un utilisateur déjà habitué aux machines virtuelles sur Azure, aucune différence lors de la création d’un Windows 11 sur Azure. En attendant le passage de Windows 11 en disponibilité générale, prévu pour le 05 octobre prochain, voici un article détaillé sur les nouveautés présentes dans le nouvel OS de Microsoft. Enfin voici également un test de celui-ci en vidéo :
Il ne me reste qu’à vous souhaiter une bonne lecture. N’hésitez pas à faire part de vos remarques sur Windows 11 dans les commentaires ????
La fonctionnalité d’optimisation des performances multimédia sur Azure Virtual Desktop avait été annoncée il y a déjà quelques temps. Elle est maintenant accessible pour une phase de test publique. Pour en savoir plus, voici un lien vers la documentation officielle de Microsoft.
Dans cet article, nous allons installer et tester la fonctionnalité, étape par étape, afin de mesurer l’impact sur les performances sur un environnement Azure Virtual Desktop :
Contrôle de la version de Windows Desktop Client
Création d’un nouvel environnement AVD
Assignation des utilisateurs aux machines virtuelles d’AVD
Modification des paramètres RDP
Ajout des droits RBAC sur le groupe de ressources AVD
Création d’Azure Bastion
Installation de Google Chrome
Installation de Multimedia Redirector Service
Installation des extensions sur les navigateurs Internet
Test de la solution avec et sans optimisation
Etape I : Contrôle de la version de Windows Desktop Client
Une version minimale est nécessaire pour profiter de la redirection multimédia sur votre poste local : 1.2.2222. Vous pouvez retrouver la page de téléchargement ici. Voici également le lien vers le patchlog de l’outil Windows Remote Desktop.
Comme indiqué dans la documentation Microsoft, la machine locale doit disposer de performances minimales pour effectuer la redirection multimédia dans de bonnes conditions. Microsoft met donc à disposition une liste de recommandations matérielles pour Teams.
Il est également nécessaire d’intégrer la machine locale au programme Insider. Cette action s’effectue directement depuis le Registre Windows :
Il est nécessaire de créer les entrées suivantes.
Une fois la modification du registre terminée, relancez Windows Remote Desktop pour constater qu’une nouvelle mise à jour est maintenant disponible :
Notre client Windows Remote Desktop est maintenant à jour. Retournez sur le portail Azure pour créer un nouvel environnement Azure Virtual Desktop. Passez ces étapes si vous disposez déjà d’un AVD fonctionnel sur une souscription Azure.
Etape II : Création d’un nouvel environnement AVD
Afin de faire un test de la solution sur un nouvel environnement, je vous remets ici tous les écrans de création d’AVD. Veuillez noter que nouvelles options sont apparues, nous prendrons le temps d’en parler lors de ce déploiement. Suivez si besoin ce guide étape par étape :
Utilisez la barre de recherche pour retrouver le service Azure Virtual Desktop.
La création complète de l’environnement Azure Virtual Desktop commence en cliquant ici :
Le premier onglet d’options ci-dessous défini les options de mon environnement (Pool d’hôtes) :
Le second onglet est dédié aux machine virtuelles. Notez qu’il est nécessaire de créer au préalable un réseau virtuel dans la même région Azure que votre AVD. Le processus de création ne propose pas d’en créer un :
Depuis quelques temps déjà, il est possible de se passer d’un domaine Active Directory pour AVD. Un article sur ce sujet est consultable ici.
Nouvelle option très pratique.
Le troisième onglet est consacré à l’espace de travail des utilisateurs :
Aucun changement particulier ici.
Un nouvel onglet fait son apparition pour permettre le paramétrage des options de logs et de métriques. J’en ai donc profité pour créer un espace Log Analytics Workspace, avant le déploiement de ma solution AVD :
Notez que cette nouvelle fonctionnalité ne paramètre la remontée que pour le pool d’hôtes et l’espace de travail. Il reste encore des opérations manuelles pour y intégrer les machines virtuelles.
Une fois la configuration AVD terminée, comptez environ une bonne quinzaine de minutes pour que le déploiement se fasse :
Etape III : Assignation des utilisateurs aux machines virtuelles d’AVD
Dans le cadre de mon test, j’ai souhaité assigner manuellement les deux machines virtuelles à différents utilisateurs. Je dois donc faire les deux opérations moi-même.
Avant d’assigner les utilisateurs sur les machines virtuelles AVD, il est nécessaire de rajouter ces derniers sur le groupe d’applications AVD, créé automatiquement lors de l’étape précédente :
Il est préférable de faire une assignation via un groupe.
L’assignement des utilisateurs AVD sur les machines virtuelles peut se faire sans souci juste après :
Attention : l’assignement des utilisateurs aux machines virtuelles est irrévocable !
Comme mon exemple est basé sur une intégration des machines virtuelles avec Azure AD, je suis dans l’obligation d’effectuer des étapes supplémentaires pour rendre pour AVD fonctionnel. Les étapes 4 et 5 sont donc dédiées au scénario AVD sans serveur Active Directory.
Etape IV : Modification des paramètres RDP
Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se font directement sur le pool d’hôtes d’AVD :
targetisaadjoined:i:1
La copie d’écran ci-dessus montre le paramétrages des options RDP possibles.
Vous retrouverez ici la liste de toutes les options RDP possibles, dont seulement certaines sont compatibles avec Azure Virtual Desktop. Voici les arguments utilisés sur la copie d’écran ci-dessus :
Etape V : Ajouts des droits RBAC sur le groupe de ressources AVD
Afin d’autoriser les utilisateurs d’Azure AD à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se font assigner directement le groupe de ressources AVD :
Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD
L’étape suivante avec Azure Bastion permet d’administrer plus facilement les machines virtuelles d’Azure Virtual Desktop. Vous pouvez déployer ce service et en profiter pour toutes les machines virtuelles présentes dans le même réseau virtuel que ce dernier. Cela marche aussi pour les VMs sur des réseau virtuels appairés.
Etape VI : Création d’Azure Bastion
Azure Bastion est un service que vous déployez et qui vous permet de vous connecter à une machine virtuelle à l’aide de votre navigateur et du portail Azure. Cette étape est facultative dans notre démonstration, mais Azure Bastion nous facilite les opérations d’installation sur les machines virtuelles d’AVD.
Schéma expliquant le principe de connexion TLS d’Azure Bastion.
La création d’Azure Bastion est très facile et se fait en seulement quelques minutes sur notre environnement de test :
Le nom du subnet d’Azure Bastion est normé et ne peut être différent de cette copie d’écran.
Quelques minutes plus tard, Azure Bastion s’est déployé sur le réseau virtuel. Rien de plus n’est nécessaire pour l’utiliser !
Azure Bastion est maintenant installé. Dans le cadre de notre test, nous allons effectuer l’opération d’optimisation sur une seule des 2 machines virtuelles AVD. Le but étant de comparer le bénéfice de la solution, avec et sans la redirection multimédia. L’étape suivante est dédiée à l’installation de Google Chrome et se fera sur les 2 VMs.
Etape VII : Installation de Google Chrome
Connectez-vous via Azure Bastion sur la première machine virtuelle :
Renseignez ici les codes admins saisis lors du déploiement d’AVD.
Voici ici le lien officiel pour installer Google Chrome.
Il faudra aussi installer Google Chrome sur la seconde machine virtuelle pour nos tests. Vous pouvez garder ouvert l’onglet d’Azure Bastion de la première machine virtuelle quand vous vous connectez à la seconde.
Etape VIII : Installation de Multimedia Redirector Service
Vous l’avez compris, l’installation du Multimedia Redirector service ne doit se faire que sur la première machine virtuelle. Vous pouvez le télécharger ici.
L’installation est assez rapide et ne comporte que quelques écrans.
Etape IX : Installation des extensions sur les navigateurs internet
Si le navigateur Google Chrome est encore ouvert sur votre première machine virtuelle, vous devriez voir le message d’alerte suivant :
L’ouverture de Microsoft Edge après l’installation de Multimedia Redirector Service doit également remonter l’alerte suivante :
Etape X : Test de la solution avec et sans optimisation
A date, la fonctionnalité de redirection multimédia sur AVD n’est pas disponible via accès Web, mais uniquement via Windows Remote Desktop. Nous voilà donc prêts à tester notre solution :
Si vous rencontrez des difficultés d’authentification lors de votre entrée dans la VM : faite un sign-out complet de Windows Remote Desktop.
La mention Insider est bien présente dans le titre de notre fenêtre de Windows Remote Desktop.
Une fois connecté dans votre session AVD avec le compte de votre premier utilisateur de test, vérifiez l’état des extensions dans les 2 navigateurs Internet :
Google Chrome et Microsoft Edge présentent aussi une case à cocher pour rendre la fonctionnalité opérationnelle sur tous les sites.
La version publique de la redirection multimédia pour Azure Virtual Desktop a limité la lecture sur YouTube. Pour tester YouTube dans le cadre du déploiement de votre organisation, vous devrez activer une extension.
Microsoft
Un tour sur YouTube permet de se rendre compte de l’impact des performances sur la machine virtuelle. Voici un lien vers une vidéo en 4K. Prenez le navigateur Internet de votre choix pour les tests :
Un petit tour dans les performances des 2 machines virtuelles pendant la lecture de cette vidéo à haute résolution montre l’impact sur les performances avec ou sans la redirection multimédia :
Sans redirection multimédia :
L’utilisation CPU est totale pour cette lecture 4K sans l’optimisation multimédia.
Avec redirection multimédia :
L’utilisation CPU est fortement diminuée pour cette lecture 4K avec l’optimisation multimédia.
Conclusion
Avant tout, l’objectif premier de la redirection multimédia n’est pas de permettre à tous les utilisateurs d’Azure Virtual Desktop de lancer des vidéos 4K YouTube en simultané. Le but ici est bien d’alléger les sollicitations en performance des machines virtuelles AVD. Imaginez l’impact sur un environnement Azure Virtual Desktop, partagé par une douzaine d’utilisateurs utilisant Microsoft Teams.
La redirection multimédia vous permet d’obtenir une lecture vidéo fluide lorsque vous regardez des vidéos dans votre navigateur Azure Virtual Desktop. La redirection multimédia déplace l’élément multimédia du navigateur vers la machine locale pour un traitement et un rendu plus rapides.
Microsoft
Merci à Freek Berson pour sa vidéo de démonstration.
Comme toujours, faites part de vos remarques sur la redirection multimédia d’Azure Virtual Desktop dans les commentaires ????
Sorti le 02 août dernier, beaucoup de personnes ont déjà eu l’occasion de tester Windows 365 en version d’essai ou via un achat de licences. A l’inverse d’Azure Virtual Desktop, ce nouveau service bureau à distance proposé par Microsoft se positionne au plus proche d’un service SaaS. De façon générale, le déploiement de Windows 365 est assez facile et rapide.
A peine sorti et déjà dans la mouise????.
Mise en place de Windows 365
La mise en place de Windows 365 a déjà été abordé dans cet article. Voici également d’autres liens très utiles :
Néanmoins, de petits blocages peuvent arriver à différentes étapes du processus de mise en place. Dans cet article, nous allons passer en revue quelques problèmes possibles et tenter d’y apporter des solutions.
Problème 1 : Impossible de commander des licences d’essai de Windows 365
Problème 2 : Windows 365 Entreprise : Erreur de check(s) sur la connexion réseau on-premise
Problème 3 : Windows 365 Entreprise : L’inscription d’Intune MDM a échoué
Problème 4 : Windows 365 Entreprise : Erreur de passerelle lors de l’ouverture de session Windows 365
Problème 1 : Impossible de commander des licences d’essai de Windows 365
Au premier jour de disponibilité de Windows 365, des licences d’essai étaient disponibles pour Windows 365. Ces licences gratuites étaient bien visibles depuis la console d’administration de Windows 365 :
3 éditions sont disponibles pour Windows 365. Plus d’informations ici.
Dans chaque des 3 éditions se trouvaient la version d’essai disponible en plusieurs tailles de Cloud PC. La durée de la licence d’essai était de 60 jours.
Chaque tenant pouvait prendre 3 tailles de Cloud PCs pour chacun des 3 éditions de Windows 365.
Présente encore il y a quelques jours, l’activation de la version d’essai affichait le message d’erreur suivant :
Gauche : message d’erreur au moment de l’achat. Droite : les licences d’essai ne sont plus visibles dans la liste.
En lieu est place de ces licences, il est malgré tout possible de découvrir Windows 365 par cette simulation. Selon les dernières informations de Microsoft :
L’achat de licences d’essai a été suspendu faute d’un immense succès.
Aucune date de réouverture n’est annoncée concernant la disponibilité des licences d’essai
Les licences d’essai déjà prises ne sont pas impactées par cette restriction
Il est recommandé de s’inscrire ici pour se tenir informer des prochaines nouveautés
Problème 2 : Windows 365 Entreprise : Erreur de check(s) sur la connexion réseau on-premise
Les licences Windows 365 Entreprise nécessitent systématiquement une connexion réseau on-premise. Mon article précédent sur Windows 365 détaille bien le processus de création de cette connexion. Vous pouvez aussi regarder la vidéo très explicative de Dean sur ce sujet :
Après la création de la connexion on-premise, Windows 365 va se charger de vérifier un certain nombre de paramètres essentiels au bon déploiement des Cloud PCs :
La première connexion est en erreur, un clic sur son status explique le détail précis de cette dernière.
Un problème d’identification sur le domaine est constaté par Windows 365. Il faut donc vérifier à nouveau les informations de domaine.
La seconde connexion a passé tous les contrôles de Windows 365. Elle peut donc être utilisée pour créer une police de provisionnement.
Note : Il existe des erreurs non bloquante, comme celle-concernant Azure AD device sync :
Comme indiqué dans cet article de Microsoft, cette erreur de synchronisation des Cloud PCs dans Azure AD peut prendre du temps. Il faut se rappeler que celui-ci s’opère avec l’agent Azure AD Connect, dont le cycle de synchronisation par défaut est de 30 minutes. Ce temps peut s’allonger si votre architecture Active Directory est repartie en différents rôles :
Si Azure AD Connect est correctement configuré avec l’option Hybrid Azure AD join, cette alerte devrait disparaître.
Problème 3 : Windows 365 Entreprise : L’inscription d’Intune MDM a échoué
Comme indiqué dans les prérequis de Windows 365 Entreprise, il est nécessaire de disposer de plusieurs licences au préalable. Windows 365 effectue une inscription MDM dans Intune.
L’erreur ci-dessous montre que la configuration MDM dans Intune est incorrect.
Les contrôles des options du tenant dans Intune indiquent clairement un problème de licence.
Problème 4 : Windows 365 Entreprise : Erreur de passerelle lors de l’ouverture de session Windows 365
L’utilisateur souhaite accéder à son Cloud PC mais rencontre une erreur lors de l’ouverture de la session Windows. Ce problème peut se produire via l’interface web ou le client Remote Desktop :
Un reprovisionnement de licence Windows 365 ou de Cloud PC n’y change rien ????.
Le Cloud PC est pourtant correctement provisionné dans Intune.
De mon expérience, le souci ici vient de l’utilisation d’un domaine managé Azure AD DS au lieu d’un domaine Active Directory. Voici un rappel des différents modèles d’identité compatibles avec les solutions de bureau à distance proposées par Microsoft :
Conclusion
Prenez le temps de lire les erreurs et de bien vérifier vos paramètres le cas échant afin de ne pas perdre trop de temps ou de motivation. Vous pouvez retrouver les documentations de gestion des erreurs ici et là. En cas de doute, il faut ne pas hésiter à reprendre la documentation initiale de déploiement disponible là. Faites part de vos remarques sur la solution Windows 365 dans les commentaires ????
