Azure – Windows Virtual Desktop Cloud Only (Partie 2)

Windows-Virtual-Desktop-logo-WVD

Dans la première partie, nous avons posé les bases de notre infrastructure. Nous allons maintenant entrer dans le vif du sujet, Windows Virtual Desktop.

Article en cours de relecture.

Presentation de l’environnement Windows Virtual Desktop (WVD)

Tout commence à partir de la console Azure, se rendre dans tous les services et recherché “Windows Virtual Desktop”.

Nous voici sur la console d’administration de Windows Virtual Desktop !

Avant de créer un nouveau pool de machine, nous allons faire un tour rapide de cette console.

Host pools

Les hosts pools sont des regroupement de machines accueillant les sessions utilisateurs. Un host pool donc un regroupement de machines identiques assure la capacité aux utilisateurs d’accéder à une application où un bureau, ce regroupement assure la montée en charge ainsi que la disponibilité des apps /bureaux.

Il existe deux type de pool :

– personnel ou personal : machines affectées /attribuées à un utilisateur précis, fonctionnement proche d’un poste physique.

– mutualisé ou polled : machines mutualités entre plusieurs utilisateurs. Permet de présenter soit des bureaux ou des applications “RemoteApp”. 

Application groups

Les applications group ou groupe d’applications possèdent deux types :

  • Session : présente un bureau complet à l’utilisateur.
  • RemoteApps : présente une application précise installée sur l’ensemble des machines d’un pool.

L’application pool est un regroupement logique d’apps publiée depuis les machines d’un host pool. Lors de la création d’un host pool, un application group par défaut est créé proposant un bureau.

Workspaces

Les workspaces sont des regroupements logique d’applications pools. Le workspace est présenté à l’utilisateur et permet d’ordonner le bureaux où applications qui lui sont présentés. 

Users

Le session “users” permet de rechercher un utilisateur précis et obtenir l’ensemble des sessions (bureaux /applications) auquel il est connecté. 

Types de Host Pools

Lors de la création d’un nouveau pool de machine, nous avons la possibilité de choisir entre deux type de pool, a savoir “Personal” ou “Pooled”.

Pooled pool

Les pools de type pooled sont des ensembles de machines mutualisées entre plusieurs utilisateur. Ce type de pool est ce que l’on retrouvait on-prems avec les sessions-host sous Windows server.

Le principe est de créer plusieurs machines strictement identiques, de publier sur celle-ci un bureau ou des applications afin que les utilisateurs puissent s’y connecter et partagent la même machine. Dans ce type de pools, nous allons retrouver bien entendu les OS de type Windows server et la “nouveauté” Windows 10 multi-session.

La particularité de Windows 10 multi-session est qu’il s’agit d’un OS client en l’occurrence Windows 10 et que celui-ci peut avoir plusieurs sessions utilisateurs simultanées. Ce qui n’était pas possible nativement sur les anciennes version des OS client de Windows. L’avantage de cet OS est que l’on va retrouver le fonctionnement des fermes RDS Windows server où plusieurs utilisateurs partagent la même machine mais avec un interface utilisateurs Windows 10. Ce qui dans le cas de publication de bureau est moins déroutant pour les utilisateurs et permet de lever certaine limitation coté application lorsque celle-ci vérifie la version d’OS avant de s’installer.

Personal pool

Les pools de type personal sont des ensemble de machines où chaque utilisateur à sa propre machine dédiée et n’en changera pas. Il s’agit du PC (virtuel certes) mais le PC dédiés de l’utilisateur. Ceux-ci implique que chaque machine au sein du pool peuvent être différentes tant au niveau hardware qu’au niveau applicatif. Les machines de ce type de pool peuvent avoir un cible de vite très proche de celui d’un poste physique. Il peuvent être enrôlés dans Microsoft Endpoint Management.

Chaque utilisateurs se retrouve avec une machine qui lui est assignée, il s’agit donc de sa machine où il se connectera tout le temps.

Il existe de méthode pour assigner les machines aux utilisateurs :

  • Direct : un admin soit assigner manuellement une machine à un utilisateur.
  • Automatic : une machine est assignée à un utilisateur de manière automatique si une machine est disponible et que l’utilisateur n’a pas encore de machine qui lui est assignée.

Dans tout les cas, l’utilisateur possède ça propre machine et sera connectée à celle-ci.

Création des premiers environnements Windows Virtual Desktop (WVD)

Il est compliqué et long de tester chaque cas de figure pour la création de pool, nous allons voir dans cette partie la création des deux type de pools (polled et personal) basées sur Windows 10. Bien entendu il existe une multitude de combinaison entre pool, OS et méthodes d’assignation qui je vous invite à tester de votre coté.

Création pool de type Polled

Nous allons commencer par créer un pool de type “Polled” donc un pool de bureaux partagés par plusieurs utilisateurs.

Pour ce faire se rendre dans l’interface d’administration WVD et cliquer sur “Create a host pool”.

Dans le blade “Basic”, renseigner les informations demandées :

  • Subscription : votre abonnement Azure.
  • Ressource group : le ressource group correspondant à votre environnement WVD.
  • Host pool name : le nom de votre host pool. Créer une charte de nommage contenant la localisation et le type de pool si possible.
  • Location : enlacement Azure où seront enregistrés les metadatas du pool. Ici nous parlons de metadatas (information sur la configuration du pool) et non de données utilisateur.
  • Validation environment : no, il s’agit d’une maquette.
  • Host pool type : Pooled (mutualisé s’oppose à personal).
  • Laod balancing algotithm (voir note en dessous) : Depth-first.
  • Max session limit (voir note en dessous) : 2 (valeur arbitraire pour la maquette).

Concernant le “Load balancing algorithm”, il s’agit de la méthode employé par WVD pour répartir les utilisateurs entre les différents hosts d’un pool. Il existe deux méthodes :

  • Depth-first : envoie toutes les demandes de connexions sur le même host jusqu’à ce que celui-ci atteigne la limite fixée par “Max session limit” puis dirige les nouvelles connexions sur le second host du pool et ainsi de suite.
  • Breadth-first : les demandes de connexions sont réparties entre tous les hosts du pool.

Plus d’information dans le KB :

 Concernant le “Max session limit”, il s’agit du nombre de session qu’un host peut accueillir simultanément.

Pour le dimensionnement des machines et le calcule du nombre de session par host, vous pouvez vous référencer au KB :

Basic

Dans le blade “Virtual Machines”, nous avons la possibilité de créer les hosts qui vont composer notre pool.

Renseigner les informations concernant le ressource group, le hardware des machines …

Quelques champs qui méritent une attention particulière :

  • Image type : Gallery (pour le moment, nous n’avons pas d’image personnalisé).
  • Image : l’image correspond à la version de Windows déployée pour le moment, nous n’avons pas d’image personnalisé, nous utilisons donc une image Windows 10 provenant de la market place. Dans le future nous pourrons sélectionner une image perso.
  • Specify domain or unit : yes
  • Domain to join : permet de spécifier le nom du domaine AD dans lequel les machines seront jointe.
  • Organization unit path : permet de spécifier l’OU où seront enregistrées les machines.
  • AD domain join UPN : le compte AD qui a une délégation pour joindre les machines dans le domaine.
WVD-PoolPooled-0030
Virtual Machines

Nous allons rattacher ce nouveau pool à un workspace. Vu que nous somme sur la création de notre premier environnement, aucun workspace n’est présent, nous allons donc en créer un nouveau. Ce workspace permet de présenter les bureaux et applications de manière ordonné.

WVD-PoolPooled-0040
Workspace

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

WVD-PoolPooled-0050
Review

Après quelques minutes, l’environnement ainsi que les machines sont prêts à être utilisés.

Ce qui a été créé

La création de l’host pool de type polled a créer plusieurs objets, nous allons faire le tour de ceux-ci.

Pour commencer dans la section “Host pools”, nous pouvons voir notre pool “WestEu-Polled01” avec quelques informations intéressantes dont :

  • Location : où les medatada du pool sont stockées.
  • Host pool type : pooled ou personal.
  • Load balancer type : manière dont les sessions vont être réparties entre les machines.
  • Application groups : le nombre de groupe d’application qui sont rattachés à ce host pool.

En cliquant sur notre host pool, nous pouvons voir la configuration de celui-ci.

Dans la vue d’ensemble nous retrouvons toutes les informations sur le pool, le nombre de machines qui le compose et les caractéristiques hardware de ces machines.

C’est depuis cette console qui vous pourrais configurer /déléguer la gestion des machines du pool depuis la section “Access control (IAM)” ou encore configurer les propriété du protocole RDS afin de customiser les redirection de périphériques par exemple (généralement le premier niveau de hardening RDS).

Nous allons nous attarder sur section “Session hosts” car rappelons le un host pool est un regroupement d’host avant tout.

Nous pouvons donc voir la liste de nos machines qui vont accueillir les sessions utilisateur, le nombre de session active sur chacun d’eux, leur statut … C’est depuis cette console que vous pourrais aussi passer une machine en maintenance mode à l’aide du bouton “Turn drain mode on ou off” et bien sûr ajouter ou retirer des machines du pool.

Nous avons fait un tour rapide, même très rapide de notre pool. Nous aurons l’occasion de revenir sur cette console plus tard.

Maintenant la seconde partie de la console WVD les “Application groups”. Pour rappel, les application groups sont des objets faisant références à une application ou un bureau hosté sur un host pool. Ce sont ces objets qui seront mis à disposition des utilisateur au travers d’un espace de travail.

Nous pouvons voir que la création du notre host pool à créer par défaut un premier “Application group” celui-ci est créer automatiquement et permet de publier une application de type bureau.

Nous retrouvons donc quelques informations telque le type d’application “Desktop” publié au travers de ce group, l’host pool sur lequel il va récupérer les ressources et le workspace par lequel il sera présenté à nos utilisateurs.

En cliquant sur l’application group, nous pouvons accéder à la configuration de celui-ci. C’est à partir de cette console que nous allons pouvoir publier des applications /bureaux et surtout donner accès à ces ressources à nos utilisateurs.

Se rendre dans la section “Applications”, c’est dans cette section que nous pouvons obtenir la liste des application mis à disposition des utilisateurs. Dans ce type d’application group seul les bureaux sont présentés. Nous allons pouvoir donner un nom convivial à ce bureau avant de d’autoriser l’accès à celui-ci.

Cliquer sur l’objet “SessionDesktop” (qui correspond à la publication du bureau). Vous aurais la possibilité de donner un nom d’affichage au bureau plus parlant que “SessionDesktop”.

Depuis la section “Assignment”, vous pouvez donner l’accès à cette ressource à vos utilisateurs.

Ce point est traité plus bas dans ce post : Autoriser l’accès à une ressources à des utilisateurs.

Dès lors que l’accès est utilisé, vous pouvez accéder à ce bureau à l’aide du client Remote Desktop. Le client est traite plus bas dans ce post : Le client WVD pour accéder à nos ressources.

Comme vous pouvez le constater, il est possible d’accéder au bureau partagé.

Nous pouvons constaté, comme indiqué dans les nouveautés sur WVD du mois de mars 2021, le client FSLogix est déjà installé dans les images de type Windows 10 multi-session.

cf : Azure – Windows Virtual Desktop Nouveautés Mars 2021

WVD-PoolPooled-0180

Et un dernier petit composant qui a été créé, le Workspace.

Vous pouvez retrouver les information sur celui-ci dans la section “Workspace”. Nous reviendrons plus tard sur ce composant. Ca principale utilité est de présenter /grouper les applications /bureaux aux utilisateurs. 

Publication RemoteApps

La publication RemoteApps se situe au niveau Application Groups. Il s’agit d’un type d’application groups particulier qui a pour objectif de donner l’accès non pas à un bureau, mais à une application particulière en mode fenêtré.

Les RemoteApps se basent généralement sur des pool de type polled bien que rien n’empêche de se baser sur du dédié, mais l’usage est limité.

Plutôt que de présenter un bureau complet, le but est d’exécuter une .exe dans une session distante et de présenter uniquement l’application via le protocole RDP.

Pour créer ce type de publication se rendre dans la section “Application groups” et ajouter “Add” un nouveau groupe.

Dans le blade “Basic”, sélectionner :

Host pool : sélectionner le host pool contenant le machine en mode polled.

Application group name : nommer le group.

Note, il existe déjà un application group de type bureau (défaut) sur le pool, nous ne pouvons donc pas sélectionner ce type.

Dans le blade “Applications”, cliquer sur “Add applications” et renseigner les informations sur l’application à publier.

Application source :

  • Menu démarré, il s’agit d’un application qui a déposé un raccourcis dans le menu démarré. Les informations renseignées dans le raccourcis seront utilisées pour lancer l’application. Il s’agit de la méthodes à préférer.
  • File path : si une application n’est pas présente dans le menu démarré, il est possible de spécifier le chemin d’accès afin de lancer le fichier .exe correspondant à l’application.
  • MSIX package : permet de lancer une fichier MSIX.

Dans le blade “Assignments”, vous pouvez sélectionner les utilisateurs /groups autorisés à accéder aux applications publiées dans ce groups.

Dans le blade “Workspace”, vous pouvez créer un nouveau workspace ou utiliser un workspace déjà présent.

Cliquer sur “Create” pour lancer la création du nouvel application group contenant nos publication RemoteApps.

Après quelques secondes, l’application groups est créé. Vous pouvez la manager depuis la console WVD. notamment ajouter /supprimer des application ou modifier l’affection des utilisateurs.

Du couté client, les applications publiées en RemoteApps sont accessibles.

Voilà, nous avons publié nos premières applications en RemoteApps.

Les RemoteApps ne sont pas compatibles avec tous les client Remote Desktop.

Création pool de type Personal

Nous allons continuer et créer un pool de type “Personal” Il s’agira d’un pool de machine dédiés à un utilisateur précis.

Pour ce faire se rendre dans l’interface d’administration WVD et cliquer sur “Create a host pool”.

Dans le blade “Basic”, renseigner les informations demandées :

  • Subscription : votre abonnement Azure.
  • Ressource group : le ressource group correspondant à votre environnement WVD.
  • Host pool name : le nom de votre host pool.
  • Location : emplacement Azure où seront enregistrés les metadatas du pool. Ici nous parlons de metadatas (information sur la configuration du pool) et non de données utilisateur.
  • Validation environment : no, il s’agit d’une maquette.
  • Host pool type : Personal (machine dédié à un utilisateur).
  • Assignment type : Direct (soit direct ou une affectation manuel de la machine doit être réalisée en opposition à Automatic).

Dans le blade “Virtual Machines”, nous avons la possibilité de créer les hosts qui vont composer notre pool.

Les informations demandées sont les même que pour le pool Polled. Vous pouvez vous référer aux informations expliquées plus haut.

Nous allons utiliser le Workspace que nous avons créé précédemment. 

Un petit résumé de ce que nous allons déployer.

Après quelques minutes d’attentes, le nouvel host pool est créé et les machines provisionnées.

Maintenant, il faut que nous affections les machines à nos utilisateurs. Pour rappel, nous avons configuré l’affectation sous le type “Direct” et non “Automatic”.

Pour ce faire, assigner les utilisateurs sur l’application group correspondant au pool. voir : Autoriser l’accès à une ressources à des utilisateurs.

Puis se rendre dans la partie “Session hosts” du pool, sur la machine que vous souhaitez assigner, cliquer sur le bouton “Assign” et sélectionner l’utilisateur à assigner.

L’opération n’est pas réversible.

WVD-PoolPooled-0250

Coté client, le bureau est publié.

Autoriser l'accès à une ressources à des utilisateurs

L’accès à une ressource se fait depuis le blade “Application groups”. En effet, on ne donne pas l’accès aux utilisateurs à une machine ou une autre, mais bien à une application publiée que ce soit un bureau ou une RemoteApp. Donc dans “Application groups”.

Se rendre sur l’application group contenant les ressources concernées, dans la section “Assignment” cliquer sur “Add”.

Dans la liste des utilisateurs sélectionner les utilisateurs /groupes auquel vous souhaitez octroyer l’accès à ces ressources.

Le client WVD pour accéder à nos ressources

L'accès conditionnel pour plus de sécurité

Point de situation

Dans cette partie, nous avons vu les grandes briques sui composent le service Windows Virtual Desktop. Nous sommes loin d’avoir fait le tour de la technologie certes, mais sous avons abordé les différents types de pools de machines et comment mettre à disposition ces ressources à nos utilisateurs. Il est important de comprendre les 3 niveaux qui composent ce service et leurs portée avant de continuer.

En effet pour la suite, nous allons voir comment gérer les profils utilisateurs à l’aide de FSLogix ou encore comment créer une “Golden image” ce qui ne représente pas une mince affaire. Mais bien assimiler les 3 types d’objets qui vont représenter la majeur partie du travail lors de l’administration quotidienne du service. A savoir :

  • Host pool : regroupement de machines hébergeant les sessions utilisateur. ==> La ressource /le calcul.
  • Application groups : regroupement logique d’applications /bureaux provenant d’un même host pool où seront géré les droit d’accès des utilisateurs. ==> Mes applications /ACL.
  • Workspace : regroupement logique d’application groups permettant la mise en forme de l’environnement de travail des utilisateurs. ==> Le rendu utilisateur.