Solutions pour la gestion des domaines Windows Active Directory

Comment configurer l'outil prise de contrôle à distance TightVNC (partage d'écran) ?

Comment optimiser l'utilisation de TightVNC ?

J'utilise votre logiciel IDEAL Administration et TightVNC pour prendre le contrôle à distance de postes situés sur mon réseau local ou sur un site distant et je trouve que les temps de réponse ne sont pas très bons.

L'objet de cet article est de vous montrer les voies d'amélioration ainsi que les différents paramètres entrant en ligne de compte lorsque l'on veut diminuer les temps de réponse lors de prise de contrôle à distance.

La fluidité et la rapidité des mises à jour de l'écran dépendent de nombreux paramètres: processeur du poste distant, vitesse du réseau entre les deux postes, performances de votre carte vidéo locale, encodage des données, type de compression mise en oeuvre, etc...

Il va donc vous falloir trouver le meilleur compromis entre occupation processeur, temps de compression et temps de transfert !

I. Accélération matérielle

Une astuce, applicable par exemple lorsque le poste distant est un serveur, consiste à désactiver totalement l'accélération graphique matérielle.

Pour ce, bouton droit de la souris sur le Bureau puis "Paramètres" puis onglet "Paramètres", cliquez sur le bouton "Avancés..." et sélectionnez l'onglet "Résolution des problèmes". Sélectionnez "Aucune" en faisant glisser le curseur vers la gauche. Validez en cliquant deux fois sur le bouton OK.

Essayez une nouvelle prise de contrôle à distance. Vous devriez constater une très nette amélioration des performances.

Remarques:

1. Cette option n'est pas accessible sur tous les postes ni tous les systèmes d'exploitation. Il faut essayer et voir si elle existe dans votre cas.
   
2. Ne surtout pas essayer ceci sur une carte graphique ATI: certaines de ces cartes sont connues pour générer des BSOD ( "plantages" ) lorsque l'on désactive cette fonctionnalité.

II. Propriétés d'affichage dans TightVNC

C'est là que l'on gagne le plus sur les ressources processeur du poste distant.

Au niveau du configurateur TightVNC, onglet "Connexion", section "Mises à jour".
Veuillez décocher "Totalité de l'écran" et cocher, uniquement, les cases suivantes:
"Fenêtre de premier plan", "Seulement les fenêtres en mode Console" et "Seulement les événements reçus".

Ces paramètres donneront un réultat tout à fait satisfaisant pour des applications de type Windows graphiques.
Pour les applications DOS, c'est moins sûr...

A l'issue de nos tests, le taux d'occupation processeur lié à TightVNC dépasse rarement les 30% une fois ce paramétrage réalisé. Avec le paramétrage par défaut - c'est à dire, rafraichissement de tout l'écran - le taux d'occupation processeur peut très facilement dépasser les 70 à 80%...

III. Codage des images écran

Il s'agit de jouer sur les différents algorithmes possibles pour encoder les données écran à transférer. Il est clair qu'il n'y a pas de solution passe partout ou universelle: si tel était le cas, nous l'aurions mise en place!

Nous vous invitons à consulter la page de tests existant sur le site officiel de TightVNC (https://www.tightvnc.com/) afin de mieux comprendre et apprécier ce qui se passe - en matière de volumes et temps de compression - en choisissant un algorithme à un autre... Atttention, cette page est en Anglais uniquement...

Vous allez donc devoir, si vous souhaitez optimiser votre connexion, essayer les différents paramètres possibles et voir lesquels sont le plus adaptés à votre cas précis. Ceux-ci seront à mentionner dans la zone "Ligne de commandes de VNCViewer" de l'onglet "Général" d'une configuration TightVNC.

Les principaux paramètres possibles sont:

"-encoding tight" : Il s'agit de la valeur par défaut. C'est avec ce paramètre que l'on obtient le volume transféré le plus faible. Cette option est tout à fait adpatée pour une prise de contrôle à distance via modem ou ligne RNIS.
Par contre, il y a une certaine latence étant données les étapes de compression.

"-encoding hextile" : Temps de compression le plus faible. Sans doute le meilleur compromis pour un réseau local, quelle que soit la configuration.

"-encoding raw" : Aucune compression n'a lieu: l'occupation processeur est alors la plus faible mais la taille des données transitant entre le poste distant et le votre est très, très importante !

A ces trois paramètres peut être ajouté un autre commutateur: /8bit. Dans ce cas, le nombre de couleurs sera limité à 8bits soit 256. Vous y perdrez un peu en qualité mais gagnerez en termes de bande passante requise et donc de vitesse.

Enfin, une autre solution est de jouer sur l'encodage JPEG des données et le taux de compression utilisé par TightVNC, lorsque l'on utilise l'algorithme "Tight".

La qualité JPEG peut osciller entre 0 et 9, 0 signifiant "la plus mauvaise", 9 signifiant "la meilleure".
Le taux de compression peut osciller entre 1 et 9, 1 signifiant "compression la plus faible" et 9 signifiant "meilleure compression possible".

Par défaut: compresslevel = 6 et quality = 6.

Exemples:

"-compresslevel 9 -quality 0" donnera une compression maximale des données avec une image de piètre qualité mais des volumes transférés ridiculement faibles. A essayer sur les connexions bas débit ( modem, RNIS, WAN ).

"-compresslevel 1 -quality 6" donnera une image de qualité presque parfaite avec une compression minimale et donc une occupation processeur presque inexistante.

Exemples de combinaisons possibles:

"-encoding tight -compresslevel 6 -quality 6" : Valeurs par défaut!
"-encoding tight -compresslevel 9 -quality 0" : Compression maxi, volume mini.
"-encoding hextile" : Le plus rapide en local

"-encoding hextile -compresslevel 1 -quality 5 /8bit" : A essayer !

IV. Utilisation conjointe avec Zebedee

Comme avec tout logiciel de tunneling, les trames circulant dans les tunnels sont compressées. Cela signifie donc qu'un certain temps processeur est nécessaire à cette compression.

Par ailleurs, TightVNC utilise lui aussi différents algorithmes de compression afin de réduire la taille des "images" transitant entre le poste serveur et votre poste d'administration. La aussi, un certain temps processeur est requis.

Enfin, il ne faut pas oublier que compresser des données compressées entraine souvent une augmentation de taille!

Par conséquent, si vous utilisez conjointement TightVNC et Zebedee au sein de votre réseau local, nous vous conseillons de modifier le fichier suivant :

* Program Files\Pointdev\IDEAL Administration\Zebedee\VNCViewer.zbd

Ajoutez (ou modifiez) la ligne suivante:
compression 0

Dorénavant, toute prise de contrôle à distance effectuée depuis ce poste d'administration ne compressera plus les données dans le tunnel Zebedee.

V. Utilisation du driver video miroir "DFMirage"

Le driver vidéo miroir DFMirage est un add-on de TightVNC permettant l'amélioration des performances au niveau du rendu graphique. Censé amélioré la rapidité de la communication lors de la prise de contrôle à distance, il prend également notamment en compte la gestion des effets de transparence (OS Vista et supérieurs, bouton du menu Office 2007 ...).

Pour copier le fichier d'installation du driver sur l'hôte distant, vérifier au niveau de la configuration de la prise de contrôle à distance TightVNC (onglet général) que la case "Copier le driver vidéo (DemoForge Mirage) lors de l'installation du service" soit bien cochée.

Ensuite, après avoir pris le contrôle de la machine distante, le driver peut être installé automatiquement et silencieusement, directement depuis le visualiseur TightVNC (bouton gestion du driver vidéo miroir). En fonction de l'OS de la l'hôte distant, il pourra vous être éventuellement demandé de certifier l'installation de ce programme (via la fenêtre Windows de vérification de l'éditeur du pilote). Veuillez alors valider sur "Installer ce pilote quand même".

A l'issue de l'installation, vous pouvez vérifier que le driver a été correctement installé en ouvrant le gestionnaire de périphériques, puis Cartes Graphiques : l'entrée Mirage Driver devrait alors apparaitre.

Pour que le driver soit pris en compte après son installation, il peut être nécessaire de relancer TightVNC.

Attention toutefois, des problèmes de compatibilités connus peuvent survenir sur certaines configurations et OS (voir par ailleurs).