[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

Publicité

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.

[eBook /Book] RDS 2012 R2 – Securisation et Hardening: Guide du Consultant [1ère Edition]

Ce guide pas à pas vous permet de planifier et mettre en place une politique de sécurisation et durcissement de votre infrastructure RDS sous Windows Server 2012 R2. Plus de 30 paramètres (Hardening) de stratégies de groupe sont détaillés dans ce guide. Les options de sécurisation telles que NLA, Certificat SSL, chiffrement RDP y sont également traitées. De plus, je vous liste à travers cet eBook tous les outils (GUI & CLI) de protection du rôle RDS et vous montre comment les utiliser, et quand les utiliser. Enfin, vous y trouverez toutes les bonnes pratiques liées à RDS ainsi que mes retours d’expériences.

Le livre est en Français 😀 ::: La version Anglaise est en cours de rédaction…

Le format :: Broché :: est disponible sur Amazon.fr et Amazon.com, cliquez sur l’image ci-après pour en savoir plus :

Le format :: eBook [PDF] :: est disponible sur BecomeITExpert.com, cliquez sur l’image ci-après pour en savoir plus :

 

[RDS Security] Changer le port d’écoute RDP [par défaut :: 3389]

 

S’applique à : Windows Vista > Windows 10 | Windows Server 2008 > Windows Server 2016

Par défaut, une machine Windows (Client ou Server) sur laquelle les connexions Bureau à distance ont été activées /autorisées, écoute sur le port 3389 (TCP), ce dernier correspond au protocole RDP (Remote Desktop Protocole).

Pour le constater, ouvrez une Session (locale) sur une machine (Physique ou Virtuelle) ayant le RDP activé, lancez l’invite de commande (CMD.exe) en tant qu’Administrateur et saisissez NetStat -a, enfin notez l’existence du port d’écoute 3389

 

Protocole RDP : Vulnérabilité 

L’utilisation du port par défaut (3389 :: TCP) présente plusieurs vulnérabilités au sein d’un S.I et offre aux Hackers la possibilité d’effectuer plusieurs types d’attaques, notamment :

• Attaque par Brute-Force
• Attaque par DoS (Denial of Service)

En effet, tous les hackers qui s’en prennent aux connexions RDP s’appuient sur le port 3389 pour provoquer un DoS ou brute-forcer une machine Windows.

A l’aide de n’importe quel Network Sniffer, un Hacker peut capturer les RDP Data et facilement localiser la(es) machine(s) écoutant sur le port TCP 3389.

Prenons l’exemple de la vulnérabilité MS12-020, celle-ci a été détectée dans le protocole RDP et permettant un déni de service, et ce via l’utilisation du port 3389.

Comme le montre la vidéo ci-après, à l’aide d’un simple outil de Hacking (MSF « MetaSploit Framework » fourni avec KALI Linux), vous pouvez provoquer un DoS, et rendre (en quelques secondes…) un serveur RDSH (Remote Desktop Session Host) ou une Machine d’Administration écoutant sur le port 3389 indisponible :

 

Recommendations

Il est fortement recommandé de changer le port RDP par défaut [TCP : 3389] et en définir un autre « Personnalisé ».

Vous pouvez utiliser un numéro de port situé entre 1025 et 65535

Dans l’exemple suivant, le port 9933 sera configuré.

 

HowTo : Changer le port RDP par défaut

Le port RDP par défaut peut être changé via :

Le Registre (BDR : Base De Registre)

Lancez l’outil RegEdit.exe (depuis le menu Démarré /Exécuté ou Welcome Screen)

Naviguez jusqu’au : HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Localisez et éditez la clé DWORD « PortNumber »

Définissez un nouveau port (Base > Décimale)

 

GPO (Group Policy Objects)

Créez une nouvelle GPO ou éditez une GPO existante, naviguez ensuite jusqu’au : Configuration Ordinateur | Préférences | Paramètres Windows

Faites un clic-droit sur « Registre » et sélectionnez « Elements Registre »

Remplissez les champs comme suit :

Liez votre GPO aux OUs contenant les objets AD « Ordinateurs » correspondant à vos serveurs RDSH ou Poste d’Admin.

Enfin, lancez un GpUpdate.exe depuis un serveur sur lequel la GPO a été linkée et enjoy the change :).

 

Script PowerShell

Un script PowerShell a été développé (par mes soins :)) et uploadé sur la Gallery TechNet > Scripts Center.

Il vous permet de changer le numéro de port RDP par défaut en deux clics, il suffit de l’exécuter, renseigner le nouveau numéro de port RDP et valider le changement en cliquant sur la touche « Entrée » du clavier.

Ce script est téléchargeable ici.

 

L’outil « RDP Port Configurator »

Je work actuellement sur outil GUI que j’ai nommé « RDP Port Configurator » basé sur le script PowerShell décrit ci-dessus.

Il sera disponible en téléchargement gratuit sur BecomeITExpert.com, so Keep in touch :).

L’outil RDP Port Configurator ressemble à l’image ci-après :

 

Note importante 

Downtime

Tout d’abord, il faut noter que le changement de port RDP par défaut nécessite un redémarrage de votre machine. S’il s’agit d’un changement sur une ou plusieurs machines de production, pensez à planifier ce changement et surtout le downtime qui aura lieu lors du reboot de la machine.

Nouvelle syntaxe de connexion RDP

Quand vous utilisez un port autre que le 3389 pour les connexions Bureau à distance, vous devez le spécifier après l’adresse (IP ou Hostname) de l’ordinateur distant, dans notre cas la connexion bureau à distance se fait sur Nom_Serveur_RDS:9933

 

Extrait de l’eBook [RDS 2012 R2 – Sécurisation et Hardening : Guide du Consultant]

HowTo : Afficher le nom d’utilisateur sur le Portail RD Web Access [RDS 2012 et RDS 2012 R2]

Lors de plusieurs interventions chez différents clients, le besoin suivant m’a été exprimé :

Peut-on faire apparaître le nom d’utilisateur (AD) sur le portail RD Web Access ?

Tout d’abord, il faut savoir que par défaut, tout utilisateur authentifié sur le Portail RD Web (Remote Desktop Web Access) ne voit pas apparaître son nom d’utilisateur sur celui-ci, voir l’image ci-après :

Le coin supérieur droit de cette page (fichier Default.aspx) regroupe uniquement les deux boutons : Aide & Se déconnecter

Nous allons voir à travers cet article comment personnaliser le Portail RDWeb pour afficher le nom d’utilisateur connecté à côté du bouton « Se déconnecter ».

Par défaut, l’ensemble des fichiers correspondant au Portail RDWA sont stockés dans C:\windows\web\RDWeb\Pages

Donc commencez par faire une copie de ce dossier avant de suivre les instructions détaillées ci-après.

Le but étant d’avoir un moyen de rétablir le portail RDWA en cas de mauvaise manipulation /erreur de configuration.

Comment ça marche ?

1. Editez le fichier C:\windows\web\RDWeb\Pages\Web.config
2. Localisez la ligne 52 : <system.web>
3. Copiez /collez le code suivant (en dessous de la ligne 52) :

   <compilation defaultLanguage="c#" debug="true">
     <assemblies>
       <add assembly="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
     </assemblies>
   </compilation>

4. Le résultat doit ressembler à celui illustré dans l’image suivante:
5. Ce code a pour but d’indiquer au serveur RDWA que nous avons besoin d’insérer un code spécifique, et plus précisément un code (.NET) depuis la DLL « System.DirectoryServices.dll »
6. Dès que le code est inséré, enregistrez et fermez le fichier Web.config
7. Maintenant, éditez le fichier C:\windows\web\RDWeb\Pages\fr-FR\Default.aspx
8. Localisez la ligne 225 : </script>
9. Copiez /collez le code suivant (avant la ligne 225) :

   private static string GetDisplayName(string strUserName)
   {
     string strLDAPPath = "LDAP://dc=vLAB,dc=Lan";
     string strFilter = string.Empty;
     
     if(strUserName.Contains("\\")){strUserName = strUserName.Substring(1 + strUserName.IndexOf("\\"));}
     strFilter = "(SAMAccountName=" + strUserName + ")";
     if(strUserName.Contains("@")){strFilter = "(UserPrincipalName=" + strUserName + ")";}
     
     System.DirectoryServices.DirectoryEntry de = new System.DirectoryServices.DirectoryEntry(strLDAPPath);
     System.DirectoryServices.DirectorySearcher ds = new System.DirectoryServices.DirectorySearcher(de);
     ds.Filter = strFilter;
     ds.PropertiesToLoad.Add("DisplayName"); 
     System.DirectoryServices.SearchResultCollection results = ds.FindAll();
     
     return (results != null && results.Count > 0) ? Uri.EscapeDataString(results[0].Properties["DisplayName"][0].ToString()) : string.Empty;
   }

10. Remplacer la valeur de LDAP://dc=vLAB,dc=Lan par le nom DNS de votre domaine AD
11. Le résultat doit ressembler à celui illustré dans l’image suivante : 
12. Le code inséré occupe les lignes 224 > 240 sur mon fichier Default.aspx
13. Localisez ensuite la ligne 248 : baseurl= »<%=SecurityElement.Escape(baseUrl.AbsoluteUri)%> »
14. Insérez la ligne de code ci-après après la ligne 248 ‘baseurl…. » :

    userdisplayname="<%=GetDisplayName(strDomainUserName)%>"

15. Le résultat doit ressembler à celui illustré dans l’image suivante : 
16. Les étapes ci-dessus permettent d’afficher le nom d’utilisateur sur la page Default.aspx uniquement. Pour faire la même chose sur les autres pages du Portail RDWA, le fichier Site.xsl doit également être modifié, pour ce faire éditez ce dernier qui se trouve dans C:\windows\web\RDWeb\Pages\Site.xsl 
17. Localisez la ligne 15 (ligne vide) et insérez le code suivant juste en dessous :

    <xsl:variable name="userdisplayname" select="/RDWAPage/@userdisplayname"/>

18. Enfin, localisez la ligne 322 (ou 323 selon la configuration du déploiement RDS 2012 /2012R2) : <xsl:value-of select= »$strings[@id = ‘SignOut’] »/>
19. Copiez /collez le code suivant juste après cette ligne :

    <xsl:if test="$userdisplayname">(
    document.write(decodeURIComponent(''));)</xsl:if>

20. Le résultat final doit ressembler à celui illustré dans l’image suivante :

Enregistrez et fermez le fichier Site.xsl et connectez-vous sur le Portail RDWA.

Enfin, constatez l’apparition du nom complet de l’utilisateur authentifié (Hicham KADIRI dans l’exemple suivant) :

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

C’est une technique pour les [RDS Advanced users only].

Toute mauvaise manip sur les fichiers Web.config /Default.aspx /Site.xsl peut entraîner un downtime du portail RDWA

Vérifiez que vous avez bien copié /sauvegardé le dossier C:\Windows\Web\RDWeb\Pages avant d’appliquer cette procédure sur vos serveurs RDWA de prod :).

Goodluck et à bientôt.

[TOOLBOX] RDS User Session Control v1.2

RDS User Session Control est un outil graphique gratuit développé par [Ramon Bruin], il peut être exécuté d’une manière autonome sur n’importe quel serveur exécutant Windows Server 2012 et 2012 R2
RDS USer Session Control permet de localiser une ou plusieurs sessions Bureau à distance et de la fermer ou prendre le contrôle de celle-ci par la suite (Shadow Mode)

Cet outil est accompagné d’un fichier INI (settings.ini) qui contient le FQDN du serveur Broker à interroger.
Vous devez donc éditer ce fichier et spécifiez le FQDN de votre serveur Broker avant d’exécuter l’outil RDS User Session Control

Téléchargement

L’outil est disponible en téléchargement gratuit ici

[TOOLBOX] Sidder v2.0

Sidder un outil graphique gratuit développé par [Arjan Mensch], développé pour Framework .NET 4.5, il peut être exécuté d’une manière autonome sur n’importe quel serveur exécutant Windows Server 2012 et 2012 R2.
Sidder vous permet de lister et identifier les Disques de profils utilisateurs mappés pour chaque Utilisateur Bureau à distance.

Téléchargement

L’outil est disponible en téléchargement gratuit ici.

[TOOLBOX] RDSSendMessage Tool v1.0

J’ai l’honneur de vous annoncer la mise en ligne de mon premier outil graphique, il s’agit de RDSSendMessage Tool, en version 1.0 (First Release), donc vos feedback sont les bienvenus :)).

RDSSendMessage est un outil graphique gratuit qui vous permet de lister les sessions Bureaux à distance hébergées sur un ou plusieurs Serveurs Hôtes de Session (RDSH :RD Session Host), et d’envoyer par la suite des messages via réseau aux différents utilisateurs Bureaux à distance. Aucune installation n’est requise, il s’agit en effet d’un exécutable que vous pouvez lancer depuis n’importe quel serveur RDS du déploiement ou depuis une machine d’administration ayant les outils RSAT installés.

Prérequis

Framework .NET 3.5

Téléchargement

L’outil est disponible en téléchargement gratuit ici.

Liste complète des Mises à jour disponibles pour RDS sous Windows Server 2012 R2

Microsoft vient de publier une KB [2933664] qui regroupe et détaille toutes les Updates disponibles pour le rôle RDS [Remote Desktop Services] sous Windows Server 2012 R2.

Lien [Version Française]

Link [English Version]

Résumé de la KB

Cet article résume les correctifs disponibles et les mises à jour pour les problèmes qui peuvent se produire dans des environnements de Remote Desktop Services pour Windows Server 2012 R2.

La plupart des mises à jour répertoriées sur cette KB sont déjà incluses dans les mise à jour de Windows des cumuls mensuels normales. Veuillez sélectionner les « mises à jour recommandées » définies à partir de Windows Update pour accéder plus facilement.

Remarque : Si vous pensez que vous rencontrez un problème répertorié ci-dessous, installez uniquement le correctif pour ce problème spécifique ou utiliser l’option de calcul mensuel comme indiqué ci-dessus.

Les correctifs et les mises à jour sont organisés en zones de composant au sein d’environnements de Remote Desktop Services 2012 R2 et pourraient s’appliquent également à Windows 7 et Windows 8.1 les Clients Bureau à distance.

Source : https://support.microsoft.com/fr-fr/kb/2933664

HowTo : Cacher l’onglet « Se connecter à un ordinateur distant » du Portail RD Web Access [RDS2012 R2]

Suite à la demande d’un follower, j’ai rédigé cet article pour vous détailler la technique qui vous permettra de cacher l’onglet « Se connecter à un ordinateur distant » à partir du Portail RDWA (RD Web Access).

Par défaut, après authentification sur le Portail RD Web Access, l’utilisateur distant voit apparaître deux onglets :

RemoteApp et Bureaux : cet onglet regroupe les Programmes et Bureaux publiés auxquels l’utilisateur distant a accès

Se connecter à un ordinateur distant : représente un client RDC (Remote Desktop Connection)  light (Web) qui permet la connexion Bureau à distance directe sur un Ordinateur et/ou Serveur du réseau via RDP

Vous pouvez être amené à supprimer ce deuxième onglet pour éviter toute tentative de connexion Bureau à distance par vos utilisateurs du réseau.

La suppression de cet onglet du Portail RDWA consiste simplement à changer une valeur d’un paramètre au niveau IIS et le positionner à « false ».

Comment ça marche ?

Ouvrez une Session sur votre serveur RD Web Access

Lancez le Gestionnaire IIS depuis l’Interface UI ou depuis le Menu « Exécuter » en saisissant InetMgr.exe

Naviguez jusqu’au : Sites\Default Web Site\RDWeb\Pages\

Sous ASP.NET, double-cliquez sur « Paramètres d’application » et localisez le paramètre « ShowDesktops »

Changez la valeur « true » par « false » et validez en cliquant sur « OK »

Lancez l’invite de commande (CMD.exe) en tant qu’Administrateur et saisissez la commande suivante:

IISReset /Restart

Enfin, lancez IE, connectez-vous sur le Portail RDWA et notez le résultat.

Comme illustré dans l’image ci-après, l’onglet « Se connecter à un ordinateur distant » n’est plus disponible et vos utilisateurs Bureaux à distance ne pourront donc lancer des connexions Bureau à distance « directe » depuis le Portail RDWA.

Notez que cette procédure doit être appliquée sur l’ensemble de vos serveurs RDWA.