ORION REMOTE DESKTOP ET REMOTEAPP - chu … · animations, son et vidéos. Enfin, Windows 2012 dispose de mécanismes de distribution de charge, d’authentifications et d’encryptions

ORION REMOTE DESKTOP ET REMOTEAPP Guide d’installation et d’utilisation avancée

Service Informatique 18/08/2015

Version 1.2

18/08/15 Orion Remote Desktop et RemoteApp 2012 1/47

AVERTISSEMENT

Ce document technique est destiné à des utilisateurs avancés ayant de bonnes

connaissances générales en informatique et une maîtrise complète de leur

environnement client. Il a été écrit à des fins d’exhaustivité pour permettre à cette

catégorie d’utilisateurs de tirer parti de toutes les fonctionnalités proposées par ce

nouveau système.


TABLE DES MATIERES

AVERTISSEMENT ............................................................................................................................. 1

1 Introduction ........................................................................................................................... 4

2 Prérequis ................................................................................................................................. 7

2.1 Microsoft Windows ........................................................................................................ 7

2.2 Windows 8 (Mobile) / Mac OS / iOS/ Android ........................................................ 9

3 Remote Desktop Web Access ......................................................................................... 10

3.1 Introduction .................................................................................................................. 10

3.2 Accès aux ressources locales .................................................................................. 11

3.3 Roaming des sessions ................................................................................................. 12

3.4 Impressions.................................................................................................................... 15

4 Web Feed ............................................................................................................................. 18

4.1 Start Menu .................................................................................................................... 18

4.2 Associations de fichiers .............................................................................................. 23

5 Remote Desktop Connection .......................................................................................... 25

5.1 Introduction .................................................................................................................. 25

5.2 Configuration Manuelle ............................................................................................ 26

5.3 Modern UI ..................................................................................................................... 30

5.3.1 Contrôle de la connexion ................................................................................. 31

5.3.2 Accès à toutes les applications ....................................................................... 32

5.3.3 Recherche d’une application .......................................................................... 33

5.3.4 Options de l’utilisateur ........................................................................................ 34

5.3.5 Terminer la session ............................................................................................... 35

6 Accès Internet ..................................................................................................................... 36

6.1 Introduction .................................................................................................................. 36


6.2 messages et déconnexions ...................................................................................... 36

6.3 Remote Desktop Connection .................................................................................. 36

6.4 RD Web Access ........................................................................................................... 37

7 Dispositifs mobiles ............................................................................................................... 39

7.1 Introduction .................................................................................................................. 39

7.2 Remote Desktop Connection .................................................................................. 39

7.3 Web Feed ..................................................................................................................... 41

7.4 Navigation .................................................................................................................... 43

8 Troubleshooting ................................................................................................................... 46

ANNEXE 1 – points d’accès ...................................................................................................... 47


1 INTRODUCTION

Ce nouvel environnement « Remote Desktop Services 2012 » est destiné à remplacer

notre vieux système de terminaux serveurs 2003 « Mercure ». Il s’agit d’un

environnement entièrement réactualisé, basé sur Windows 2012 R2, qui apporte un

certain nombre de changements, d’améliorations et de nouvelles fonctionnalités par

rapport à nos anciens « Mercure ».

On trouvera ci-dessous un résumé des points techniques clés de cette solution

incluant des considérations pratiques basées sur l’expérience déjà acquise et les

remarques déjà formulées.

Modern UI

L’interface graphique Windows 2012 R2 de ces nouveaux terminaux serveurs est

calquée sur celle de Windows 8.1. On peut ne pas l’aimer mais le fait est qu’il s’agit

de la direction prise par Microsoft et qu’il n’est pas possible de revenir en arrière. Il faut

toutefois reconnaitre que cette interface fournit un meilleur confort en cas d’utilisation

d’écrans « multi-touch ».

RemoteApp

Le mode « Remote Desktop Session » tel que nous l’avons toujours connu avec les

« Mercure » n’est plus le seul mode d’accès possible. Avec cette nouvelle solution, il

est possible de lancer les applications distantes sans avoir besoin d’ouvrir un

Desktop Windows.

Ce mode d’utilisation RemoteApp présente deux avantages importants :

1. Il devient possible de mélanger applications locales et applications distantes

sur un seul bureau.

2. On ne doit plus passer par les terminaux serveurs pour des choses que l’on peut

faire de manières plus simples et plus efficaces sur son propre poste : accéder

à une application intranet, utiliser la suite MS Office, surfer sur Internet, …

Compatibilité

Windows 2012 et Office 2013 sont dotés des interfaces graphiques les plus récentes et

les plus sophistiquées qui existent actuellement sur Windows avec animations, lissages,

effets de transparence, d’ombres, de fondus, …

A cela il faut ajouter que les sites web, que ce soit intranet (ex Xero) ou Internet sont

chaque jours un peu plus complexes et mélangent allègrement texte, images,

animations, son et vidéos.

Enfin, Windows 2012 dispose de mécanismes de distribution de charge,

d’authentifications et d’encryptions qui sont eux aussi bien plus lourds et complexes

que sur les versions précédentes.

Pour garantir des performances adéquates dans le cadre d’une utilisation en terminal

serveur, Microsoft, via sa technologie RemoteFX, a amélioré ses protocoles réseaux


ainsi que la manière dont les rendus graphiques sont effectués tant sur les serveurs

que les clients.

Le résultat combiné de tout cela est que cet environnement nécessite des thins clients

à fois plus puissants et certifiés pour Windows 2012, ce qui n’est le cas actuellement

d’aucun des thin clients utilisés pour les « Mercure ». Cette nouvelle solution vient donc

obligatoirement avec son propre lot de thin clients.

64-bit

Windows 2012 R2 est uniquement 64-bit, ce qui présente le grand avantage de ne

plus être limité au niveau de la RAM. Les anciennes applications 32-bit continuent à

s’exécuter sans trop de problèmes en mode « compatible » (WOW64), mais restent

dans ce cas limitées à 2GB de RAM par exécution. Chaque fois que cela est possible,

Il est donc important d’exiger aussi de la part de nos fournisseurs des versions 64-bit

de leurs applications.

Fair Share Scheduling

La distribution des ressources (CPU, disques et réseau) se fait désormais de manière

équitable entre tous les utilisateurs et tous les processus des terminaux serveurs. Ce qui

n’était pas le cas sur nos « Mercure » ou un utilisateur qui lançait une tâche lourde

pouvait, par exemple, se voir attribuer 100% du CPU au détriment de tous les autres

utilisateurs.

Cette nouvelle méthode d’attribution des ressources est donc bienvenue pour le bien

commun, mais il faut comprendre que cela peut avoir des effets particuliers. Ainsi, en

cas de forte charge, un programme gourmand en ressource sera volontairement

« ralenti » pour limiter son impact global, ce qui pourrait donner l’impression qu’il est

moins performant, tant bien même que le serveur est plus puissant.

Tunneling RDP

Il ne s’agit pas à proprement parlé d’une nouvelle fonctionnalité, mais elle n’a jamais

vraiment été activée sur « Mercure ».

Pour fonctionner correctement, ce nouveau système exige désormais que le

« Tunneling RDP » soit actif. Ce qui se traduit par le fait que les ressources locales

(disques, USB, audio, imprimantes, clipboard, …) sur le poste client sont

automatiquement rendus disponibles dans la session distante.

Ceci à une conséquence importante pour les BYODs et les PCs à la maison ou ailleurs

puisqu’il est désormais possible de partager du contenu entre son dispositif privé et

les systèmes de fichiers sur le réseau Brugmann. Quelque part, il s’agit d’un substitut

aux clouds data, une fonctionnalité fort demandée par nos utilisateurs.

Easy Print Driver

Etant 64-bit et de toute dernière version, la compatibilité de nos vieilles imprimantes

avec ce système est sujette à caution et reste une source d’inquiétude. Ce système

dispose toutefois d’un driver d’impression universel (« Easy print ») qui, en théorie et à


condition de choisir un mode d’impression par tunneling RDP, ne doit plus nécessiter

de driver spécifiques.

Ceci devra être validé au cas par cas par des tests, et si tout se passe bien, sera même

plus simple qu’avant, même avec des imprimantes complètement dépassées qui ne

disposent plus que de drivers 32-bit.

Dispositifs Mobiles

Microsoft fournit des logiciels d’accès compatibles avec cette solution pour la quasi-

totalité des systèmes du marché, à savoir: Windows, Mac OS, iOS et Android. La

disponibilité de ces clients associés à l’interface ModernUI de Windows 2012 et au

support du « multi-touch » rend l’utilisation au départ de tablettes tout à fait

acceptable. Finalement, et comme souvent avec ce type de terminaux, seules la

taille réduite de leur écran et la difficulté qu’il y a à effectuer de nombreuses saisies

sont susceptibles de constituer un frein à leurs utilisations.


2 PRÉREQUIS

Ce nouvel environnement nécessite que le « Remote Desktop Protocol » du client soit

à jour dans sa dernière version, à savoir RDP 8.1 à l’heure actuelle.

Cette dernière version RDP n’est pas absolument indispensable stricto sensu car

Windows 2012 R2 est rétro-compatible avec la plupart des clients modernes qui sont

équipés au minimum de RDP 7. Toutefois, seule la 8.1 permet de bénéficier de toutes

les fonctionnalités ainsi que de performances optimales avec ce système de toute

dernière génération.

Les nouveaux Thin clients que nous sommes en train d’acquérir sont d’emblés équipés

de la 8.1 et les PCs de notre parc sont mis à jours automatiquement via WSUS vers

cette version. Il n’y a donc normalement rien à faire à ce niveau. Finalement, cette

mise à jour - optionnelle mais vivement conseillée - ne concerne que les dispositifs

personnels gérés par les utilisateurs eux-mêmes : PCs Home et BYODs.

2.1 MICROSOFT WINDOWS

Seuls Windows 7 SP1, Windows 8 et Windows 8.1 sont supportés. Windows XP est

incompatible avec cette solution, mais est de toute façon à bannir dans tous les cas

de figure.

�La dernière version RDP est automatiquement installée lors des « Windows

Updates » à condition toutefois d’accepter aussi les mises à jour optionnelles.

Pour vérifier la version RDP de Windows, ouvrez l’outil « Remote Desktop Connection »

et allez voir le « about » :


Si pour une raison X ou Y, à priori anormale, ce n’était toujours pas le cas même

après l’application correcte des Windows Update optionnels, il reste possible

d’installer manuellement la version RDP 8.1 :

� Sur Windows 8, effectuez la mise à jour complète vers Windows 8.1

� Sur Windows 7, télécharger et appliquer les packages suivants en

veillant à bien choisir entre les versions X86 (32-bit) ou X64 (64-bit) en

fonction de votre distribution Windows:

http://support.microsoft.com/kb/2830477

http://support.microsoft.com/kb/2923545

Attention, les différents packages doivent impérativement être installés dans

un ordre précis et il faut rebooter le PC chaque fois que cela vous est

demandé. L’ordre d’installation des packages est le suivant:

Windows6.1-KB2574819-v2-xXX.msu

Windows6.1-KB2830477-xXX.msu





2.2 WINDOWS 8 (MOBILE) / MAC OS / IOS/ ANDROID

Pour ces différents systèmes, il existe une multitude de clients RDP sur le marché

quoique généralement payants.

Il est toutefois fortement recommandé d’utiliser l’application « Remote Desktop »

produite par Microsoft. Non seulement cette dernière est gratuite mais elle garantit

une compatibilité totale avec toutes les fonctionnalités de notre environnement RDS

2012.

La dernière version en date du client « Microsoft Remote Desktop » est disponible en

téléchargement gratuit sur les différents « stores », « markets » et autres « Google

play ».

Voici les leurs liens directs :

Pour Tablette Windows 8.X (RT ou X86/X64) �

http://apps.microsoft.com/windows/en-us/app/remote-desktop/051f560e-

5e9b-4dad-8b2e-fa5e0b05a480

Pour Mac OS X ≥ 10.7 �

https://itunes.apple.com/be/app/microsoft-remote-desktop/id715768417

Pour iOS ≥ 6.0 �

https://itunes.apple.com/us/app/microsoft-remote-desktop/id714464092

Pour Android ≥ 2.2 �

https://play.google.com/store/apps/details?id=com.microsoft.rdc.android


3 REMOTE DESKTOP WEB ACCESS

3.1 INTRODUCTION

De la même manière que l’on avait des « Mercure » et des « Ochrome » en leur temps,

le système RDS 2012 pourra être constitué à terme de plusieurs « fermes » de serveurs.

Dans le jargon RDS 2012, on appelle cela des « Workspaces ». Et l’équivalent des

« Mercure » aujourd’hui est le workspace « Orion ».

La façon la plus simple d’accéder à « Orion » est d’utiliser Internet Explorer et de

passer par son portal « RD Web Access », soit via un point de menu de l’intranet, soit

directement via l’URL : https://gateway.chu-brugmann.be/orion

A partir du portal, il est alors possible de lancer les différentes applications publiées

par l’informatique, dites « RemoteApps ». Ces RemoteApps sont, en fait, des


applications distantes qui s’exécutent en dehors de leur desktop d’origine sur terminal

serveur pour s’afficher et interagir sur le desktop du client.

Remarques :

1. Il s’agit d’une page web, le lancement d’une RemoteApp se fait donc par

simple clic et non double clic comme sur le bureau Windows.

2. Les RemoteApps disponibles sur la page dépendent du profil de l’utilisateur.

Des utilisateurs différents peuvent donc avoir accès à des RemoteApps

différentes. Ce sont des groupes de sécurité dans notre Active Directory qui

déterminent quels utilisateurs ont accès à quelles RemoteApps.

3. Les RemoteApps correspondantes à nos applications Web (MediWeb, Plus,

DPI, Wish, …) ne sont pas disponibles lorsqu’on lance la page sur notre réseau

local. En effet, en interne, il n’y a aucune raison d’utiliser nos applications web

au travers d’« Orion ». Il est plus simple et plus efficace de les lancer, comme

d’habitude, directement via Internet Explorer sur le poste client.

3.2 ACCÈS AUX RESSOURCES LOCALES

Les RemoteApps s’affichent sur le poste client, mais s’exécutent sur les terminaux

serveurs. Elles se comportent toutefois comme des applications locales et toutes les

fonctions Windows habituelles sont disponibles : copier/coller, minimisation de

l’application, impression sur l’imprimante du client, accès aux disques locaux, …

Dans une RemoteApp, les répertoires Windows conventionnels (« Documents »,

« Pictures », « Download », …) sont ceux de la « Home Directory », c.-à-d. le H:\, de

l’utilisateur. Le répertoire « Document » correspond à l’ensemble du H:\ et il n’y a en

conséquence plus de disque H:\ apparent. Les disques locaux apparaissent eux sous

la forme « X on CLIENT », où X est la lettre du disque local et CLIENT le nom du poste

client.


Ce mode de fonctionnement est identique pour les imprimantes locales du client qui

apparaissent avec la mention « redirected ».

3.3 ROAMING DES SESSIONS

Toutes les RemoteApps que vous lancez sur votre poste client sont associées à votre

identifiant utilisateur et cet ensemble de RemoteApps en cours d’exécution constitue

votre « session ». Si vous lancez ne fusse qu’une RemoteApp sur un autre poste, votre

session sur le premier poste sera déconnectée et entièrement redirigée vers ce

nouveau poste, c.-à-d. que toutes vos RemoteApps ouvertes vont réapparaître telles

quelles sur le deuxième poste et disparaître du premier.

Notez que l’utilisation de « logins génériques », de toute façon fortement déconseillée

pour des raisons de fiabilité et de sécurité, est tout simplement impossible avec RDS

2012. Un utilisateur ne pouvant avoir qu’une et une seule session en cours.

Une session commence avec l’ouverture de la première RemoteApp et se termine

quelques temps après la fermeture de la dernière.

� Après une longue période d’inactivité, l’ouverture de la première RemoteApp initie

une nouvelle session et est donc significativement plus longue que les suivantes. Pour

accélérer le lancement des RemoteApps il suffit de laisser au moins une RemoteApp

ouverte en permanence.

Une session distante est matérialisée sur le poste client par une notification de l’outil

« RemoteApp and Desktop Connection » dans la barre des tâches. Si nécessaire, cet

outil peut être utilisé pour déconnecter manuellement la session, par exemple, pour

des raisons de sécurité sur un ordinateur public. Après un clic droit sur l’icône, choisir

« disconnect from » ou « disconnect all connections » :


Pour faciliter le roaming et accélérer le lancement des prochaines RemoteApps, les

sessions déconnectées restent actives et en attentes sur les terminaux serveurs durant

une période de 12 heures. Après cette période, la session distante est définitivement

clôturée et toutes les ressources sont libérées.

En cas de problème avec la session ou l’une ou l’autre des RemoteApps, il est toujours

possible de forcer la fermeture complète de la session via la RemoteApp « Reset » du

sous-menu « Controls » :


Cette opération clôture complètement la session distante (= « Logoff ou Sign out ») et

va donc fermer toutes les RemoteApps encore ouvertes de manière abrupte sans que les documents éventuellement ouverts soient sauvegardés !

Il est possible d’effectuer la même opération au travers du menu de contrôle de la

session en tapant la séquence « CTRL-ALT-END » dans n’importe quelle RemoteApp.

Ce menu de contrôle permet en outre de modifier certains paramètres de la session

(contraste, clavier, accessibilité, …) ainsi que de changer de mot de passe réseau.


3.4 IMPRESSIONS

Deux types d’imprimantes peuvent être utilisées avec cet environnement : les

imprimantes configurées sur le poste client et les imprimantes configurées sur les

terminaux serveurs. Le fait qu’une imprimante soit configurée sur le poste ou le serveur

ne veut pas forcément dire qu’elle est physiquement connectée au poste ou au

serveur en question car il peut très bien s’agir d’une imprimante réseau.

Les imprimantes configurées sur le poste client sont redirigées au travers d’un tunnel

RDP sur les terminaux serveurs et apparaissent dans un écran de sélection

d’imprimantes avec la mention « redirected » (voir aussi chapitre 3.2). Dans ce cas le

driver de l’imprimante sur le client communique avec un driver unique et universel

(« Easy Print Driver ») installé sur les terminaux serveurs. Ce mode de fonctionnement

présente de nombreux avantages:

1. Il est possible d’imprimer sur une imprimante locale physiquement attachée au

poste client et non accessible par les terminaux serveurs, comme c’est

typiquement le cas pour une imprimante à la maison.

2. S’il s’agit d’une imprimante réseau reconnue de notre domaine, elle peut être

installée par l’utilisateur sans intervention de l’informatique.

3. Seul un driver sur le poste client est requis, hors nous disposons bien des drivers

pour tous les clients de notre parc, ce qui n’est pas forcément le cas pour les

terminaux serveurs. Pour certain vieux modèles d’imprimantes, de tels drivers

n’existent tout simplement plus pour Windows 2012 R2 64-bit.

4. Si l’imprimante est déjà connue sur le poste client, il n’y a rien à faire au niveau

des terminaux serveurs, elle sera attachée automatiquement et de manière

transparente.

On préfèrera donc généralement l’utilisation de ce mode « tunnel RDP », mais en cas

d’incompatibilités avec le « Easy Print Driver », il y a un risque d’artéfacts ou de lenteurs

à l’impression. Dans ce cas, il n’y a malheureusement pas d’autre solution que

d’ajouter l’imprimante en question directement sur les terminaux serveurs comme

nous l’avons toujours fait sur nos « Mercure ».

Pour définir une imprimante sur les terminaux serveurs eux-mêmes, il est nécessaire

que le driver d’imprimante soit préalablement installé par les administrateurs sur tous

les serveurs de la ferme. Si c’est le cas, alors il ne reste plus qu’à ajouter dans

l’imprimante dans son profil utilisateur via la RemoteApp « Printers » :




4 WEB FEED

4.1 START MENU

Le « RD Web Access » vu précédemment est incontestablement la manière la plus

simple pour accéder rapidement aux RemoteApps, mais, il est aussi possible de lancer

les RemoteApps directement à partir du menu démarrer de Windows, c.-à-d. de la

même manière que les applications locales.

Exemple sous Windows 7:


Sur un domaine, cette fonctionnalité est généralement configurée par les

administrateurs de manière automatique via « Group Policies ». Il est toutefois possible

de la configurer soi-même manuellement via l’applet « RemoteApp and Desktop

Connections » du control panel:


L’écran suivant demande alors le point d’accès au « web feed » de notre réseau, c.-

à-d. à la configuration dynamique des menus via le serveur web. Ce point d’accès

peut être renseigné de deux manières différentes :

1. Dans tous les cas via l’URL:

https://gateway.chu-brugmann.be/rdweb/feed/webfeed.aspx

2. Pour Windows 8.X et uniquement sur notre domaine, via l’adresse email de

l’utilisateur, ex : [email protected]

Une fois que le point d’accès est correctement renseigné, il ne reste plus qu’à

introduire votre login utilisateur et mot de passe en veillant à bien cocher l’option

« Remember my credentials » sans quoi ceci vous sera demandé à intervalle régulier.



Les RemoteApps associées au workspace « Orion » sont désormais disponibles dans

votre menu démarrer.

Il ne faut pas perdre de vue que le RemoteApps sont publiées et (dé)publiées de

manière centrale par les administrateurs. En général, de nouvelles RemoteApps sont

susceptibles d’être ajoutées au fil du temps. Il s’agit donc d’un processus dynamique

et effectivement le menu est rafraîchi automatiquement par défaut toutes les 30 min.


�Le menu des RemoteApps étant rafraîchi dynamiquement, il est vain d’essayer de

procéder à des ajustements manuels du menu ou à des copies de points de menu sur

le bureau Windows car ces modifications seront potentiellement perdues lors d’un

prochain rafraîchissement.

Enfin, pour supprimer à tout moment entièrement le menu des RemoteApps, il suffit

de cliquer sur « Remove » dans l’applet :

4.2 ASSOCIATIONS DE FICHIERS

Il est possible d’associer les RemoteApps aux types de fichiers correspondants,

comme par exemple associer la RemoteApp « Word » aux extensions de fichiers

« .doc ». Ainsi, lorsque l’utilisateur cliquera sur un de ces fichiers, il sera ouvert

automatiquement dans la RemoteApp correspondante.

Cette fonctionnalité n’est toutefois disponible que pour Windows 8.X uniquement et

ne peut être configurée que de manière centrale par les administrateurs du domaine.

Il n’est donc pas possible pour un simple utilisateur de la configurer manuellement sur

son propre poste.

Ce dernier point est assez logique car cette configuration peut entrainer des

changements perturbants et notamment des conflits avec les applications installées

en local. Par exemple, si l’on associe les fichiers « .doc » à la RemoteApp « Word » alors

que Microsoft Word est déjà installé localement sur le poste, l’utilisateur devra choisir

qui de l’application locale ou de la RemoteApp ouvrira le fichier en question :


Si on multiplie les associations (Acrobat, Excel, …) et les versions (ex Office 2010 en

local, Office 2013 à distance) cela peut vite devenir très compliqué.

En conclusion, l’association de fichiers est sujette à caution, mais peut s’avérer utile

pour des configurations à base de Windows 8.X entièrement sous contrôle de

l’informatique comme, par exemple, des Thin Clients sous Windows Embedded 8.

Dans un tel cas, la configuration sera mise au point dès le départ, maintenue et testée

de manière à être entièrement compatible et éviter ainsi les risques de conflits.


5 REMOTE DESKTOP CONNECTION

5.1 INTRODUCTION

J’ai choisi d’aborder la présentation de ce nouvel environnement par le biais des

RemoteApps. En effet, quand on dispose déjà d’un desktop, c.-à-d. d’une interface

graphique sur son poste client, et à fortiori un desktop Windows, on peut se demander

quel est l’intérêt d’en ouvrir un deuxième ?

Il y a toutefois des cas ou ouvrir une session complète, comme on l’a toujours fait avec

les « Mercure », peut s’avérer utile, notamment :

• Pour certains types de thin clients qui ne disposent pas de desktop.

• Pour les tablettes qui ont un écran de taille réduite et une interface graphique

mono fenêtre et faiblement multitâches comme iOS et Android.

• Dans les cas où l’accès aux RemoteApps s’avère trop compliqué à mettre en

œuvre comme par exemple sur un poste public à l’extérieur de notre domaine.

Si toutefois l’accès aux RemoteApps reste possible que ce soit via le menu démarrer

ou le RD Web Access, alors mieux vaut lancer une session distante vers « Orion » via

ce canal:


En effet, l’environnement RDS 2012 est configuré et maintenu d’une façon centralisée

par le service informatique. Certains paramètres s’appliquent aux serveurs, mais

d’autres aux clients. Dans le cas des RemoteApps, on a donc l’assurance que

l’ensemble de ces paramètres sont automatiquement et dynamiquement appliqués

sans que l’utilisateur n’ait à configurer quoique ce soit lui-même. Ainsi :

• Les RemoteApps sont signées digitalement avec le certificat officiel du CHU

Brugmann, ce qui garantit leurs sécurités et évite l’affichage de messages

d’avertissement.

• Les paramètres clients (type d’authentification, redirections, paramètres de

performance et de qualité, support multi écrans, …) sont toujours

correctement configurés pour le domaine et peuvent évoluer de manière

transparente dans le temps.

5.2 CONFIGURATION MANUELLE

Si l’accès à la RemoteApp « Orion Desktop » n’est pas possible, il faut alors soit disposer

d’un fichier « .RDP » préconfiguré par l’informatique, soit configurer manuellement soi-

même une session Remote Desktop non signée.

Un fichier préconfiguré « Orion.rdp » est disponible ici: \\chu-

brugmann.be\share\it\InfoSoft\Public\ Il contient une configuration très proche

de celle fournie par la RemoteApp, quoique purement statique et figée dans le

temps. Il suffit de cliquer dessus pour ouvrir une session distante vers « Orion ».

Pour être complet, la configuration équivalente peut se faire manuellement de la

manière suivante sous Windows via l’outil « Remote Desktop Connection » :





�Même si ce n’est pas vraiment utile pour les Thin Clients et PCs fixes de notre

domaine, il n’y a pas d’inconvénients à toujours renseigner le champ « RD Gateway »

pour peu que l’on coche bien « Bypass RD Gateway for local addresses ». Dans le

cas d’un dispositif mobile, cela lui permet de passer d’un réseau à l’autre sans qu’il

faille changer sa configuration.

5.3 MODERN UI

En mode session, on se retrouve avec un desktop Windows 2012 R2 Update 1, c.-à-d.

très proche de celui de Windows 8.1. Il y a toutefois des différences de

fonctionnement liées au fait qu’il s’agit d’un environnement partagé. Ainsi, certaines

fonctionnalités sont désactivées ou simplement limitées. D’autres se comportent

parfois différemment que leur équivalent sur PC. Le point commun est que l’interface

graphique est bien le « Modern UI » de Windows 8.1.

Ce document ne saurait être un guide complet d’utilisation de Modern UI, mais on

trouvera toutefois ci-dessous quelques conseils pour effectuer correctement certaines

opérations de base.


5.3.1 Contrôle de la connexion

Pour vérifier que la connexion est correctement établie et que RemoteFX est actif.

En mode plein écran :

Notez aussi que la barre de connexion peut glisser le long de l’écran en maintenant

un click gauche de souris dessus.

En mode plein écran, tous les raccourcis clavier Windows sont opérationnels à

l’exception de CTRL-ALT-DEL qui se traduit par CTRL-ALT-END.

En mode fenêtre, les raccourcis clavier usuels sont remplacés par les suivants :

ALT+HOME: Displays the Start menu.

ALT+PAGE UP: Switches between programs from left to right.

ALT+PAGE DOWN: Switches between programs for right to left.

ALT+INSERT: Cycles through the programs in the order they were

started.

CTRL+ALT+BREAK: Switches the client between full-screen mode

and window mode.


5.3.2 Accès à toutes les applications

Le menu de démarrage comprend les applications les plus courantes. Pour voir

toutes les applications disponibles :


5.3.3 Recherche d’une application


5.3.4 Options de l’utilisateur


5.3.5 Terminer la session


6 ACCÈS INTERNET

6.1 INTRODUCTION

Cet environnement est prévu pour pouvoir être utilisé à la fois sur notre réseau local

et depuis l’extérieur à partir d’Internet. Afin de permettre la mobilité et le roaming, c.-

à-d. l’utilisation d’un dispositif mobile qui passe d’un réseau à l’autre, les

configurations sont identiques quel que soit la localisation géographique. Tout ce qui

a été vu précédemment en terme de prérequis, de configuration et d’utilisation est

donc valable tel que pour tout ordinateur connecté à Internet, qu’il soit à la maison

ou ailleurs.

� Via l’explorateur Windows sur « Orion », que ce soit en mode session ou en

RemoteApp, il est possible de copier des fichiers de son PC vers ses répertoires

réseaux du CHU Brugmann (H:\ = « Documents », N:\) et vice-versa. Ce qui offre une

alternative aux clouds data (Dropbox, OneDrive, …) quoique manuelle et sans

synchronisation automatique, ce qui n’est pas toujours plus mal.

6.2 MESSAGES ET DÉCONNEXIONS

En dehors de notre réseau, les automatismes (authentification automatique, group

policies, login scrips, …) fournis par notre domaine ne s’appliquent plus. De même,

pour des raisons évidentes, la sécurité est significativement renforcée. En

conséquence, certains messages d’avertissement avec demande de confirmation

peuvent apparaître et les sessions sont déconnectées automatiquement après une

période relativement courte d’inactivité1.

Les messages d’avertissements ne s’appliquent que partiellement aux portable et

hybrides sous Windows qui font du roaming entre notre réseau et l’extérieur. En effet,

vu que ces derniers se sont déjà connectés au moins une fois à notre domaine, ils ont

déjà reçus automatiquement nos configurations et préférences.

Les déconnexions automatiques en cas d’inactivité s’appliquent dans tous les cas.

Elles sont nécessaires pour protéger notre réseau si d’aventure un utilisateur laissait par

inadvertance une session ouverte sur un ordinateur public ou sur son ordinateur

portable en public. Cela peut parfois être un peu gênant en home working, mais il

faut bien comprendre qu’une fois sur Internet il est impossible de faire la distinction

entre les accès « privés » (ex de la maison) ou publics (ex depuis le PC d’un hôtel).

6.3 REMOTE DESKTOP CONNECTION

Le mode session est la manière la plus simple et la plus transparente pour se connecter

à « Orion » depuis l’extérieur. C’est la méthode préconisée pour les utilisateurs lambda

1 Cette période est actuellement de 20 minutes mais est susceptible d’être encore raccourcie dans le futur.


car c’est celle qui se rapproche le plus de ce qu’ils ont eu l’habitude de faire jusqu’à

présent avec les « Mercure ».

L’utilisateur doit simplement s’assurer que les prérequis sont respectés sur son PC (voir

Section 2) et qu’il dispose du bon fichier RDP préconfiguré par l’informatique. Ce

dernier pourra lui avoir été transmis par email ou mis à sa disposition sur le site web de

l’hôpital.

6.4 RD WEB ACCESS

L’accès de l’extérieur au RD Web Access est un peu plus compliqué à configurer et

une bonne maîtrise d’Internet Explorer est nécessaire en cas de soucis. Il est donc

plutôt destiné à des utilisateurs avertis.

Ainsi, lors du tout premier accès au portal web, il est indispensable d’accepter la

demande d’installation de l’ActiveX « Microsoft Remote Desktop Web Access » :


De plus, lors du lancement de la première RemoteApp, le message d’avertissement

suivant est affiché :

Ce message est « by design ». Il indique que même si le CHU Brugmann dispose bien

d’un certificat valide (si ce n’était pas le cas un message bien plus critique serait

affiché !) l’utilisateur doit quand même approuver ou non le fait que la RemoteApp

puisse accéder aux ressources locales du PC. Une fois approuvée avec l’option

« Don’t ask me again… » ce message ne sera plus affiché pour aucune RemoteApp.

Le portal web est légèrement différent de ce qu’il est en local. Il offre la possibilité de

lancer directement à partir de la page des « Remote Desktop Connections » (ex vers

son PC à Brugmann) ou de lancer le « webmail ». Il permet aussi de choisir

manuellement le mode d’optimisation de l’affichage des RemoteApps en fonction

de la vitesse de la ligne :

�En dehors de notre domaine, toutes les applications sont disponibles, y compris

nos applications Web (Plus, Mediweb, Wish, …). Ce qui offre une alternative à

l’absence d’extranet au départ de notre réseau.


7 DISPOSITIFS MOBILES

7.1 INTRODUCTION

Tout ce qui a été vu dans ce document concernant les RemoteApps et les sessions

Remote Desktop est aussi valable pour les tablettes et les hybrides. Les configurations

sont identiques et les points d’accès strictement les mêmes. La seule différence est

que pour un dispositif mobile il est nécessaire au préalable d’y installer une

application RDP comme décrit dans le chapitre « 2.2 Prérequis – Dispositifs Mobiles ».

Tous les exemples donnés ci-dessous le sont avec l’application « Microsoft Remote

Desktop Client » sur iPad avec iOS 8.1:

Ils peuvent toutefois être appliqués de manières équivalentes sur Android et Mac OS,

de même que comme fonctionnalités additionnelles sur tablettes/hybrides Windows

8.X.

7.2 REMOTE DESKTOP CONNECTION



7.3 WEB FEED



7.4 NAVIGATION

Sur tablette, il y a deux façons d’interagir avec l’interface Windows : soit de manière

habituelle en mode multi-touch, soit de manière plus classique via une souris virtuelle.

Le mode multi-touch est le mode par défaut et s’avère satisfaisant dans la grande

majorité des cas. Il y a cependant des circonstances ou ce mode est inopérant ou

trop difficile à utiliser, ex : pour naviguer dans les menus de l’intranet ou pour

manipuler des champs trop petits à l’écran. Le basculement d’un mode à l’autre peut

se faire via une option dans la barre de connexion :

Ceci fait alors apparaître le pointeur de la souris :


Remarques:

1. En mode multi-touch, un clic droit peut être obtenu en appuyant longuement

à l’écran tandis qu’en mode souris un clic droit se fait en appuyant avec deux

ou trois doigts.

2. Le clavier n’apparait pas automatiquement quand on se positionne dans un

champ de saisie. Il doit être invoqué manuellement via la barre de connexion:

3. Lorsqu’on ferme une RemoteApp ou qu’on quitte (« Sign out ») une session

Remote Desktop, le retour dans le client peut prendre du temps. Pour revenir

rapidement au client RDP, on peut cliquer sur le bouton de déconnexion de la

barre de connexion :

4. Pour plus de facilité, le clavier peut se fendre en deux et ainsi prendre moins

de place à l’écran. Il aussi est possible de faire défiler l’écran avec une molette

virtuelle pour accéder aux zones cachées par le clavier. Pour fendre le clavier

en deux, il faut rester appuyer sur l’icône en bas à droite du clavier et la tirer

vers le haut.



8 TROUBLESHOOTING

Problème [01] : La page RD Web Access est vide ou ne contient quasi pas de RemoteApps.

Solution :

Les RemoteApps auxquelles vous avez accès vous dépendent de votre profil

utilisateur. Si vous n’avez pas les bonnes RemoteApps, c’est qu’une erreur

d’attribution a été faite. Contactez le help desk informatique ou les administrateurs

du système.

Problème [02] : Il est impossible d’exécuter des RemoteApps dans la page RD Web Access car, au lieu de les lancer, Internet Explorer propose de les télécharger.

Solution :

L’active X « MsRdpClientShell Class» (voir 6.4 – RD Web Access depuis Internet) n’est

pas fonctionnelle. Si vous l’avez bien autorisée et que cela ne fonctionne toujours

pas, c’est que la configuration de sécurité de votre Internet Explorer empêche toute

exécution d’ActiveX.

Vérifiez que le filtrage des ActiveX n’est pas actif : Tools-> ActiveX Filtering

Si cela ne fonctionne toujours pas, il faut alors vérifier les options de sécurité ActiveX

de chaque zone, de même que les paramètres avancés, mais il est plus facile de

remettre votre IE dans sa configuration par défaut : Tools -> Internet Options ->

Advanced -> Reset

Problème [03]: Vous subissez des déconnexions intempestives que ce soit de votre page RD Web Access, de vos RemoteApps ou de vos sessions Remote Desktop.

Solution :

Il n’y a pas de limites de temps à l’utilisation de cet environnement. Si, lorsque vous

travaillez dessus, vous êtes déconnecté de manière inopinée c’est que vous avez

subit un crash de votre application, une perte du réseau ou qu’un problème grave

est survenu sur le système lui-même. Dans tous les cas il s’agit d’un phénomène

anormal qui, s’il devait se reproduire, doit être signalé à l’informatique.

Par contre, pour libérer des ressources et pour des raisons de sécurité (voir 6.2 – Accès

Internet – Messages et déconnexions), les sessions sont automatiquement

déconnectée après une période d’inactivité. Cette période dépend de votre

localisation : sur notre domaine elle est de plusieurs heures, à l’extérieur de quelques

dizaines de minutes.

Notez aussi qu’en cas de reconnexion dans les deux heures à l’environnement, vous

retrouverez votre session telle qu’elle était avant la déconnexion, que cette dernière

ait été volontaire ou non. Après ces deux heures votre session est définitivement

clôturée.


ANNEXE 1 – POINTS D’ACCÈS

Workspace « ORION » :

Remote Deskop Connection : orion.chu-brugmann.be

RDS Gateway : gateway.chu-brugmann.be

RD Web Access: https://gateway.chu-brugmann.be/orion

RD Web Feed: https://gateway.chu-brugmann.be/RDWeb/Feed/webfeed.aspx