[TSE & RDS Licensing] Matrice d’Interopérabilité : s’applique à Windows Server 2008 à 2019

J’avais publié dans le passé un post décrivant la matrice d’interopérabilité des Licences TSE/RDS Windows Server 2000 à 2016.

Note : le post est disponible directement depuis ce lien.

 

J’expliquais à travers cet article quand et comment pouvez-vous ré-utiliser vos Licences (CAL) TSE/RDS 2000 à 2016 sur les différentes plateformes Windows Server 2000 à 2016.

Aujourd’hui, je vais partager avec vous la nouvelle Matrice d’interopérabilité des Licences/CAL RDS à partir de 2012 à 2019.
Windows Server 2003 & 2008/2008 R2 étant Obsolètes, nous allons principalement nous focaliser sur les versions d’OS Server pouvant être utilisées en Production.

 

Comme vous le savez, Windows Server 2008 et 2008 R2 ne sont plus supportés depuis le 14 Janvier 2020. Consultez ce post pour en savoir plus.

 

Je vais plus précisément répondre aux questions suivantes :

• Puis-je réutiliser mes anciennes CAL 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 Hôtes de Session (RDSH) exécutant des versions Windows Server différentes ?

 

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és OnPrem mais aussi ceux qui tournent sous forme de VM IaaS Azure (ou AWS, GCP, AliBabaCloud…Etc)

 

#R1 : Compatibilité des CAL RDS avec les serveurs de Licences RDS (RD Licensing Server)

Le tableau ci-dessous vous montre les CAL 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) :

 

#R2 : Compatibilité des CAL RDS avec les serveurs Hôtes de Session RDS (RD Session Host Server)

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

Ce qu’il faut retenir

Vous ne pouvez pas utiliser vos anciennes CAL RDS pour accéder aux nouvelles versions de Windows Server (RD Session Server), mais vous pouvez utiliser des nouvelles CAL RDS pour accéder aux anciennes versions de Windows Server (RD Session Host). Les serveurs de licences RDS peuvent héberger toutes les CAL RDS ayant la même version de l’OS qu’il exécute ou ultérieur (eg : un RD Licensing Server 2016 peut héberger des CAL RDS 2016 et 2019).

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 2012 R2 et est sur le point de dé-commissionner son infrastructure RDS 2012 R2 pour en déployer une nouvelle sous 2016 ou 2019. Comme indiqué dans le tableau ci-dessus, les CAL « RDS 2012 R2 » peuvent être installées sur les OS Windows Server suivants : 2012, 2012 R2, 2016 et 2019. Cette société pourra donc continuer à utiliser (en réinstallant) les Licences RDS 2012 R2 sur tout futur serveur de Licence RDS exécutant Windows Server 2012 R2 à 2019.

Cette même société souhaite savoir s’elle peut réutiliser ses licences RDS 2012 R2 pour permettre l’accès à des hôtes de session RDSH 2016 ou 2019, comme indiqué dans le tableau ci-haut, les CAL RDS 2012 R2 ne permettent l’accès qu’à des RDSH Servers exécutant la même versions que les CAL ou antérieur, donc des hôtes de sessions sous Windows Server 2012 R2, 2012, 2008 R2 ou 2008.

 

Référence documentation

Pour en savoir plus sur le Licensing RDS et la compatibilité des CAL RDS entre les différentes versions d’OS Windows Server, je vous invite à consulter la documentation officielle Microsoft disponible directement depuis ce lien.

A bientôt, et soyez forts pendant cette crise sanitaire (covid-19), tout va rapidement rentrer dans l’ordre :).

#ProtegezVous #RestezVous #SoyezForts

 

[RDS – Tip Of The Week] HowTo : Transférer des fichiers volumineux (+2 GB) via RDP

Bonjour tout le monde,

Voici notre « RDS Tip of The Week » :

Comment transférer des fichiers/données de plus de 2GB via RDP

 

Description de la limitation /problème

Il existe une limitation relative au protocole RDP quand il s’agit de transférer des données/fichiers volumineux via une Session Bureau à distance.

Si vous avez déjà essayez de transférer des fichiers volumineux (+ 2 GB), le message d’erreur suivant vous est retourné (Error Copying File or Folder « Unspecified Error« ):

 

Solution (HowToFix)

Il existe deux techniques permettant de contourner ce problème :

• Transférer vos données via la « la Redirection de disque local » mappé directement sur votre Session Bureau à distance
• Transférer vos données via un Partage UNC (\\tsclient\C$)

 

Perso, j’utilise la redirection de mes disques locaux vers la Session Bureau à distance pour transférer des données volumineuses, par XP, je trouve que c’est plus stable & fiable.

Si votre infra RDS se trouve en Back-end derrière une Gateway RDS, tout le traffic RDP est encapsulé over HTTPS, il s’agit du même principe qu’un service STaaS (STorage-as-a–Service) tel que OneDrive ou Dropbox. Les protocoles de partages réseaux (eg : SMB/445 TCP) ne sont jamais exposés à Internet, tout le traffic passe à travers le canal HTTPS.

De plus, accéder à un \tsclient\c$ nécessite des privilèges « LocAdmin », si des utilisateurs standards doivent transférer des données via RDP, il suffit de configurer (autoriser) la Redirection de disque local sur la machine cible, aucun privilège « Admin » n’est requis, ils doivent simplement appartenir au groupe local « Remote Desktop Users » sur la machine cible.

Voyons comment ça marche.

Depuis la machine qui héberge les données/fichiers à transférer, lancez l’outil MSTSC.exe, depuis « Ressources locales« , > « Autres » > « Lecteurs » > cochez le lecteur/disque contenant vos données à transférer pour le rediriger vers la Session RDS (C: dans l’exemple suivant) :

Une fois connecté sur votre session Bureau à distance, ouvrez Windows Explorer (Drapeau+E) et vérifiez que votre ou vos lecteurs locaux ont bien été redirigés :

Enfin, cliquez sur votre lecteur redirigé et copiez/collez vos données sur le Windows Desktop de la session RDS (ou Documents..etc) :

Et voilà le tour est joué :).

A bientôt,

#HK

 

[RDS – Free Training] Lesson1 : Security Risks & Best Practices You Should Know

Introduction

RDP (Remote Desktop Protocol) est (par défaut) considéré comme un protocole vulnérable qui peut exposer votre infrastructure (voire tout votre S.I) à des risques assez importants, notamment :

• Brute-Force Attack
• DoS (Denial-of-Service) Attack
• Encryption Attack
• Man-in-The-Middle (MiTM) Attack
• …

 

Vous exposerez également votre S.I à un risque de sécurité si vous êtes consommateur (Cloud Consumer) d’une solution/Application Cloud hébergée sur une infrastructure RDS distante : Multi-tenancy Risk.

Plusieurs Cloud Providers proposant des applications SaaS (Software-as-a-Service) virtualisées et distribuées (RemoteApp) via des Portail RD Web Access personnalisés. Ces Apps sont souvent hébergées sur des infrastructures RDS « Partagées /Shared », cela veut dire que plusieurs clients, se connectent et consomment les mêmes Apps Cloud RDS depuis le même environnement. Pour des raisons de réduction de coût, plusieurs Cloud Providers déploient des RD Session Host en mode « Shared », et proposent rarement des infrastructures RDS dédiées (Collections de Session RDS dédiées par client/app).

Malheureusement la plupart des clients ne pensent pas à poser la question et se contentent de signer un contrat désignant les responsabilités de chacun (SLA) : en mode SaaS vous êtes uniquement responsable de vos données, les couches infra/storage/middleware sont gérées par le CP, seul ce dernier est responsable de la gestion, maintenance, patching… de l’environnement Cloud.

En revanche, vous avez la responsabilité de s’assurer du niveau de sécurité offert à travers ces applis Cloud qui souvent font parties de votre IT globale car les devices clients depuis lesquels vos users se connectent sont souvent intégrés dans votre AD local et connectés au niveau de votre Coporate Network.

 

Guide de Sécurité RDS : Liste des Risques, Menaces et Bonnes Pratiques que vous connaître 

Je viens de publier sur Slideshare un Guide de sécurité RDS assez complet (en Anglais) traitant ce sujet.

Il décrit et détaille toutes les Security Risks, menaces ainsi que les bonnes pratiques que vous devez prendre en considération lors de la phase « Design » de tout projet RDS (de 2008 R2 à 2019).

Il vous liste également les Risks/Menaces liées à des infrastructures RDS Offsites (hébergées chez un Cloud Provider), si vous êtes Cloud Customer d’une ou plusieurs Apps Cloud, vous pouvez toujours challenger l’éditeur/Cloud Provider en posant les questions listées dans ce Slide.

Le document est disponible sur SlideShare, à cet URL.

Vous pouvez aussi le visualiser directement depuis ce post, voir Slide ci-dessous :

[RDS /Remote Desktop Services] Lesson 1 : Security Risks & Best Practices You Should Know from ☁ Hicham KADIRI ☁

Si vous souhaitez être accompagné, n’hésitez pas à me Ping via MP pour planifier un call et discuter plus en détail de votre projet.

Bonne lecture à tous,

#HK

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

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 :

• Télécharger Remote Desktop pour Mac OS X
• Télécharger Remote Desktop pour Android
• Télécharger Remote Desktop pour iOS

 

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

HowTo : Personnaliser le lien « Aide » du Portail RD Web Access 2012, 2012 R2 et 2016

 

Une question intéressante m’a été posée récemment par un de mes clients :

Est-il possible de modifier le lien du bouton « Aide » du Portail RD Web Access ?

Eh bien, la réponse est Oui 🙂

Vous pouvez presque tout modifier sur le Portail RD Web Access 2012, 2012 R2 mais aussi 2016.

What is The default Link déjà ?

Notez que par défaut, le lien programmé sur le bouton « Aide » est le suivant :

http://go.microsoft.com/fwlink/?LinkId=141038

Cette URL renvoie simplement vers une KB OnLine décrivant les RemoteApps et leur fonctionnement depuis le Portail RD Web Access, le lien de redirection est le suivant :

https://technet.microsoft.com/en-us/library/ff608240(WS.10).aspx?ocid=fwlink

Le besoin de mon client était de remplacer ce lien par l’URL de sa plateforme de Ticketing /Support (GLPI).

Solution ?

Le lien « Aide » a d’abord été renommé en « Support », cela permettra aux End Users rencontrant des problèmes (utilisation, fonctionnement) sur le Portail RD Web Access d’avoir un lien unique pour la création de ticket de support.

Maintenant, pour changer l’Hyperlink du bouton « Support » et spécifier une URL personnalisée, suivez les instructions suivants :

Note importante : je vous recommande de sauvegarder le dossier C:\Windows\Web\RDWeb avant d’apporter toute modification aux fichiers de configuration du Portail RD Web. Donc commencez par faire une copie /sauvegarde de ce dossier avant d’appliquer la procédure décrite ci-dessous :

• Ouvrez une Session Windows sur le serveur RD Web Access et naviguez jusqu’au : C:\Windows\Web\RDWeb\Pages\fr-FR (ou C:\Windows\Web\RDWeb\Pages\en-US si votre OS Server est en EN’glais)
• Editez le fichier Login.aspx (de préférence à l’aide de Notepad++)
• Allez à la ligne N° 91 (sHelpSourceServer = ….) et remplacez l’URL http://go.microsoft.com/fwlink….. par votre URL.

• Dans l’exemple suivant, l’URL http://glpi.BecomeITExpert.com sera spécifiée. Enregistrez la modification (File > Save) et fermez le fichier Login.aspx
• Reconnectez-vous sur le portail RD Web Access et cliquez sur le Lien « Aide » (Support dans l’exemple suivant), et constatez la redirection vers l’URL spécifiée :

That’s All :).

J’espère que cette astuce pourra vous être utile.

D’autres RDS Tips & Tricks arrivent prochainement, so stay in touch

HK | Just Another IT Guy | Twitter | LinkedIn

[RDS 2012 R2 et 2016 – Script Resources] Déployer, Créer et Gérer RDS 2016 via Scripts PowerShell

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

[RDS Troubleshooting] Dépannez votre infrastructure RDS (Remote Desktop Services) 2016

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

 

[RDS Windows Server 2016] Pensez à déployer vos Services/Serveurs RDS en mode « Core »

 

S’applique à : RDS Windows Server 2012, RDS Windows Server 2012 R2 et RDS Windows Server 2016

Introduction

Pour réduire la surface d’attaque sur certains rôles/serveurs RDS, il est fortement recommandé de les déployer sur une infrastructure Windows Server en mode « Core » plutôt qu’en mode « GUI ». Cela vous permet aussi de réduire vos efforts en terme de maintien et exploitabilité de la plateforme (moins d’Updates, moins de config post-déploiement…).

 

Services de rôles RDS pris en charge par Windows Server Core 2016

Le tableau ci-dessous, liste les différents services RDS pouvant être déployés/pris en charge sur un Windows Server 2012, 2012 R2 et 2016 en mode Core:

Service de rôle RDS	Supporté sur Server Core
RDCB
RDLS
RDSH
RDVH
RDWA
RDG

pris en charge

non pris en charge

 

En outre, Windows Server 2016 « Core » prend en charge tous les agents (graphiques) de Monitoring, Antivirus, Sauvegarde ou encore Sécurité (Encryption de Disk /Files). Vous pouvez donc continuer à inclure vos serveurs RDS en mode Core dans le périmètre de vos solutions d’infrastructures existantes, et ce sans aucun impact.

Pensez donc à privilégier l’utilisation du more « Core » pour vos serveurs Brokers (RDCB) et de Licences (RDLS).

Note importante : depuis Windows Server 2016, il n’est plus possible de Switcher entre les modes « GUI » et « Core ». Vous devez donc déployer vos serveurs RDS en mode Core « From Scratch ». Les serveurs RDS 2016 (existants) qui sont déjà en mode « Graphique » ne peuvent malheureusement être transformés en mode « Core » comme c’était le cas avec Windows Server 2012 et 2012 R2.

Gérer vos serveurs RDS Core à distance

Les serveurs RDS (RDCB et RDLS) exécutant Windows Server 2016 en mode Core peuvent être gérés à distance depuis n’importe quelle machine d’administration ayant les outils RSAT installés. Cela pourrait être une machine cliente (Windows 7, 8/8.1 ou encore Windows 10) ou un serveur d’administration (Windows Server 2008/2008, 2012 /2012 R2 ou encore 2016).

Depuis un Serveur d’Administration

Depuis Windows Server (2008 R2 ou ultérieur), lancez Windows PowerShell et saisissez la commande suivante :

Get-WindowsFeature RSATRDS* | FT –AutoSize

Les outils RSAT dédiés pour la gestion des services de rôles RDS sont retournés

L’outil (Snap-in) RSAT-RDS-Licensing-Diagnosis-UI correspondant à « Outils de diagnostic des licences des services Bureau à distance » vous permet de gérer et diagnostiquer les services de licence RDS à distance.

Quant à l’outil « Gestionnaire de Licence des Services Bureau à distance« , celui-ci vous permettra d’activer votre serveur de Licence RDS, installer, gérer et migrer vos CAL RDS.

Depuis une machine cliente d’Administration

Il est également possible de gérer votre déploiement RDS depuis une machine cliente (Windows 7 ou ultérieur) ayant les outils RSAT installés.

En effet, ces derniers incluent l’outil « Server Manager » qui vous permet de regrouper vos serveurs RDS de déploiement dans le même pool de serveurs et gérer ainsi votre déploiement depuis le volet « Services Bureau à distance ».

Vous trouverez ci-après les liens de téléchargements des outils RSAT pour les clients Win7 > Win10:

Outils RSAT pour Windows 10

Outils RSAT pour Windows 8.1

Outils RSAT pour Windows 7

 

A bientôt,

Comprendre et utiliser le mode « Remote Credential Guard »

S’applique à : Windows 10 et Windows Server 2016

Remote Credential Guard, qu’est-ce que c’est ?

Le géant américain a lancé l’année dernière le « Credential Guard », une fonctionnalité de sécurité native dans Windows 10 Enterprise et Windows Server 2016. Credential Guard aide à empêcher le vol d’informations d’identification et permet de réduire l’efficacité des attaques Kerberos telles que Overpass-The-Hash et Pass-the-Ticket.

Récemment, avec la publication de la mise à jour « Anniversaire » Windows 10, Microsoft a annoncé la disponibilité du « Remote Credential Guard », une nouvelle fonctionnalité de sécurité qui vise elle aussi à protéger les informations d’identification sur les connexions Bureau à distance en générant des tickets de service nécessaires à partir de la machine source au lieu de copier les informations d’authentification (Haches et TGT) vers la machine cible.

Notez que Remote Credential Guard a été introduite sur Windows 10 version 1607.

Cette fonctionnalité peut être considérée comme le successeur /remplaçant du mode « Restricted Admin ».
En effet, les deux fonctionnalités s’activent et fonctionnent de la même manière, la seule différence réside dans le fait que le Remote Credential Guard ne limite pas l’accès aux autres ressources du réseau en redirigeant de nouveau toutes les demandes d’identifications vers la machine cliente du réseau.

Si vous voulez en savoir plus sur le mode « Restricted Admin », je vous invite à consulter cet article.

Enfin, un article détaillé sur le « Remote Credential Guard » a été rédigé et publié par CyberArk, je vous invite à consulter pour en savoir plus sur cette nouvelle fonctionnalité :
https://www.cyberark.com/blog/no-pass-hash-exploring-limitations-remote-credential-guard/

Prérequis

La fonctionnalité « Remote Credential Guard » est prise en charge par les OS suivants uniquement :

• OS Server : Windows Server 2016
• OS Client : Windows 10 (Entreprise)

Vous pouvez donc l’implémenter uniquement pour sécuriser des Connexions Bureau à distance établies depuis et vers les OS cités ci-dessus.

HowTo : Activer ou Désactiver le mode « Remote Credential Guard »

Le mode « Remote Credential Guard » est désactivé par défaut.

Il s’active de la même manière que le mode « Restricted Admin », il suffit donc de créer /ajouter la clé de Registre suivante sur vos machines cibles :

Chemin: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Valeur DWORD (32-bits) : DisableRestrictedAdmin

Données de la valeur : 0

Note importante : Cette clé de Registre peut également être crée en exécutant la commande suivante (depuis CMD.exe lancée en tant qu’Admin) :

Reg.exe Add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V DisableRestrictedAdmin /D 0 /T REG_DWORD

Utiliser le mode « Remote Credential Guard »

Une fois activé, le mode « Remote Credential Guard » doit être forcé sur l’ensemble des machines du réseau (cibles) sur lesquelles vous vous connectez via Bureau à distance.

Cette configuration peut être effectuée d’une manière centralisée sur un ensemble de serveurs /postes de travail via GPO, et ce via l’utilisation du paramètre de Stratégie de groupe suivant :

Chemin : Configuration Ordinateur | Stratégies | Modèles d’administration | Système | Délégation d’informations d’identification

Paramètre : Limiter la délégation d’informations d’identification à des serveurs distants

Valeur du paramètre : Activé

Mode restreint : Requérir Credential Guard à distance

Le mode « Remote Credential Guard » ou « Credential Guard à distance » est représenté par un paramètre de l’outil MSTSC.exe et plus précisément le paramètre /remoteGuard, lancez MSTSC /? depuis l’invite de commande (CMD.exe) ou le Menu Démarrer et constatez la disponibilité du mode « /remoteGuard » :

Dans l’exemple suivant, nous allons établir une Connexion Bureau à distance en mode « remoteGuard » sur le serveur distant « LABRDS01 » :

---

Ceci est un extrait de l’eBook « RDS 2016 – Securisation et Hardening [2ème Edition] »

Remote Desktop Services [RDS] Windows Server 2016 – What’s New

RDS (Remote Desktop Services) Windows Server 2016 apporte un lot conséquent de nouveautés et d’améliorations qui répondent à plusieurs problématiques et besoins clients en matière de Virtualisation d’Apps et Postes de travail, notamment :

Compatibilité d’Apps [Windows Server 2016 et Windows 10]

Conçu et développé sur la même base de Windows 10, Windows Server 2016 présente le même look et expérience utilisateur que ce dernier. En outre, plusieurs mêmes Applications  sont fournies par défaut sur les deux OS Client et Server. Ce qui permet aux utilisateurs distants de retrouver « presque » le même environnement /espace de travail sur le serveur Bureau à distance.

Azure SQL Database pour la mise en HA de votre service RDCB

Parmi les « Big » News de RDS 2016 est la prise en charge du service Azure SQL pour la mise en haute disponibilité du service Broker (RDCB : Remote Desktop Connection Broker).

Vous pouvez désormais « Bypasser » le déploiement d’une infrastructure SQL OnPrem complexe et envisagez un scénario « Hybride » en utilisant Azure SQL.

En hébergeant la base de données RDS HA sur Azure SQL, vous bénéficiez de la puissance du Cloud Microsoft tout en réduisant le coût de votre projet RDS 2016.

Pour en savoir plus, consultez l’article suivant :

https://blogs.technet.microsoft.com/enterprisemobility/2016/05/03/new-windows-server-2016-capability-use-azure-sql-db-for-your-remote-desktop-connection-broker-high-availability-environment/

MultiPoint Services

Il s’agit d’un nouveau rôle, désormais natif dans Windows Server 2016.

Le rôle MultiPoint Services a pour but de permettre à des postes clients économiques et à des clients légers de se connecter à un serveur via USB ou via Ethernet pour proposer à plusieurs utilisateurs des sessions individualisées sur un même serveur. L’idée est de fournir un bureau Windows 10 à de multiples utilisateurs sur un seul et même serveur Windows.

L’ancienne solution Windows MultiPoint Server, la version multi-utilisateurs de Windows, disparaît donc avec Windows Server 2016 pour devenir qu’un simple rôle natif du nouvel OS Server.

Notez que le service de rôle RDSH (Hôte de Session Bureau à distance) est installé automatiquement avec l’installation du rôle MultiPoint Services.

Enfin, MPS peut être installé via l’option « Installation des Services Bureau à distance »

Nouvelles Cmd-Lets PowerShell

6 nouvelles Cmd-Lets ont été ajoutées au Module PowerShell « RemoteDesktop », voir la liste ci-après:

Export-RDPersonalSessionDesktopAssignment

Get-RDPersonalSessionDesktopAssignment

Import-RDPersonalSessionDesktopAssignment

Remove-RDDatabaseConnectionString

Remove-RDPersonalSessionDesktopAssignment

Set-RDPersonalSessionDesktopAssignment

Nouveau mode « Personal Desktop Session »

Un nouveau mode de déploiement a été introduit avec RDS 2016 : Personal Desktop Session.

Ce nouveau mode de déploiement RDS combine les deux modes de déploiement disponibles avec RDS 2012 /2012 R2 (Déploiement basé sur une Session & VM), ce qui veut dire qu’avec un déploiement RDS 2016 en mode Personal Session Desktops (ou Server Based Personal Desktop), vous pouvez mettre en place une infrastructure VDI sans utilisation d’OS Client :).
Le principe est simple, chaque utilisateur distant disposera d’un Serveur Hôte de Session dédié, ce dernier fera office d’un poste de travail virtuel comme dans une infrastructure VDI classique.

Je vous invite à consulter les deux articles suivants pour en savoir plus:

https://hichamkadiri.wordpress.com/2016/05/26/part1-nouveau-mode-de-deploiement-sous-rds-2016-personal-session-desktops-part1/

https://hichamkadiri.wordpress.com/2016/05/30/part2-nouveau-mode-de-deploiement-sous-rds-2016-personal-session-desktops/

Prise en charge des Apps OpenGL par RemoteFX vGPU

Avec RDS 2016, RemoteFX vGPU prend désormais en charge les Applications OpenGL.

Les clients qui utilisent des applications graphiques nécessitant des capacités de mémoire vidéo élevées peuvent désormais virtualiser leurs Apps sur un environnement RDS sous Windows Server 2016.

Consultez l’article suivant pour en savoir plus :
https://blogs.technet.microsoft.com/enterprisemobility/2014/11/05/remotefx-vgpu-updates-in-windows-server-next/

Nouvelles capacités et améliorations du service Broker

La gestion de connexions Bureau à distance par le service RDCB a été amélioré d’une manière considérable. En effet, un serveur Broker peut désormais gérer jusqu’à 10.000 demandes de connexions simultanées.

En savoir plus : https://blogs.technet.microsoft.com/enterprisemobility/2015/12/15/improved-remote-desktop-connection-broker-performance-with-windows-server-2016-and-windows-server-2012-r2-hotfix-kb3091411/ 

Prise en charge de Microsoft Edge & Office 2016

Le nouveau navigateur Web de Microsoft « Edge » est pris en charge dans un environnement RDS 2016 et peut être publié (sur un serveur RDSH) et distribué comme n’importe quel Programme RemoteApp aux utilisateurs distants. C’est le cas aussi pour la suite Microsoft Office 2016. Une version prenant en charge les services Bureau à distance 2016 est désormais disponible dans le store /plateforme MSDN.

Prise en charge des « VMs Génération 2 »

Vous pouvez désormais utiliser des VMs Génération 2 comme des « Images Templates » pour créer des Pools de VMs ou VM Personal au sein de votre infrastructure RDS VDI 2016.

Aucune configuration supplémentaire n’est requise.

Just deploy and enjoy :).

Nouvelle version du protocole RDP

La version 10 du protocole RDP utilise désormais le codec H.264/AVC 444, ce qui permet une optimisation maximale des vidéos et texte sur un environnement Bureau à distance.

Pour en savoir plus sur ces améliorations, je vous invite à consulter le lien ci-après :

https://blogs.technet.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview/

RDP Planning Poster

L’équipe Remote Desktop Services a publié un nouveau Poster qui vous aidera à préparer, concevoir et déployer votre infrastructure RDS sous Windows Server 2016.

Voir la Big-Picture ci-après :

 

Ce Poster est téléchargeable gratuitement ici.