Installer le Client R(emote) D(esktop) Web HTML5 sur RDS Windows Server 2016

Publié: 24/10/2018 dans TSE & RDS, Windows 10, Windows Server 2016
Tags:, , , , , , ,

Introduction

Vous devez sûrement connaître le fameux client « Connection Bureau à distance » fourni nativement avec les OS Windows (Client & Server). Cette Windows Desktop App fait simplement appel à l’outil MSTSC.exe qui est, aujourd’hui utilisé par la quasi totalité des Admins devant gérer et administrer (à distance) des plateformes Windows Server.

 

Note : Petit reminder, l’outil MSTSC.exe est (par défaut) placé dans : C:\Windows\System32\mstsc.exe

 

En outre, Microsoft propose depuis quelques années un client lourd « Multi-Platforme** » appelé « Remote Desktop« . Cette App est en effet disponible pour :

  • Mac OS X (depuis Mac Apple Store)
  • iOS (depuis Apple Store)
  • Android (depuis Google Play Store)

 

** Vous trouverez ci-dessous les liens de téléchargement de l’App « Remote Desktop », pour les différentes plateformes :

 

Session Bureau à distance « Windows 7 » sur un Smartphone « Samsung »

 

Après avoir sorti cette App « Cross-Platform », Microsoft a commencé à travailler sur son client Web HTML5, appelé RD (Remote Desktop) Web Client 🙂

Ce client est proposé depuis RDS Windows Server 2016 sous forme d’extension/plug-in du service RD Web Access.

Nous allons découvrir à travers cet article comment installer et configurer ce nouveau client RD Web sous RDS 2016.

Let’s Do It !

 

Prérequis

Le déploiement du client RD Web nécessite un certain nombre de prérequis, à savoir :

  • Votre (ou vos) Serveur(s) RD Web Access doit exécuter (à minima) Windows Server 2016 (ou 2019)
  • Votre déploiement RDS 2016 doit comporter (au moins) une Passerelle RDS
  • Les CAL RDS installées doit être de type « Par-Utilisateur« 
  • Les certificats SSL configurés pour la Passerelle RDS et le Serveur RD Web Access doit être délivrés et signés par une CA (Certification Authority) valide Publique : les certs SSL auto-signés empêchent l’utilisation du client RD Web
  • Seuls les connexions provenant des OS Suivants seront acceptés par le Client RD Web :
    • Windows 10
    • Windows Server 2008 R2 (ou ultérieur)

 

HowTo : Installer le client RD Web HTML5 sur un déploiement RDS 2016

Suivez les instructions suivantes pour installer correctement le client RD Web HTML5 au niveau de votre déploiement RDS 2016 :

  • Tout d’abord, ouvrez une Session Windows sur le serveur RD Web Access
  • Lancez Windows PowerShell en tant qu’Administrateur
  • Saisissez la commande suivante pour mettre à jour le module « PowerShellGet« 

Install-Module -Name PowerShellGet –Force

Note : Saisissez Y (comme Yes) pour confirmer l’exécution de la commande

  • Fermez la console PowerShell, et ré-ouvrez une nouvelle instance pour que l’Update du module PowerShellGet soit prise en compte
  • Exécutez la commande suivante pour installer le Module de Gestion du client RD Web :

Install-Module -Name RDWebClientManagement

  • Vous êtes invités à accepter les termes du contrat de Licence, saisissez A comme [All] et validez en cliquant sur Entrée :

  • Vous devez ensuite exécuter la commande suivante pour installer la dernière version du client RD (Remote Desktop) Web :

Install-RDWebClientPackage

  • Une fois le Package du Client RD Web installé, exécutez la commande suivante et notez le résultat :

Get-RDWebClientPackage

Maintenant, vous devez exporter le certificat SSL utilisé par votre service Broker. Ouvrez une Session Windows sur le Serveur Broker et lancez la console (snap-in) MMC > Ajouter « Certificats » > pour le « Compte d’Ordinateur » > Développez « Personal >> Certificats »

Faites un clic-droit sur le certificat utilisé par le service Broker. Dans l’exemple suivant, un seul certificat (rdgateway-hk.corp) a été utilisé pour signer tous les échanges Broker/RDWeb/RDG

  • Le fichier .Cer a été exporté et placé dans C:\
  • Le fichier .Cer exporté précédemment (C:\rdgateway-hk.cer) sera utilisé lors de la prochaine opération pour prendre en charge l’authentification SSO depuis le Client RD Web.
  • Exécutez la commande suivante en spécifiant l’emplacement vers lequel le .Cer a été exporté et placé :

Import-RDWebClientBrokerCert C:\RDGateway-hk.cer

  • Enfin, exécutez la commande PS suivante pour publier le nouveau client RD Web :

Publish-RDWebClientPackage -Type Production –Latest

Note importante : cette commande doit être exécutée si vous devez déployer le client RD Web dans un environnement de production, si vous souhaitez simplement « PoKé » le client RD Web sur un environnement de Test/Dev/Hom, exécutez plutôt la commande suivante :

Publish-RDWebClientPackage -Type Test –Latest

 

Let’s Test tout ça :).

Pour se connecter à votre client RD Web, la syntaxe de l’URL à utiliser est la suivante :

  • Si Installation en Production (paramètre -Type Production)

https://FQDN-de-votre-RDWebAccess.com/RDWeb/WebClient

  • Si Installation en environnement de Test (paramètre -Type Test)

https://FQDN-de-votre-RDWebAccess.com/RDWeb/WebClient-Test

Dans l’exemple suivant, je me connecte sur mon portail RD Web Access hébergé dans Azure. Comme illustré dans la capture d’écran ci-dessous, je suis connecté sur https://rdgateway-hk.xxxxxxxx.com/RDweb/webclient :

Une fois authentifié sur le Portail, je retrouve toutes mes Applis publiées (RemoteApps) :

Je lance une RemoteApp (Server Manager dans l’exemple suivant) …. :

Une fois lancé, je retrouve ma RemoteApp (Server Manager) depuis mon client RD Web.

Comme vous pouvez le voir, le client « lourd » local (MSTSC.exe) n’est pas lancé/utilisé, et je suis dans un mode « Full Web » 🙂 :

J’ai aussi lancé une instance WordPad 🙂 :

N’hésitez pas à publier vos RemoteApps favorites et les tester depuis le client RD Web.

Enjoy :).

 

Note : Un nouvel article sur le RD Web Client sous RDS 2019 arrive bientôt. Stay connected.

#HK o_O

Publicités
commentaires
  1. Jb dit :

    bonjour,
    quelqu’un a t’il testé avec les clients légers Wyse ?

    • Hicham KADIRI dit :

      Bonjour JB,
      Yes, et cela fonctionne sans problème.
      Maintenant, tout dépendra du ThinOS de ton Wyse.
      Un Upgrade sera peut être nécessaire avant support du client Web RDP_HTML5.

      • Jb dit :

        Salut Hicham,
        je vais tester avec la dernière version de ThinOs (8.6) et je ferais un retour

  2. Martin40 dit :

    Bonjour,

    J’ai un petit soucis, l’installation c’est déroulé comme prévu, et la connexion fonctionne, cependant quand j’essaie de lancer mon bureau à distance (pas application), j’ai une erreur :

    « La connexion à l’ordinateur distant a été perdue. Cela peut être dû à un problème de connexion réseau. Si ce problème persiste, demandez de l’aide à votre administrateur ou au support technique. »

    Quelqu’un a déjà eu le soucis ? Merci Hicham !

    • Martin40 dit :

      Désolé du doublon mais juste avant l’erreur, j’ai « Ouverture du port distant » une demi seconde puis j’ai l’erreur qui s’affiche.

    • Hicham KADIRI dit :

      Bonjour Martin,

      Peux-tu me décrire ton architecture/infra RDS ?
      Comment les composants sont répartis et isolés ?
      Version des services RDS déployés ?

      A bientôt
      #HK

      • Martin40 dit :

        Bonjour Hicham,

        Je viens de comprendre mon problème.

        Quand je me connecte depuis :
        – MONBROKEUR.LOCAL/RDWeb/WebClient , j’arrive à me connecter mais quand je passe par
        – NOMDEDOMAIN.DOMAINE/RDWeb/WebClient, j’ai le blocage.

        En gros, lorsque je passe en local, j’arrive à me connecter mais pas lorsque je passe par la GateWay.

        Et j’ai compris pourquoi, c’est du au fait que le certificat que j’ai acheté n’est pas un WildCard. Vu que le certificat est disponible que pour un seul NOMDEDOMAIN, et que le broker fait la redirection vers HOTE1, HOTE2 etc.. ça ne passe pas.

        Je vais re-acheter un wildcard et certifier tous mes hôtes et là je ne devrais plus avoir de soucis 😉

      • Hicham KADIRI dit :

        Ou sinon, acheter un certificat avec des SAN (Subject Alternative Name). Exemple :

        Mon Domaine : tsgateway.masocite.com
        Mes Host :
        (RDSH1) : rdsh1.masociete.com
        (RDSH2) : rdsh2.masociete.com

        Les RDSH1 et 2 sont des SAN à déclarer dans ton certificat.

        A noter qu’il faut déclarer des CNAME DNS qui font pointer tes dns locaux vers les dns rdhs1.masociete.com et rdsh2.masociete.com

        Les noms de domaine locaux ne sont pas supportés en tant que SAN.

        Goodluck

  3. olivier dit :

    bonjour
    super article comme d habitude

    par contre j ai ca en permanance

    Se déconnecter

    Toutes les ressources

    Les paramètres de confidentialité des ressources gérées ont été prédéfinis par votre organisation. En savoir plus

    • Hicham KADIRI dit :

      Hello Olivier,

      Depuis quel device établit tu la connexion via le client RD HTLM ?
      Depuis un PC perso ou Pro (d’entreprise, héritant des GPOs de domaine par exmeple) ?

      Peux-tu me faire un extract des GPOs appliquées sur la machine depuis laquelle tu fais le test ?

      • Olivier dit :

        Bonjour,

        Depuis un poste hors domaine donc pas de gpo appliqué
        Sinon config classic rds via interface graphique pour les Connection.
        Redirection port disque dur etc..

        Là je ne l ai plus sous le coude car j ai remonter un lab test pour utiliser rdgateway et rdweb sur de serveur différents.

        Des que j ai fini la mise en place je réinstalle le client html5 et je peux t envoyer une copie d écran.

        Merci pour la réponse.

        PS .juste une question hors sujet, impossible de me connecter sur le serveur avec le client rap en utilisant la passerelle. Msg erreur Connection html reçu NTLM attendu.
        D ou mon interrogation, est il possible d utiliser la gateway avec le client rap natif de Windows.
        Je n ai pas ce problème avec le RemoteApp puisque c est un déport d applications.

  4. Stéphane R. dit :

    Bonjour, M. KADIRI

    Dans le cadre de la migration d’une ferme CITRIX (Windows Server 2008R2) vers MICROSOFT RDS (Windows Server 2016), nous rencontrons avec mon hébergeur qui installe la solution une difficulté majeure.

    Nous avons une réauthentification à l’ouverture d’une application ou d’une session bureau à distance. Nous accédons au portail via des postes hors domaine (sur internet). Nos postes sont sur Windows 10.

    Que doit on faire pour ne plus avoir cette double authentification ?

    Nous avons trouvé une solution mais qui ne nous convient pas complètement. Nous avons installé le webclient HTML5 que j’ai découvert sur votre site. Ca fonctionne sans réauthentification mais le webclient :

    1) est moins performant par rapport à mstsc.exe :
    – le rafraîchissement d’une fenêtre est saccadé si on la déplace à la souris par exemple
    – il y a parfois des bandes grises ou des ascenseurs, le bureau ou l’application n’est pas en plein écran ou est masqué
    – la barre noire du haut est escamotable mais un petit rectangle persiste au milieu de l’écran et ne semble pas être déplaçable.

    2) est moins fonctionnel :
    – l’impression ne se fait pas directement, cela génère un fichier PDF… qu’il faut imprimer…)
    – on ne peut plus parcourir les ressources locales « tsclient » c:\
    – il ne semble pas gérer le multi écran

    3) n’est plus personnalisable (pas important) :
    – Il n’y a plus de « place » pour le logo de l’entreprise
    – Nous ne pouvons plus mettre un lien pour inviter à changer le mot de passe sur la fenêtre de connexion comme on le fait sur la page de connexion rdweb.

    Merci pour votre retour. J’ose espérer qu’il y a une solution pour utiliser rdweb via mstsc.exe sans double authentification sur des postes hors domaines sur internet et ce avec tous les navigateurs. Sinon il faudrait que l’on retourne sous CITRIX…

    • Hicham KADIRI dit :

      Bonjour Stéphane,

      Vous utilisez quel Web Browser sur les PC hors domaine ?
      Il faut noter que pour avoir le SSO (depuis le Web Access Portal), l’ActiveX est requis. ce dernier n’est supporté et fourni qu’avec Internet Explorer. Si vous utilisez Chrome ou Firefox, le SSO n’est pas opérationnel (par défaut). Il existe des techniques /tools permettant de le faire tourner, mais il est recommandé d’utiliser IE pour accéder et utiliser des RemoteApps RDS.

      Le problème de le double authent peut également être lié à une mauvaise configuration/utilisation des certificats SSL du déploiement RDS.
      Pouvez-vous me décrire comment vous avez configuré les certs SSL de votre déploiement ?

      A bientôt,
      #HK

      • Stéphane R. dit :

        Bonjour, l’objectif est de ne pas imposer un navigateur comme c’est le cas avec CITRIX.
        Mais vous faîtes bien de préciser, en effet, nous arrivons à nous connecter sans double authentification avec Internet Explorer et l’ActiveX>client RDP. Donc je ne pense pas qu’il y a un problème au niveau des certificats.

        J’aurai aimé que cela fonctionne à minima avec EDGE (car mes utilisateurs ne savent pas faire la différence entre Internet Explorer et EDGE). C’est le comble que ca ne fonctionne pas sans double authentification avec le navigateur « moderne » de Microsoft.

        Pour ma part, j’ai développé une page intermédiaire qui redirige les utilisateurs vers « www.xxxx.xxx/rdweb » si Internet Explorer ou vers « www.xxxx.xxx/rdweb/webclient » si pas Internet Explorer. De plus pour les utilisateurs de EDGE qui se plaindront du Webclient, je les redirigerai automatiquement sur Internet Explorer en modifiant la clé de registre (mode de compatibilité entreprise) : [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\MicrosoftEdge\Main\EnterpriseMode] « SiteList »= »www.xxxx.xxx/compat.xml »

        N’ayant pas de GPO, il faudra le faire « manuellement » sur les postes… pas simple.

        Avez vous un lien vers les « techniques Tools » dont vous parlez ? Merci

        ———–A ne pas publier ——
        voici l’url de notre page intermédiaire merci de ne pas la publier : https://www.acpei.pro

Répondre à Martin40 Annuler la réponse.

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 )

Photo Google

Vous commentez à l'aide de votre compte Google. 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 )

Connexion à %s