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

Je vous propose de voir ensemble comment installer une petite infrastructure Remote Desktop Services sur Windows Server 2012 R2. Avant d’aller plus loin, il faut bien comprendre qui ce rôle se distingue suivant 2 modes de fonctionnement. Tout comme Citrix, vous avez la possibilité de :

1. Proposer une infrastructure de type Session Host (dans ce cas là vous vous rapprochez de Citrix XenApp) qui permet aux utilisateurs d’accéder à des applications à distance. Applications qui s’exécutent sur des serveurs distants mais dont l’utilisateur ne voit que l’application (et non pas l’ensemble du bureau) ;
2. Proposer une infrastructure de type VDI pour que chaque utilisateur dispose non pas d’une ou plusieurs applications mais d’un environnement complet virtualisé (on parle de bureau virtuel).

Par défaut, Remote Desktop Services propose tous les sous-rôles suivants :

• RDCB – Remote Desktop Connection Broker : c’est la pièce principale de votre infrastructure. Ce rôle gère les différents serveurs VDI ou Session Host et c’est lui qui permettra aux utilisateurs d’établir les connexions avec les serveurs disposant des ressources à accéder. Il gère la répartition de charge dans les serveurs Session Host et bien d’autres choses !
• RDWA – Remote Desktop Web Access : c’est la partie web ; il s’agit d’un site IIS avec une mire d’authentification pour permettre à vos utilisateurs de s’identifier sur le portail et de sélectionner quelles ressources ils souhaitent exécuter.
• RDSH – Remote Desktop Session Host : il s’agit du (ou des) serveur(s) qui hébergent les ressources qui sont exécutées par les utilisateurs. C’est en général ce à quoi les utilisateurs pensent lorsque l’on parle de serveur TSE (Terminal Server). C’est notamment sur ce composant que seront hébergés les RemoteApps.
• RDGW – Remote Desktop Gateway : il s’agit d’un autre site web qui permet d’encapsuler le plus RDP dans du https afin de rendre disponible votre infrastructure vers l’extérieur.
• RDVH – Remote Desktop Virtualization Host : c’est le rôle qui correspond à un serveur hôte disposant d’Hyper-V et qui sera capable de générer à la demande les bureaux virtuels pour les utilisateurs.
• RDLI – Remote Desktop Licensing : tout simplement, c’est le rôle qui gère vos licences RDS. Il en existe 2 types différents : licences per user ou licences per device.

Maintenant que vous connaissez tous les composants d’une infrastructure RDS, notez que dans cet article je ne vais m’intéresser qu’aux fonctionnalités de type RemoteApp (puisque je ne dispose pas de serveur physique pour votre montrer comment faire de la VDI via RDS – j’y reviendrai dans un prochain article). Et pour en finir avec mon parallèle Citrix, autrement dit, nous allons faire du XenApp ! 🙂

Pour ce tuto (et les suivants qui vont traiter de RDS 2012 R2), je vais utiliser 5 machines virtuelles (je vous indique également les hostnames car je risque d’y faire référence dans l’article) :

• 1 VM AKL-RDBRK pour le Connection Broker,
• 1 VM AKL-RDWAC pour le Web Access,
• 1 VM AKL-RDGAT pour la Gateway RDS (sera déployé dans un prochain article car non nécessaire à une infrastructure standard RDS),
• 2 VM : AKL-RDSH1 + AKL-RDSH2 pour nos serveurs Session Host qui vont héberger nos RemoteApps.

A noter que je vais mutualiser le rôle qui gère les licences RDS sur la VM qui héberge le Connection Broker. On pourrait également faire la même chose pour la Gateway RDS et le Web Access, mais je préfère personnellement les séparer.

Nous allons à présent débuter l’installation. Pour ce faire, nous pourrions aller dans le Server Manager sur chaque machine virtuelle et installer et configurer chaque sous-rôle (méthode je dirais : à l’ancienne). Ou bien, comme vous le savez dans Windows Server 2012, le Server Manager a été grandement amélioré et il vous permet désormais de créer des groupes de serveurs que vous pourrez gérer et administrer depuis un seul et même serveur. C’est cette fonctionnalité qui va nous permettre d’installer nos sous-rôles RDS et de les répartir sur nos serveurs en fonction de nos besoins (grâce à WinRM).

A ce niveau-là de l’article, je vais supposer que vous disposez donc de 5 machines virtuelles installées en Windows Server 2012 R2, up to date en KB et insérées dans un domaine Active Directory. 🙂

Création de notre groupe de serveur

Connectez-vous sur la VM qui jouera le rôle du Connection Broker, nous allons créer notre grappe de serveur pour notre infra RDS. Depuis le Server Manager, cliquez sur Manage puis Create Server Group.

Nommez votre nouveau groupe de serveur et sélectionner les différents serveurs qui vont composer ce groupe. On retrouve les 5 machines dont je vous avais précédemment parlé.

Installation des rôles RDS : Connection Broker, Web Access et Session Host.

Toujours dans le Server Manager, cliquez sur Manage puis Add Rolles and Features comme pour installer n’importe quel nouveau rôle sur un serveur.

Etant donné le nombre de screens, si une capture d’écran n’est pas présente, vous pouvez considérer qu’il faut utiliser l’option par défaut ou simplement cliquez sur Next.

Comme je vous le disais précédemment, nous allons procéder à une installation de RDS à distance sur tous les serveurs de notre groupe.

Pour cet article, nous allons uniquement faire du Session-based desktop car je ne dispose pas de serveur physique pour vous montrer comment utiliser le rôle RDVH et gérer la virtualisation des bureaux VDI.

Comme vous le voyez, nous n’avons pas besoin de beaucoup de VM d’autant que certains composants vont être mutualisés. Cliquez sur Next.

C’est dans la capture suivant que les choses intéressantes commencent puisque nous allons spécifier pour chaque sous-rôle sur quel serveur de notre groupe de serveurs nous souhaitons que ce dernier soit installé (et en principe le Server Manager fera tout le reste tout seul). 😉

Pour chaque sous-rôle, le Server Manager va nous demander de choisir quelle serveur / VM sera utilisée. Nous commençons par le Connection Broker, il s’agira pour moi de la VM qui porte le nom de AKL-RDBKR.

Nous passons maintenant au composant Web Access. Pareil, nous sélectionnons la VM qui jouera ce rôle et cliquons sur Next. Remarquez au passage que le Server Manager, vous ajoute une option à cocher dans le cas où vous souhaiteriez mutualiser ce rôle avec le précédent.

Nous sélectionnons à présent les serveurs qui hébergeront le contenu. Vous pouvez en choisir plusieurs et dans ce cas le rôle RD Session Host sera automatiquement installé sur chaque serveur (c’est notre cas puisque j’ai provisionné 2 serveurs).

Si nécessaire, les serveurs redémarreront automatiquement.

Si vous avez tout suivi jusque là, vous aurez sans doute remarqué que le Server Manager ne nous a pas proposé de choisir un serveur pour les rôles de Gateway (RD GW) et de Licensing (RD LI). En fait, vous pourrez déjà faire du RemoteApp avec les rôles choisis pour l’instant. La Gateway c’est pour rendre accessible votre infra à l’extérieure (non nécessaire de base) et vous disposerez dans un premier temps de 120 jours de licences gratuites RDS (avant de devoir installer vos propres licences CAL).

Cliquez sur Next.

L’installation s’est correctement déroulée, les serveurs devant redémarrés ont pu être redémarrés et reprendre l’installation ; cliquez sur Close pour terminer cette étape d’installation.

Avant d’aller plus loin, je vous propose de regarder la console RDS depuis le Server Manager de notre Connection Broker. Cliquez sur l’onglet Overview dans un premier temps.

On retrouve un certain nombre d’informations :

• L’agencement de notre infrastructure et quels sont les rôles déjà installés ou les rôles qui peuvent encore être installés (en cliquant sur le gros symbole plus entouré de vert : RD Gateway et RD Licensing) – en bas au centre.
• Les serveurs composants notre architecture actuelle RDS – en bas à droite.
• La possibilité d’ajouter de nouveaux serveurs Session Hosts pour accroître les capacités de notre infrastructure – en haut à droite.

Passons maintenant à l’onglet Collections.

Dans la zone centrale, nous retrouverons nos collections de serveurs RDS. Il s’agit de regroupement de serveurs RD SH. Cela est particulièrement utile dans le cas d’une infrastructure plus importante pour par exemple distinguer certains serveurs en fonction des besoins métiers que vous cherchez à atteindre. Par exemple :

• Certaines applications qui ne peuvent pas être regroupées sur les mêmes serveurs et doivent donc être séparées (contrainte technique),
• Certaines ressources sensibles ne sont utilisées que par des VIP ou Manager et les applications concernées doivent être installées sur quelques serveurs qui ne seront accessibles qu’à certains utilisateurs (contrainte métier).

En bas à gauche, vous trouverez également la liste des serveurs RDS SH et vous pourrez également activer le mode maintenance en effectuant un clic droit sur chaque serveur. Cela vous permet de ne plus autoriser de connexions sur un serveurs RDS SH – celui-ci se vide alors petit à petit et vous pourrez alors intervenir sur celui-ci dès lors que plus aucun utilisateur n’y sera connecté (patch, installation d’une nouvelle application, etc.).

En bas à droite, vous pourrez visualiser la liste de tous les utilisateurs actuellement connectés à votre infrastructure RDS avec le type de ressources auxquelles ils accèdent actuellement : collection name, serveur RD SH utilisé, username, état de la session, etc.

Nous allons maintenant créer une collection pour l’exemple.

Création d’une collection RDS

Depuis le Server Manager, dans la console RDS et l’onglet Overview, cliquez sur Create session collections.

Nommez votre collection et attachez lui une description.

Cliquez sur Next.

Définissez maintenant le groupe d’utilisateurs qui sera autorisé à y accéder. Il peut s’agir d’utilisateurs spécifiques ou comme dans mon cas d’un (ou plusieurs) groupe(s) Active Directory. Donc tous les ressources publiées sur cette collection seront accessibles à ces utilisateurs ou groupes d’utilisateurs.

Une fois votre choix effectué, cliquez sur Next.

Je désactive cette option ; je ne souhaite en effet pas offrir la possibilité de mémoriser ou retenir quelque configuration que ce soit ou élément qui pourrait être personnalisé par mes utilisateurs. A adapter selon vos besoins donc. Et si vous souhaitez l’utiliser de manière avancée, je recommande l’utilisation d’un fileshare. Cliquez sur Next.

Notre collection est à présent créée.

Passons maintenant à la publication et au test d’accès à une application.

Publication d’une ressource

Toujours dans le Server Manager depuis notre Connection Broker, rendez-vous dans la console RDS puis dans la collection que vous avez précédemment créée (pour ma part il s’agit de My RDS Collection).

Dans la section centrale : RemoteApp Programs, cliquez sur Publish RemoteApp programs. L’assistant va automatiquement rechercher toutes les applications disponibles sur les serveurs Session Host concernés et la liste apparaît. Vous n’avez donc plus, comme sous 2008 R2, à spécifier le chemin de l’exécutable ou le dossier de l’application. Dans la majorité des cas, la console RDS 2012 R2 détecte l’application et son emplacement et il ne vous alors plus qu’à sélectionner l’application en la cochant.

Je vous propose de publier un grand classique : la calculatrice, Remote Desktop Connection et PowerShell. 🙂

Notez que c’est à ce moment que vous pouvez cliquer sur le bouton Add pour ajouter manuellement une application qui n’aurait pas été détectée mais qui se trouve bien sur les serveurs Session Host.

Une fois le choix terminé, cliquez sur Next. Puis sur Close.

Test d’accès à une ressource RemoteApp

Vous l’avez certainement remarqué, nous avons pu procéder à toute l’installation et à la configuration en restant uniquement sur le Server Manager depuis notre Connection Broker. Nous avons pu publier 3 premières applications, je vous propose maintenant de vous connecter au site IIS Web Access pour vérifier que nous accédons bien à nos RemoteApps. Pour ce faire, connectez-vous sur n’importe quelle VM et démarrez votre navigateur Internet préféré. Allez directement à l’URL suivante : http://akl-rdwac.akril.cloud/RDWeb (à adapter en fonction de votre domaine AD et du nom de votre VM qui héberge le rôle RD Web Access).

Pour l’instant notre site IIS n’est pas correctement configuré au niveau du https et nous devrons probablement à adjoindre un certificat auto-signé pour éviter cette erreur (voir un véritable certificat signé par une autorité externe dans cas de Production). Mais je reviendrai sur ce point dans un prochain article.  Là nous voulons vérifier que notre infra RDS est fonctionnelle. Cliquez donc sur Continue to this website.

Identifiez-vous en précisant votre domaine et votre compte AD.

Tentez d’exécuter une application ; après quelques instants l’application démarre.

Notez également que l’onglet Connect to a Remote PC vous permet de vous connecter en Remote Desktop à n’importe quel serveur de votre infrastructure (comme n’importe quelle connexion RDP en passant par l’intermédiaire de votre infrastructure RDS 2012 R2).

C’est terminé pour cet article et votre infra RDS 2012 est complètement fonctionnelle. 😉

Dans de prochains articles je vous proposerai de regarder les points suivants :

• Activation du https et utilisation d’un certificat auto-signé pour votre portail d’accès ;
• Extension de l’architecture RDS 2012 R2 avec les rôles de RD Gateway et RD Licensing pour accéder à votre infrastructure RDS depuis l’extérieur et également activer vos licences CAL RDS (via une abonnement MSDN par exemple dans mon cas) ;
• Création d’une stratégie GPO pour gérer votre infra RDS et (notamment) renseigné votre serveur de licences depuis une GPO centralisée ;
• Et bien d’autres choses encore…

A très vite. 🙂