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

 

S’applique à : RDS Windows Server 2016 et RDS Windows Server 2019

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 et 2019

Le tableau ci-dessous, liste les différents services RDS pouvant être déployés/pris en charge sur un Windows Server 2016 et 2019 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 2019 « 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 et 2019 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 2012 /2012 R2, 2016 ou encore 2019).

Depuis un Serveur d’Administration

Depuis une Session Windows Server (2012 ou ultérieur), lancez Windows PowerShell en tant qu’Administrateur 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

 

Enjoy :).

[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

 

Microsoft LAPS : Introduction au module PowerShell « AdmPwd.PS »

 

La configuration de la solution LAPS est réalisée via PowerShell (PowerShell V2 minimum), cette solution possède un module dédié nommé « AdmPwd.PS ». Ce module s’installe avec LAPS en sélectionnant l’option « PowerShell Module ». Avant l’installation et le déploiement de la solution il est préférable de se familiariser avec ce module.

Avant chaque opération LAPS via PowerShell, vous devez d’abord importer le module PowerShell « AdmPwd.PS » en exécutant l’une des deux commandes suivantes :

Ci-dessous vous trouverez la liste des Cmd-Lets inclus dans le module PowerShell.

Import-Module AdmPwd.PS IpMo AdmPwd.PS

Vous pouvez ensuite exécuter la commande suivante pour obtenir la liste complète des Cmd-lets fournis avec le module LAPS PS « AdmPwd.PS » :

Get-Command -Module AdmPwd.PS

Comme illustré dans la capture d’écran ci-dessous, le module « AdmPwd.PS » dispose de plusieurs Cmd-lets, celles-ci sont détaillées dans le tableau ci-dessous :

Cmd-Let /Explication

Find-AdmPwdExtendedRights Permet d’obtenir les groupes /comptes par OU ayant la permission de consulter les mots de passe.

Get-AdmPwdPassword Permet d’obtenir le mot de passe d’une machine.

Reset-AdmPwdPassword Permet de modifier la date d’expiration du mot de passe.

Set-AdmPwdAuditing Permet d’activer l’audit d’accès au mot de passe d’une machine. Créer l’événement 4662 sera consigné dans le journal des événements de sécurité des contrôleurs de domaine.

Set-AdmPwdComputerSelfPermission Permet de créer sur les OU dans Active Directory les délégations de contrôles pour les comptes ordinateurs. Ceux-ci peuvent modifier les attributs LAPS afin de renseigner le mot de passe.

Set-AdmPwdReadPasswordPermission Permet de créer sur les OU dans Active Directory les délégations de contrôles pour les groupes/utilisateurs. Ceux-ci peuvent afficher le mot de passe.

Set-AdmPwdResetPasswordPermission Permet de créer sur les OU dans Active Directory les délégations de contrôles pour les groupes /utilisateurs. Ceux-ci peuvent modifier la date d’expiration afin d forcer le changement du mot de passe.

Update-AdmPwdADSchema Permet de modifier le schéma AD en ajoutant les objets de type ordinateur les attributs suivants : ms-MCS-AdmPwd ms-Mcs-AdmPwdExpirationTime

 

Ceci est un extrait de l’eBook « Microsoft LAPS – Déploiement et Configuration en Entreprise« .

L’eBook est disponible ici.

N’hésitez pas à consulter la table des matières pour en savoir plus.

 

#HK

L’App « Windows Terminal » est désormais disponible en téléchargement depuis Windows Store

Microsoft a dévoilé pour la première fois sa nouvelle « Command Line Desktop App » pour Windows baptisée « Windows Terminal » au Microsoft Build 2019. L’équipe Windows avait annoncé qu’il s’agit d’une App Open source qui offre un emplacement central où les Développeurs/Scripteurs peuvent accéder à la ligne de commande traditionnelle, tels que la Command Prompt, Windows PowerShell, PowerShell Core ou encore au sous-système Windows pour Linux (WSL : Windows SubSytem for Linux), en version 1 mais aussi WSLv2.

Quelques améliorations verront le jour pour le nouveau Terminal Windows, notamment :

• Prise en charge de plusieurs onglets (Multiple Tabs)
• Moteur de rendu « Text » basé sur DirectWrite / DirectX accéléré par le GPU
• Paramètres de configuration avancés

 

Bien que les développeurs pouvaient compiler et utiliser Windows Terminal à partir du code disponible sur GitHub, Microsoft propose désormais un « Installer » via son Windows Store.

 

Télécharger Terminal Windows App

La nouvelle App « Windows Terminal » pour Windows 10 peut être téléchargée depuis l’URL suivante :

https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701

Vous serez automatiquement redirigé vers Windows Store pour télécharger l’App :

Une fois installée, cliquez sur « Lancer » pour démarrer une nouvelle instance Windows Terminal :

Notez qu’il existe tout de même certains prérequis, notamment la version de Windows 10 sur lequel vous souhaitez installer le nouveau Windows Terminal.

Pensez à Updater votre OS avant l’install de cette nouvelle App.

 

Lancement de Windows Terminal (Preview)

Une fois installée, la nouvelle (Preview) App « Windows Terminal » est accessible depuis Windows Store ou le Menu Démarré de votre machine Windows 10

Exécutez la nouvelle App Windows Terminal and Enjoy 🙂

Personnalisez l’interface « Windows Terminal »

Windows Terminal est fourni avec plusieurs thèmes et permet une personnalisation complète de l’interface.

La personnalisation consiste à modifier un fichier JSON (profiles.json) pour accéder à toutes les options de personnalisation (e.g : modification l’image d’arrière-plan…etc)

Microsoft fournit quelques instructions intéressantes concernant la partie personnalisation du Windows Terminal, je vous invite à consulter ce post pour en savoir plus.

 

Ce qu’il faut retenir

L’App Windows Terminal pour Windows 10 est encore en « Preview », Microsoft promet plusieurs améliorations/introduction de New Features, donc restez connectés et suivez les évolutions depuis la Page GitHub dédiée à Windows Terminal mais aussi et surtout depuis le DevBlog Windows 

 

Windows Terminal in Action 

Je vous invite à regarder la Vidéo Demo ci-dessous, réalisée par l’équipe « Microsoft Windows Developper »:

 

Participez à l’évolution/amélioration du nouveau Windows Terminal, Partagez votre Feedback !

N’hésitez pas à partager votre avis/feedback avec l’équipe Windows Developper ainsi que la communauté MS pour participer à l’évolution/amélioration de cette powerful App.

Vous pouvez contribuer depuis le repo GitHub dédié au nouveau Windows Terminal > Onglet « Issues » voir URL suivante :

https://github.com/Microsoft/Terminal

[New eBook] MDT 8450 – Présentation et Mise en place [Volume 2]

A propos de cet eBook

Le volume 2 de l’eBook MDT 8450 vous permet d’approfondir certaines fonctionnalités MDT comme le déploiement d’application et la personnalisation de l’OSD.

On y verra également comment déployer des correctifs avec WSUS pendant le déploiement d’un poste de travail.

Le déploiement de MDT sur plusieurs sites est également abordé.

 

Publics concernés par cet eBook

Ce guide pas à pas peut intéresser plusieurs populations IT :

• Architecte Poste de travail
• Ingénieur /Consultant Poste de travail
• Administrateur Systèmes /Packageur
• Technicien Systèmes /Réseaux /Applicatif
• Toutes personnes désirant se former sur l’outil MDT

 

Enfin, cet eBook est organisé en 5 chapitres, n’hésitez pas à consulter la table des matières pour avoir plus de détail sur les sujets abordé.

L’eBook est disponible sur BecomeITexpert.com, cliquez sur l’image ci-après pour en savoir plus :

Très bon eBook de Nicolas BONNET | Microsoft MVP sur Enterprise Mobility.

Bonne lecture à tous :).

A bientôt,

#HK

[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

 

[Azure VM Guest OS – What’s New] Disponibilité Générale (GA) de Windows Server 2019 pour Azure VM

Microsoft a annoncé aujourd’hui la disponibilité générale (GA : General Availability) de Windows Server 2019 en tant que « Guest OS » pour son offre IaaS (Infrastructure-as-a–Service) : Azure Virtual Machine.

Windows Server 2019 pour Azure VM fait désormais parti de la famille 6 des Guest OS disponibles depuis le Azure Marketplace.

Consultez ce post pour en savoir plus !

 

Petit Reminder sur les familles de Guest OS pour Azure VM

Il existe aujourd’hui 5 principales Famille de Guest OS pour vos VMs Azure (Numérotation commence à 2) :

Famille 6

Windows Server 2019

Famille 5

Windows Server 2016

Famille 4

Windows Server 2012 R2

Famille 3

Windows Server 2012

Famille 2

Windows Server 2008 R2 SP1

 

Je vous invite à consulter cet article pour plus d’informations sur chaque Family Release.

#HK

Les Rôles, Services de rôles et Fonctionnalités modifiées sous Windows Server 2019

 

Plusieurs modifications ont été apportées aux rôles, services de rôles et fonctionnalités de Windows Server 2019.

Avant la sortie officielle de Windows Server 2019 (le 02 Octobre 2018), l’équipe Windows Server Corp a mis à jour la liste des rôles/service de rôles et fonctionnalités ayant été modifiés par rapport à Windows Server 2016.

Cette liste (complète) est disponible à cet URL.

Je vais vous lister quelques « Major Changes » à travers cet article.

Nouveaux Rôles 

Pas de nouveaux rôles !

Nouveaux Services de Rôles

Pas de nouveaux services de rôle !

Rôles Supprimés

Les deux rôles suivants ont été supprimés de Windows Server 2019 :

MultiPoint Services

Expérience Windows Server Essentials 

 

Services de Rôles supprimés

Seul le service de rôle suivant a été supprimé (Fonctionnalité de Scan Management). Il a été introduit avec WS Server 2008 R2, mais n’a pas connu beaucoup de succès, de plus pas beaucoup de devices sont compatibles avec cette Windows Feature, MS a donc décidé d’arrêter le développement de ce service de rôle.

Serveur de numérisation distribuée

 

Fonctionnalités Modifiées

Les deux fonctionnalités Windows Server suivantes ont été modifées suite à l’évolution de version :

ASP.NET 4.7 au lieu de ASP.NET 4.6

Extensibilité .NET 4.7 au lieu de Extensibilité .NET 4.6

 

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

[Remote Desktop Services sous Windows Server 2019] What’s New ?

Printf « Hello RDS Guys ^__^ »

Comme vous le savez, Windows Server 2019 est disponible (GA > Generally Available) depuis début Octobre.

Note : consultez cet article pour en savoir plus

Plusieurs améliorations ont été apportées au rôle R(remote) D(esktop) S(ervices) sous Windows Server 2019, cela concerne la partie Server (RD Servers), End-User (Experience Utilisateur) mais aussi la partie intégration avec le Cloud (Azure bien évidemment :)).

Je vous présenterai donc à travers cet article toutes les nouveautés introduites avec RDS Windows Server 2019 et ce qu’il faut retenir pour vos prochains projets de migration vers RDS 2019.

 

Les « Areas » de développement

L’équipe RDS Corp a focalisé sur efforts sur les axes de développement suivants :

• Simplifier la gestion d’une infrastructure RDS
• Améliorer l’expérience utilisateur
• Améliorer la sécurité des environnements RDS
• Faciliter l’intégration d’une infra RDS avec le Cloud (Azure)

 

Gestion simplifiée d’une infrastructure RDS

Deux améliorations majeures à noter :

• La première concerne le service RDLS (Remote Desktop Licensing Server)
• La deuxième est relative aux applications publiées (RemoteApp) jugées comme « Slow RemoteApp Experience« 

RD Licensing Server : HA & Mode Offline Active Directory

Enfinnnnnnnn du HA pour le RDLS :xD

Avec RDS 2019, vous pouvez désormais configurer le service RD Licensing dans un vrai mode « HA : High Availability ».

Avec les versions RDS 2016, 2012 R2 ou encore 2012, la seule possibilité permettant la redondance du service RDLS consistait à déployer deux serveurs RDLS (ou +) et y installer la même quantité de CAL pour permettre une continuité de service en cas de perte d’un des deux serveurs.

Avec RDS 2019, il est désormais possible de configurer le service de Licensing RDS en mode HA avec une Built-in Feature, similaire à celle du Broker. Vous aurez donc besoin d’une instance SQL pour héberger la base de données RDLS-HA qui stockera la configuration de la haute disponibilité du service RDLS.

En outre, une nouvelle amélioration pour le service RDLS a été introduite avec Windows Server 2019, il s’agit de la prise en charge d’un Mode « Offline Active Directory« .

Je m’explique :

Sur les anciennes versions RDS (2016 et antérieur), le rôle RDLS avait toujours besoin d’accéder aux services d’annuaires Active Directory (ADDS) et plus précisément d’une connectivité avec un Domain Controller pour mettre à jour certains attributs AD avec les informations relatives aux Licences Utilisateurs (CAL RDS Per-User), avec RDS 2019 cela n’est plus nécessaire. En effet, un RDLS supporte désormais un mode « AD Offline » et peux mettre à jour les informations de Licensing d’un user RDS sur ses propriétés AD sans avoir besoin de contacter un DC.

Nouvelle API PerfMon pour les « Slow RemoteApp »

Des nouveaux compteurs de performances ont été ajoutés pour RDS 2019 à travers une nouvelle PerfMon API (Application Programming Interface). Ces compteurs vous aideront à collecter les données/informations (metrics et autres) liées aux RemoteApp présentant des problèmes de stabilité et de performance pour diagnostiquer et améliorer l’expérience utilisateur.

 

Expérience Utilisateur améliorée

Toujours dans un souci d’amélioration de l’expérience utilisateur, Microsoft a bien travaillé la partie End-User Experience pour les environnements RDS 2019, résultats :

• Ajout de Notifications « Modernes » sur les Sessions Bureau à distance et plus précisément au niveau du « Centre de Notifications », le but étant d’améliorer l’utilisation des RemoteApp telles que Microsoft Outlook ou encore Teams.
• La redirection des « Caméras » intégrées ou externes (USB) vers une Session RDS est désormais possible : Vous pouvez rediriger jusqu’à 8 Caméras sur une Session Bureau à distance :

• Des nouvelles améliorations ont été apportées au niveau du DDA (Discrete Device Assignment) sous RDS 2019 pour augmenter le niveau de sécurité et assurer une meilleure isolation des VMs. Ces améliorations des technologies de virtualisation des GPU se traduiront par une réduction du trafic réseau et une lecture vidéo plus fluide.

• Enfin, l’utilisation du CPU et la Bande Passante sur le client Web et Serveur RDSH ont été réduites, cela permet une meilleure expérience des utilisateurs se connectant via le nouveau Client Web.

 

Plus de sécurité avec RDS 2019

L’équipe produit RDS a également concentré ses efforts sur l’aspect « Sécurité ».

La sécurité RDS a été amélioré à travers :

• L’Intégration avec « Windows Admin Center » : cela vous permet de regrouper tous les serveurs Remote Desktop locaux et distants (RD Broker, Web Access…) en une seule console et les gérer de manière centralisée
• L’Optimisation de Windows Defender pour prise en charge du Multi-Session et une meilleure sécurité des environnements Bureau à distance
• Le RD Web Client prend désormais en charge le SSO (Single Sign-On) pour simplifier le processus d’authentification et rendre l’expérience utilisateur meilleure pour les clients se connectant via le Client Web
• De nouvelles fonctionnalités de sécurité comme par exemple le chiffrement DTLS (Datagram Transport Layer Security) qui peut être activé facilement pour renforcer la sécurité au niveau de vos déploiements RDS.

 

RDS 2019 & Microsoft Azure

La vision de Microsoft depuis la sortie de Windows Server 2016 déjà, était de pousser ses clients à déployer RDS dans Azure.

En effet, avec RDS 2016, vous aviez déjà la possibilité de configurer le service Broker en mode HA en utilisant l’offre PaaS (Platform-as-a–Service) Azure qu’est Azure SQL Database.

L’utilisation du Cloud Azure offre plusieurs avantages par rapport à un hébergement traditionnel (dans un Datacenter OnPrem > sur du VMware vSphere ou Hyper-V Server) :

• Réduction des coûts : en utilisant le Cloud Azure, vous passez généralement du mode CAPEX (investissement dans le matériel & logiciel) au mode OPEX (consommation). Avec Azure, vous êtes généralement dans un mode « Pay-as-you-go », cela veut dire que vous payez uniquement les ressources Azure (Compute/VM, Stockage, Réseau…) quand celles-ci sont utilisées (eg : je consomme mes services RDS uniquement du Lundi au Vendredi de 8h à 18h).
• Tirer profit de la puissance de calcul du Cloud, de la scalabilité, flexibilité et agilité
  • Eg : vous pouvez configurer vos VM avec du scaling-out & down pour que vos serveurs RDS peuvent monter en charge (de manière automatique) quand des pics d’activité se présentent et redescendre à leur configuration initiale quand une baisse de charge a lieu. Dans un mode traditionnel, vous devez rajouter de la RAM, vCPU voire acheter un nouveau matériel (serveur, changer le type de la carte réseau…etc)
• Réduction MCO/Effort de gestion : Azure étant une plateforme de Cloud Publique, toute l’infrastructure physique Serveur/Storage/Network est gérée et maintenue par l’éditeur (MS), vous n’avez donc plus à vous soucier des pannes matérielles, maintenances à planifier …Etc
• …

Pour faciliter l’adoption du Cloud Azure, Microsoft a introduit un mode « RDS Hybride ». En effet, l’infrastructure RDS 2019 peut désormais être déployée en mode « Hybride », mode dans lequel les serveurs RD Connection Broker, Web Access et Gateway sont hébergés dans Azure et les Hôtes de Session hébergés dans votre Datacenter local.

 

Prise en charge  {Azure Key Vault} & {Azure SQL Database}

Une des améliorations majeure quant au déploiement du rôle RDS dans Azure est l’intégration avec le service « Azure Key Vault ».

Azure Key Vault est la solution de « Key Management » d’Azure qui vous permet de stocker de manière sécurisée vos clés de chiffrement, Codes/Secrets/Crédentials…etc

Dans le cadre d’un déploiement RDS, les certificats SSL utilisés pour chiffrer les différents échanges au niveau de la Gateway, Web Access et RD Publishing/SSO peuvent désormais être stockés dans un Azure Key Vault.

Note : je prépare un Step-by-step guide à travers lequel je vous détaillerai comment utiliser Azure Key Vault pour stocker les certificats SSL RDS, il sera bientôt publié sur mon Blog So Stay Connected :).

 

De plus, Azure SQL Database peut héberger vos bases de données RDCB et RDLS HA, cela vous évite le déploiement d’une infrastructure SQL OnPrem dédiée (et complexe :)).

Enfin, Microsoft promets un nouveau model de Licensing RDS sur Azure à travers le Programme CSP (Cloud Solution Provider), nous aurons plus d’informations sur le sujet bientôt, fin Octobre normalement.

 

Useful Informations /Documentations

Pour les personnes n’ayant peu ou pas de connaissance sur les services Azure cités plus haut, je vous invite à consulter les liens suivants :

• Documentation Azure SQL Database
• Documentation Azure Key Vault

Je suis en train de finaliser plusieurs articles autour de RDS 2019, abonnez-vous sur mon Blog (si ce n’est pas déjà fait :)) pour rester informé de tout nouvel article publié.

A bientôt

#HK