Für den Zugriff von TCs auf Windows-Terminal-Server verlangt Microsoft immer eine passende Lizenz. Beim Einsatz von zusätzlichen Lösungen fallen daher Lizenzkosten für den Zugriff auf den Windows-Server und für die zusätzliche Lösung an. TCs bringen in der Regel einen Client für RDP und ICA mit. Bei anderen wie Tarantella oder Jetro muss das Unternehmen mit dem TC-Hersteller klären, ob es bereits eine Lösung gibt, oder der Hersteller für den Kunden die Client-Software integriert.

Die Typfrage

Hat sich ein Unternehmen auf TC eingelassen, muss es entscheiden, welchen Typen es einsetzen will. Um TCs einzuteilen, gibt es sicher verschiedene Möglichkeiten. Über die des TC sagt das Betriebssystem, das dieser betreibt, sicher am meisten aus. Am gebräuchlichsten sind derzeit Windows-based- oder Linux-based-Terminals. Windows-based-Geräte verwenden entweder ein angepasstes Windows-CE oder nutzen Windows-XP-embedded (XPe).

Network-Computer, die das Thema TCs erstmals richtig in die Öffentlichkeit gebracht haben, sind wieder von der Bildfläche verschwunden. Eine Ausnahme bildet die »SunRay«-Lösung. Schließlich gibt es noch Netzwerk-PCs oder TC-PCs. Beide sind aber keine reinen TC-Formen. Netzwerk-PCs besitzen zwar ein zentrales Management. Aber ihre Hardware ist die eines normalen PCs mit allen Anfälligkeiten und Sicherheitsfragen. Ähnliches gilt für TC-PCs. Diese erhalten entweder über Software oder einen Hardware-Einschub eine TC-Oberfläche verpasst. Auch hier läuft unter der Haube also eine PC-Hardware weiter. Allerdings bietet sich dieses Vorgehen als Übergangslösung an, wenn ein Server-based-Computing bereits steht, die TCs aber erst in einem späteren Schritt kommen sollen.

Die Popularität von TCs begann erst mit dem Aufkommen der Windows-based-Terminals. Die Clients laufen typischerweise mit Windows-CE. XPe oder dessen Vorgänger. NT-embedded haben höhere Hardware-Anforderungen und kommen eher zum Einsatz, wenn auf dem Client etwa Anwendungen laufen sollen, die nicht für Windows-CE verfügbar sind. Ursprünglich war es deutlich schwieriger, die CE-Clients zu bauen und Treiber zu integrieren. Ab Windows-CE.Net besitzt das Betriebsystem jedoch einen modularen Aufbau, so dass es flexibler in der Anpassung ist. Mit CE.Net kommt der Internet-Explorer 6 hinzu. CE beherrscht seitdem SNMP, kann mit Smartcards umgehen und versteht PPTP. Für den Nachfolger Windows-CE 5.0 gibt es erste Geräte von TC-Herstellern. CE-5.0 arbeitet jetzt mit der 32-Bit-PC-Card-Architektur, unterstützt USB 2.0 und Bluetooth. Für das Dot-Net-Framework bringt es das Service-Pack 2 mit. Außerdem kommt mit CE-5.0 die RDP-Version 5.5.

XPe besitzt ebenfalls einen modularen Aufbau. Um den NTOS-Kernel gruppieren sich verschiedene Komponenten wie Netzwerk-Interface, Maus und Tastatur, PCI-Interface, Parallel-Port oder USB-Interface. Auf diesem Basissystem laufen dann Anwendungen für Windows-XP wie Internet-Explorer, Sun-Java-Virtual-Machine oder Acrobat-Reader. Auch XP-embedded besitzt sein Service-Pack 1. Es erlaubt jetzt Remote-Boot oder Diskless-Betrieb und bringt das Dot-Net-Framework mit. Für XP-embedded gibt es einen »Platform Builder« und ein »Target Designer Windows Embedded«-Tool-Set. Gegenüber Windows-CE spielt es vor allem seine Stärken im Projektgeschäft aus, wenn es beispielsweise um individuelle Anforderungen und daraus resultierende Treiberanforderungen geht.

Linux-based-Clients haben in jüngster Zeit immer mehr an Gewicht gewonnen. In einer Umgebung mit Unix- oder Linux-Servern besitzen sie den Vorteil, dass sie einen X11-Server für den Zugriff auf die Unix- oder Linux-Server bereits mitbringen. Ein besonderes Plus für Linux-TCs besteht darin, dass ihnen die komplette Vielfalt der Linux-Opensource-Software zur Verfügung steht und spezielle Lösungen sich relativ einfach anpassen lassen. Auch können hier TC-Hersteller recht flexibel auf Anforderungen im Projektgeschäft reagieren. Allerdings gibt es Fälle, in denen es beispielsweise für Peripheriegeräte keinen Linux-Treiber gibt. Dann kommt wieder XPe zum Zug. Mittlerweile haben nahezu alle TC-Produzenten sowohl Window-based- als auch Linux-based-Clients in ihrem Portfolio.

Die Sun-Ray-Lösung fällt hier ein wenig aus dem Rahmen, weil »SunRay Ultra Thin Clients« kein lokales Betriebssystem auf dem Client besitzen wie typischerweise die Thin-Clients mit Windows oder Linux. Stattdessen lädt eine kleine Firmware beim Start alles Notwendige vom »Sun Ray Server«. Über DHCP erhält der Client dann unter anderem seine IP-Adresse. Server und TC sprechen ihr eigenes Protokoll, so dass Sun-Ray-Clients auch wirklich nur mit dem Sun-Ray-Server zusammenarbeiten.

Druckvoll arbeiten

Das Drucken scheint ein besonderes Problem im Einsatz von Windows-Terminal-Servern zu sein. Druckertreiber können die Server richtig aus dem Gleichgewicht bringen. Aus diesem Grund bringen die Windows-Terminal-Server-Ergänzungen auch entsprechende Lösungen. Diese enthalten einmal einen universellen Druckertreiber auf dem Server. Außerdem stellen die Lösungen Bandbreitenbegrenzung und Komprimierung zur Verfügung. Dabei wandelt der universelle Druckertreiber die Druckerdaten in ein allgemeines Format wie PCL oder PDF um, bevor er es zum TC schickt. Neben den Windows-Terminal-Server-Lösungen gibt es noch eigene Produkte wie »ThinPrint« oder »Uniprint«, die sich dieses Themas annehmen. Diese beiden Lösungen verlangen allerdings, dass ein zugehöriges Stück Software auf dem TC liegt. Der Thin-Print-Client befindet sich dabei standardmäßig schon auf einigen TCs.

Zentrales Management gehört dazu

Wenn bei TCs der Konfigurationsaufwand gegenüber einem PC auch geringer ist, fällt er doch nicht ganz weg. Um nicht wieder bei der Turnschuh-EDV zu landen, muss der Administrator neben der lokalen Konfiguration auch remote auf den TC zugreifen können. Hier bringen TCs etwa einen integrierten Web-Server oder eine Secure-Shell wie bei Linux-Geräten mit. Allerdings steigt der Aufwand auch bei einem Remote-Management bei einer größeren Anzahl von Clients, so dass sich das Ganze nur noch schwer oder gar nicht mehr verwalten lässt. Deshalb gehört eine zentrale Management-Lösung zur Pflichtausstattung eines TC-Angebotes.

Die Management-Lösungen der TC-Hersteller beschränken sich in der Regel auf die eigenen Clients. Hat der Hersteller mehrere Produktlinien im Programm, lohnt es hinzuschauen, ob er denn alle Geräte mit der gleichen Funktionalität verwaltet und auch alle Möglichkeiten des Clients abbildet. Hat ein Unternehmen Geräte von mehreren Herstellern im Programm, handelt es sich damit normalerweise auch mehrere Management-Programme ein. Eine Ausnahme bildet hier »Rapport« von Wyse, das auch Neoware-TCs verwalten will. Die Beschränkung auf die eigenen Geräte bedeutet auch, dass ein Unternehmen, das etwa TCs und PC einsetzt, auch dafür verschiedene Management-Programme benötigt. Eine Ausnahme bilden HP-TCs. Sie besitzen einen Agenten für die »Client Management Suite« von Altiris, die auch Laptops und PCs verwaltet.

Um größere Mengen von TCs effizient zu verwalten, sollte die Management-Software Gruppen unterstützen. Diesen Gruppen weist der Administrator dann stattdessen die Konfiguration zu. Gut ist es, wenn die Software auch Ausnahmen in einer Gruppe zulässt.

Manchmal stellen Administratoren sich einen TC ins Büro, den sie dann remote konfigurieren. Anschließend laden sie die Konfiguration als Template auf den Management-Server und verteilen sie über diesen an die entsprechenden Clients. Dies Vorgehen hat den Vorteil, dass der Administrator schon zu Beginn weiß, dass die ausgewählte Konfiguration so funktioniert.

Ein Client-Discovery hilft dem Administrator, seine TCs schnell in das Management zu integrieren. Allerdings sollte er den Discovery-Vorgang auch abstellen können, ansonsten hat er vielleicht in regelmäßigen Abständen zusätzliche Broadcasts auf seinem Netz.

Damit ein Administrator auch bei der Erstinstallation eines Clients nicht vor Ort sein muss, wäre es ideal, wenn dieser sich beim erstmaligen Booten vom Management-Server automatisch die Konfiguration holt, dessen Adresse er etwa über DHCP erfährt. Für Firmware-Update ist eine Wakeup-on-LAN-Funktion gut. Dann kann der Administrator hoffentlich zeitgesteuert nachts die Aktualisierung durchführen. Anwender müssen dann beispielsweise morgens nicht warten, bis der Client beim Booten sein Firmware-Update erledigt hat.

Über ICA oder RPD kann der Administrator parallel zum Anwender über Shadowing auf den TC-Destop zugreifen. Allerdings kann der Administrator eventuell über die Management-Lösung auch ohne ICA oder RDP mit Shadowing arbeiten.

Fazit

Thin-Clients stellen ein interessantes Instrument dar, um die Kosten und den Administrationsaufwand zu senken. Sie bilden aber nur einen Baustein im Gesamtkonzept des Server-based-Computing, um Kosten zu senken und IT zu zentralisieren. Vor dem Einsatz von TCs muss zuerst die Server-based-Computing-Farm stehen. Erst dann kommen TCs in einem zweiten Schritt an die Reihe. Nicht alle Anwendungen eignen sich für Server-based-Computing. Einem Einsatz sollte daher ein gründlicher Test der benötigten Anwendungen vorausgehen. Bei der Auswahl der TCs geht es einmal vor allem um die Wahl des Betriebssystem: Linux, Windows-CE oder XP-embedded. Hier hängt viel davon ab, welche Anwendungen auf dem Client arbeiten sollen und in welchem Umfeld er zum Einsatz kommt. Beispielsweise kann eine Entscheidung dadurch fallen, dass ein Treiber für ein bestimmtes Peripheriegerät nur auf einer Plattform zur Verfügung steht. Zum anderen sollte auch die Leistungsfähigkeit der zentralen Management-Software bei der Auswahl der TC-Lösung mit eingehen. [ wve ]