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.
sommaire
Presentation de l’environnement Windows Virtual Desktop (WVD)
Tout commence à partir de la console Azure, se rendre dans tous les services et rechercher “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 regroupements 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 ou un bureau, ce regroupement assure la montée en charge ainsi que la disponibilité des apps /bureaux.
Il existe deux types 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. Permets de présenter soit des bureaux, soit 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ées depuis les machines d’un host pool. Lors de la création d’un host pool, un “application group” est créé par défaut, celui-ci publie un bureau.
Workspaces
Les workspaces sont des regroupements logiques d’applications pools. Le workspace est présenté à l’utilisateur et permet d’ordonner les bureaux ou applications qui lui sont présentés.
Users
Le section “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 types de pools, à savoir “Personal” ou “Pooled”.
Pooled pool
Les pools de type pooled sont des ensembles de machines mutualisées entre plusieurs utilisateurs. 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 versions 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 une interface utilisateur Windows 10. Ce qui dans le cas de publication de bureau est moins déroutant pour les utilisateurs et permet de lever certaines limitations côté application lorsque celle-ci vérifie la version d’OS avant de s’installer.
Personal pool
Les pools de type personal sont des ensembles 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é de l’utilisateur. Ceux-ci impliquent que chaque machine au sein du pool peut être différente que ce soit sur le hardware ou sur les applicatifs installés. Les machines de ce type de pool peuvent avoir une cible de vite très proche de celui d’un poste physique. Ils peuvent être enrôlés dans Microsoft Endpoint Management.
Chaque utilisateur 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 doit 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 tous les cas, l’utilisateur possède sa propre machine et sera connecté à celle-ci.
Création des premiers environnements Windows Virtual Desktop (WVD)
Il serait trop long de tester chaque cas de figure pour la création de pools, nous allons voir dans cette partie la création des deux types de pools (polled et personal) basés sur Windows 10. Bien entendu, il existe une multitude de combinaison entre pool, OS et méthode d’assignation qui je vous invite à tester de votre côté.
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ée 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 sessions 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 :
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 futur nous pourrons sélectionner une image perso.
- Specify domain or unit : yes
- Domain to join : permets de spécifier le nom du domaine AD dans lequel les machines seront jointes.
- Organization unit path : permets 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.
Nous allons rattacher ce nouveau pool à un workspace. Vu que nous sommes 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és.
Les informations pour la création du nouveau pool sont complètes.
Nous pouvons lancer la création en cliquant sur “Create”.
Après quelques minutes, l’environnement ainsi que les machines sont prêtes à être utilisées.
Ce qui a été créé
La création de l’host pool de type pooled 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 medatadas 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 à cet host pool.
En cliquant sur le “host pool” (WestEu-Polled01), 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 ainsi que leurs caractéristiques hardware.
C’est depuis cette console qui vous pourrait configurer /déléguer la gestion des machines du pool depuis la section “Access control (IAM)” ou encore configurer les propriétés du protocole RDS afin de customiser les redirections 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’hosts 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 pourrez 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 applications groups sont des objets faisant référence à une application ou un bureau hébergé sur un host pool. Ce sont ces objets qui seront mis à disposition des utilisateurs 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éé automatiquement et permet de publier une application de type bureau.
Nous retrouvons donc quelques informations tels que 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 un “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 applications mise à disposition des utilisateurs. Dans ce type d’application group uniquement les bureaux sont présentés. Nous allons pouvoir donner un nom convivial à ce bureau avant d’autoriser l’accès à celui-ci.
Cliquer sur l’objet “SessionDesktop” (qui correspond à la publication du bureau). Vous avez la possibilité de donner un nom d’affichage au bureau plus user friendly 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 à aux ressources pour les 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 traité 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.
Et le dernier composant qui a été créé, le Workspace. La 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 pooled 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 application (.exe) dans une session distante et d’afficher 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.
Coté client, le bureau est publié.
Autoriser l'accès à aux ressources pour les 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
Le client Remote Desktop WVD est documenté dans le post :
L'accès conditionnel pour plus de sécurité
L’accès conditionnel est traité dans le post ci-dessous :
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.
