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

Publicité

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.

[VIDEO] Améliorations apportées à RDS Windows Server 2016

Joydeep Mukherjee (Senior Product Marketing Manager) et Scott Manchester 😀 (Principal Group Program Manager) vous présentent lors de cette session (vidéo) toutes les améliorations apportées à RDS Windows Server 2016 et vous expliquent comment cette nouvelle version peut aider vos clients à Builder une infrastructure Poste de travail virtuel (VDI) mais aussi vApps sécurisée, scalable et hautement disponible.

Watch & Enjoy :).

RDS Windows Server 2016 – Planning Poster

 

Une bonne News from Microsoft Corp :).

L’équipe Remote Desktop Services vient de publier 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.

[PART2] Nouveau mode de déploiement sous RDS 2016 : Personal Session Desktops

Lors de la [PART1], nous avons découvert le nouveau mode de déploiement introduit avec RDS 2016 : Personal Session Desktops

Now let’s setup notre infrastructure RDS (VDI) sur MS Azure :).

Comme illustré dans l’image ci-après, 3 VMs dédiées à mon future infra RDS 2016 ont été créées :

Note : depuis Windows Server 2012 et 2012 R2, le déploiement d’une infrastructure RDS requiert un domaine AD. une infrastructure AD (vLAB.com) est donc déjà en place, celle-ci est hébergée /gérée par l’unique DC nommé « DC01 ».

Les services de rôles RDS vont être répartis de la manière suivante :

• VM « RDCB01 » : fait office de Serveur Broker et Web Access Server (RDWA)
• VM « RDSH01 » : premier serveur Hôte de Session du déploiement
• VM « RDSH02 » : second serveur Hôte de Session du déploiement

Toutes mes VMs hébergées sur Azure tournent sous Windows Server 2016 Technical Preview 5

Tous les serveurs de déploiement RDS doivent être joint au domaine AD, de plus la gestion à distance (via PowerShell Windows) doit être activée sur chacun des serveurs.

HowTo : Setup(er) votre infrastructure RDS (VDI) 2016 TP 5

-Ouvrez une Session sur le serveur RDCB01 avec un compte « Domain Admin » ou équivalent (Session bureau à distance forcement vu que le serveur est dans le Cloud xD)

-Lancez Windows PowerShell en tant qu’Administrateur et saisissez les commandes suivantes :

#Pour importer le module PowerShell RemoteDesktop

Import-Module RemoteDesktop

#Pour déployer RDS sur les deux serveurs listés ci-haut

New-RDSessionDeployment -ConnectionBroker RDCB01.vLAB.com -WebAccessServer RDCB01.vLAB.com -SessionHost RDSH01.vLAB.com

#Pour ajouter le deuxième serveur RDSH « RDSH02 » au déploiement

Add-RDServer -Server RDSH02.vLAB.com -Role « RDS-RD-Server » -ConnectionBroker RDCB01.vLAB.com

#Pour créer une nouvelle Collection RDS nommée « MyVDICollection » et y ajouter les deux serveurs RDSH

Note : le paramètre –PersonalUnmanaged permet de spécifier le mode « Personal Session Desktops », quant au paramètre -GrantAdministrativePrivilege, il permet d’attribuer le droit « Administrateur local » aux utilisateurs Bureau à distance sur leur Serveur Hôte de Session Personnel.

New-RDSessionCollection -CollectionName « MyVDICollection » -ConnectionBroker RDCB01.vLAB.com -SessionHost RDSH01.vLAB.com,RDSH02.vLAB.com –PersonalUnmanaged -GrantAdministrativePrivilege

#Enfin, pour assigner (dédier) des Serveurs Hôtes de Session « Personnels » à vos users, les commandes suivantes sont utilisées. Notez que dans l’exemple suivant, le serveur RDSH01 sera assigné à l’utilisateur ‘dlanoizeley’ (David LANOIZELEY) et le serveur RDSH02 à l’utilisateur ‘hkadiri’ (Hicham KADIRI). Imaginez ça comme une infrastructure VDI « Personnelle » sur Azure :). 

Set-RDPersonalSessionDesktopAssignment -CollectionName « MyVDICollection » -ConnectionBroker RDCB01.vLAB.com -User « hkadiri » -Name RDSH01.vLAB.com
Set-RDPersonalSessionDesktopAssignment -CollectionName « MyVDICollection » -ConnectionBroker RDCB01.vLAB.com -User « dlanoizeley » -Name RDSH02.vLAB.com

What Next ?

Let’s test our VDI infrastructure 🙂

Le test suivant consiste simplement à lancer le client RDC (Remote Desktop Connection) > outil MSTSC.exe depuis ma machine locale (ou depuis n’importe quel terminal d’ailleurs : Smartphone /Tablette .. App ‘Remote Desktop’) et se connecter à mon RDSH Server dédié, disponible via le service cloud RDSH02.cloudapp.net

A bientôt

Keep in touch

Hicham.K