Installation d’une application sous Terminal Server / Remote Desktop Server et Fonctionnement des Shadow Keys

Installer une application sous Terminal Server n’est pas anodin. En effet, le serveur étant multi-utilisateurs, il faut que l’application soit capable d’être utilisée simultanément par plusieurs utilisateurs. Il faut donc clairement séparer les données et paramètres communs, de ce qui ne l’est pas. Si l’application n’a pas été écrite en tenant compte de cela, les risques de plantage sont garantis.

   1. Le principe

Pour éviter ces situations, et gérer malgré tout le plus grand nombre d’applications, les différentes versions de Terminal Server font appel à un module de compatibilité, TS Compatibility, qui doit être activé à chaque installation. Cette activation se fait lors du basculement du serveur en mode « Installation » et se termine lorsque le serveur bascule de nouveau en mode « Exécution ».

En mode « Installation », selon les applications qui sont exécutées, un travail de surveillance sera effectué automatiquement ou pas. Ce qui détermine cette surveillance est la présence du flag TSAWARE ou non, dans l’entête du fichier exécutable de l’application. Pour les applications « TSAWARE », le serveur fera confiance à l’application pour gérer correctement ses paramètres et données. Pour toutes les autres applications, une capture des modifications des clés de registre, ainsi que des fichiers INI dans C:\Windows sera effectué.

2. Gestion des fichiers INI

Une copie des fichiers INI modifiés sera effectué vers un répertoire « Windows » crée dans le profil de l’utilisateur. Une modification de la variable d’environnement %WINDIR% permettra de pointer vers ce répertoire. Ainsi, si l’application référence les fichiers INI en se basant sur la variable d’environnement %WINDIR%, elle ne s’apercevra pas de la substitution et fonctionnera normalement. Dans le cas contraire, elle ouvrira la voie à tous les conflits de paramètres entre utilisateurs.

3. Gestion des clés de régistres – Les Shadow Keys

Les modifications de clés de registre provenant de HKEY_CURRENT_USER ou de HKEY_USERS\.DEFAULT seront dupliquées vers HKEY_LOCAL_MACHINE\Software\ [Wow6432Node\] Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software. Ces clés de sauvegarde sont appelées les Shadow Keys. Ainsi, lorsqu’un utilisateur se connectera, selon que les clés de l’utilisateur seront plus récentes ou non que les Shadow Keys correspondantes, ces dernières seront recopiées dans le profil utilisateur.

4. Les TimeStamp

Pour déterminer s’il faut mettre à jour les clés de registre du profil utilisateur, une comparaison entre 2 TimeStamp est réalisée. A chaque Shadow Keys créée, un 1^er TimeStamp contenant l’heure de cette modification est écrit dans HKEY_LOCAL_MACHINE\Software\ [Wow6432Node\] Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\IniFile Times\LatestRegistryKey. Cette valeur pourra ainsi être comparée au 2^ème TimeSTamp, qui contient l’heure de la dernière synchronisation entre profil utilisateur et Shadow Keys. Ce TimeSTamp est stocké pour chaque utilisateur dans HKEY_CURRENT_USER\Software\ [Wow6432Node\]\ Microsoft\Windows NT\CurrentVersion\Terminal Server\LastUserIniSyncTime.

Une fois la recopie démarrée, il faut savoir qu’elle n’est pas réalisée « en aveugle ». En effet, seules les clés ayant été récemment modifiées dans la Shadow Keys seront recopiées. Pour faire le tri, une nouvelle comparaison de TimeStamp est réalisée, mais cette fois avec l’attribut caché affecté à chaque clé de registre. Cet attribut caché est appliqué uniquement sur les clés, et non sur les valeurs. Ainsi donc, seules les clés contenant de réelles modification récentes seront recopiées, et dans ce cas, avec l’intégralité de leurs valeurs.

5. Cas des fermes de serveurs

Ce mécanisme pourrait être parfait, s’il n’y avait pas une petite complication : l’ajout d’un serveur TS/RDS dans une ferme de serveurs déjà existante. En effet, pour ce nouveau serveur, le TimeStamp des Shadow Keys étant forcément plus récent que celui des profils utilisateur, la synchronisation, et donc l’écrasement des clés du profil utilisateur se fera à chaque connexion d’un nouvel utilisateur de ce serveur. C’est la raison pour laquelle il est recommandé, lors de l’ajout d’un nouveau serveur qui contient des applications non TSAWARE native, de modifier la date système de celui-ci lors de l’installation des applications, afin qu’il ait une date d’installation équivalente aux autres serveurs. A la fin de l’installation, ce serveur pourra reprendre la date courante.

6. Conclusion

En conclusion, le fonctionnement des Shadow Keys a été imaginé à l’origine uniquement pour permettre à des applications mal écrites de fonctionner quand même sur un Terminal Server. Aujourd’hui, les éditeurs de logiciel sont à même d’écrire des applications certifiées TSAWARE, évitant ainsi les complications liées au Shadow Keys. Ce mécanisme devrait donc disparaitre avec le temps.

Enfin, afin que tout soit clair, voici une petite Foire Aux Questions :

Q: Ce mécanisme, est il toujours le même sous Remote Desktop Server 2012 ?

R: Oui. Ce mécanisme n’a pas changé depuis Windows Server 2003.

Q : Comment basculer en mode « Installation » puis en mode « Execution » ?

R : Pour basculer en mode « Installation », plusieurs méthodes sont possibles :

- Saisir la commande change user /install dans une invite de commande avec élévation de privilège.

- Depuis le panneau de configuration, faire Ajout/suppression de programme / Installer un nouveau programme

- Lancer l’installation d’un fichier MSI

- Exécuter un programme depuis la clé RunOnce au démarrage du serveur.

De la même façon, pour rebasculer en mode « Exécution », plusieurs méthodes :

- Saisir la commande change user /execute dans une invite de commande avec élévation de privilège

- Cliquer sur la boite de dialogue de « fin d’installation » du panneau de configuration

- Terminer l’installation d’un fichier MSI.

- Terminer l’installation du programme lancé depuis la clé RunOnce

Q : Pourquoi est-il particulièrement recommandé d’installer le rôle Terminal Service ou Remote Desktop Session Host en premier, avant d’installer toute autre application ?

R : Plusieurs bonnes raisons à cela.

- Si votre application est TSAWARE, mais ne peut pas détecter qu’elle s’installe sur un serveur TS/RDS, elle n’initialisera pas les bons paramètres, et risque même de ne pas installer les bon modules. Par exemple, les différentes versions de Microsoft Office, quand elles s’installent, n’installent pas les mêmes composants selon qu’elles sont sur un serveur TS/RDS ou sur toute autre type de machine.

- Si votre application n’est pas TSAWARE, le mécanisme des Shadow Keys ne pourra pas s’appliquer, et les risques de conflits lors de l’utilisation seront importants.

Q : Si j’ai installé plusieurs applications, et que je doive ajouter le rôle Terminal Service ou Remote Desktop Session Host sur mon serveur, que dois-je faire ?

R : Le plus simple est de commencer par désinstaller toutes les applications, redémarrer la machine, installer le rôle, redémarrer autant de fois que nécessaire, puis, installer de nouveau les applications, en basculant préalablement le serveur en mode « Installation ».

Q : Comment savoir si mon application contient le flag TSAWARE dans son entête ?

R : Il n’y a pas d’outil intégré au système permettant de vérifier cela. Toutefois, l’utilitaire dumpbin.exe, fournit avec les différentes versions de Visual Studio, le permet. Il suffit de l’exécuter avec le paramètre /headers pour afficher une liste des attributs de l’entête PE du fichier exécutable. L’attribut à chercher est : « Terminal Server Aware ».

Q : Pourquoi quand je modifie manuellement les clés de HKEY_CURRENT_USER, en mode installation, ces clés ne sont pas recopiées dans la zone Shadow Keys ?

R : Cela est très certainement dû au fait que l’outil que vous utilisez pour modifier ces clés manuellement, regedit.exe ou reg.exe, est par défaut flaggué comme étant TSAWARE. Les modifications ne sont donc pas surveillées par le serveur TS/RDS.

Q : Je voudrais utiliser le mécanisme des Shadow Keys pour modifier les profils des utilisateurs de mon serveur TS/RDS, mais les différents TimeStamp me compliquent la vie. Y aurait-il une façon simple de procéder ?

R : Oui, ne pas utiliser ce mécanisme, mais lui préférer une mise à jour par GPO.

Philippe

Windows Core Support Escalation Engineer