Articles Tagués ‘Remote Desktop Services’

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

Le Remote Desktop est une technologie utilisée aujourd’hui par la quasi-totalité des entreprises, que ce soit pour du support technique (Session Shadowing pour les end-users) ou pour permettre aux téléworkers d’accéder aux applications d’entreprise.

Microsoft propose depuis plusieurs années déjà, une application « Lourde » nommée Microsoft Remote Desktop pour différentes plateformes (Cross-Platform Remote Desktop Client) :

Mac OS

Télécharger Microsoft Remote Desktop pour MacOS X

Android

Télécharger Microsoft Remote Desktop pour Android

iOS

Télécharger Microsoft Remote Desktop pour iOS

Avec l’arrivé du Cloud, la vision (à court terme) de plusieurs décideurs informatique, est de proposer à leur End-users un environnement « Full Cloudisé » et uniquement un client léger (e.g : Chrome Book) pour l’accès aux applications hébergées dans le Cloud (SaaS Apps : Software-as-a-Service Applications).

Avec cette vision, aucun client « Lourd » ou application locale ne doit être installée sur le poste client (Thin Client). L’accès se fait principalement depuis un Web Browser.

Pour répondre à ce type de besoin (ou d’architecture), Microsoft a introduit le nouveau Remote Desktop Web nommé « RD Web Client ». Ce client Web est basé sur HTML5 et prend en charge la plupart des navigateurs Web (Edge, IE, Chrome, Firefox, etc.).

Selon les informations communiquées par l’équipe Remote Desktop Services Corp, RD Web Client ne prend malheureusement pas en charge les Clients « Mobile ».

RD Web Client est disponible (au moment de la rédaction du présent post) en Preview et supporte déjà les fonctionnalités classiques de l’outil RDC (Remote Desktop Connection : MSTSC.exe) telles que :

Clipboard (Copier/Coller)

Redirection d’imprimante

Remote Audio

 

Prerequis à prendre en considération 

Pour pouvoir déployer le Client Web Remote Desktop, votre infrastructure RDS cible doit remplir les conditions suivantes :

Tous les serveurs RDS du déploiement (RDCB, RDSH, RDWA et RDG) doivent exécuter Windows Server 2016.

Votre déploiement RDS ne doit pas être configuré avec des CAL RDS « Per-Device /Par-Périphérique »

La  KB4025334 doit être installée sur votre serveur RDG (Remote Desktop Gateway).

Les serveurs RD Web Access et Gateway doivent utiliser des certificats SSL signés par une CA (Certification Authority) Publique.

Enfin, côté client, il faut bien évidemment utiliser des Web Browsers prenant en charge de la HTML5. IE11, Edge, Chrome, Firefox et Safari le sont, donc all is Ok :).

 

Installation du RD Web Client

Je détaillerai l’installation du Client Web Remote Desktop lors d’un prochain post, comme expliqué précédemment, il est aujourd’hui en « Preview Version ». Je publierai un HowTo détaillé directement sur la Finale Preview ^_^.

Ce que vous devez savoir, c’est que le RD Web Client est simplement une Extension à ajouter au niveau du service de rôle « RD Web Access ».

L’équipe RDS Corp travaillent sur une nouvelle Cmd-let qui permettra de faciliter le déploiement de ce client : Install-RDWebClientPackage

L’affichage des ressources RDS déportées directement sur le RD Web Client ressemble à l’image ci-dessous :

Je vous en dirais pas plus :),

Keep in touch

#HK

 

Certains clients disposant d’une zone démilitarisée (ou DMZ pour Demilitarized Zone) et désirant déployer une infrastructure RDS avec une ou plusieurs Passerelles RDS (RDG : Remote Desktop Gateway) et serveurs RDWA (Remote Desktop Web Access) se posent souvent la question suivante :

Quels sont les (ports) requis à ouvrir pour permettre à tous les services de rôles RDS de communiquer correctement ?

Cette communication concerne principalement les serveurs RDG et RDWA placés en DMZ avec les autres services de rôles RDS en back-end, placés généralement sur le réseau interne de l’entreprise et se trouvant derrière un ou plusieurs Firewalls, notamment les serveurs Hôtes de Session (RDSH : Remote Desktop Session Host) et serveurs Broker (RDCB : Remote Desktop Connection Broker).

Vu que le serveur de Passerelle RDS doit être membre du domaine AD (Workgroup non supporté !), les flux avec les Contrôleurs de domaine AD (DC : Domain Controllers) sont nécessaires, et ce pour authentifier les utilisateurs distants (externes) et les autoriser à accéder aux ressources RDS internes.

Dans ce type d’architecture (scénario de déploiement), plusieurs ports sont à ouvrir pour permettre à la Passerelle RDS de remplir les fonctions suivantes:

  • Authentifier les utilisateurs distants/externes RDS
  • Autoriser les utilisateurs distants/externes RDS à accéder aux ressources internes publiées
  • Résoudre les noms DNS des ressources RDS internes
  • Forwarder (au Broker) les packets RDP envoyés par les clients distants.
  • Obtenir la liste des Révocations de Certificats SSL
  • Envoyer des requêtes RADIOS (si vous déployez un serveur NPS central)

 

Pour simplifier la compréhension de la matrice de flux « global », j’ai décidé de créer deux catégories de Flux, à savoir :

Flux entre « External Network » et la Passerelle RDS placée en DMZ : config au niveau du Firewall Externe

Flux entre la « Passerelle RDS » et les ressources internes (RDSH, RDCB, DC…) : config au niveau du Firewall Interne

Le diagramme Visio ci-dessous représente une architecture RDS classique avec RDG/RDWA en DMZ et le reste des services de rôles en interne

Flux entre « External Network » et la Passerelle RDS placée en DMZ : Pare-feu Externe

Déployer une Passerelle RDS vous évite d’exposer directement vos ressources RDS à Internet et les protéger contre plusieurs types attaques informatique (e.g DoS/DDoS Attack !).

La Passerelle RDS a besoin du serveur Web IIS (Internet Information Services) pour fonctionner.

Le WebSite RDG hébergé sur IIS nécessite une liaison « HTTPS », par conséquent le port de communication (d’écoute) utilisé par la RDG est le 443.

Vous aurez compris, pour autoriser le trafic HTTPS entrant et permettre une communication entre les clients externes et la Passerelle RDS placée en DMZ (derrière un Firewall Externe/Public), la règle suivant doit être créée/configurée :

Nom de la règle : External_to_RDG (nom de règle donné à titre d’exemple)

Port : 443/TCP

Protocol : HTTPS

Source : Internet

Destination : @IP de la Passerelle RDS placée en DMZ

 

Flux entre la « Passerelle RDS » placée en DMZ et les ressources internes (RDSH,RDCB,DC…) : Pare-feu Interne

Le Pare-feu Interne doit être configuré pour autoriser plusieurs types de communications (trafics) entre le ou les serveurs RDG placés en DMZ et vos ressources internes tels que les Domain Controller (pour authentification/autorisation), Serveurs Broker (redirection aux ressources RDS), Serveurs RDSH (accès aux ressources publiées).

Trafic lié à l’authentification  & autorisation via la Passerelle RDS
#Kerberos

La règle à mettre en place pour autoriser le trafic (Kerberos) entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne afin d’authentifier les utilisateurs distants est la suivante :

Nom de la règle : RDG_to_InternalDC (nom de règle donné à titre d’exemple)

Port : 88/TCP

Protocol : Kerberos

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#Service RPC NT Directory Service (NTDS) 

Le serveur RDG a également besoin de communiquer avec le service RPC NTDS (NT Directory Services) lié à l’AD, ce dernier écoute généralement sur un numéro de port non utilisé et pris d’une plage de ports haute. Le serveur RDG n’ayant pas la capacité de connaitre ce numéro de port (dynamic port) utilisé par le service RPC NTDS, il contacte le Mappeur de point de terminaison RPC (RPC Endpoint Mapper) en utilisant le port 135, l’Endpoint Mapper indique ensuite au serveur RDG le port d’écoute pour le service demandé qu’est le RPC NTDS. Comme indiqué précédemment, ces numéros de ports sont attribués de manière dynamique (généralement compris entre 1024 et 65 535), notez qu’à l’aide d’une clé de Registre, vous pouvez configurer un port « Statique » pour le RPC NTDS si nécessaire. Je vous laisse consultez cet article pour en savoir plus.

Nom de la règle : RDG_to_RPCMapper (nom de règle donné à titre d’exemple)

Port : 135/TCP + Port d’écoute configuré pour le service RPC NTDS

Protocol :RPC Endpoint Mapper + RPC NTDS

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#LDAP

La règle à mettre en place pour autoriser le trafic (LDAP) entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne afin d’autoriser les utilisateurs distants est la suivante :

Nom de la règle : RDG_to_InternalDC (nom de règle donné à titre d’exemple)

Port : 389/TCP et 389/UDP

Protocol : LDAP

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#DNS

La règle à mettre en place pour autoriser le trafic DNS entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne et permettre la résoudre des noms DNS des ressources internes :

Nom de la règle : RDG_to_DNS (nom de règle donné à titre d’exemple)

Port : 53/TCP et 53/UDP

Protocol : DNS

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs_ou un des serveurs DNS du réseau

 

#RDP

La règle à mettre en place pour autoriser le trafic RDP entre la Passerelle RDS placée en DMZ et les serveurs RDS internes pour forwarder les packets RDP reçus par les clients distants :

Nom de la règle : RDG_to_RDSHCB (nom de règle donné à titre d’exemple)

Port : 3389/TCP

Protocol : RDP

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP des serveurs RDSH ainsi que RDCB

 

Note importante : si le port RDP par défaut, a été personnalisé/changé sur le déploiement RDS (e.g 33381 au lieu de 3389), le port 33381 doit être spécifié dans la règle ci-dessus.

Trafic entre le serveur RD Web Access et les serveurs RDSH internes

Si vous avez décidé de placer votre ou vos serveurs RD Web Access en DMZ (chose que je vous recommande d’ailleurs :)), notez qu’un seul flux est à ouvrir :

Nom de la règle : RDWA_to_RDCB (nom de règle donné à titre d’exemple)

Port : 5504/TCP

Protocol : RPC

Source :@IP du ou des serveurs RDWA placés en DMZ

Destination : @IP du(es) serveurs RDCB

 

J’espère que cet article pourra vous être utile lors du Design de votre infra RDS et/ou rédaction de votre document d’architecture technique/DAT/TAD (RDS Network Considerations Section).

Notez que des ports supplémentaires peuvent être requis si vous disposez d’une plateforme RADIUS, ou utilisez par exemple des solutions « Third-party » pour l’authentification/autorisation (dans ce cas, referez-vous à la documentation technique fournie par l’éditeur de solution pour en savoir plus).

Keep in touch,

A bientôt

#HK

 

Les questions suivantes m’ont souvent été posées par mes différents clients et partenaires :

Puis-je réutiliser mes anciennes CAL TSE/RDS et les réinstaller sur un nouveau serveur exécutant une version d’OS Windows Server différente à celle du serveur « Source/existant »?

Puis-je utiliser mes CAL TSE/RDS existantes pour autoriser mes utilisateurs RDS à se connecter à des serveurs TSE/Hôtes de Session (RDSH) exécutant des versions Windows Server différentes ?

J’ai donc décidé de rédiger ce post pour y répondre car cela pourrait intéresser plusieurs personnes se posant les mêmes questions :).

Ma réponse sera « Splitée » en deux parties :

  • Compatibilité des CAL TSE/RDS pour les serveurs de Licence RDS (RDLS)
  • Comptabilité des CAL TSE/RDS pour les serveurs Hôte de Session (RDSH

 

Note importante : les informations détaillées ci-dessous s’applique à vos serveurs de Licence RDS et RDSH hébergées dans vos Datacenters mais aussi ceux qui tournent sous forme de VM IaaS Azure (ou AWS, GCP, AliBabaCloud…Etc)

 

#R1 : Liste des CAL TSE/RDS pouvant être installées sur chaque version d’OS Windows Server 

Le tableau ci-dessous vous montre les CAL TSE et RDS pouvant être installées/utilisées sur chaque version d’OS Windows Server hébergeant le service de Licensing RDS (RDLS : Remote Desktop Licensing Server) :

Pour vous aider à mieux comprendre le tableau, je vous détaillerai un vrai « Use Case »:

Supposons qu’un Client (Société) X dispose déjà d’un Pack de Licences RDS 2008 R2 et est sur le point de dé-commissionner son infrastructure RDS 2008 R2 pour en déployer une nouvelle sous 2012 R2 ou 2016. Comme indiqué dans le tableau ci-dessus, les CAL RDS « 2008 et 2008 (R2) » peuvent être installées sur les OS Windows Server suivants : 2008, 2008 R2, 2012, 2012 R2 et 2016. Cette société pourra donc continuer à utiliser (en réinstallant) les Licences RDS 2008 R sur tout futur serveur de Licence RDS exécutant Windows Server 2008 à 2016.

#R2 : Liste des CAL TSE/RDS pouvant être utilisées pour autoriser vos utilisateurs RDS à se connecter sur un serveur RD Session Host

Le tableau ci-dessous vous montre les CAL TSE et RDS pouvant être installées/utilisées pour autoriser vos utilisateurs distants à se connecter aux serveurs TSE/RDSH en fonction de la version d’OS Windows Server qui exécutent :

Scott Manchester, RDS PPM (Principal Program Manager) vous explique les Upcoming Updates pour RDS (Securité, Cloud, MFA, Scalability …Etc)

Watch & Enjoy 🙂

Hello RDS Guys,

Je viens de créer un partage « OneDrive » dans lequel j’ai ajouté tous les scripts (développés par mes soins) liés au rôle RDS et au protocole RDP.

Ils sont accessibles en free download, à l’URL suivante :

https://1drv.ms/f/s!Agu0mgqr6F71pUWk4wK4fwu6H5_Q

Enjoy !

HK

Outils de Diagnostic
Outils de Diagnostic Natifs

La console de gestion « Service Bureau à distance » intégrée dans le Gestionnaire de Serveur inclut plusieurs outils de diagnostic et de monitoring, notamment :

  • Services: vous permet de manipuler les services RDS et visualiser leurs états.
  • Performances : vous permet de configurer des compteurs et alertes de performances liés aux différents composants de l’infrastructure RDS
  • BPA (Best Practice Analyzer) : vous permet de vérifier l’état de santé de l’infrastructure RDS
  • Observateurs d’évènements: vous permet de consulter les différents journaux liés aux différents composants de l’infrastructure RDS

Ces outils sont disponibles depuis le volet « Serveurs » depuis la console « Services Bureau à distance »

De plus, après déploiement du serveur RDSH, un outil de diagnostic de Licences RDS est installé et placé dans les outils d’Administration, celui-ci vous permet de visualiser les Licences RDS disponibles ainsi que de vérifier le bon fonctionnement du serveur de Licence RDS et sa disponibilité sur le réseau.

ToDo : Je vous recommande l’exécution du RDS Best Practice Analyzer (BPA) au moins une fois par mois pour vérifier l’état de santé de l’infrastructure RDS 2016 et ses différents composants.

L’outil BPA peut être lancé depuis le volet « Serveurs » sous « BEST PRACTIVE ANALYZER ».

Cliquez sur « TÂCHES » et sélectionnez « Commencer l’analyse BPA».

La boite de dialogue suivante apparaît, sélectionnez le(s) serveur(s) à analyser et cliquez sur « Rechercher » :

Après analyse, le BPA remonte les informations collectées depuis les différents services de rôles RDS et les affiche sous « BEST PRACTICE ANALYZER » :

RDS Diagnostic Tool

Microsoft met à votre disposition un outil gratuit de diagnostic d’une infrastructure RDS 2016 en mode Session et VDI.

Il s’agit de « Remote Desktop Diagnostic Tool », disponible en téléchargement gratuit à l’URL ci-après :

https://www.microsoft.com/en-us/download/details.aspx?id=40890

Il permet de diagnostiquer et vérifier l’état de santé de chaque composant et service de l’infrastructure RDS 2016.

Note : Cet outil est supporté uniquement sur Windows Server 2012, 2012 R2 et 2016. Il ne peut être exécuté sur les plateformes Windows Server 2008 et 2008 R2.

Certains prérequis liés à cet outil existent :

  • Exécution avec un compte utilisateur ayant des privilèges Administrateur
    • Compte Administrateur du domaine ou équivalent
  • Exécution sur un serveur Broker du déploiement RDS à diagnostiquer.
    • Si l’outil est exécuté sur un serveur autre que RDCB, aucune information n‘est collectée et remontée.

Services Windows utilisés par RDS

La solution RDS a besoin des trois services Windows suivant pour fonctionner correctement :

  • Services Bureau à distance (anciennement appelé Service Terminal Services
    • Nom du service : TermService
  • Configuration des Services Bureau à distance
    • Nom du service : SessionEnv
  • Redirecteur de port du mode utilisateur des Services Bureau à distance
    • Nom du service : UmRdpService

Si le Service « TermService » est arrêté, aucune connexion Bureau à distance n’est possible.

Le Service « SessionEnv » offre la possibilité d’apporter des modifications sur le déploiement RDS : création de Collection, modification de paramètres de Collection, ajout de nouveau serveur au déploiement …

Enfin, la redirection des ressources et périphériques locaux vers les sessions Bureau à distance est assuré par le service « UmRdpService », si ce dernier est arrêté, aucun périphérique ni ressource locale ne peut être redirigée vers la Session distante des utilisateurs RDS.

N’hésitez pas à arrêter ces services pour prendre connaissance des risques et impacts sur votre infrastructure RDS 2016.

D’autres sous-services liés à l’infrastructure RDS existent, il s’agit de :

Service de rôle Services Windows associés
Service Hôte de la Session (RDSH) TermService
Service Broker (RDCB) Tssdis
Service Passerelle RDS (RDG) TSGateway
Service de Licence RDS (RDLS) TermServLicensing
Service Accès Web (RDWA) Aucun service Windows associé

Ces services sont listés sur le Volet « Serveurs » de la console « Services Bureau à distance » intégrée dans le Gestionnaire de Serveur, il suffit de sélectionner un serveur ou plusieurs serveurs et visualiser le statut de leurs services Windows liés à RDS sous « Services », dans l’exemple suivant, tous les serveurs du déploiement sont sélectionnés :


Cet Article est un extrait de l’eBook RDS 2016 – Guide du Consultant [2ème Edition]. Bientôt disponible sur BecomeITExpert.com