Annoncé fin mars 2021 pour les environnements personnels Azure Virtual Desktop, Azure Preview propose maintenant cette même fonction pour les environnements AVD mutualisés (Pooled).
Voici un petit rappel de la solution par Dean d’Azure Academy.
La vidéo de Dean met en oeuvre la solution sur un environnement AVD personnel, qui fonctionne aussi pour les environnements mutualisés, et applique les point suivants :
Activation de l’option « Start VM On Connect » sur le Host Pool
Création d’un rôle custom pour donner le droit à AVD de démarrer les VMs
Affectation du rôle custom à la souscription ou au groupe de ressources
Déconnexion des sessions inactives via GPO
Activation de l’arrêt automatique des machines virtuelles à une heure fixe
Mise en place : La mise en place de cette solution est bien expliquée dans la vidéo de Dean, vous pouvez aussi suivre la documentation de Microsoft juste ici.
Rappel : La fonction est encore en public preview pour les environnements AVD mutualisés, il faut donc utiliser le portail adéquat.
Testez vous-même
De mon côté, j’ai souhaité tester la solution sur différents cas de figure :
Test sur un AVD en mode personnalisé : OK
Test sur un AVD en mode mutualisé (Windows 10 multisession) : OK
Test sur un AVD en mode mutualisé (Windows Server 2019) : OK
J’ai aussi fait un test plus poussé dans le cadre d’un environnement AVD mutualisé comprenant plusieurs machines virtuelles :
Nombre de machines virtuelles : 2
Algorithme d’équilibrage de charge : Breadth-first
Nombre maximal de sessions : 5
Voici ce qui s’est passé au niveau des machines virtuelles :
Environnement de départ, toutes les VMs sont OFF.
Connexion du premier utilisateur, une seule VM s’allume.
Connexion du second utilisateur, la seconde VM ne s’allume pas car l’utilisateur se retrouve connecté à la première VM.
J’ai donc refait un autre test en modifiant le nombre maximal de sessions :
Nombre de machines virtuelles : 2
Algorithme d’équilibrage de charge : Breadth-first
Nombre maximal de sessions : 1
Les premières étapes n’ont pas changé, mais j’ai bien eu autre chose lorsque le second utilisateur a tenté de se connecter :
Le second utilisateur doit bien attendre le démarrage de la seconde VM pour s’y connecter.
Les deux VMs sont bien allumées dans ce cas.
Conclusion
Au final, la fonctionnalité est bien opérationnelle et s’adapte bien à différents cas d’architecture Azure Virtual Desktop. Seul petit bémol concernant la fonction Breadth-first qui demande encore quelques ajustements pour bien allumer les autres VMs afin de répartir les utilisateurs ????
Dans le cloud, il faut anticiper les pannes. Au lieu d’essayer d’empêcher toutes les défaillances, l’objectif est de réduire les répercussions d’une défaillance potentielle au niveau de chaque composant. Dans ce cas, les stratégies de sauvegarde et de récupération deviennent importantes.
Azure propose une solution de récupération d’urgence de bout en bout, simple, sécurisée, évolutive et rentable, qui peut être intégrée à des solutions locales de protection des données. Il est donc possible d’assurer une continuité de service par la réplication des ressources sur une seconde région.
Voilà pour la définition officielle côté Microsoft.
Je trouve cette image d’architecture assez parlante : le but d’un Disaster Recovery est bien de répliquer un site de production existante vers un second site, et d’assurer une synchronisation des données pour avoir une reprise d’activité des plus performantes.
Voici un exemple d’architecture Azure, redondée en totalité sur une seconde région Azure.
Contexte : AzureVirtual Desktop
Pour les architectures basées sur Azure Virtual Desktop, le fonctionnement est identique : je vais répliquer les services suivants dans une seconde région Azure :
Active Directory : ici Azure Active Directory Domain Services
Machine virtuelle : composant principal de AVD
Disque managé : utilisé pour OS
Compte de stockage : utilisé pour les profils utilisateurs via la solution FSLogix
Il est également possible de répliquer les ressources propres à Azure Virtual Desktop dans une seconde région, telles que :
Host Pool
Workspace
Applications groups
Je ne vais pas faire cette réplication globale dans ce billet, car je souhaite vous montrer ici le processus d’auto-enrôlement des machines virtuelles, issues du Test Failover, directement dans l’environnement Azure Virtual Desktop existant.
Je vais détailler de manière assez rapide la mise en place du premier environnement de production AVD, hébergé sur Suisse Nord. Cela reste un déploiement classique, car il ne nécessite pas de spécificités particulières pour la mise en place du Disaster Recovery, installé dans un second temps.
Etape I : Création d’un domaine Active Directory
La première étape consiste à la création du domaine. Cette solution est obligatoire pour la mise en place de tout environnement Azure Virtual Desktop.
Comme indiqué plus haut, j’ai choisi d’utiliser le service Azure Active Directory Domain Services. Pour rappel, il s’agit d’un domaine managé par Microsoft et c’est une ressource unique par Tenant :
Alternative : Il est malgré tout possible de choisir un serveur Active Directory sur une machine virtuelle.
Voici une vidéo très explicative de Travis Roberts, qui montre les différences entre Active Directory, Azure Active Directory et Azure Active Directory Domain Services
Pour pouvoir répliquer mon service AADDS dans une seconde région Azure, j’ai choisi le SKU “Enterprise” car le SKU “Standard” ne permet pas d’utiliser la fonction Réplica Set. Pas de panique, ce SKU reste modifiable, même après la création du service AADDS et comme expliqué ici :
Merci à AnubhavinIT pour cette démonstration d’installation d’AADDS.
Etape II : Création d’une image pour les machines virtuelles
Encore une fois, je ne vais pas m’étendre en détail sur ce processus de création d’une image pour votre environnement Azure Virtual Desktop. A vrai dire, il ne diffère en rien de la préparation d’une image en dehors du cloud. L’idée générale ici est de créer un ensemble d’applicatifs et de configurations pour automatiser le processus de création de machines virtuelles dans votre environnement AVD.
La dernière vidéo complétement déjantée de Dean Cefola le montre très bien ????.
Etape III : Création d’un environnement AzureVirtual Desktop
Une fois l’image “prête à l’emploi”, nous allons pouvoir créer notre environnement Azure Virtual Desktop. Cette création va mettre en place les ressources Azure suivantes :
Host pool
x machine(s) virtuelle(s)
Workspace
Applications groups
Pour être toujours complet dans le processus de création AVD, je vous conseille cette vidéo de Mike Rodrick sur cette étape.
Etape IV : Mise en place du compte de stockage FSLogix
Le service Azure Virtual Desktop recommande les conteneurs de profils FSLogix en tant que solution de profil utilisateur. FSLogix est conçu pour l’itinérance des profils dans des environnements informatiques à distance, comme Azure Virtual Desktop. Il stocke un profil utilisateur complet dans un seul conteneur.
L’idée générale de séparer le profil utilisateur de la VM permet faciliter la mise à jour des images, de laisser l’utilisateur se connecter sur une autre VM en y retrouvant toutes ses applications et ses datas.
Pour comprendre en détail son fonctionnement et son utilité dans notre architecture AVD, quoi de mieux que de demander encore une fois à Dean.
Point important : L’installation de FSLogix nécessite quelques étapes, notamment au niveau de l’application des droits utilisateurs sur le file share (NTFS + RBAC).
Une bonne vidéo vaut toujours que de longues explications, merci Travis Roberts.
Etape V : Mise en place du Disaster Recovery via Azure Site Recovery
Notre environnement de production de Azure Virtual Desktop est maintenant prêt, nous allons pouvoir commencer la mise en place de la solution de Disaster Recovery.
Pour vous assurer que les utilisateurs peuvent toujours se connecter pendant une panne de région, vous devez répliquer leurs machines virtuelles à un autre emplacement. En cas de panne, le site principal bascule vers les machines virtuelles répliquées dans l’emplacement secondaire. Les utilisateurs peuvent continuer à accéder aux applications à partir de l’emplacement secondaire sans interruption. En plus de la réplication de machine virtuelle, vous devez conserver les identités utilisateur accessibles à l’emplacement secondaire. Si vous utilisez des conteneurs de profils, vous devrez également les répliquer. Enfin, assurez-vous que vos applications d’entreprise qui reposent sur les données de l’emplacement principal peuvent basculer avec le reste des données.
Dans mon cas, je vais utiliser le service Azure Site Recovery pour assurer la réplication des machines virtuelles. En effet ce service assure une réplication constante des données dans Azure.
Attention : pour faire un DR complet, il faudra aussi prendre en considération la réplication du compte de stockage utilisé pour les profils gérés par FSLogix.
Activer la réplication d’une machine virtuelle peut se faire directement depuis l’interface de la VM.
Je vais pouvoir choisir ma région de réplication et personnaliser certains paramètres de configuration. Il n’est pas obligatoire de localiser la réplication sur la région paire de la première. Des coûts de bande passante entre région seront évidemment facturés par Microsoft.
J’ai déjà créé au préalable un premier groupe de ressources et un premier réseau virtuel dans ma seconde région, j’ai donc pu les sélectionner sans souci.
On peut donc démarrer la réplication juste après :
Ce processus d’initialisation prend un peu de temps, mais peut-être suivi par les notifications Azure.
Une fois la première réplication entièrement terminée, nous retrouvons sur la machine virtuelle son état de DR et toutes les informations associées.
Voici les ressources Azure créées dans la seconde région Azure. Finalement, nous n’avons qu’un compte de stockage et qu’un réseau virtuel.
Avant de démarrer la bascule des VMs dans AVD vers la seconde région Azure, je souhaite vous montrer l’état d’environnement de Azure Virtual Desktop :
Le Remote Desktop est bien accessible aux utilisateurs via l’application AVD Remote Desktop ou l’accès WEB.
Pour vérifier le bon fonctionnement du Disaster Recovery, qui je le rappelle doit TOUJOURS être déclenché manuellement, nous allons utiliser la fonction “Test Failover” de ce dernier :
Je commence par éteindre les machines virtuelles AVD déjà présentes sur Suisse Nord.
Je déclenche le Test Failover sur la ou les VMs AVD.
Un DR, exercice ou non, doit TOUJOURS être déclenché manuellement.
Pourquoi cela ?
Cela tient à une propriété d’enrôlement automatique des machines virtuelles à AVD.
Du fait que les nouvelles machines virtuelles vont avoir le même nom de machine que les précédentes, je souhaite vous montrer ici l’interruption de service, puis la reprise d’activité avec les nouvelles machines dans la seconde région Azure :
L’arrêt des machines virtuelles entraîne un service indisponible dans AzureVirtual Desktop.
Une fois le failover déclenché sur les deux machines virtuelles de mon environnement AVD, on retrouve toutes les nouvelles ressources Azure, automatiquement créées dans la seconde région Ouest Europe :
Copie d’écran des ressource présentes dans le groupe de ressources ASR.
Copie d’écran de ma liste de VMs : on retrouve bien donc deux VMs allumées (Ouest Europe) et deux VMs éteintes (Suisse Nord).
Résultat constaté : quelques minutes plus tard, je retrouve donc un environnement Azure Virtual Desktop opérationnel, sans aucune action supplémentaire de ma part :
Attention une VM qui passe peut en cacher une autre ! On peut noter que la région indique toujours la Région Azure Suisse nord car l’enrôlement de la nouvelle machine virtuelle s’appuie toujours sur les propriétés de la machine originelle.
Côté utilisateur : les utilisateurs peuvent donc se reconnecter à Azure Virtual Desktop :
Aperçu utilisateur via l’application Remote Desktop dédiée à AzureVirtual Desktop.
Note : Une fois le test de Failover réussi, pensez à nettoyer les ressources créées pour l’occasion et rallumer les machines virtuelles de production :
Une fonctionnalité de nettoyage des ressources issues du test du DR est directement disponible ici.
Résultat attendu :
Une fois le nettoyage démarré et les VMs de production rallumées : les machines virtuelles de production reprendront leur place dans l’host pool de Azure Virtual Desktop :
Le statut des VMs dans le host pool AVD retourne en « Unvailable » lorsque je le nettoie les ressources issue du test du Failover.
Le statut des VMs de retourne en « Available » lorsque je redémarre les machines de productions dans Suisse Ouest.
Conclusion
J’espère avoir été assez claire dans ce billet pour vous permettre de faire votre propre test dans votre environnement Azure Virtual Desktop.
Attention rappel, je n’ai pas parlé de la réplication de compte de stockage pour FSLogix, lui aussi à prendre en compte dans une solution de disaster recovery complète.
N’hésitez pas à faire part de vos réactions ou questions dans les commentaires ????
Mon expérience sur l’examen Windows Virtual Desktop (AZ-140)
Fin mars 2021, une nouvelle certification Microsoft Azure a vu le jour et elle se consacre uniquement à seul produit : Windows Virtual Desktop. Pour rappel, Windows Virtual Desktop (aussi appelé WVD) est une plateforme lancée en septembre 2019 de type « Desktop-as-a-Service » (DaaS) sur Microsoft Azure qui offre la meilleure expérience virtuelle de Windows et de Microsoft Office. Voilà pour la définition officielle.
Comme pour la certification SAP sur Azure, le but de cette certification est de valider des connaissances sur les caractéristiques de WVD, mais aussi d’être en en mesurer déployer cette solution selon plusieurs scénarios et contraintes possibles :
Migration d’un environnement RDS existant en y simplifiant le management
Création d’un nouvel environnement de virtualisation sécurisé et moderne
Apporter de la continuité pour des applications “Legacy” qui fonctionne encore sur Windows 7
Ayant passé cette certification début avril 2021, encore en version Beta, je vais vous partager mon retour d’expérience sur cet examen en attendant les résultats finaux, afin de vous aider au mieux sur le contenu à maitriser.
Pour rappel, le contenu exact est aussi disponible sur la page de la certification AZ-140 (ici). Vous pouvez aussi le télécharger au format PDF à partir de ce lien.
On va donc retrouver différents sujets dans cette certification, dont les principaux pourraient être :
Architecture on-premise existante : vous avez de fortes chances de vous retrouver avec un ou plusieurs use-cases. Ces derniers partiront certainement d’une architecture on-prem existante, avec des contraintes à respecter pour migrer sur WVD. Le cas assez classique pourrait être un multisites avec un siège et succursales ayant des besoins variés et des contraintes de distances.
Connaissances des réseaux sur Azure : là encore c’est un grand sujet de presque toutes les certifications Azure. La maîtrise de la solution WVD passe par la mâitrise de ses exigences réseaux. Il n’est quand pas utile de connaître cette liste de ports et d’URLs par coeur ! Mais on va vous demander de bien connaître les réseaux utilisés, notamment pour la partie dédiée utilisateur (ex spécificité iOS). Vous pourrez également avoir des questions sur les accès par lien VPN ou le peering entre v-net.
Active Directory : Composante fondamentale d’un environnement Windows Virtual Desktop, vous pouvez être sûr que des questions vont concerner ce sujet. Les possibilités de monter environnement WVD sont variées concernant ce point et nécessite d’en avoir testé au préalable plusieurs. Attendez-vous aussi avoir des connections sur le très célèbre Azure AD Connect.
L’utilisation d’un domaine managé, tel que d’AADDS est un moyen simple et rapide d’installer la solution pour des entreprises Cloud-only. Il comporte malgré tout quelques contraintes avant de le choisir.
Autre cas avec un Active Directory hébergé dans une seconde région Azure. A noter ici la présence d’un point of failure : Si la région Azure UK South devient inaccessible, les utilisateurs se connectant sur la région East US ne pourront qu’attendre qu’un rétablissement de service
Architecture Windows Virtual Desktop : il sera question de vérifier ici vos connaissances concernant les grandes notions techniques qui compose la ressource WVD : Host pool (Pooled / Personnal) – Workspace – Applications group. Savoir ce que chacun, savoir ce qu’il fait et connaître leurs principales options est évidement de rigueur.
Merci à Dean Cefola qui anime sur YouTube la chaîne Azure Academy pour cet exemple d’architecture WVD multisites.
Estimation du coût de l’architecture : cette notion est présente dans cette certification, comme dans la certification « Microsoft Azure Architect Design » AZ-304. L’idée ici n’est pas de connaitre tous les prix en $ ou en €, mais d’avoir une idée des gammes de produits de des coûts potentiels. Vous penserez à cela quand la question comportera la remarque « La moins chère possible ». Petite anecdote : AD DF et « La moins chère possible » font rarement bon ménage !
FSLogix : grand gagnant de l’architecture WVD, cette solution a montré ses qualités (souplesse de configuration, performances, facilité de management, …) et reste une valeur sûre dans le jeu de questions que vous pourrez avoir. Pour rappel, FSLogix a été acquis par Microsoft automne 2018. Il faut donc vous attendre à des questions sur son périmètre d’installation (type de storage, SKU, …) et ses principales fonctionnalités (Cloud cache , App masking, configuration Regedit, … ). Ne pas être surpris non plus d’avoir aussi des questions sur la gestion des droits (RBAC ou NTFS)
Gestion des golden images : une bonne pratique a la mise en place d’un remote desktop passe par l’utilisation d’images préconfigurées et mises régulièrement à jour afin de gérer la solution WVD dans les conditions les plus sécurisées. On souhaite donc savoir ici si vous maîtriser le process de création des images (sysprep, capture, …) et leur gestion en exploitation (shared image galery et autres)
Connaissances des rôles WVD : De manière bien large, la construction de ressources sur Azure passe toujours par l’attribution des bons droits (ni trop, ni trop peu). Plusieurs roles WVD ont donc été créés dans le scope Azure RBAC, mais aussi d’autres liés à exploitations des autres ressources tels que les machines virtuelles ou encore les comptes de stockages. Ici donc, il faut aller plus loin que « Owner », « Contributor » et « Reader »
Sécurité : Comme les autres application SaaS, l’accès conditionnel d’Azure AD est aussi de la partie sur Windows Virtual Desktop. Il est en effet possible de créer des règles exigeant l’utilisation de postes « compliant » ou encore d’exiger l’autentification multifacteur. Profitez-en pour faire une piqûre de rappel sur cette partie, cela ne fait jamais de mal !
Expérience utilisateur : en relisant la liste des compétences mesurées pour l’AZ-140, je vois que l’on attendsde vous de savoir configurer Universal Print, MSIX App Attach, Teams AV Redirect et autres. Honnêtement, je n’ai pas souvenir d’avoir eu des questions sur ces points mais d’autres sont plus successible de tomber comme le timeout ou encore sur les propriétés RDP.
Sauvegarde : point capital dans toute architecture informatique, il faut savoir ce qui est capital de sauvegarder et ce qui ne l’est pas ! Prenez le temps de faire des tests sur ce chapitre. Recovery Services vault est un outil assez complet avec les backups et les fonctionnalités de DR intégrées.
PowerShell et Azure CLI : je pense que ce point est réduit puisque presque tous les commandes WVD sont aussi disponible dans le portail Azure. Néanmoins je pense encore que certaines actions, comme joindre un compte de stockage à un domain AD, sont toujours faisable uniquement via ligne de commande
Monitoring de la solution WVD : Plusieurs outils sont disponibles pour monitorer toute la solution. Comme à chaque fois, Azure est toujours généreux dans sauvegarde de logs et de métrics dans un Log analytics workspace ! Il s’agit aussi d’un sujet à lui tout seul, tellement l’espace et les possibilités sont grandes.
Au final et comme toujours, le passage par la case pratique est obligatoire pour réussir cette certification Windows Virtual Desktop. Pensez-à prendre en compte des variations de scénarios pour voir les différents cas de figure.
Voici quelques liens qui m’ont été utile pour préparer mes connaissances :
