Déployer RDS sous Windows Server 2012 R2 via Windows PowerShell

Publié: 02/04/2015 dans TSE & RDS, Windows Server 2012 (R2), Windows Sever
Tags:, , , , , , ,

 

Depuis Windows Server 2012 et 2012 R2, le rôle RDS (Remote Desktop Services) peut être déployé et géré via Windows PowerShell, en effet un module PowerShell nommé « RemoteDesktop » est désormais disponible et regroupe plus de 70 cmdlettes dédiées au déploiement, configuration et gestion de la solution RDS.

Nous allons voir à travers cet article comment déployer RDS 2012 R2 à l’aide de Windows PowerShell dans les deux modes , à savoir :

Déploiement Standard

Démarrage Rapide

Liste des cmdlettes PowerShell pour RDS

Vous pouvez utiliser la commande suivante pour lister toutes les cmdlettes du module « RemoteDesktop »

  • Depuis Windows PowerShell lancé en tant qu’Administrateur, saisissez :

  Get-Command -Module RemoteDesktop

2

 

 

 

 

 

 

 

 

 

 

 

Le résultat retourné inclut 73 cmdlettes vous permettant de déployer et gérer le rôle RDS sous Windows Server 2012 R2.

Mon LAB

Mon LAB est composé des serveurs suivants

  • LABDC01 : Contrôleur de domaine (W2012 R2) : AD + DNS
  • LABRDS01 : Serveur W2012 R2 sur lequel nous allons déployer RDS en mode « Démarrage Rapide » : Serveur Autonome avec les 3 services de rôles RDSH – RDCB – RDWA
  • LABRDSH :  Serveur W2012 R2 sur lequel le service de rôle « Hôte de session » sera déployé | mode « Déploiement Standard » : Serveur RDSH
  • LABRDCB :  Serveur W2012 R2 sur lequel le service de rôle « Service Broker » sera déployé | mode « Déploiement Standard » : Serveur RDCB
  • LABRDWA :  Serveur W2012 R2 sur lequel le service de rôle « Accès Web » sera déployé | mode « Déploiement Standard » : Serveur RDWA

Autre info :

  • Nom DNS de mon domaine AD  : vLAB.LAN

Déploiement de la solution RDS

Déploiement sur un seul serveur Autonome « Mode Démarrage Rapide »

Depuis le DC, dans notre cas « LABDC01 », lancez Windows PowerShell en tant qu’Administrateur et saisissez la commande suivante pour importer le module RemoteDesktop:

Import-Module RemoteDesktop

1

 

 

 

Une fois le module importé, la commande suivante sera utilisée pour déployer RDS en mode « Rapide » et à distance via Windows PowerShell sur le serveur LABRDS01 :

New-RDSessionDeployment -ConnectionBroker LABRDS01.vLAB.Lan -SessionHost LABRDS01.vLAB.Lan -WebAccessServer LABRDS01.vLAB.Lan

Note : il faut à chaque fois spécifier le FQDN de votre serveur RDS Autonome, le Nom NetBIOS uniquement n’est pas pris en charge.

Rappel : un déploiement « Rapide » du rôle RDS consiste à déployer les trois services de rôles (Hote de la Session « RDSH » – Service Broker « RDCB » – Accès Web « RDWA ») sur le même serveur, c’est la raison pour laquelle le même hostname (LABRDS01.vLAB.Lan) est réutilisé avec les 3 paramètres.

Une fois la commande ci-haut exécutée, le déploiement du rôle RDS en mode « Rapide » sur le serveur LABRDS01.vLAB.Lan démarre :

3

 

 

 

 

Dès que le déploiement est terminé, lancez le Gestionnaire de Serveur depuis le serveur LABRDS01 et constatez l’apparition de la console de gestion des Services Bureau à distance sur le Gestionnaire de Serveur :

4

 

 

 

 

 

 

 

 

 

Déploiement sur plusieurs Serveurs « Mode Déploiement Standard »

Dans un déploiement Standard, il faut dédier un serveur par Service de Rôle RDS, dans notre exemple, nous allons déployer :

= Service Broker sur LABRDCB

= Accès Bureau à distance par le Web sur LABRDWA

= Serveur Hôte de Session sur LABRDSH

La commande à utiliser est donc :

New-RDSessionDeployment -ConnectionBroker LABRDCB.vLAB.Lan -SessionHost LABRDSH.vLAB.Lan -WebAccessServer LABRDWA.vLAB.Lan

Création de la Collection de Session

La création de la Collection se fait en utilisant la cmdlette New-RDSessionCollection.

Saisissez la commande suivante pour créer une collection de session (Collection que nous allons nommer « NosRemoteApps ») et dans laquelle nous allons regrouper nos serveurs Hôte de session ,pour l’instant que LABRDS01 :

New-RDSessionCollection -CollectionName « NosRemoteApps » -CollectionDescription « Collection de session regroupant toutes les applications publiées de Dev » -ConnectionBroker LABRDS01.VLAB.LAN -SessionHost LABRDS01.VLAB.COM 

5

 

 

 

 

Depuis LABRDS01, lancez le Gestionnaire de Serveur > « Services Bureau à distance » > Collections et vérifiez que la collection « NosRemoteApps » est bien créée :

6

 

 

 

 

 

 

 

 

 

Publication des Programmes RemoteApp

Maintenant il nous reste plus qu’à publier des Applications (Programme RemoteApp) :).

J’ai déjà installé la suite Microsoft Office 2013 (v86x) sur mon serveur LABRDS01, nous allons utiliser la commande suivante pour publier par exemple MS Word :

Note : la même commande est réutilisée pour publier d’autre programme RemoteApp, il suffit de remplacer l’alias – nom d’affichage – chemin d’accès à l’exe correspondant au programme RemoteApp

Depuis LABRDS01, lancez Windows PowerShell en tant qu’Administrateur et saisissez :

Import-Module RemoteDesktop

New-RDRemoteApp -Alias MSWord -DisplayName « Word 2013 » -FilePath « C:\Program Files (x86)\Microsoft Office\Office15\WINWORD.EXE » -ShowInWebAccess 1 -ConnectionBroker LABRDS01.VLAB.LAN -CollectionName « NosRemoteApps »

Microsoft Word 2013 est donc publié sur notre serveur LABRDS01 et accessible aussi via le Portail Web D’accès Bureau à distance.

Ouvrez maintenant IE depuis n’importe quelle machine du réseau et connectez-vous à : https://LABRDS01/RDWeb

Authentifiez-vous et vérifiez que Word 2013 est bien publié.

7

 

 

 

 

 

 

 

 

Enfin, cliquez dessus pour le lancer et Enjoyr ur first RemoteApp Program 😀

8

 

Publicités
commentaires
  1. jb dit :

    bonjour,
    je me familiarise en ce moment au langage powershell,
    j’ai fait une ferme rds de test je vais en refaire une pour la prod,
    je me demande si je ne dois pas installer tous les serveurs en mode core a part les RDSH,
    est ce une bonne pratique ?
    je voulais me faire une VM d’administration en mode graphique et gérer les rôles dessus et via powershell

    • Hicham KADIRI dit :

      Bonjour JB, le seul service de rôle supporté sur un Server Core (Windows Server 2012 et 2012 R2) est le RDCB (Service Broker). Les autres rôles ne sont pas supportés. Ce scénario peut être adopté uniquement dans des infrastructures ou une ferme de serveur Broker doit être placé sur des réseaux sécurité ou isolés (type DMZ).

  2. Julien Penven dit :

    Bonjour Hicham,

    Je ne suis pas sûr de poster ce commentaire au bon endroit mais tant pis :

    Actuellement j’ai une infra montée avec ADMT et je souhaiterais migrer une ferme RDS (Windows server 2012 R2) d’un domaine A vers un domaine B.
    Sais-tu ce que ce changement de domaine implique en termes de reconfiguration ?

    Merci d’avance pour ta réponse

    Julien

    • Hicham KADIRI dit :

      Bonjour Julien.à partir du domaine ou la migration AD se fait via ADMT (Mig de comptes d’ordinateurs (des serveurs RDS) et des utilisateurs (Remote Desktop Users), aucun effet de bord n’a lieu. notez que l’ensemble des serveurs RDS doivent continuer à utiliser leurs Hostnames & IP@ associées. commencer à migrate l’ensemble sur un PoC (si cela est possible) et notez le résultat. vous pouvez m’en informer du résultat et me dire si des problèmes post-mig ont eu lieu.

      • Julien Penven dit :

        Bonjour Hicham,

        Merci pour ta réponse. Le problème c’est que si on migre un serveur (serveur de test) appartenant à une ferme RDS (ayant une collection), on perd l’accès TSE à ce serveur et impossible de se connecter dessus.
        En y accédant via la console vSphere, le gestionnaire du serveur indique que le serveur doit être ajouté dans le pool de serveurs, sans quoi on ne peut pas manager la ferme RDS.

        Il y a donc un effet de bord par rapport à la connexion au serveur post-migration et la nécessité de reconstruire entièrement la ferme, republier les collections, reaffecter les utilisateurs, etc.

        Julien

      • Hicham KADIRI dit :

        Quand vous migrez un serveur Hôte de Session faisant parti d’une Collection « X ». il faut simplement reproduire la même configuration sur l’environnement cible, en créant une nouvelle Collection nommée « X » et à laquelle vous ajoutez votre serveur RDSH. maintenant, il est tout à fait normal, qu’une fois migré, le serveur RDSH ne peut plus être managé depuis le Server Manager (source), vu qu’il appartient plus à l’ancienne collection. vous pouvez aussi partir sur la conf suivante :

      • Hicham KADIRI dit :

        Créez une nouveau déploiement RDS (RDSH/CB/WA) sur un serveur (physique ou VM) sur l’environnement cible (sur le nouveau domaine). récupérez la configuration du déploiement de l’infra source (via PowerShell ou des scripts que vous pouvez trouvé sur le Net >> MS TechNet Scripts Center), importez la conf sur la nouvelle infra RDS. maintenant, faut faire attention niveau autorisation & droits d’accès : faire le listing des groupes d’utilisateurs /utilisateurs autorisés sur le serveur source, et reproduire la même chose (définir la meme liste sur le nouveau serveur cible). Goodluck. HK

  3. Julien Penven dit :

    Ok merci, oui nous envisageons d’intégrer les serveurs TSE source dans une ferme RDS cible déjà reconstruite.
    Je vais voir ce qu’il est possible de passer comme script pour faciliter l’import dans la nouvelle ferme.

    • Hicham KADIRI dit :

      c’est tout à fait logique, faudrait simplement utiliser la cmd-let Remove-RDsessionHost RDSH_FQDN -CollectionName Nom_Collection pour le sortir de la collection. Cette commande ne supprime pas le service de rôle RDSH mais permet uniquement de sortir votre rdsh server de la collection. vous pouvez ensuite le migrer vers le new domaine, et le rajouter ds la nouvelle collection et le tour est joué. l’avantage ici c’est que votre serveur RDSH garde sa config initiale (REmoteApp installés …). Goodluck

  4. François dit :

    Merci pour ce blog qui m’a apprit tout ce que je voulais savoir sans oser le demander sur les différents rôle de RDS.

    Je me posais une question supplémentaire. Est il possible de mutualiser un serveur Web Access entre plusieurs serveurs hôte de session. C’est a dire publier sur un meme serveur Web Access des applications différentes provenant de plusieurs serveur hôte différent.

    Encore merci,

    • Hicham KADIRI dit :

      Salut François, yes, il est tout a fait possible d’avoir un seul RD Web Access server et plusieurs RD Session Host dans un déploiement.
      à partir du moment ou la remoteapp est configurée avec l’option « Affichée sur Portail RDWA » (paramètre PowerShell « ShowinWebAccess -1 »; toutes les remotesApps publiées sur les différents hote de session sont affichées sur le serveur rd web access. ces rôles n’ont pas besoin d’être installés sur le même serveur.

      • François dit :

        Hicham

        J’ai d’une part des problêmes de rafraichissement quand je publie en Powershell, je ne vois pas mon application dans le Server Manager sauf si j’en publie une autre dans le Server Manager. Ou quand je supprimer mon RD Web Access il continue de publie les applications sauf si je fais un iisreset.

        Et surtout d’autre part, j’ai l’impression que c’est le dernier qui parle qui a raison.

        – Je lie mon RD Web Access a un premier RD Host Session, je publie des applications je les vois sur la page Web.
        – Je lie mon RD Web Access a un second RD Host Session, je publie des applications je ne vois que les application de mon second serveur sur la page Web.

        Je ne sais plus trop comment chercher…

        Merci pour ton aide et la qualité de ton blog

      • Hicham KADIRI dit :

        ce problème est dû à une mauvaise config du role RDS et ses différents services de roles associés. l’application d’une RemoteApp est automatique sur l’ensemble des hotes de sessions (que ce soi via Windows PS ou server Manager). de plus, celle-ci sont (par défaut ) automatiquement visible dans le portail RD Web Access, dans un état normal, il n’y pas besoin de faire un reset niveau IIS (iisreset /restart).

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s