Installation de Remote Desktop Services (RDS) sur Windows Server 2019 et publication d’une RemoteApp

Je vous propose aujourd’hui de voir comment déployer une infrastructure Remote Desktop Services sous Windows Server 2019 (anciennement TSE – Terminal Services).

Vous allez vous rendre compte que si le processus avait changé en passant de 2008 R2 à 2012 R2. Il n’a pas vraiment évolué depuis ! 🙂

Introduction

Avant de débuter les manipulations, quelques rappels sur les possibilités offertes par une ferme RDS :

• Scénario 1 : Remote Desktop Services vous permet de créer ds bureaux partagés (Shared Desktops) ou bien de publier des applications (RemoteApp) ;
• Scénario 2 : Il est également possible de faire de la VDI (Virtual Desktop Infrastructure). Dans ce second cas, l’utilisateur final dispose de sa propre VM/serveur (contrairement au premier cas où on parle d’environnement partagé).

L’implémentation de ces 2 usages diffère. Dans le contexte de cet article, je vais m’intéresser uniquement au scénario N°1 – à savoir le déploiement d’une infrastructure RDS qui permette de créer des bureaux partagés et/ou de publier des applications.

Avant d’aller plus loin, revoyons également un peu quels sont les différents rôles qui peuvent composer une infrastructure Remote Desktop Services :

• RD – Connection Broker : c’est un composant important puisqu’il s’agit un peu du « chef d’orchestre« . C’est lui qui gère les serveurs sur lesquels les utilisateurs vont se connecter et de quelle façon ils seront répartis suivant la charge entre les différents serveurs.
• RD – Web Access : c’est le composant qui propose l’interface web que l’on verra plus tard et qui permet de mettre à disposition les ressources aux utilisateurs. Les utilisateurs cliquent sur les icônes et cela démarre la connexion. Cette interface web repose sur le serveur web de Microsoft – à savoir IIS.
• RD – Session Host Server : en général vous disposez de plusieurs serveurs qui jouent ce rôle. Ce sont les serveurs sur lesquels les utilisateurs vont se connecter pour accéder à leurs applications et/ou bureaux partagés.
• RD – Gateway : ce composant vous permet d’encapsuler et sécuriser le flux de connexion des utilisateurs dans le cas où la plateforme devrait être accédée depuis l’extérieur (via Internet).
• RD – Desktop Virtualization Host : c’est le rôle qui s’interconnecte à un hyperviseur pour générer les serveurs nécessaires à chaque utilisateur. Ce composant est spécifique au scénario N°2. Nous ne l’utiliserons donc pas dans le contexte de cet article.
• RD – Licensing : évidemment rien n’est gratuit… Donc pour pouvoir utiliser une plateforme RDS, vous devez vous acquitter de licences CAL RDS auprès de Microsoft. Il en existe de 2 sortes : par utilisateur ou par équipement (device).

Maintenant que vous connaissez tous les composants, je vous propose de démarrer. Si vous envisagez de suivre ce tuto pour créer un environnement de votre côté, notez bien que je considère que vous disposez déjà d’un domaine Active Directory.

Mon infrastructure RDS sera composée de 3 machines virtuelle distinctes :

• RDS001 – 10.0.0.9
  • RD Broker + RD Licensing
• RDS002 – 10.0.0.10
  • RD Web Interface
• RDS003 – 10.0.0.11
  • RD Session Host Server

Pour la première VM, j’ai donc choisi de mutualiser les 2 rôles suivants : RD Broker + RD Licensing. Ces 2 serveurs n’accueillent pas directement d’utilisateurs mais gèrent l’infrastructure. La charge sera donc moins élevée.

Là-encore, je vais supposer que ces 3 machines sont correctement intégrées à votre domaine Active Directory – qui encore une fois est un pré-requis à notre déploiement.

Etape 1 – Création d’un Server Pool (groupe)

Connectez-vous depuis le premier serveur et créez un server group avec vos 3 serveurs. Depuis le Server Manager, Manage, sélectionnez Create Server Group.

Dans mon cas, j’ai choisi d’appeler mon groupe : My RDS Infrastructure.

Etape 2 – Installation de nos différents rôles Remote Desktop Services

Si ce n’était pas déjà le cas, connectez-vous en RDP sur le premier serveur – dans mon cas RDS001. Démarrez le Server Manager s’il n’apparaît pas tout seul. Tout en haut à droite cliquez sur Manage puis choisissez Add Roles and Features.

NB : Comme toujours : n’oubliez pas si je dis rien ou qu’une capture d’écran est manquante, considérez que vous gardez les options par défaut.

Cliquez sur Next.

Sélectionnez la seconde option pour procéder à l’installation de Remote Desktop Services.

C’est la seule chose qui a changé entre la version 2008 R2 et la version 2012 R2 (puis a été conservée après pour 2016 ou 2019) : la manière de déployer une infrastructure RDS. Par le passé, vous deviez vous connectez sur chacun de vos serveurs pour y déployer le rôle désiré. Désormais, vous pouvez vous connecter sur 1 des serveurs et déployer tous les rôles sur l’ensemble des serveurs de l’infrastructure RDS depuis la même et unique console ! 😉

Sélectionnez l’option Standard deployment. La seconde option permet dans des cas de POC, de déployer l’ensemble des rôles sur un seul et même serveur.

Comme indiqué précédemment, dans notre cas nous allons faire du Shared Desktops et du RemoteApp (pas de VDI) – nous choisissons donc la seconde option.

Rien à faire ici. C’est simplement un rappel des rôles que nous allons installer au vue des choix précédents. Cliquez sur Next.

Ensuite, pour chacun de nos 3 serveurs, nous allons simplement attribuer le rôle prévu…

D’abord, notre RD Broker. Prenez le serveur de votre groupe qui doit porter ce rôle et déplacez le sur la droite (dans mon cas RDS001).

Renouvelez l’opération pour choisir le serveur qui portera le rôle de RD Web Access (dans mon cas RDS002).

Et finalement, même chose pour notre RD Host Server.

Dans mon cas, je dispose que d’1 seul et unique RD Host Server mais si votre infrastructure doit accueillir de nombreux utilisateurs, vous en installeriez probablement plus d’un… 😉

Rien de particulier ici, c’est simplement la confirmation de ce que nous allons installer. Cochez la casse pour redémarrer automatiquement les serveurs si c’est nécessaire (notamment pour le serveur RD Session Host). Cliquez sur Deploy.

Patientez durant l’installation…

Une fois l’installation terminée avec succès, cliquez sur Close.

Avant d’aller plus loin, je vous invite à découvrir la console Remote Desktop Services. Elle vous rappelle les différents rôles actuellement déployés et ceux qui pourraient être ajoutés.

Comme vous le voyez :

• Le composant RD Licensing ne nous a pas été proposé. Il doit être déployé séparément et manuellement. Une plateforme RDS sans serveur de licences valide pourra fonctionner avec la période de grâce pour une durée de 180 jours.
• Nous pouvons étendre notre infrastructure et ajouter des serveur RD Session Host par un simple clic (en haut à droite).
• La prochaine étape consiste à créer notre Collection de ressources… 🙂

Etape 3 – Déploiement du serveur de Licences Remote Desktop Services

Cliquez sur le gros bouton vert « PLUS » pour installer le composant RD Licensing. Comme indiqué précédemment, j’ai choisi de le mutualiser avec notre Broker et donc sur le serveur RDS001 (dans mon cas).

Même interface et donc même principe que pour les étapes précédentes.

L’installation est terminée. Mais concrètement pour l’instant, notre serveur de licences ne sert à rien. Car vous devez lui ajouter des jetons de licences CAL RDS. Cela étant, je ne vais pas détailler cette partie dans l’article suivant. Si besoin, je vous invite à consulter cet article qui traite du sujet pour Windows Server 2016 mais c’est vraiment identique.

Etape 4 – Publication des ressources (application, Bureau partagé)

Toujours dans le même console. Cliquez sur la partie à gauche sur Collections. C’est ce qui va nous permettre de définir les applications ou bureaux qui doivent être utilisés par nos utilisateurs.

Cliquez sur Next.

Choisissez le nom de votre Collection et une description puis cliquez sur Next. Une infrastructure RDS peut être composée de plusieurs Collections.

Une Collection va offrir des ressources (applications ou bureaux) à vos utilisateurs. Bien qu’appartenant à la même ferme RDS tous les serveurs RD Session Host ne possèdent pas nécessairement les mêmes ressources. C’est pourquoi on précise les serveurs qui seront concernés par cette Collection (dans mon cas je n’en ai qu’un seul).

On défini ensuite la liste des utilisateurs – via un groupe Active Directory qui seront capables de voir et accéder aux ressources.

Ce paramètre est un peu particulier. Pour notre exemple, on ne va pas l’utiliser. Je ne coche donc pas l’option.

Sachez simplement que dans les environnements partagés, la gestion du profil utilisateur peut être un peu complexe. En effet, imaginez que votre utilisateur ait accès à un bureau partagé. Ce bureau partagé peut être hébergé sur 2 serveurs RD Session Host différents – et en fonction de la charge l’utilisateur peut être réparti sur un serveur différent chaque jour. Dans ce cas, il faut être capable de déporter le stockage du profil utilisateur afin que la personnalisation de son environnement ne soit pas perdue lorsqu’il change de serveur.

Simple récapitulatif avant la création de votre Collection, cliquez sur Create.

La création est terminée. Cliquez sur Close. Nous allons maintenant pouvoir définir le contenu de notre Collection.

Etape 5 – Publier une application ou un bureau partagé

Dans les options de votre Collection, vous allez pouvoir cliquez sur Publish RemoteApp programs.

Cette option est aussi accessible depuis le menu déroulant Tasks.

Les applications disponibles sur votre serveur RD Session Host vont être automatiquement détectées. Il suffit de cocher les applications que vous souhaitez rendre disponible via la plateforme RDS.

Vous devez donc installer toute application personnalisée que vous souhaitez rendre disponible à vos utilisateurs sur le serveur RD Session Host concerné de votre Collection.

Dans certains cas d’applications portables, les exécutables ne sont pas automatiquement détectés. Dans ce cas, vous pourrez ajouter manuellement une application en cliquant sur le bouton Add.

Cliquez sur Next quand vous avez terminé votre sélection. Dans mon cas, j’ai choisi de publier la Calculatrice (pour l’exemple). Cliquez sur Close une fois l’opération terminée.

Etape 6 – Test d’accès à votre application RemoteApp

Notre application est à présent publiée. Il ne nous reste plus qu’à essayer de nous y connecter ! 😉

Pour ce faire, nous allons utiliser notre serveur RD Web Interface. Dans mon cas, il s’agit du RDC002. Par défaut, l’URL d’accès se présente sur le format suivant :

• https://server-web-interface/RDWeb et donc dans mon cas https://RDC002.mydomain.local/RDWeb.

Une fois connecté sur l’interface web, il vous suffit de vous identifier avec un compte de domaine. Ce dernier doit fait parti de groupe que vous avez autorisé à accéder aux ressources de la ferme RDS.

Cliquez sur l’icône de la Calculatrice pour démarrer l’application. Cette calculatrice va s’ouvrir mais sera exécutée depuis un serveur distant.

Nous avons un warning car normalement l’accès à notre plateforme RDS devrait être sécurisée en https avec un véritable certificat – ce qui n’est pas le cas pour le moment. Mais cela vous donne une idée du comportement de votre infrastructure RDS.

Vous pouvez également utiliser l’onglet Connect to a remote PC pour vous connecter à distance vers un serveur de votre infrastructure en passant par votre ferme RDS.

C’est terminé pour cet article. Votre infrastructure RDS sur Windows Server 2019 est fonctionnelle. En revanche, dans un scénario de Production, il vous resterait à vous familiariser avec les points supplémentaires suivants :

• Sécurisation de l’accès à votre plateforme avec des certificats,
• Activation de votre serveur de licences.

N’hésitez pas à utiliser la zone des commentaires pour toute question. 🙂

Plus d’infos sur le site de Microsoft concernant le rôle Remote Desktop Services.