Windows Server 2019 : présentation et installation du rôle RDS

Comment fonctionne le service de bureaux à distance de chez Microsoft ? Comment le mettre en place de manière classique ?

Historiquement nommé TSE pour Terminal Services, le service RDS (Remote Desktop Services) permet comme son nom l’indique de créer des « bureaux » à distances, mais pas que !

En effet, grâce au rôle RDS nous allons pouvoir non seulement créer des sessions distantes sur lesquels les utilisateurs pourront se connecter (idéal depuis des clients légers par exemple, pour réduire les coûts matériel) mais nous allons aussi pouvoir créer de véritables ordinateurs virtuels ou encore créer des remote-app, permettant d’utiliser des logiciels hébergés sur notre serveur RDS mais sans devoir se connecter à une session.

Bien entendu, il est possible de créer des « fermes » de serveurs RDS pour faire face à de nombreux utilisateurs ou à diverses montées en charge, mais dans un premier temps nous allons nous contenter de l’installation d’un seul serveur, histoire de bien appréhender le fonctionnement.

I) Comment ça fonctionne au juste ?

Prenons ce schéma tiré du site openhost-network.com :

Pour faire simple :

• Le rôle RD Web Access permet tout simplement d’accéder aux bureaux distants / applications RemoteApp via une inteface web HTML5 sécurisée ;
• Le rôle RD Gateway permet de relayer les demandes de connexion aux services RDS depuis Internet vers notre ferme de serveur (ou notre unique serveur) RDS, et ce sans avoir à recours à un VPN ;
• Le rôle RD Connection Broker qui joue le rôle de « master », dans le sens où c’est lui qui va gérer les connexions utilisateur pour réaliser de la répartition de charge, mais aussi veiller à ce que si un utilisateur se déconnecte du serveur 04 par exemple, lors de sa reconnexion, il soit redirigé vers le serveur 04 pour ne pas perdre le travail en cours sur sa session distante ;
• Le rôle RD Session Host, qui est simplement le serveur où se trouvent les appliactions installés, et sur lequel les utilisateurs e connecteront (pour lancer ces fameuses appliactions, stocker leurs fichiers, etc). Soit on peut utiliser ce rôle pour créer des bureaux distants, soit pour déployer des Remote App, ou encore pour déployer de véritables machines virtuelles pour les utilisateurs ;

II) Mise en place du lab

Bien, j’ai donc créé deux vm Windows Server 2016, une AD-01 en 192.168.1.60/24, et une RDS-01 en 192.168.1.70/24. Sur cet AD j’ai déjà créé un utilisateur test, et mon RDS est bien relié à l’Active Directory. On peut donc commencer l’installation de notre fameux rôle !

On se rend donc sur notre serveur RDS en nous connectant avec le compte administrateur du domaine, puis comme type de rôle nous choisissons Installation des services Bureau à distance :

On va choisir le type de déploiement Démarrage rapide, car ici nous n’aurons qu’un seul serveur, regroupant les différent « sous-rôles » du RDS :

On choisi ensuite le scénario de déploiement, et étant donné les ressources limitées pour notre lab, nous allons choisir celui basé sur les sessions. D’ailleurs en entreprise, c’est ce scénario que l’on retrouvera en général :

On choisi ensuite le serveur sur lequel ce rôle va être déployé :

Et hop, en cochant la case permettant de redémarrer le serveur cible l’installation se lance :

Une fois le service correctement installé, il convient d’installer le gestionanire de licences RDS, car chaque utilisateur et appareil se connectant à un hôte RDS a besoin d’une licence d’accès client (CAL). Je ne vais pas trop m’étendre ici sur le type de licence et leur fonctionnement, la documentation officielle est assez bien fichue pour le coup : https://docs.microsoft.com/fr-fr/windows-server/remote/remote-desktop-services/rds-client-access-license

On se rend donc sur le Gestionnaire de serveur, puis Services Bureau à distance et cliquez sur le « (+) » du Gestionnaire de licence :

On choisi ensuite le serveur cible, comme toujours, puis l’installation débute :

Une fois fait vous obtiendrez un rapide avertissement vous disant que le service n’est pas configuré, c’est normal. On se rend sur Collections dans le Gestionnaire de serveur et en cliquant sur tâches on choisit Modifier les paramètres de déploiement :

Cliquer sur Gestionnaire de licences sur la droite du menu puis séléctionner le type souhaité, dans notre cas ce sera par utilisateur étant donné notre lab :

On notera d’ailleurs que via le déploiement rapide, Windows nous a créé une collection par défaut nommée QuickSessionConnect, comprenant d’ailleurs 3 logiciels en RemoteApp :

On va donc continuer avec cette collection créée par défaut et en cliquant donc dessus puis en nous rendant sur Tâches sur la droite nous allons pouvoir la paramétrer et même la renommer :

En cliquant sur Groupes d’utilisateurs on peut même supprimer le groupe par défaut Utilisateurs du domaine et créer un groupe dédié, qui pourra accueillir certaines GPO ou autre. concernant l’option Session ici aussi nous allons pouvoir modifier des tonnes de choses, comme la limite de session active, mettre fin à une session déconnectée, etc, libre à vous de fouiner un peu de ce côté là.

Un autre paramètre intéressant si nous avions plusieurs serveur est celui des Disques de profil, en effet si activé les données du profil utilisateur sont stockés sous forme de de disque dur virtuel (VHDX), et dans le cadre de multiples serveurs ce disque sera toujours rattaché à la session (contrairement aux profils itinérants, car ici le disque ne sera pas copié sur le client, il reste sur le serveur).

Bref, assez parlé ! On va quand même tester un peu tout ça !

III) Connexion à une session distante

On démarre un client Windows 7 Pro classique, relié au domaine, on démarre l’utilitaire bureau à distance et on rentre le FQDN de notre RDS et le nom/mot de passe de notre utilisateur créé dans notre AD et là, tadaaaa :

Notre session est belle et bien créée ! C’est donc une session tout à fait classique. On peut d’ailleurs sauvegarder en raccourci cette connexion, en sauvegardant les credentials histoire d’obtenir quelque chose d’encore plus « user-friendly » :

Concernant les RemoteApp, nous pouvons nous rendre sur l’url
http://rds-01.notamax.local/RDWeb, nous logguer avec notre compte utilisateur du domaine, et nous pourrons exécuter nos applications ! Bon ici rien d’incroyable, ce sont les apps de la collection par défaut :

A noter qu’en utilisant un navigateur autre qu’Internet Explorer (Chrome en l’occurence, je n’ai pas testé avec d’autres) le fait de cliquer sur l’icône de l’application va la télécharger sous forme de fichier .rdp ! Pratique quand même ?

Et bien voilà voilà, cet article est à présent terminé, nous aurons appris ce qu’est ce fameux rôle RDS, son fonctionnement, et son installation !

Je devais faire cet article depuis un sacré moment, et j’ai enfin trouvé le temps de le faire. Je ferai sûrement d’autres articles sur l’installation d’une ferme complète, avec séparation des rôles, mais ce ne sera pas pour tout de suite 😉

Bonne journée/soirée à vous !