Articles Tagués ‘Remote Desktop Services’

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 :

1

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

2

A bientôt

Keep in touch

Hicham.K

ScriptGuyPic

Avec Windows Server 2016 (encore sous Technical Preview 5 au moment où j’ai écrit cet article), un nouveau mode de déploiement RDS verra le jour.

Actuellement avec Windows Server 2012 et 2012 R2, deux modes de déploiement sont disponibles :

Déploiement de Bureaux basé sur une Session : mode basé sur le serveur Hôte de Session (RDSH : Remote Desktop Session Host) où chaque utilisateur distant exécute une Session sur un OS serveur partagé. Il s’agit du modèle traditionnel {Terminal Server}.

Déploiement de Bureaux basé sur une Machine Virtuelle (VM) : modèle basé sur le serveur Hôte de Virtualisation (RDVH : Remote Desktop Virtualization Host) où chaque utilisateur distant exécute un poste de travail virtuel dédié (VM dédiée : VM Personnelle ou dans un Pool de VM) qui héberge un OS Client. Il s’agit ici de l’infrastructure de poste de travail virtuel, connue aussi sous le nom VDI (Virtual Desktop Infrastructure)

1

Avec la sortie de Windows Server 2016 Technical Preview 2, Microsoft a introduit un nouveau mode de déploiement : Personal Session Desktops ou Server Based Personal Desktop (le nom final n’est pas encore décidé !).

Ce nouveau mode de déploiement RDS combine les deux modes de déploiement disponibles actuellement avec RDS 2012 /2012 R2 (Déploiement basé sur une Session & VM), ce qui signifie 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 :). ce n’est pas magique ça ?

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.

Pourquoi dédier un Serveur RDSH pour un utilisateur Bureau à distance ? la réponse est Azure (Offre Cloud de Microsoft pour la partie DaaS {Desktop-as-aService})

En effet, quelque soit le type /niveau d’abonnement sur Microsoft Azure, vous ne pouvez actuellement souscrire à une offre VDI dans Microsoft Azure, vu qu’aucun contrôle /gestion de l’Hyperviseur n’est possible, de plus vous ne pouvez installer /attribuer des Licences aux VMs Clients utilisées dans un scénario VDI dans Azure.

Le nouveau mode de déploiement « Personal Session Desktops » permettra donc d’utiliser une solution VDI dans Microsoft Azure via l’attribution des Serveurs Hôtes de Sessions dédiés sous forme de Poste de travail virtuels.

De plus, de nouvelles améliorations ont été apportées à la fonctionnalité « Expérience utilisateur » (Desktop-experience pour les OS en anglais).

Pour en savoir plus sur la fonctionnalité « Expérience utilisateur », consultez cet article.
Cette fonctionnalité vous permet d’avoir la couche graphique de Windows 10 ainsi que les outils de poste de travail tel que l’Outil de capture, la Table des matières, l’outil de Nettoyage de disque ou encore le Lecteur Windows Media sur vos serveurs RDSH hébergés dans le Cloud.

Notez que depuis Windows Server 2016 (TP*), la fonctionnalité « Expérience utilisateur » est installée /fournie par défaut avec l’OS Server.

Utilisée dans un scénario de déploiement « Personal Session Desktops », vous pouvez proposer à vos end users un environnement VDI (Serveur Hôte de Session dédié sous forme de poste de travail avec un look Windows 10) hébergé chez Microsoft.


La deuxième partie de cet article détaille la « Mise en place d’une infrastructure VDI RDS 2016 sur Microsoft Azure ».

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 :

1

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:2
  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 : 3
  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 : 4
  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 :

5

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) :

6

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.

RDSUserSessionControl

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

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.

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

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

1

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 »

2

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

3

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

IISReset /Restart

5

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.

4

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

S’applique à : RDS 2012 et 2012 R2

Une question intéressante m’a été posée lors d’un audit d’une infrastructure RDS 2012 R2 (RemoteApp & VDI) :

Pouvez-vous paramétrer le dimensionnement intelligent « Smart Sizing » des fenêtres RDP lors de l’accès aux Bureaux Windows publiés ou P2T virtuels (VDI) lancés depuis le Portail RD Web 2012 R2 ?

La réponse est oui, et ce via la modification d’un certain nombre de fichiers de configuration liés au site RDWeb hébergé sur IIS.

Je vous présenterai donc à travers cet article les instructions à suivre pour activer le Smart Sizing sur vos batteries de serveurs RD Web Access.

Comme illustré dans l’image ci-après, le « Smart Sizing » n’est pas disponible (n’est pas activé) par défaut.

Dans l’exemple suivant, le Bureau Windows nommé « LABRDS01 » a été lancé depuis le Portail RD Web et comme vous pouvez le constater, la console Connexion Bureau à distance (RDC : Remote Desktop Connection) lancée n’est pas ajustée (hauteur & largeur) automatiquement, vous devez en effet utiliser les barres de défilement (horizontale et verticale) pour atteindre les différents coins du Bureau Windows lancé :

2

Mon client a souhaité que les fenêtres RDC utilisent le Smart Sizing pour un auto-ajustement lors du lancement, je peux comprendre son besoin et à quel point cela peut être embêtent pour certains types de end user exigeant une meilleure expérience utilisateur.

Comment ça marche ?

Ouvrez une Session Windows (compte Admin du domaine ou équivalent) sur le Serveur RD Web Access

Commencez par sauvegarder le dossier « C:\Windows\Web\RDWeb » avant de suivre les instructions ci-dessous, faites simplement une copie du dossier sur une partition autre que C:\

Editez le fichier « C:\Windows\Web\RDWeb\Pages\Site.xsl »

Localisez la ligne N° 665 (Notepad++ est votre ami :))

3

Insérer le code suivant au niveau de cette ligne :

strRdpFileContents += « smart sizing:i:1\r\n »;

Le résultat final doit ressembler au bloc de code suivant :

4

Sauvegardez et fermez le fichier Site.xsl

Enfin, relancez IE, reconnectez-vous sur le Portail RD Web Access et notez le résultat

Comme illustré dans l’image ci-après, le Bureau Windows lancé est désormais affiché en mode « Smart Sizing » :

5

N’hésitez pas à redimensionner la fenêtre RDC pour constater l’ajustement automatique de celle-ci en fonction de la taille du Bureau Windows.

J’espère que cette astuce pourra vous être utile dans vos projet de déploiement & d’optimisation RDS 2012 et 2012 R2.

 

S’applique à : RDS 2012 et RDS 2012 R2

Lors d’un projet d’optimisation et de personnalisation d’une infrastructure RDS 2012 R2 chez un client grand compte, le client a souhaité changer et remplacer l’image d’arrière-plan du Portail RD Web Access, non pas pour intégrer une simple image statique mais plutôt pour intégrer l’arrière-plan « dynamique » du moteur de recherche « Bing » qui, change tous les jours.

Cette personnalisation est possible, et ce via l’utilisation d’un outil appelé « PyBingWallpaper »

Note importante : le serveur RDWA doit être connecté à Internet pour la récupération du Wallpaper Bing depuis l’URL http://www.bing.com/HPImageArchive.aspx?format

Cet outil est téléchargeable gratuitement ici et doit être installé sur chaque serveur RDWA de votre infrastructure RDS 2012 R2

L’installation de l’outil « PyBingWallpaper » requiert l’installation de « Visual C++ 2010 x86 Redistributable » que vous pouvez télécharger ici.

Dès que Visual C++ 2010 x86 Redistributable est installé, lancez l’exe « pybingwp-*****.exe » et suivez les instructions suivantes :

Cochez uniquement le composant « !PyBingWallpaper » et sélectionnez « France » comme Pays

Laissez le chemin d’installation par défaut

2

Par défaut, mon portail RD Web Access ressemble à l’image ci-après :

1

Nous allons dans un premier temps éditer un fichier de configuration nommé « settings.conf » situé dans C:\Program Files (x86)\Genzj\PyBingWallpaper pour changer et remplacer les valeurs suivantes :

Remplacez
setter = win

Par
setter = no

Remplacez
output_folder = C:\Users\Administrator\MyBingWallpapers

Par
output_folder = C:\Windows\Web\RDWeb\Pages\images

Enregistrez et fermez le fichier « settings.conf »

Maintenant, si vous lancez l’exécutable correspondant à l’outil PyBingWallpaper, ce dernier va simplement récupérer l’image depuis Bing.com et la stocker sur une image nommée « wallpaper.jpg » placée localement dans le dossier d’installation de l’outil PyBingWallpaper, en revanche le Moteur de recherche Bing change d’image d’arrière-plan d’une manière quotidienne, il faudrait donc exécuter l’outil une fois par jour pour que l’image d’arrière-plan de votre Portail RDWA change en fonction de celle de Bing.

Cette opération peut être automatisée via l’utilisation d’une tâche planifiée qui fera le travail à votre place.

Nous allons donc créer une tâche planifiée nommée « BingWallPaper » qui va lancer l’exécutable « BingWallpaper-cli.exe » toutes les heures. Notez qu’au moment de la rédaction de cet article, la tâche sera programmée pour démarrer à 14h.

Ouvrez l’invite de commande (cmd.exe) depuis votre serveur RDWA et exécutez la commande suivante :

SchTasks /Create /SC HOURLY /TN « BingWallPaper » /TR « C:\Program Files (x86)\Genzj\PyBingWallpaper\BingWallpaper-cli.exe » /ST 23:10

Vous pouvez vérifiez la création de la tâche planifiée « BingWallPaper » depuis l’outil « TaskSchd.Msc » > Planification de tâches
3

Cette tâche planifiée permettra à l’outil PyBingWallpaper d’actualiser l’image « Wallpaper.jpg » en stockant la dernière image récupérée depuis Bing.com

Maintenant, il suffit de configurer le serveur RDWA pour utiliser l’image « Wallpaper.jpg ».

Pour ce faire, commencez par sauvegarder le dossier %windir%\Web\RDWeb\Pages (par sécurité et au cas au vous faites une mauvaise manipulation sur le fichier que nous allons éditer :D)

Dès que le dossier est sauvegardé, ouvrez le fichier tswa.css situé dans %windir%\Web\RDWeb\Pages\fr-FR (ou ****\Pages\en-US si votre OS est en EN)

Note : dans l’exemple suivant, le fichier tswa.css sera édité via Notepad++

Sous le bloc « Body », remplacez la ligne N° 27 par le code suivant :

background-image: url(../images/wallpaper.jpg);

Ajoutez ensuite le code suivant avant la ligne N° 31 :

background-size: cover;

Le bloc de code « Body » doit être similaire à celui ci-après :

4

Enregistrez et fermez le fichier tswa.css

Enfin, exécutez la tâche planifiée créée précédemment et connectez vous sur le Portail RDWA.

Notez le chargement et l’apparition de l’arrière-plan Bing sur votre Portail RDWA:

5

Quelques secondes après la récupération et intégration de l’image d’arrière-plan de Bing sur mon Portail RDWA, le moteur de recherche de Microsoft a été consulté, comme illustré dans l’image ci-après, Bing.com présente le même « wallpaper » récupéré précédemment par notre outil PyBingWallPaper.

6

24h plus tard (après que Bing ai changé de Wallpaper), la tâche planifiée a été exécutée et une nouvelle image d’arrière-plan est désormais présente sur mon portail RDWA.

7

Pour conclure, nous avons automatiser l’intégration du Wallpaper utilisé par Bing sur notre Portail RDWA

A l’aide de la tâche planifiée, l’image d’arrière-plan de votre Portail RDWA est mise à jour chaque heure et changera en fonction du Wallpaper utilisé de Bing.com

 

S’applique à : RDS 2012 et RDS 2012 R2

Introduction

Par défaut, le Portail RDWA (Remote Desktop Web Access) affiche un lien « Aide » qui permet aux utilisateurs Bureau à distance de consulter une aide en ligne regroupant plusieurs informations utiles concernant l’utilisation du Portail Web RDS et les différentes ressources (RemoteApp & Bureaux Windows) qui peuvent y être publiées.

1

Ce lien « Aide » renvoie simplement vers la base de connaissance suivante : http://go.microsoft.com/fwlink/?LinkId=141038

3

De plus, il est affiché en permanence (mode Déconnecté et/ou Connecté). En effet, dans l’exemple suivant, un utilisateur Bureau à distance est authentifié sur le Portail RDWA et le lien « Aide » reste toujours affiché :

2

Certains clients chez lesquels j’ai déployé des infrastructures RDS 2012 et 2012 R2 m’ont fait part de deux demandes par rapport à ce lien « Aide » :

Remplacer l’aide en ligne par le fichier « Aide » local ou une autre source externe

Masquer le lien « Aide » définitivement

Les deux options citées ci-dessus sont tout à fait possibles, voir les sections ci-après pour en savoir plus.

#Option1 : Remplacer l’aide en ligne par le fichier d’aide local ou une autre source externe

Le remplacement de l’aide en ligne par le fichier d’aide local se fait au niveau du Gestionnaire IIS

Lancez donc l’outil « InetMgr.exe » depuis le Menu « Exécuter » ou l’Interface Moderne et naviguez jusqu’au :

Sites > Default Web Site > RDWeb > Pages

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

Changez ensuite la valeur (définie par défaut) « false » à « true« .

4

Lancez l’Invite de commande (cmd.exe) en tant qu’Administrateur et saisissez : IISReset /Restart

Enfin, connectez-vous sur le Portail RDWA et cliquez sur « Aide », le fichier d’aide local est donc appelé et apparaît sur votre écran :

5

Vous pouvez aller plus loin dans la personnalisation et appelez votre propre fichier d’aide (manuel dédié aux utilisateurs finaux | Document d’exploitation RDS disponible sur votre plateforme Externe …Etc).

Pour ce faire, éditez le fichier C:\Windows\Web\RDWeb\Pages\fr-FR\login.aspx avec Notepad (ou Notepad++ pour une meilleure visibilité), les lignes 87 et 91 sont à modifier pour :

Ligne 87 : spécifier votre propre fichier d’aide

Ligne 91 : une URL Externe (Aide en ligne disponible sur votre plateforme Externe)

6

#Option1 : Masquer le lien « Aide »

Le lien « Aide » peut être masqué en modifiant un fichier de configuration nommé « Sites.xsl » situé sur le serveur RDWA dans :

%WINDIR%\Web\RDWeb\Pages\

Localisez le code suivant (ligne 152) :

7

Cette ligne doit être précédée par <!– pour être marquée comme commentaire.

Enfin, la ligne 154 doit terminer par –>, et ce pour marquer la fin du commentaire.

Le bloc de code (Ligne 152 à 154) devient donc :

8

Enregistrez les modifications et fermez le fichier « Sites.xsl »

Enfin, connectez-vous sur le Portail RDWA et constatez la disparition du lien « Aide » :

9