Desktops in der Ferne
Windows-Terminalservices

von Ralph Staudigl (Ausgabe 03/1, März 2003)

 

Windows-Terminalservices bieten die Möglichkeit, einzelne Windows-Programme oder das komplette Windows-Betriebssystem nicht am eigenen Rechner (der natürlich ebenfalls ein Betriebssystem benötigt), sondern auf einem Server laufen zu lassen. Am Arbeitsplatzrechner befindet sich nur ein relativ kleines Programm, der sogenannte Terminalservices-Klient, der bei aktuellen Windows-Systemen bereits standardmäßig integriert ist (z.B. die Remotedesktopverbindung in Windows XP). Der Klient leitet einerseits die Tastatureingaben und die Mausbewegungen bzw. -klicks zum Server weiter; andererseits übernimmt er die Bildschirmausgabe vom Server und stellt sie - als Fenster oder im Vollbildmodus - am lokalen Monitor dar (siehe Abb. 1). Aus der Sicht des Benutzers scheint das Programm am eigenen Computer zu laufen, und es besteht jederzeit die Möglichkeit, zwischen der Terminalserver-Ansicht und der des lokalen Rechners zu wechseln.

Bildschirmausgabe
Abb. 1: Tastatur- und Mauseingaben am lokalen Rechner

Windows-Terminalservices bieten folgende Vorteile:

  • Ein Benutzer kann über Programme bzw. Windows-Versionen verfügen, die nicht auf seinem Rechner installiert sind (Remote-Zugriff), und muß dazu nicht einmal einen Windows-PC verwenden.
  • Da der Terminalservices-Klient kaum Ansprüche an den lokalen Rechner stellt, können auch Applikationen mit hohen Ressourcen-Anforderungen auf älteren oder weniger gut ausgestatteten Geräten benutzt werden.
  • Der Server, auf dem die Terminalservices laufen, kann viele Benutzer gleichzeitig bedienen.
  • Die bereitgestellten Programme können zentral am Server gewartet werden und müssen nicht auf die einzelnen lokalen Rechner verteilt werden.

Darüber hinaus hat man folgende Möglichkeiten:

  • Zugriff auf lokale Laufwerke
    Obwohl die Anwendungen in einer Terminalservices-Sitzung auf dem Server laufen, kann man auch auf Daten am lokalen Rechner zugreifen, da im Windows Explorer neben den Laufwerken des Servers auch alle lokalen Laufwerke (Disketten-, CD-ROM-Laufwerk und Festplatten) sichtbar sind.
  • Zugriff auf lokale Drucker
    Der lokale Drucker wird bei der Verbindung zu einem Terminalserver automatisch der Liste aller am Server verfügbaren Drucker hinzugefügt. Möchte man Dokumente auf einem lokal angeschlossenen Drucker ausgeben, muß dieser nur aus der Liste ausgewählt werden.
  • Kopieren und Einfügen zwischen Terminalserver und lokalem Rechner
    Möchte man die Zwischenablage oder Dateien übertragen, genügt es, den jeweiligen Text, das Bild oder die gewünschten Dateien im Kontextmenü (rechte Maustaste) zu kopieren, auf die Ansicht des anderen Computers zu wechseln und die Daten wieder einzufügen.

Verwendet man auf dem Terminalserver Netzwerkdienste, muß man sich der Tatsache bewußt sein, daß man dessen Netzwerkregeln unterliegt. Ist man z.B. am lokalen Computer berechtigt, auf bestimmte Internetseiten zuzugreifen, ist dies bei Verwendung eines Webbrowsers auf dem Server eventuell nicht möglich. Auch Firewall-Einstellungen sind von dieser Regelung betroffen.

Remote, aber wie?

Im aktuellen Windows Server sind die Terminalservices bereits integriert. Hier wird zur Kommunikation zwischen Server und Klient und zur Übertragung der Benutzer-Daten RDP (Remote Desktop Protocol) in der Version 5.1 verwendet. Bei den aktuellen Windows-Plattformen ist ein Klient bereits enthalten. Mit dem kostenlosen rdesktop steht für die meisten Unix-Plattformen unter X-Windows ebenfalls ein Klient zur Verfügung, und selbst für MacOS X existiert ein Microsoft-Klient. Falls nicht anders angegeben, beziehen sich die in diesem Artikel vorgestellten Funktionen auf RDP 5.1, das unter Windows XP und dem künftigen Windows Server 2003 zum Einsatz kommt.

Von der Firma Citrix stammt das Produkt MetaFrame XP, das einen bereits vorhandenen Windows Server voraussetzt. Die Citrix-Produkte verwenden als Protokoll ICA (Independent Computing Architecture), das im wesentlichen dieselbe Funktion wie RDP besitzt. Allerdings waren ICA-Klienten schon viel früher für verschiedene Plattformen verfügbar, und auch Features wie beispielsweise hohe Farbtiefe, Umleiten der seriellen Schnittstelle (COM-Port) und Audioausgabe wurden wesentlich früher implementiert als bei RDP.

MetaFrame XP bietet im Vergleich mit Microsofts Windows Server einige zusätzliche Funktionen:

  • Lastverteilung über mehrere Server
    Gesetzt den Fall, es existieren zwei oder mehr Windows-Terminalserver und man möchte für 50 Benutzer in öffentlichen PC-Räumen MS-Office zur Verfügung stellen, so ist es auch ohne MetaFrame-Erweiterung möglich, die Benutzer auf mehrere Server zu verteilen. Dies geschieht jedoch eher zufällig - ist also aus irgendeinem Grund ein beteiligter Server schon sehr ausgelastet, bekommt er weiterhin Benutzer zugewiesen. Mit der MetaFrame-Erweiterung (im folgenden MetaFrame-Server genannt) wird die Verteilung der Benutzersitzungen jedoch der Auslastung der einzelnen Server angepaßt. Damit ist der Aufbau einer Server-Farm möglich, die im Gegensatz zu einer Server-Farm unter Windows auch die Anzahl der Instanzen des Programms, die CPU- und Speicherbelegung und die maximale Netzwerkbandbreite berücksichtigt.
  • Veröffentlichen von Anwendungen unabhängig vom Desktop des Servers
    Unter Windows-Terminalserver (d.h. via RDP) ist nur eine Verbindung zum Desktop des Terminalservers, jedoch nicht zu einer einzelnen Anwendung möglich - das gewünschte Programm kann also erst dann ausgewählt werden, wenn die Verbindung mit dem Server bereits besteht. Die auf einem MetaFrame-Server verfügbaren Anwendungen scheinen hingegen unabhängig von der Verbindung zum Server auf dem Desktop des PCs auf und sind von Verknüpfungen mit lokalen Anwendungen nicht zu unterscheiden.
  • Rahmenlose Fenster
    Nachdem eine Sitzung mit einem MetaFrame-Server zustande gekommen ist, wird nur die Anwendung selbst angezeigt, ohne Hinweis darauf, daß es sich dabei um ein Netzwerk-Service handelt (also ohne den für Terminalservices typischen Rahmen bei der Ansicht eines Desktop-Ausschnitts). Die Anwendung erscheint so, als ob sie direkt auf dem lokalen Rechner laufen würde. Es könnte aber auch statt einer einzelnen Anwendung der gesamte Desktop zur Verfügung gestellt werden.
  • Lokales Drucken von allen Windows-Plattformen
    Im Gegensatz zu RDP-Klienten ist das Drucken auf lokalen Druckern auch von älteren Windows-Plattformen aus möglich, wenn die entsprechenden Treiber auf dem Server unter MetaFrame zur Verfügung gestellt werden.
  • Integration in WWW-Umgebungen
    Der Verbindungsaufbau zu einem MetaFrame-Server kann auch durch einen Hyperlink gestartet werden.
  • Unix-Integration
    Die UNIX Integration Services (eine auf MetaFrame aufbauende Erweiterung) vermögen die Bildschirmausgabe eines MetaFrame-Servers auch via X11-Protokoll an einen beliebigen X-Server zu schicken.

Einsatz am ZID

Am ZID werden Terminalservices sowohl mit als auch ohne MetaFrame-Erweiterung eingesetzt. Für Office- und Acrobat-Kurse steht ein einzelner Server unter Windows 2000 Terminal Services zur Verfügung. Es handelt sich dabei um eine Pentium III-Doppelprozessormaschine mit je 1 GHz und insgesamt 1,6 GB RAM, was für rund 30 bis 40 Office-Benutzer ausreichend ist.

Wie im Artikel Software, Everywhere... beschrieben, bringt die Fernwartung einer großen Anzahl von PCs einiges an Problemen mit sich, sodaß es an Instituten nicht möglich ist, individuelle Software für Lehrveranstaltungen in den PC-Räumen zu installieren. Dieses Problem läßt sich mit Hilfe der Terminalservices umgehen, da die benötigte Software, sofern sie in einer Terminalserver-Umgebung läuft, unabhängig vom Software-Angebot der PC-Räume verwendet werden kann. Wird an einem Institut ein Terminalserver betrieben, stellt der Zentrale Informatikdienst bei Bedarf in den betreffenden PC-Räumen die Terminalservices-Klienten zur Verfügung.

Den größten Einsatz am ZID erfahren die Terminalservices bei den Datenbank-Services der Universitätsbibliothek. Diese starteten 1998 mit einem Server, auf dem Citrix WinFrame unter Windows NT 3.51 verwendet wurde, das später durch Citrix MetaFrame 1.8 unter Windows NT 4.0 Terminal Server Edition abgelöst wurde. Nach der Übernahme der Datenbank-Services durch den ZID erfolgte schließlich die Umstellung auf Windows 2000 mit MetaFrame XP. Die Funktionen des ICA-Protokolls waren insofern unabdingbar, als sie von Anfang an das lokale Speichern von Ergebnissen einer Datenbankrecherche ermöglichten; darüber hinaus muß dafür nur das (kostenlose) ICA-Plugin für den verwendeten Webbrowser installiert werden. Mittlerweile befindet sich hinter den Kulissen ein MetaFrame XP-Cluster aus sieben Servern, die unter Windows 2000 Server laufen. Der Grund für diese Aufteilung liegt nicht nur in der Last durch viele Benutzer, sondern auch in der großen Anzahl verschiedener Retrievalprogramme und den daraus resultierenden Datenmengen.

Tips für Systemadministratoren

Für den Systemadministrator eines aktuellen Windows-Servers ist es relativ leicht, die Terminalservices zu aktivieren, wobei jedoch folgende Punkte beachtet werden sollten:

  • Hardwareausstattung
    Da die Rechen- und Dateiverwaltungsarbeit aller verbundenen Benutzer serverseitig abläuft, ist eine stärkere Hardware (beispielsweise ein bis zwei schnelle CPUs und deutlich mehr Hauptspeicher) als bei einem Arbeitsplatzrechner vonnöten.
  • Zeitpunkt der Aktivierung
    Die Terminalservices müssen vor der Installation von Programmen aktiviert werden: Um die bei der Programminstallation vorgenommenen Standardeinstellungen allen Benutzern zugänglich zu machen, werden diese in einen benutzerunabhängigen Bereich der Registry (Windows-Konfigurationsdatenbank) umgeleitet. Programme, die bereits vor der Aktivierung der Terminalservices installiert wurden, müssen daher nach der erfolgten Aktivierung neu installiert werden.
  • Softwareinstallation
    Ein Großteil der aktuellen Software funktioniert auch auf einem Terminalserver. Bei 16-Bit-Programmen kann es jedoch insofern zu Problemen kommen, als diese oft auf Systembereiche zugreifen müssen, die seit Windows 2000 standardmäßig geschützt sind. Auch die früheren Office-Pakete können bei der Installation auf einem Terminalserver Probleme bereiten. Mit entsprechenden Anpassungen des Systems ist es aber meist möglich, die jeweilige Software zu installieren.
  • Benutzerverwaltung
    Bei einem einzelnen Server müssen natürlich auch die Benutzerkonten zusätzlich angelegt und verwaltet werden - außer wenn eine Windows-Domäne vorhanden ist oder wenn man sich für die Verwendung anonymer Benutzerkonten entschließt.
  • Filesystem und Security
    Falls das Vertrauen in die Umsicht der Benutzer nicht ausreichend gegeben ist, lohnt es sich, eine grundlegende Absicherung des Filesystems und eine Einschränkung der Benutzerrechte durchzuführen, da einige sensible Teile des Betriebssystems jedem Benutzer zugänglich (sprich: zerstörbar) sind. Das Ausmaß der Einschränkungen ist stark von den Anforderungen des geplanten Einsatzgebiets abhängig. Grundsätzlich sollte man möglichst wenig Schreibrechte auf Systemverzeichnisse und (im Idealfall) keine auf Programmverzeichnisse gestatten.
  • Policies
    Um den Benutzern den Zugriff auf verschiedene Systembereiche zu untersagen (oder zumindest zu erschweren), muß man ihre diesbezüglichen Rechte einschränken. Dies ist zwar in einer Active Directory-Domäne relativ leicht zu lösen (durch Anwenden von Policies auf Organisationseinheiten - engl. Organizational Units -, in denen sich die Benutzer befinden), jedoch mit einem erheblichen administrativen und finanziellen Mehraufwand verbunden. Auch auf einem einzelnen Server ist es möglich, die Benutzer durch die lokalen Richtlinien mit den gleichen Optionen zu beschränken wie in einer Active Directory-Domäne. Der kleine Nachteil daran ist, daß davon auch der Systemadministrator betroffen ist, was dieser aber durch ein Login-Skript beheben kann: Da Policies nichts anderes sind als Registry-Einträge, kann man sie durch das Skript wieder entfernen, was unter Zuhilfenahme der für die jeweilige Policy zuständigen ADM-Datei (zu finden in %windir%\inf) mit etwas Tüftelei zu bewerkstelligen ist.
  • Drucken
    Für die Druckausgabe ist es zwar prinzipiell möglich, einen am PC installierten Drucker über den Server anzusprechen; es muß sich beim PC-Betriebssystem aber zumindest um Windows 2000 handeln. Als Alternative kann vom Administrator ein Druckserver direkt am Terminalserver installiert werden.
  • Zugriff auf lokale Laufwerke
    Dem Benutzer werden zwar alle lokalen Laufwerke automatisch zur Verfügung gestellt, sie sind aber keinen Laufwerksbuchstaben zugeordnet. Um den Zugriff zu erleichtern, ist es sinnvoll, wenn der Systemadministrator dies in den Login-Skripts berücksichtigt.
  • Citrix MetaFrame
    Benötigt man Funktionen der MetaFrame-Erweiterung, darf man nicht vergessen, daß diese neben den zusätzlichen Funktionen auch einen höheren Implementierungsaufwand und höhere Kosten mit sich bringt.
  • Lizenzierung
    Zwar sind die Klienten sowohl für die Windows-eigenen Terminalservices als auch für MetaFrame XP kostenlos, die Zugriffslizenzen auf den Server jedoch nicht. Für verschiedene Klienten-/Server-Kombinationen sind unterschiedliche Lizenzierungsmodelle vorgesehen, die an die Art der Installation angepaßt werden müssen. Die Lizenzen für RDP sind nur bei den aktuellen Klienten ab Windows 2000 inkludiert (was sich mit der Veröffentlichung von Windows Server 2003 jedoch noch ändern kann), für ältere Klienten betragen die Lizenzkosten jeweils EUR 5. Nähere Informationen zu Terminalserver-Zugriffslizenzen (Client Access Licenses) an der Uni Wien erhalten Sie bei Peter Wienerroither (Tel.: 4277-14138).

    Citrix-Produkte hingegen sind nicht im Rahmen der Standardsoftware, sondern nur im Handel erhältlich. Für universitäre Einrichtungen betragen die Kosten für eine MetaFrame XP-Lizenz inklusive fünf Benutzerlizenzen EUR 2157 und für fünf zusätzliche Lizenzen weitere EUR 1354. Darüber hinaus müssen auch noch Lizenzen für Windows-Terminalservices erworben werden.

So hilfreich ein Terminalserver in bestimmten Situationen auch sein mag - der Planungs-, Installations- und Wartungsaufwand ist auf jeden Fall zu bedenken: Abhängig von den Vorkenntnissen sind für eine einfache Installation ein bis zwei Wochen, für eine ausgeklügeltere Konfiguration weitere zwei bis drei Wochen zu veranschlagen.