Der Server übernimmt die Last
Artikel erschienen in Swiss IT Magazine 2001/06
Die historische Idee hinter den Terminaldiensten ist die Reduktion des Aufwands für die Konfiguration und Konfigurationsanpassung bei Clients in Netzwerken. Statt die Anwendungen jeweils lokal bereitzustellen, können sie auch von einem Terminalserver abgerufen werden. Dadurch entfällt der Installationsaufwand ebenso wie der für Anpassungen. Ausserdem lässt sich potentiell eine grössere Sicherheit erreichen.
Ein weiteres klassisches Einsatzfeld der Terminaldienste besteht in der Ausführung von Anwendungen auf Systemen, auf denen diese eigentlich nicht lauffähig sind. Der Speicherbedarf des Terminaldienste-Clients ist verglichen mit dem beispielsweise für eine SAP-GUI oder ein Microsoft Office minimal. Damit können einerseits spezialisierte Terminal-Clients, andererseits aber auch 16- und 32-Bit-Windows-Clients erreicht werden. Mit dem Citrix Metaframe gibt es darüber hinaus ein Add-on, das eine Vielzahl weiterer Clients unterstützt - angefangen von Java-Applets über den Apple Macintosh bis hin zu einer Reihe von Unix-Plattformen. Das ist insbesondere dann interessant, wenn eine Windows-Anwendung in einheitlicher Weise und unabhängig von den eingesetzten Client-Betriebssystemen genutzt werden soll.
Neben diesen eher klassischen Einsatzbereichen existieren aber auch verschiedene neue Anwendungsbereiche. Dazu gehört beispielsweise die Nutzung der Terminaldienste für dezentrale Offices. Hier kann es sehr viel einfacher sein, mit den Terminaldiensten und einem Drucker-Switch zu arbeiten, als einen lokalen Server zu betreiben. Denn dieser erfordert zwangsläufig einen hohen Administrationsaufwand und kann zudem oftmals nicht in einer wirklich sicheren Struktur eingerichtet werden.
Ein zweiter wichtiger Bereich ist die Ansteuerung von mobilen Endgeräten insbesondere auf Basis von Windows CE. Hier können ebenfalls Terminalsitzungen ausgeführt werden. Durch die geringe benötigte Bandbreite können solche Sitzungen gegebenenfalls sogar über Verbindungen mit Transferraten von nur 9,6 kbps genutzt werden.
Eine weitere Einsatzvariante ist die Serveradministration über den Remote-Verwaltungsmodus. Die Terminaldienste sind bei Windows 2000 eine Standardfunktionalität des Servers, die bei allen Versionen verfügbar ist. Dies war beim Vorgänger, Windows NT, noch nicht der Fall, da die Terminaldienste eine Reihe von Anpassungen im Kernel erfordern, die bei Windows 2000 nun generell vorgenommen worden sind. Damit lassen sich die Terminal-Services nun auch jederzeit nachträglich installieren. Im Remote-Verwaltungsmodus kann dabei eine eigentliche Fernadministration von Systemen erfolgen.
In dieser Betriebsart werden maximal zwei parallele Verbindungen zum Server unterstützt, wobei dafür allerdings keine zusätzliche Lizenzierung erforderlich ist. Im Remote-Verwaltungsmodus wird eine grafische Schnittstelle für Server bereitgestellt, die für die dezentrale Verwaltung genutzt werden kann.
Der zweite unterstützte Modus ist der sogenannte Anwendungsservermodus, bei dem Applikationen von Clients genutzt werden können. Hierfür ist eine spezielle Lizenzierung nötig, auf die weiter unten noch eingegangen wird. Die Terminaldienste von Windows 2000 verwenden dabei das Protokoll RDP (Remote Desktop Protocol).
Die Terminaldienste verlagern die Ausführung von Anwendungen vom Client zum Server. Das bedeutet in der Konsequenz aber auch, dass sich die Last verlagert - es kann mit schlankeren Clients gearbeitet werden, dafür werden aber leistungsfähigere Server benötigt. Immerhin unterstützt das NLB (Network Load Balancing) von Windows 2000 auch die Verteilung von Terminalsitzungen auf verschiedene Terminalserver innerhalb einer Serverfarm.
Die Konsequenz aus dieser Verlagerung von Funktionalität auf den Server sind die gestiegenen Hardware-Anforderungen. Genaue Aussagen dazu lassen sich nur im konkreten Anwendungsfall treffen. Im Whitepaper Windows 2000 Terminal Services Capacity and Scaling finden sich aber doch einige wichtige Aussagen. Microsoft geht dort von verschiedenen Benutzerklassen aus. Denn ob ein Benutzer nur eine SAP-GUI und einen Browser oder eine komplette Office-Suite benutzt, hat doch einigen Einfluss auf das Systemverhalten. Microsoft setzt je nach Anwendungsbereich zwischen 3,5 MB und 9 MB Hauptspeicher an, wobei der höhere der Werte eher zu knapp bemessen ist. Ein Ein-Prozessor-Server mit 1 GB Hauptspeicher kann entsprechend zwischen 25 und deutlich über 250 Benutzern unterstützen - je nachdem, ob diese aktiv mit Office-Anwendungen arbeiten oder nur Daten eingeben. Daher werden Dateneingabe-Anwendungen typischerweise eher auf Ein- oder Zwei-Prozessor-Systemen betrieben, während bei sehr aktiven Benutzern auch die Zahl der Prozessoren stärker steigen wird. Allerdings ist Skalierung über vier Prozessoren hinaus nicht wirklich sinnvoll, da dann andere Einschränkungen beispielsweise in Bezug auf das Bus-System und den I/O greifen werden. Hier macht es dann deutlich mehr Sinn, mit NLB oder Clustern zu arbeiten.
Die eigentliche Installation ist in sehr einfacher Weise zu bewerkstelligen. Die Terminaldienste werden über den Bereich Software der Systemsteuerung eingerichtet. Dort finden sie sich unter Windows-Komponenten hinzufügen/entfernen bei der Option Terminaldienste. Nach der Installation ist ein Neustart erforderlich. Bei der Installation kann auch eine Erstellung von Disketten mit Client-Erstellungsdateien erfolgen, mit denen die Terminaldienste auf Rechnern eingerichtet werden können, die nicht mit vorinstallierten Terminal-Clients geliefert werden. Allerdings kann eine Verteilung der Software auch über das Netzwerk erfolgen.
Dieser Terminaldienste-Client ist denn auch die Schnittstelle zu den Terminaldiensten. Neben dem Windows-Client gibt es auch den neuen Advanced Terminal Services Client, der von www.microsoft.com/windows/downloads geladen werden kann. Dabei handelt es sich um ein ActiveX-Control, das beispielsweise auch in Web-Sites eingebunden werden kann.
Beim Terminaldienste-Client muss der Rechnername oder die IP-Adresse des Servers sowie die Bildschirmauflösung angegeben werden. Ausserdem können Festlegungen zum Caching getroffen werden. Diese Festlegungen haben Einfluss auf die verwendete Bandbreite. Bei schmalbandigen Leitungen empfiehlt sich eine Auflösung von maximal 800x600 Bildpunkten, die Komprimierung sowie das Zwischenspeichern von Bitmaps.
Nicht alle Anwendungen arbeiten ohne weiteres mit den Terminaldiensten. Das ist zwar bei den meisten Systemen der Fall. Es gibt aber eine Reihe von erforderlichen Anpassungen insbesondere bei älteren Applikationen und bei Systemen, die nicht in allen Details den Entwicklungsrichtlinien für Windows-Anwendungen folgen. Eine Ausführung von 16-Bit-Anwendungen ist dabei zwar grundsätzlich möglich, aber in den wenigsten Situationen sinnvoll, da durch das Speichermanagement sehr schnell Performance-Probleme auftreten können.
Zu berücksichtigen ist ferner, dass für jeden Benutzer eine Instanz der Anwendung gestartet wird. Das bedeutet, dass nun mehrere Instanzen um die Systemressourcen konkurrieren, die entsprechend - wie oben ausgeführt - ausgelegt sein müssen.
Ausserdem ist auch zu berücksichtigen, dass die Anwendung auf einem System von mehreren Benutzern verwendet wird. Das heisst, dass spezifische Einstellungen auch pro Benutzer und nicht pro System gehalten werden dürfen. Aus diesen Besonderheiten ergeben sich auch spezifische Anforderungen für das Design beziehungsweise die Konfiguration von Anwendungen.
Bei der Installation muss beispielsweise für jeden Benutzer ein eigenes Benutzerverzeichnis vorhanden sein. Es empfiehlt sich, dieses vorab zu konfigurieren, da es vom System im Verzeichnisbaum des Betriebssystems eingerichtet würde. Ausserdem sollte auch mit Benutzerprofilen gearbeitet werden, da sich nur so Änderungen in der Konfiguration in einer Form durchführen lassen, die von den Terminaldiensten verarbeitet wird. Über solche Profile müssen auch einige Anpassungen vorgegeben werden. Ein Beispiel dafür ist die Deaktivierung der rechenzeitintensiven Rechtschreibprüfung von Word, falls diese nicht zwingend erforderlich ist. Wenn mehrere Instanzen einer solchen Funktion laufen, kann das sehr schnell zu einer extrem hohen Systembelastung führen.
Zu beachten ist auch, dass .ini-Dateien, die beispielsweise von Lotus Notes immer noch verwendet werden, automatisch in die Benutzerverzeichnisse kopiert werden. Darüber hinaus werden Einträge aus HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software in HKEY_CURRENT_USER\Software kopiert.
Unkompliziert sind die Installationsvorgänge, wenn mit MSI-Files, also Dateien für den neuen Microsoft Windows Installer, gearbeitet wird. Diese können von Administratoren einfach über den Bereich Software der Systemsteuerung auf dem Terminalserver eingerichtet werden.
Zu beachten ist dabei, dass Anwendungen keine gemeinsamen DLLs in unterschiedlichen Versionen verwenden dürfen. Das stellt beispielsweise ein Problem dar, falls ein Internet Explorer in unterschiedlichen Versionen genutzt werden soll. Allerdings ist ein solches Szenario gerade im Zusammenhang mit dem Einsatz der Terminaldiensten ohnehin nicht wirklich sinnvoll.
Das grösste Problem beim Einsatz der Terminaldienste liegt aber darin, dass lokale, also benutzerbezogene, und globale, also systembezogene, Daten voneinander getrennt gehalten werden müssen.
Insbesondere betrifft das die gezielte und saubere Nutzung von HKEY_CURRENT_USER für Benutzerinformationen und HKEY_LOCAL_MACHINE ausschliesslich für Daten, die sich auf die Anwendung insgesamt beziehen. Es trifft aber in gleicher Weise auch auf Daten zu, die im Dateisystem abgelegt werden. Diese müssen, wenn sie sich auf einzelne Benutzer beziehen, logischerweise auch im Benutzerverzeichnis abgelegt werden. Das gilt nicht nur für Dateien, die explizit erstellt werden, sondern auch für ihre temporären Pendants.
Dadurch ergibt sich auch eine Reihe von Anforderungen für Anwendungsentwickler. Beispielsweise wirken sich Memory Leaks noch wesentlich gravierender aus als auf Clients, weil sich das Problem mit mehreren laufenden Instanzen multipliziert. Ausserdem muss bei Anwendungen, die nur einmal ausgeführt werden, sichergestellt sein, dass Logik und Präsentation sauber getrennt sind.
Ein gutes Beispiel sind hier Überwachungsanwendungen, bei denen die Informationen nur einmal gesammelt, aber mehrmals dargestellt werden sollen. Wichtig ist schliesslich auch noch, dass mit wechselnden IP-Adressen gearbeitet werden kann, denn jede Arbeitssitzung bei den Terminaldiensten hat ihre eigene IP-Adresse.
Immerhin unterstützen die Terminaldienste von Windows 2000 nun aber eine Anpassung der GINA (Graphical Interactive Network Logon), wie sie beispielsweise von Novells Client durchgeführt wird.
Die Liste der potentiellen Probleme macht aber deutlich, dass Anwendungen vor ihrem Einsatz mit den Terminaldiensten intensiv getestet werden müssen. Gegebenenfalls müssen sie dann über ACS (Application Compatibility Scripts) angepasst werden.
Microsoft stellt ein umfassendes Whitepaper zur Verfügung, das sich mit dieser Thematik beschäftigt. Dort werden die wichtigsten bekannten Anwendungsprobleme aufgeführt. Es macht Sinn, hier immer wieder nachzuschauen, um jeweils aktuelle Informationen zu erhalten.
So lässt sich beispielsweise der Microsoft SQL Server 7.0 nicht via Remote-Session über die Terminaldienste installieren. Zähler des Systemmonitors stehen wiederum nicht bei Remote-Sitzungen zur Verfügung. Allerdings lassen sich diese einmalig konfigurieren und dann nutzen. Es gibt aber auch noch eine Reihe weiterer Anwendungen, die nicht unkritisch sind. Dazu zählt beispielsweise das Snap-in für das Festplattenmanagement von Windows 2000.
Mit den Terminaldiensten wird eine relativ grosse Zahl von Scripts geliefert, die eine Anpassung der Anwendungen an die Terminaldienste erlauben. Sie stehen unter %systemroot%\Application Compatibility Scripts\Install bereit und stellen auch eine gute Basis dar, wenn andere Anwendungen Probleme machen. Ausserdem sollte im Einzelfall geprüft werden, ob es MSTs (Microsoft Transformations) speziell für die Verwendung mit den Terminaldiensten gibt. Das ist beispielsweise bei Microsoft Office 2000 der Fall.
Ein spannendes Thema bei den Terminaldiensten von Windows 2000 ist die Lizenzierung. Es werden hier entweder spezielle Terminal Server CALs oder eine unlimitierte Terminalserver-Internet-Connector-Lizenz insbesondere für den Einsatz mit dem Terminal Services Advanced Client Service (TSACS) oder Windows 2000 benötigt, bei dem die Lizenz integriert ist.
Schliesslich gibt es noch temporäre Lizenzen. Diese werden mit einer Gültigkeit von 90 Tagen ausgegeben, wenn ein Terminalserver keine gültigen Lizenzen von einem Lizenzserver erhält. Sie sorgen dafür, dass der reibungslose Betrieb nicht unterbrochen wird. Die Vergabe dieser temporären Lizenzen wird ebenfalls vom Lizenzserver überwacht. Zugriffe sind nur in diesen ersten 90 Tagen möglich. Der Sinn der temporären Lizenzen liegt darin, einen Zugriff auch dann zu erlauben, wenn die offiziellen Lizenzen auf dem Lizenzserver beispielsweise aus Abwicklungsgründen nicht rechtzeitig zur Verfügung stehen.
Um die offiziellen Lizenzen zu erlangen, hat Microsoft ein interessantes Modell entwickelt. Die Lizenzen müssen bei Microsoft angefordert und über eine eindeutige ID aktiviert werden. Microsoft stellt dafür ein License Clearinghouse bereit. Dieses aktiviert die Lizenzen für die Terminaldienste und liefert sogenannte Client License Key Packs an die Lizenzserver. Der Zugriff erfolgt über einen Assistenten in dem Verwaltungsprogramm der Lizenzdienste. Die Anforderungen von Lizenzen kann dabei über Internet, Mail, Fax oder andere Wege erfolgen.
Da beim Einsatz der Terminaldienste zwingend ein Lizenzserver benötigt wird, muss dieser auch sinnvoll im Netzwerk positioniert werden. Der Lizenzserver wird immer über das Active Directory gesucht. Da die direkte Kommunikation aber nicht zwischen Clients und Lizenzserver, sondern ausschliesslich zwischen den Terminal- und den Lizenzservern erfolgt, bedeutet das, dass diese Serversysteme in räumlicher Nähe positioniert werden müssen.
Wichtig ist ferner auch, dass das Modell fehlertolerant ausgelegt ist, so dass beim Ausfall eines Lizenzservers oder bei nicht ausreichend freien Lizenzen auf diesem automatisch auf andere Lizenzserver zugegriffen werden kann.