Introduction
Lorsqu’il s’agit de faire de la VDI ou du SBC (Server-Base Computing), vous avez globalement 2 choix qui s’affrontent sur le marché. Vous pouvez utiliser les solutions Microsoft avec le rôle que l’on appelle RDS ou Remote Desktop Services (anciennement Terminal Services [TSE]) ou bien les solutions Citrix (XenApp, XenDesktop).
J’ai d’ailleurs déjà abordé la mise en place d’une infrastructure RDS ou Citrix au sein de votre environnement. Aujourd’hui, c’est devenu quelque chose d’assez simple à mettre en oeuvre. Je vous invite à consulter les articles suivants si besoin :
- Installation de Remote Desktop Services (RDS) sur Windows Server 2019 et publication d’une RemoteApp
- Installation de Remote Desktop Services (RDS) sur Windows Server 2012 R2 et publication d’une RemoteApp
- Installation de XenApp / XenDesktop 7.12 (article un peu vieux et probablement plus trop d’actualité).
Le point commun de ces articles c’est qu’il fallait avoir des serveurs dans un datacenter et qu’on déployait ensuite une infrastructure RDS ou Citrix sur ces serveurs. Mais le Cloud a changé les choses dans ce domaine également. 🙂
Aujourd’hui, nous allons aborder un service qui est disponible dans Azure depuis fin 2019, il s’agit de Windows Virtual Desktop ou WVD.
Pré-requis
Windows Virtual Desktop c’est donc la possibilité de créer votre infrastructure RDS en mode « as a service« . Vous n’aurez donc pas à vous occuper de l’installation et de la configuration de la ferme RDS puisque cette partie sera réalisé directement par Microsoft dans le cloud d’Azure.
Si vous n’avez jamais utiliser Azure, la mise en place n’est pas simple. Pour pouvoir tester Windows Virtual Desktop, même dans le cas d’un POC, vous devez respecter les prérequis suivants :
- Vous devez disposer d’un Active Directory « on-prem« . Il peut s’agir d’un AD DS qui fonctionne au sein de votre datacenter ou dans n’importe quel fournisseur cloud.
- Un Domain Controller doit être présent au sein de la souscription Azure où vous allez créer votre environnement WVD. Cela implique donc dans la majorité des cas la présence d’une VPN S2S ou d’un ExpressRoute pour inter-connecter votre environnement on-prem et le reste de votre infrastructure dans le Cloud.
- Vous devez disposer d’un AAD Connect qui soit configuré pour synchroniser vos comptes d’utilisateurs depuis votre AD DS vers Azure Active Directory (AAD).
- Enfin, vous devez autoriser Windows Virtual Desktop à se connecter à votre Azure Active Directory. Si vous ne voyez pas de quoi je parle, je vous invite à consulter le lien suivant sur le site de Microsoft – spécifiquement la partie « Allow the Windows Virtual Desktop service to access to Azure AD« .
Si vous êtes prêt, nous allons donc pouvoir passer à la construction de notre environnement. Comme il s’agit d’un POC, j’ai tout créé directement dans Azure y compris mon domaine AD DS.
Création d’un AD DS (directement dans Azure)
Si vous disposez déjà de tous les prérequis évoqués précédemment, vous pouvez passer cette étape !
Dans un premier temps, je commence par créer un nouveau domaine Active Directory (AD DS) directement dans Azure. Pour ce faire, je provisionne simplement une machine virtuelle Windows Server que j’intègre dans un nouveau VNet. Il s’agira du Domain Controller principal de mon nouvel Active Directory.
Je choisi tous les éléments pour la création ma première VM : resource group, nom de la VM, type, localisation (attention à bien rester aux US car au moment ou je rédige cet article WVD n’est disponible que sur certaines zones) et bien sûr l’identifiant et le mot de passe local de cette VM.
Au moment de la création de cette première VM, je vais également créer mon virtual network. Je reste sur la configuration standard de : 10.0.1.0/24. En revanche, je vais ouvrir le port 3389 afin de pouvoir me connecter à ma VM par la suite en RDP. Bien évidemment, cette configuration n’est pas recommandée pour de la Production puisque j’ouvre le port sur Internet sans restriction (mais une fois que vous aurez compris le principe vous pourrez optimiser). 😉
Je laisse toutes les autres options avec les valeurs par défaut. A vous de voir si vous voulez personnaliser le réseau, le disque dur, ou d’autres éléments de la VM (comme d’habitude s’il n’y pas de screenshot c’est que j’ai gardé les options par défaut).
Une fois que celle-ci est générée, connectez-vous en RDP et démarrez la configuration pour créer votre domaine AD et promouvoir ce serveur en Domain Controller.
Dans mon cas, le domaine s’appellera test.local mais je vous laisse adapter la configuration. Mon compte de domaine sera donc test\thibault.
Une fois que c’est fait, il nous reste à terminer la configuration de notre VNet. Notre DC portera le rôle DNS et on doit donc l’indiquer à Azure afin qu’au sein de ce VNet nous puissions résoudre tout ce qui concerne notre domaine test.local. Ce réglage est important pour la suite, veillez à ne pas l’oublier !
Pour ce faire, il nous suffit de définir l’adresse IP de notre DC comme serveur DNS au sein de notre Virtual Network (dans la section DNS Servers).
C’est tout ce dont nous avions besoin en prérequis Active Directory.
Création de notre infra Windows Virtual Desktop
On va donc maintenant pouvoir créer notre environnement Windows Virtual Desktop. Depuis le portail Azure, cherchez la ressource qui s’appelle « Windows Virtual Desktop » dans le champ de recherche tout en haut de la page. C ‘est le service Azure que nous allons utiliser pour créer notre infrastructure RDS gérée par Microsoft.
Cliquez sur Create a host pool.
Choisissez la même souscription que précédemment. Dans mon cas, je vais également utiliser le même resource group car je souhaite que toutes les VM qui vont être générées soient dans le même Virtual Network que j’ai déjà créé précédemment.
J’ai choisi une infrastructure de type Pooled. Contrairement au type Personal, cela signifie que les utilisateurs ne se verront pas assignés spécifiquement un serveur plus qu’un autre mais qu’ils seront répartis simplement en fonction de la charge pour optimiser l’utilisation de l’ensemble des serveurs. Je limite également chaque serveur à 5 sessions concurrentes (simplement pour tester vous pouvez modifier cela ultérieurement).
Pour les autres options, vous pouvez conserver les réglages par défaut.
A l’étape suivante, vous allez définir le type de VM que vous souhaitez utiliser accueillir vos sessions utilisateurs. Dans mon cas, j’ai opté pour une D2S v3 – à vous de voir et tester ce qui est le mieux pour vos utilisateurs. Là encore, c’est quelque-chose que vous pourrez toujours faire évoluer. J’ai choisi de créer 3 VMs avec le préfixe « VDI« .
Les 3 VMs seront créées avec une image standard de Windows Server 2019. Mais vous pourriez utiliser un OS Desktop ou même votre propre master (à réaliser préalablement).
Concernant les performances, j’ai opté pour du Premium SSD mais dans mon cas c’est un POC et je ne paye pas… Donc typiquement, il est possible que vous alliez vers un autre choix de votre côté. Dans tous les cas, je vous recommande d’utiliser les Managed Disks qui vont de toute façon devenir incontournable de plus en plus.
Toujours dans la configuration des VM qui vont être générées automatiquement, vous allez pouvoir définir dans quel virtual network Azure doit intégrer ces VM. Je récupère le Virtual Network que j’ai déjà créé précédemment et dans lequel j’ai également mon DC.
J’indique cette fois-ci le nom de mon domaine Active Directory et éventuellement le chemin vers un OU spécifique si je souhaite que mes serveurs soient créés dans un OU particulière.
Enfin, je précise le compte d’un Domain Admin ou un compte ayant suffisamment de privilèges pour procéder à l’intégration de ces machines dans votre AD DS. Dans mon cas, j’ai utilisé le même compte que précédemment.
Vous pouvez ensuite valider et lancer la création de votre infrastructure Windows Virtual Desktops ! 🙂
Ne soyez pas impatient. Le processus de création peut être assez long ! Vous pouvez attendre sur cette page ou bien revenir d’ici un moment. J’avoue que je ne me souviens plus combien de temps cela a duré… 20 mins max probablement.
Si tout s’est bien passé, vous devriez voir la fenêtre ci-dessous avec plein de nouvelles ressources qui auront alors été générées au sein de votre Resource Group. Signe que tout s’est bien passé ! 🙂
Si vous vérifiez sur votre DC, les nouvelles machines ont également été créées et sont visibles dans le container par défaut : Computers.
Votre infrastructure est prête. 🙂
Paramétrage avancé
L’objet le plus important et que nous allons utiliser est le PooledDesktop. Il va nous permettre de modifier le comportement et certains paramètres de notre infra RDS.
Pour accéder à ces réglages, cliquez sur l’objet PooledDesktop dans le Resource Group.
Une fois dans votre objet PooledDesktop, vous aurez alors accès à des réglages supplémentaires (qui vont encore s’étoffer dans le futur) : mécanique de re-connection, compression, gestion du flux vidéo, etc.
Je vous laisse parcourir tous les onglets et notamment également les fonctionnalités de Device Redirection qui vous permettront de contrôler ce que vous souhaitez faire remonter depuis le poste utilisateur vers votre infrastructure RDS.
Vous pouvez également retrouver la liste de vos serveurs ayant été générés et disponibles au sein de votre infrastructure RDS dans la partie Session Hosts.
Le bouton Add en haut de la fenêtre vous permettra d’étendre au besoin votre infrastructure en augmentant rapidement et facilement le nombre de serveurs RDS.
Assignation
Nous allons maintenant pouvoir assigner un compte utilisateur à notre infrastructure afin de lui permettre de se connecter. N’oubliez pas tous les prérequis que j’ai indiqué plus haut : présence d’un AAD Connect, d’une synchro d’identité, les comptes doivent être présents dans votre AD on-prem mais aussi sur Azure AD, etc.) – sinon arrivé à cette étape vous allez être bloqué.
Toujours dans notre objet PooledDesktop, vous allez pouvoir cliquez sur Application groups, puis sur l’objet PooleDesktop-DAG (vous pouvez aussi retrouver cet objet directement dans votre Resource Group). Dans la section Assignments, vous allez pouvoir affecter les comptes Azure Active Directory des collaborateurs à qui vous souhaitez permettre l’accès à votre infrastructure Windows Virtual Desktop.
Test de connection
Et finalement, si vous avez tout bien respecté, vous allez pouvoir accéder à votre environnement. S’agissant d’une infrastructure « as a service », toutes les composantes générales de l’infrastructure RDS – à savoir la RD Web ou la Gateway sont opérées par Microsoft. Nous n’avons donc rien de plus à déployer. 🙂
Pour accéder à votre environnement, il vous suffit d’accéder à l’URL suivante (plus d’informations sur le lien suivant) :
Si vous êtes déjà authentifié vous bénéficierez du SSO de votre tenant. Dans le cas contraire, identifiez-vous normalement pour accéder à vos ressources.
Après quelques secondes vous verrez les ressources auxquelles vous pouvez accéder (dans mon cas un environnement bureautique complet).
Pour vous connecter, cliquez simplement sur l’icône. 🙂
L’ensemble de votre bureau va se charger directement au sein de votre navigateur web. Je ne l’avais pas mentionné avant mais bien évidemment, vous devez utiliser un navigateur récent compatible HTML 5. Je vous recommande donc Google Chrome ou Edge Chromium.
Dans un prochain article, nous verrons comment personnaliser notre environnement de travail. 🙂
Pour aller plus loin
Je vous invite également à consulter les liens suivants si vous souhaitez aller plus loin concernant l’utilisation de Windows Virtual Desktops :
- What is Windows Virtual Desktop?
- Getting started with Windows Virtual Desktop
- Connect to Windows Virtual Desktop with the web client
- Prepare and customize a master VHD image
N’hésitez pas à utiliser la zone commentaires pour toute question ! 🙂
