Fonctionnement de Terminal Server pour Windows Server 2003

Un serveur de terminal est fondamentalement le même que le système d’exploitation Windows Server normal, sauf que dans les environnements de serveur de terminal, des composants clés ont été ajoutés ou modifiés pour prendre en charge plusieurs utilisateurs simultanés.

Microsoft Windows a toujours été un système d’exploitation « multi-utilisateurs » en ce sens que plusieurs utilisateurs peuvent être connectés à un seul serveur à un moment donné. Cependant, ces utilisateurs étaient connectés à des services de fichiers ou d’imprimantes sur les serveurs. Ils exécutaient leurs interfaces Windows locales sur leurs ordinateurs locaux, et le serveur ne prenait en charge qu’une seule interface de bureau via le clavier, la souris et le moniteur locaux. La principale différence avec Terminal Server est que plusieurs utilisateurs peuvent exécuter leurs propres sessions de bureau Windows sur le serveur. Terminal Server est donc « multi-utilisateur » dans le sens où il prend en charge plusieurs interfaces de bureau. Certaines personnes aiment considérer cela comme un environnement de « contrôle à distance », sauf que le serveur de terminal peut accueillir de nombreux utilisateurs le « contrôle à distance » en même temps, chaque utilisateur faisant quelque chose de complètement différent.

Pour que Terminal Server prenne en charge plusieurs sessions utilisateur, certaines modifications ont dû être apportées à partir du logiciel Microsoft Windows Server standard. Il existe deux différences fondamentales entre un serveur Windows standard et un serveur Terminal Server installé:

• Lorsque Terminal Server est installé sur un serveur Windows 2003, certains composants principaux du système d’exploitation Windows sont modifiés pour prendre en charge plusieurs interfaces utilisateur simultanées. Par exemple, le gestionnaire de mémoire virtuelle et le gestionnaire d’objets sont modifiés pour prendre en charge plusieurs interfaces de bureau simultanées sans se confondre. Ce sont des modifications majeures, vous obligeant à redémarrer le système après l’installation de Terminal Server.
• De nouveaux services et composants sont ajoutés lors de l’installation de Terminal Server qui permettent au serveur de prendre en charge plusieurs sessions utilisateur. Le plus important d’entre eux est le service « Terminal Server ». Ce service, qui s’exécute au plus profond du serveur, est responsable de l’interfaçage des sessions utilisateur multiples avec le système d’exploitation. Il est également responsable de fonctions telles que la création de sessions, la réception d’utilisateurs et la fin de sessions.

Composants de serveur de terminal

Bien qu’il semble que le serveur de terminal soit essentiellement un système pcAnywhere glorifié, il s’agit en fait d’un système complexe composé de plusieurs composants, sous-systèmes et interfaces différents. Un schéma plus complet des composants du serveur de terminaux est illustré à la figure 2.1. Référez-vous à cela lorsque vous lisez les sections suivantes décrivant chaque composant composant Windows 2003 Terminal Server.

Figure 2.1: Composants Terminal Server 2003

Le noyau Windows Server 2003

Vous vous souviendrez qu’un composant clé de tout environnement informatique basé sur un serveur est un système d’exploitation multi-utilisateurs. Dans Windows Server 2003, ce système est contrôlé par le noyau.

Windows Server 2003 a besoin d’un moyen de distancer les composants critiques du système d’exploitation de tous les utilisateurs fous. Pour ce faire, les processus Windows fonctionnent dans l’un des deux modes suivants : mode utilisateur ou mode noyau. En repensant à votre formation Windows NT, vous vous souviendrez qu’une application en mode utilisateur ne peut pas écrire directement dans la mémoire du système d’exploitation. Au lieu de cela, il a un accès complet à son propre espace mémoire de 4 Go. Un composant du système d’exploitation appelé gestionnaire de mémoire virtuelle (qui s’exécute lui-même en mode noyau) contrôle tout cela et écrit dans la mémoire système pour le compte de l’application en mode utilisateur.

Dans les environnements de serveur Terminal, la séparation des applications en mode utilisateur et en mode noyau permet au système de séparer et d’isoler les utilisateurs. Le crash de l’application d’un utilisateur ne détruira pas l’ensemble du système. (Bien sûr, vous pensez qu’un crash d’application peut détruire un système, cependant, qui est généralement lié aux pilotes de périphériques qui s’exécutent en mode noyau.)

Dans les environnements Windows « standard » (c’est-à-dire serveur non terminal) où un seul utilisateur se connecte de manière interactive, tous les processus en mode noyau vivent heureux ensemble dans une zone mémoire et un espace de noms. Cependant, dans les environnements multi-utilisateurs tels que Terminal Server, ce partage ne fonctionnera pas car les demandes provenant de sessions d’utilisateurs différents pourraient entrer en conflit les unes avec les autres. Le noyau sur un serveur de Terminal est par conséquent conscient de plusieurs sessions; il maintient la session de chaque utilisateur séparée avec des processus et de la mémoire isolés. Windows Server 2003 apporte quelques modifications au noyau lorsque le composant Terminal Server est installé pour y parvenir.

Tout d’abord, le serveur place une partie de l’espace d’adressage de la mémoire du noyau dans la mémoire virtuelle. Cela permet de traiter correctement les requêtes qui seraient en conflit dans un environnement mono-utilisateur dans l’environnement multi-utilisateurs et de charger et d’utiliser plusieurs instances de pilotes de périphériques en mode noyau par plusieurs utilisateurs (raison pour laquelle un utilisateur peut techniquement planter l’ensemble du système).

Certains processus système ne sont pas spécifiques à une session, ce qui signifie que tous les utilisateurs de toutes les sessions auront besoin d’y accéder. Ces processus sont stockés dans une seule zone mémoire (globale) partagée par tous les utilisateurs.

Un effet secondaire du partage de processus comme celui-ci dans un environnement de serveur de terminal est que vous rencontrerez parfois des processus qui ne sont pas « conscients de la session « . »Un résultat potentiel (et un peu drôle) peut être des messages d’erreur affichés sur la console du serveur à partir d’applications exécutées dans la session d’un utilisateur. Comme il n’y a généralement personne dans la salle des serveurs pour accuser réception du message, il est possible d’empêcher l’application d’un utilisateur de continuer.

Le Service Terminal Services

 » Le Service Terminal Services  » désigne un service Windows régulier (Outils de Démarrage|d’Administration|Services) appelé  » Services Terminaux. »Dans le monde réel, les gens l’appellent généralement le « Service de terminal » et utilisent le terme « Serveur de terminal » pour désigner un serveur Windows exécutant le Service de Terminal.

Si le noyau multi-utilisateurs est le fondement de l’informatique basée sur le serveur dans Windows Server 2003, le service Terminal est la pierre angulaire. Ce service (chargé via termserv.dll) est chargé juste après la mise en ligne du noyau. Une fois la console du serveur (pilotes clavier, vidéo et souris) chargée, le Service Terminal lance le sous-système Gestionnaire de sessions (SMS).exe) responsable de la gestion et du suivi de toutes les sessions utilisateur sur le serveur.

Sessions Terminal Server

Une nouvelle session est créée chaque fois qu’un utilisateur se connecte à Terminal Server. Une session consiste essentiellement en un bureau virtuel à partir duquel l’utilisateur peut exécuter des applications et avec lequel il peut interagir comme avec un poste de travail. Une session serveur ne doit pas être confondue avec la console serveur, car une session n’est pas une télécommande de la console, mais en fait un nouveau bureau séparé de la console.

Chaque fois qu’un utilisateur se connecte à un serveur de terminal et crée ce  » bureau virtuel « , un numéro d’identification de session unique est créé pour différencier l’utilisateur (et donc les processus de l’utilisateur) de toutes les autres sessions et utilisateurs. Les identifiants de session permettent également au serveur de conserver une mémoire séparée pour la session de chaque utilisateur. Lorsqu’un utilisateur se déconnecte d’un client Terminal Services, la session utilisée est supprimée et les processus et la mémoire lancés et utilisés par cette session sont supprimés. Chaque serveur de terminal suit ses propres identifiants de session et se charge de les émettre, de les suivre et de les supprimer.

Étant donné que les sessions du serveur sont  » virtuelles  » (et que la mémoire et les processus sont séparés entre les sessions), un plantage ou un blocage d’une application dans une session ne devrait affecter aucune autre session utilisateur, même si d’autres utilisateurs utilisent la même application.

Cependant, la phrase clé ici est « ne devrait pas » affecter les autres utilisateurs. Même si les sessions utilisateur sont séparées sur un serveur, elles partagent toujours les ressources du serveur et certains segments de code. Si un utilisateur appelle un processus qui provoque l’écran bleu du serveur, cela aura évidemment un effet sur les autres utilisateurs. D’un autre côté, les occurrences simples comme une application suspendue à une demande expirée ou le crash de Microsoft Word lorsqu’un utilisateur ouvre un document corrompu ne seront pas vues par les autres utilisateurs (dans leurs propres sessions) sur le système.

États de session

Puisqu’une session est vraiment le bureau d’un utilisateur, il arrive qu’une session puisse se trouver dans différents états, un peu comme un poste de travail normal. Par exemple, si un utilisateur s’éloigne de son poste de travail pendant un certain temps, le poste de travail ne s’éteint pas. Au contraire, il est simplement inactif, en attente d’une entrée de l’utilisateur. Les sessions Terminal server se comportent à peu près de la même manière et peuvent se trouver dans l’un des nombreux états différents en fonction de l’activité (ou de l’inactivité) de l’utilisateur, de la connectivité entre le client et le serveur et des paramètres de délai de session.

Figure 2.2 : Chaque Serveur de terminal gère de nombreuses sessions utilisateur distinctes

Toutes les sessions utilisateur sur un serveur de Terminal doivent se trouver dans l’un des six états suivants:

• Active est un utilisateur actif et actif. L’utilisateur interagit avec la session Terminal Server et n’a pas eu de période d’inactivité ou de déconnexion du réseau du serveur. C’est l’état  » normal  » d’une session.
• Idle est l’état dans lequel une session passe lorsqu’il n’y a pas d’entrée de l’utilisateur pendant une période de temps spécifiée.
• Les sessions déconnectées se produisent lorsque les processus et les programmes d’une session  » live  » sont en cours d’exécution mais qu’aucun client RDC n’est connecté. (Si vous avez sauté le premier chapitre,  » client RDC  » est le nouveau nom du client RDP.) La cause commune est une déconnexion du réseau ou lorsqu’un utilisateur clique sur le « X » dans le coin supérieur droit de son logiciel client RDC. Un utilisateur peut se reconnecter à sa session déconnectée pour la ramener à un état « actif » (et reprendre son travail là où il s’était arrêté). Pensez à une session déconnectée comme un poste de travail verrouillé, sauf que l’utilisateur peut « déverrouiller » son poste de travail depuis n’importe quel ordinateur du bâtiment.
• Les sessions connectées sont dans un état dans lequel un périphérique client est connecté à une session de serveur, mais aucun utilisateur n’est connecté, tout comme l’invite CTRL+ ALT + SUPPR sur un poste de travail.
• Down est un état temporaire dans lequel une session est terminée et les processus au sein de la session sont tués. Down est l’état final d’une session avant sa fin.
• Listen est un état uniquement visible sur les ports d’écoute prêts à accepter les connexions entrantes. Cet état ne s’applique pas aux sessions ordinaires. Cela s’applique plutôt aux processus en cours d’exécution sur le serveur qui attendent (écoutent) de nouvelles demandes de connexion de session.

Dans la plupart des environnements, les administrateurs configurent des sessions avec différents délais d’attente. Vous pouvez limiter la durée d’ouverture d’une seule session ou convertir automatiquement une session inactive en une session déconnectée. Les délais d’attente aident à limiter le temps que le serveur passe à exécuter des processus pour les utilisateurs qui ne fonctionnent vraiment pas sur le serveur. Nous aborderons les techniques et stratégies exactes pour les configurer plus loin dans ce livre.

Ports de connexion et écouteurs

La session RDP de chaque utilisateur se connecte au serveur Terminal via un port de connexion. Un port de connexion (communément appelé uniquement « connexion « ) est un port virtuel sur le serveur associé à une combinaison spécifique de cartes réseau et de protocoles.

Un port de connexion Terminal Server est automatiquement créé lorsque le composant Terminal Server est installé. Par défaut, il permet à tout utilisateur du groupe « utilisateurs de bureau à distance » de se connecter aux sessions de serveur de terminal sur le serveur via n’importe quelle carte réseau. Cependant, même si le port de connexion par défaut fonctionne avec n’importe quelle carte réseau avec TCP/IP installée, les ports de connexion Terminal Server sont vraiment spécifiques à la carte réseau. Vous pouvez configurer un serveur avec plusieurs cartes réseau pour disposer de plusieurs ports de connexion Terminal Server, un pour chaque carte. En fait, chaque connexion peut avoir des propriétés et des autorisations entièrement différentes.

Figure 2.3 : Un serveur de terminal avec plusieurs ports de connexion

Les connexions de serveur de terminal et leurs écouteurs associés peuvent être configurés à deux endroits. Le premier est via le composant logiciel enfichable MMC de configuration de services de terminal (TSC). Vous pouvez utiliser le TSC pour configurer des options pour les connexions de serveur de terminal basées sur RDP, telles que les paramètres, les autorisations et la carte réseau sur laquelle une connexion est valide. La deuxième façon de configurer les connexions de Terminal Server consiste à utiliser un objet de stratégie de groupe (GPO) Active Directory dans un domaine Windows 2003. Cette fonctionnalité vous permet d’attribuer des connexions à plusieurs serveurs contenus avec une unité d’organisation dans Active Directory.

Écouteurs

Chaque port de connexion de serveur de terminal a un sous-composant appelé  » écouteur « . » Le composant d’écoute « écoute  » sur une combinaison de carte réseau et de protocole spécifique pour laquelle le port de connexion est configuré. Lorsqu’un utilisateur souhaite établir une nouvelle session sur le serveur, il utilise son logiciel client RDC pour contacter le serveur. L’écouteur du serveur récupère la demande du client et la transmet au gestionnaire de session. L’auditeur revient ensuite à l’écoute pour plus de demandes de connexion.

Canaux virtuels

Comme nous l’avons vu précédemment, le protocole RDP de Microsoft exécuté sur TCP/IP est le protocole réel qui connecte les utilisateurs aux sessions du serveur. Nous avons également mentionné que ce protocole peut prendre en charge plus que de simples bureaux virtuels purs. RDP permet de canaliser l’audio de session à distance du serveur vers les haut-parleurs du périphérique client. Il permet également aux périphériques branchés sur les ports série du client d’apparaître comme s’ils étaient branchés sur le serveur. Ces « extras » sont disponibles via les canaux virtuels de RDP. Un canal virtuel est simplement un mécanisme permettant de déplacer des données entre une session de serveur de terminal et un client. Par défaut, le protocole RDP sur Terminal Server 2003 contient plusieurs canaux virtuels.

• Audio: Les événements sonores générés sur la session du serveur sont redirigés via le protocole RDP vers le périphérique client RDC, où ils sont lus sur les haut-parleurs du client.Lecteurs clients
• : Les lecteurs de disques locaux du périphérique client sont mis à la disposition du serveur, de sorte que les utilisateurs puissent accéder à la fois aux lecteurs du serveur et à leurs lecteurs de périphériques clients locaux au sein de leurs sessions distantes.
• Imprimantes : Les imprimantes disponibles sur le périphérique client avant le lancement d’une session sur un serveur Terminal sont mises à la disposition des utilisateurs depuis leurs sessions serveur. Les utilisateurs peuvent ensuite imprimer sur leurs imprimantes Windows standard, y compris les imprimantes directement connectées à leurs périphériques clients.
• Ports série : Le canal virtuel de port série permet d’accéder aux périphériques branchés au port série d’un périphérique client via ses sessions de serveur de terminal distant.
• Presse-papiers Windows : Afin d’intégrer des applications locales à des sessions de serveur de terminal distant, le canal virtuel du presse-papiers Windows synchronise le contenu du presse-papiers du serveur de terminal distant avec le contenu du presse-papiers du périphérique client. Les utilisateurs peuvent facilement couper et coller entre les applications locales et distantes.

Si les canaux virtuels par défaut ne répondent pas à vos besoins, MSDN et les kits SDK Windows Server 2003 contiennent des informations sur l’écriture de vos propres canaux virtuels personnalisés. Un canal virtuel est une combinaison de deux composants — un composant côté client et un composant côté serveur. Les deux peuvent envoyer et recevoir des données via le canal virtuel, ce qui permet une communication unidirectionnelle ou bidirectionnelle. Les canaux virtuels peuvent également être indépendants du RDP, ce qui signifie que vous pouvez les personnaliser en fonction de votre environnement sans mettre à niveau ni modifier le logiciel client ou serveur réel.

Pourquoi tout l’accent mis sur les canaux virtuels? Bien que ce ne soit pas un livre de développeur et que vous ne développiez probablement jamais votre propre chaîne virtuelle, il est essentiel que vous compreniez comment ils fonctionnent. À peu près tous les produits complémentaires tiers pour Terminal Server utilisent des canaux virtuels. Comprendre le fonctionnement des canaux virtuels vous aidera à dépanner les produits tiers que vous rencontrerez sans aucun doute dans votre carrière de serveur de terminaux.

Ceci dit, jetons un dernier coup d’œil à l’architecture d’un canal virtuel. Voir la figure 2.4.

Figure 2.4 : Architecture de canal virtuel de Terminal Server 2003

Le composant de canal virtuel côté serveur est généralement un exécutable s’exécutant sur le serveur de terminal. Ce composant doit être un composant en mode utilisateur, car le serveur utilise l’ID de session pour déterminer à quelle session côté client il doit transmettre et recevoir des données.

Le composant de canal virtuel côté client est généralement une DLL fournie par Microsoft, le fournisseur de logiciels tiers, ou écrite sur mesure par vos développeurs. La DLL doit être chargée sur l’ordinateur client lorsque le programme client RDC est lancé et commence la connexion au serveur. Dans la plupart des cas, cela se fait par script ou par programme au niveau du client.

Comment tous ces Composants s’emboîtent

Maintenant que vous comprenez chacun des différents composants de Terminal Server, voyons comment ils s’emboîtent tous. Suivez le processus qui se déroule au fur et à mesure qu’une connexion client est établie, en vous référant à la figure 2.5.

Figure 2.5: Une nouvelle session est établie

1. Avant que quelque chose ne se produise, les écouteurs du serveur Terminal surveillent certaines combinaisons de cartes réseau, d’adresses IP et de ports TCP pour les demandes entrantes de démarrage de sessions.
2. Un utilisateur décide d’utiliser une application distante, elle lance donc son client RDC et demande une connexion à « server1. »Son client RDC vérifie quelles DLL de canal virtuel sont installées.
3. Dans cet environnement, le nom « server1 » fait référence à l’adresse IP 192.168.14.42 (qui se trouve être la carte réseau #1 sur ce serveur). Le client RDC de l’utilisateur envoie une demande de connexion de session au 192.168.14.42.
4. L’écouteur du serveur récupère la requête et la transmet au gestionnaire de session. Lorsque le gestionnaire de session prend le relais, l’auditeur reprend l’écoute pour plus de sessions.
5. Le serveur négocie avec le client demandeur son niveau de cryptage et ses capacités de canal virtuel.
6. L’utilisateur est ensuite authentifié sur le domaine et ses droits sont vérifiés pour l’accès à la connexion.
7. Les licences Microsoft sont vérifiées. La licence d’accès client du serveur est d’abord vérifiée, puis la licence d’accès client du serveur Terminal est vérifiée. (L’octroi de licences est détaillé au chapitre 4.)
8. À ce stade, la session utilisateur est prête à commencer. Les scripts d’ouverture de session s’exécutent et le bureau est chargé.

Dans Windows Server 2003, un port d’écoute est associé à une connexion « . »En fait, les deux termes sont presque interchangeables. Vous configurez les propriétés d’une connexion et le port d’écoute de la connexion est modifié de manière appropriée.

Maintenant que nous avons couvert tous les composants qui composent un serveur de terminaux Windows 2003, passez aux exigences.