Application TSE : démarrage, connexion et configuration pour Windows Server

J’ai passé assez de temps dans des salles serveur pour vous affirmer que les connexions Terminal Server représentent l’un des sujets les plus galvaudisés de l’administration système. Je me souviens avoir configuré mon premier environnement TSE avec l’enthousiasme d’un débutant, avant de réaliser que la théorie et la pratique divergent autant qu’un Cross Training diffère d’une session cardio classique. Les services de bureau à distance sous Windows Server permettent effectivement à plusieurs utilisateurs de se connecter simultanément pour exécuter des applications, mais la réalité technique exige une rigueur comparable à celle nécessaire pour orchestrer un programme d’entraînement intensif.

Les deux modes principaux, Administration à distance et Serveur d’applications, répondent à des besoins distincts que trop d’administrateurs confondent encore. Cette application pour Windows Server nécessite une compréhension approfondie du démarrage, de la connexion et de la configuration pour éviter les désastres que j’ai observés dans ma carrière professionnelle.

Initialisation et démarrage du service Terminal Server

Le processus de démarrage repose sur le fichier Termsrv.exe qui crée des piles d’écoute pour chaque paire protocole/transport acceptant les connexions entrantes. Chaque connexion reçoit un SessionID unique représentant une session individuelle, une architecture élégante mais exigeante. La session console charge en premier avec SessionID 0, correspondant au clavier, souris et vidéo connectés physiquement au serveur.

Le système crée ensuite deux sessions clientes inactives par défaut, attendant patiemment que des utilisateurs établissent leur connexion. Le Gestionnaire de sessions Smss.exe orchestre l’exécution du processus sous-système Csrss.exe, du processus Winlogon et du module noyau Win32k.sys. Les sessions clientes configurées chargent des pilotes distincts comme Tsharedd.dll pour l’affichage RDP, tandis que les pilotes souris et clavier transitent via le gestionnaire termdd.sys avec le pilote RDP Wdtshare.sys.

Le thread d’écouteur de connexion surveille le port TCP 3389, une configuration standard que vous devez sécuriser impérativement dans vos règles de pare-feu.

Configuration de la connexion client via protocole RDP

Les plateformes compatibles incluent Terminal Windows basé sur WinCE, Windows for Workgroups 3.11 avec TCP/IP-32b et toute plateforme API Microsoft Win32. Le client Windows for Workgroups affiche une empreinte mémoire d’environ 70 Ko, un ensemble de travail de 300 Ko et des données d’affichage de 100 Ko, des valeurs qui semblent modestes aujourd’hui mais révolutionnaires à l’époque.

Le client Win32 pèse environ 130 Ko avec des caractéristiques similaires pour l’ensemble de travail et les données d’affichage. La connexion s’établit systématiquement via le port TCP 3389, un détail technique que certains administrateurs négligent lors de la configuration réseau. L’échange de polices entre client et serveur détermine les polices système communes installées, évitant ainsi les problèmes d’affichage frustrants.

Le système réserve par défaut 1,5 Mo de mémoire pour le cache bitmap stockant icônes, barres d’outils et curseurs. Cette allocation optimise les performances en réduisant les transferts réseau répétitifs, une stratégie comparable à l’optimisation de vos séries d’exercices pour maximiser les résultats.

Niveaux de chiffrement et sécurité des sessions

Le chiffrement faible sécurise uniquement les paquets client vers serveur, protégeant l’entrée de données sensibles comme les mots de passe via l’algorithme Microsoft-RC4 avec clé 40 bits. Cette protection minimale suffisait jadis mais paraît désormais archaïque face aux menaces actuelles.

Le chiffrement moyen applique un traitement identique aux paquets sortants du client tout en ajoutant le chiffrement des paquets d’affichage retournés au client. Cette approche sécurise les données sensibles transitant sur le réseau avec le même algorithme RC4 et clé 40 bits, offrant une protection bidirectionnelle partielle.

Le chiffrement élevé protège les paquets dans les deux sens avec l’algorithme RC4 standard utilisant une clé 40 bits pour la version exportée. La version non exportée déploie RC4 avec clé 128 bits, garantissant une sécurité maximale pour les environnements sensibles. J’ai constaté que cette option ralentit parfois les performances, un compromis nécessaire pour protéger les informations critiques.

Gestion de la mémoire et partage du code applicatif

Tous les processus sur Terminal Server partagent du code en modes noyau et utilisateur dans la mesure du possible, une optimisation intelligente mais souvent mal comprise. Le gestionnaire de mémoire virtuelle utilise la protection de page copie en écriture, permettant à plusieurs processus de lire et écrire le même contenu jusqu’à une opération d’écriture déclenchant la copie du cadre de page physique.

Les applications Win32 comme Microsoft Word sont chargées en mémoire physique et marquées copie en écriture. Les nouveaux processus pointent vers la copie existante si l’application réside déjà en mémoire, évitant une consommation excessive de ressources. Les pages ne sont copiées dans un nouvel emplacement que pour les mémoires tampons et données spécifiques à l’utilisateur.

Le code partageable n’existe qu’en une seule instance en mémoire physique quel que soit le nombre d’exécutions simultanées, un principe d’efficacité remarquable que j’apprécie particulièrement après avoir géré des serveurs surchargés.

Choix entre modes Administration à distance et Serveur d’applications

Le mode Administration à distance transforme le client Terminal Services en outil d’administration, permettant une connexion à faible bande passante pour effectuer des tâches administratives sans affecter les performances des applications ou services BackOffice. La limitation à deux connexions simultanées via protocole RDP peut sembler restrictive, mais cette contrainte garantit la stabilité système.

Vous pouvez ajouter ce mode à tout moment, bien que l’installation lors de la construction du serveur simplifie considérablement la configuration initiale. Le mode Serveur d’applications traite les programmes utilisateur final en activant des objets supplémentaires pour gérer plusieurs utilisateurs exécutant simultanément les mêmes programmes.

Cette configuration impacte potentiellement les performances des programmes BackOffice et supprime toute limitation de connexion. Vous devrez acquérir des licences et déployer un service de gestion des licences Terminal Services, une dépense significative que certaines organisations sous-estiment. Pour un grand nombre d’utilisateurs, un serveur dédié devient indispensable, une recommandation issue d’expériences douloureuses avec des serveurs partagés surchargés.

Installation et configuration des programmes en environnement multi-utilisateurs

Installer les programmes en mode Installation garantit leur bon fonctionnement en environnement multi-utilisateurs, une précaution que trop d’administrateurs négligent. J’ai observé les conséquences désastreuses d’installations effectuées après Terminal Services, provoquant des dysfonctionnements nécessitant une désinstallation complète puis réinstallation.

Les méthodes pour passer en mode Installation incluent l’outil Ajouter/supprimer des programmes, l’Application Installer sur Terminal Server, ou la commande « change user /install » à l’invite de commandes. Vérifiez le mode actuel avec « change user /query » et retournez en mode Exécution via « change user /execute ».

Le système suit les entrées de Registre en mode Installation avec écriture dans HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install, puis copie dans HKEYCURRENTUSER pour chaque utilisateur lors de sa connexion en mode Exécution.

Différences entre applications 16 bits et 32 bits sur Terminal Server

Les applications 32 bits Win32 permettent le partage de code et s’exécutent remarquablement efficacement en sessions multi-utilisateurs. Les applications 16 bits Win16 s’exécutent dans un ordinateur virtuel MS-DOS (VDM) avec traduction des sorties en appels Win32, une architecture obsolète mais parfois nécessaire.

Leur code non partageable entre applications consomme potentiellement deux fois plus de ressources qu’une application Win32 comparable, impactant sévèrement les performances et la mémoire serveur. Privilégiez systématiquement les applications 32 bits pour optimiser l’utilisation des ressources serveur et améliorer l’expérience utilisateur, un conseil que j’aurais aimé recevoir lors de mes débuts.

Déconnexion de session et fermeture de session utilisateur

La déconnexion de session maintient les processus et l’espace mémoire virtuel actifs avec pagination des données sur disque si nécessaire. Le serveur conserve le mappage domaine/nom d’utilisateur et SessionID permettant à l’utilisateur de se reconnecter à sa session existante, une fonctionnalité appréciée des utilisateurs mobiles. RDP modifie les résolutions d’écran entre sessions sans difficulté.

La fermeture de session arrête tous les processus associés au SessionID et libère toute mémoire allouée, nettoyant complètement l’environnement utilisateur. Le code des applications 32 bits reste en mémoire jusqu’à fermeture par le dernier utilisateur, optimisant les ressources pour les sessions suivantes. Des processus résiduels comme ccSvcHst.exe, ctfmon.exe ou rdpclip.exe nécessitent parfois une fermeture manuelle via Ctrl+Alt+Fin, un problème frustrant que j’ai rencontré régulièrement.