Praxistest: Wyse Streaming Manager 1.1.3
Alles im Fluss
Durch das Streamen (serverseitige Bereitstellung in Echtzeit) von Betriebssystem und Anwendungen können sogar Ultra Thin Clients ohne Flash-Speicher als vollwertiger PC-Ersatz dienen. Im LANline-Test musste der Streaming Manager von Thin-Client-Marktführer Wyse seine Praxistauglichkeit unter Beweis stellen.
Der Wyse Streaming Manager stellt Betriebssysteme und Applikationen als separate Images bereit
und liefert sie nach Bedarf über das Netzwerk an die Clients. So sind sogar Thin Clients (TCs) ohne
Flash mit Windows XP Professional und den gewünschten Applikationen einsetzbar. Ein Unternehmen
kann zudem vorhandene ältere PCs so mit Software versorgen und die Vorteile einer zentralisierten
TC-Infrastruktur auch für diese Systeme nutzen. Terminalserverumgebungen lassen sich per Streaming
sinnvoll ergänzen, um nicht terminalserverfähige Anwendungen zentral vorzuhalten. Das Streaming
eignet sich zudem sehr gut für Schulungsräume, in denen die Benutzer immer dieselbe Arbeitsumgebung
vorfinden sollen.
Verschiedene WSM-Tools
Der Wyse Streaming Manager (WSM) besteht aus mehreren Komponenten: Das Streamen der
Betriebssystem- und der Application-Set-Images erfolgt über den Core-Server. Das
Betriebssystem-Image erstellt der Administrator mit den Wyse Client Tools auf einem Referenzgerät
des jeweiligen Hardwaretyps. Die gewünschten Anwendungen paketiert er mit dem Publisher auf einem
eigenen Rechner. Betriebssysteme und Anwendungspakete weist er dann über die zentrale
Webverwaltungsoberfläche des WSM den gewünschten Geräten und Anwendern zu. Dabei kann WSM vom
Active Directory (AD) Benutzer- und Gruppenkonten übernehmen. Die Anwender erhalten damit immer die
für sie freigeschalteten Applikationen, unabhängig davon, an welchem Client sie sich gerade
anmelden.
Derzeit unterstützt WSM Client-seitig Windows 2000 und XP Professional; Linux ist in
Vorbereitung. Laut Hersteller kann ein Streaming-Server bei entsprechend leistungsfähiger Hardware
zirka 50 bis 70 Clients versorgen. Das Netzwerk sollte mindestens Fast Ethernet (100 MBit/s)
liefern. Damit sich Clients beim Ausfall eines Core-Servers neu starten lassen, kann der
Administrator die Images zusätzlich über einen zweiten Core-Server vorhalten. Für hochverfügbare
Konfigurationen lassen sich laut Wyse zudem die WSM-Dienste und die MS-SQL-Datenbank clustern. Für
das Streaming in Filialen bietet der TC-Spezialist mit dem Edge-Server eine Version an, die eine
Kopie der auf dem Core-Server gespeicherten Images bereitstellt. Der Edge-Server führt keine
AD-Authentifizierung durch und nimmt keine Datenbankeinträge vor. Edge-Server lassen sich auch für
die Lastverteilung in der Zentrale nutzen.
Für den LANline-Test stellte Wyse einen V00-Client ohne Flash mit 512 MByte RAM sowie als
Referenzgerät für die Betriebssysteminstallation ein VR0-Gerät mit 2 GByte Flash und 256 MByte RAM
bereit. Zudem kam ein älterer Intel-PC mit 256 MByte RAM zum Einsatz, für den wir ebenfalls ein
Image konfigurierten. Auch Vmware-Sessions lassen sich laut Wyse mit der Streaming-Lösung
einsetzen. Damit die Clients über das Netzwerk vom WSM-Image booten können, müssen sie mit
PXE-fähigen Netzwerkkarten ausgestattet sein. Zudem ist ein DHCP-Server erforderlich, auf dem die
Option Tags 66 (Boot Server Name) und 67 (Boot File Name) gesetzt sind. Des Weiteren ist ein
TFTP-Daemon nötig, der zum Beispiel in Microsofts Remote-Installation-Services (RIS) enthalten ist.
Schließlich muss der Administrator in der Registry unter TFTPD\parameters einen neuen Wert mit dem
Pfad zum Wyse-TFTPboot-Verzeichnis hinzufügen.
Für den Test kam ein Windows-2003-Server als DHCP- und TFTP-Server zum Einsatz, ein weiterer
diente als Domänen-Controller. Als Datenbank nutzt WSM einen MS SQL 2000 Server mit SP4 (SQL 2005
soll demnächst unterstützt werden). Die Kommunikation der Webverwaltungsoberfläche mit dem
SQL-Server erfolgt über den Microsoft-Treiber "JDBC for Database Connectivity", den wir ebenfalls
noch vor der Installation des Core-Servers aufgespielten. Beim Setup des Core-Servers kann der
Administrator unter anderem angeben, in welchem Verzeichnis die Images abzulegen sind. Wyse
empfiehlt eine dedizierte Festplatte, damit die Images bei einem System-Crash über ein Ersatzsystem
schnell wieder verfügbar sind. Nach der Installation des Core-Servers 1.1 spielten wir das Update
auf WSM 1.1.3 ein. Diese Version ermöglicht es dem Administratoren, die WSM-Clients von der
Webkonsole aus herunterzufahren und neu zu starten. Zudem unterstützt die neue Version PCs mit
Hyper-Threading und Dual-Core-CPUs.
Beim ersten Start der Weboberfläche des WSM-Servers öffnet sich ein Assistent, in dem der
Administrator die AD-Integration aktivieren kann und den Pfad zur WSM-Lizenzdatei angibt. Für die
Client-Zugriffe richteten wir im AD zwei Testanwender ein und fügten sie einer gleichnamigen Gruppe
hinzu. Diese Gruppe ließ sich anschließend über das Web-GUI per Mausklick in die
WSM-Verwaltungsdatenbank importieren. Der Core-Server gleicht die Benutzerdaten regelmäßig mit dem
AD ab.
Betriebssystemabbild erstellen
Nun war Windows XP Professional im Flash des VR0-Referenzgeräts zu installieren. Dazu schlossen
wir ein externes DVD-Laufwerk per USB an, spielten mit einer XP-CD das Betriebssystem auf und
übernahmen den Client dann in die Testdomäne. Um vom frischen System ein Image zu erstellen,
installiert der Admin danach den WSM-Client auf dem Referenzgerät. Das Tool fertigt nicht nur das
Image an, sondern sorgt auch dafür, dass der Client über das Netz booten und die für ihn
freigeschalteten Applikationen nutzen kann.
Im Test brach das Setup des WSM-Clients zunächst mit der Fehlermeldung ab, die Datei otinst.dll
sei nicht auffindbar. Ein Blick ins Handbuch brachte schnell die Ursache zu Tage: Dieser Fehler
tritt auf, wenn das Service-Pack 2 für XP nicht installiert ist. In diesem Fall ist die Datei
winhttp.dll in das System32-Verzeichnis des Clients zu kopieren. Anschließend klappte die
Installation des Clients ohne Probleme. Vor der Image-Erstellung erhielt auch der WSM-Client das
Update auf Version 1.1.3.
Im nächsten Schritt startet der Administrator das Tool osmvdiskimage.exe, das ein Abbild der
XP-Installation erstellt und auf dem Streaming-Server speichert. Dabei wird auch die Größe des
Images festgelegt, die Obergrenze liegt bei 8 GByte. Zu diesem Zeitpunkt müssen alle Geräte an den
Referenz-Client angeschlossen sein, die später mit den (Flashless-)Clients genutzt werden sollen,
also Maus, Tastatur, Drucker etc.
Sollen alle Benutzer bestimmte Anwendungen wie Winzip oder Acrobat Reader erhalten, kann der
Systemverwalter sie direkt in das OS-Image integrieren. Dafür muss er sie auf dem Referenzgerät
installieren, bevor er das Abbild zieht. Für Applikationen, die nur bestimmte Anwender erhalten
sollen, schnürt er dagegen eigene Application-Set-Pakete, die unabhängig vom Betriebssystem zu den
Clients ge- streamt werden.
Der erste Anlauf der Image-Erstellung scheiterte zunächst, weil wir für das "flache" Testnetz
kein Default-Gateway konfiguriert hatten. Das WSM-Client-Tool brachte eine entsprechende
Fehlermeldung und konnte die virtuelle Disk nicht auf den WSM-Server mappen. Mit eingerichtetem
Gateway ließ sich das Image dann umstandslos erstellen.
Zentrale Image-Verwaltung
Damit die Clients per Netzwerk-Boot auf das Image zugreifen können, muss der Administrator im
Web-GUI einige Zuordnungen vornehmen: Zum einen weist er das neue Image einem oder mehreren
Streaming-Servern zu; dabei ist auch eine Lizenzierung hinterlegbar. Zum anderen bestimmt er,
welche Client-Geräte das Image im Boot-Menü zur Auswahl erhalten. Pro Client lassen sich maximal
vier Images zuweisen. Wahlweise kann der Systemverwalter über die MAC-Adresse des Clients vorgeben,
dass das Gerät immer automatisch mit einem bestimmten Image startet. Nun war der Flashless-Client
erstmals zu starten und über das Netz zu booten. Das Gerät holte sich per DHCP eine IP-Adresse und
lud per TFTP den Boot-Strap vom WSM-Server. Das Boot-Menü zeigte das konfigurierte Image an, und
der Client bootete XP erfolgreich per Netzwerk-Streaming.
Die beschriebenen Schritte führten wir dann mit einem älteren Intel-PC mit PXE-Netzwerkkarte
durch. Auf der lokalen Festplatte installierten wir Windows XP Professional mit SP2, spielten es
auf den WSM-Client auf und erstellten das Image. Dann entfernten wir die Festplatte und starteten
den PC per Streaming. Diesmal klappte alles auf Anhieb.
Ob Anwender Änderungen an "ihrem" Image vornehmen dürfen, legt der Admin über den Cache-Modus
des WSM-Servers fest: Wählt er "Persistent Cache", verwenden zwar alle Clients dasselbe
Betriebssystem-Image, laden sich aber zusätzlich individuelle Einstellungen aus einer Cache-Datei.
Die Zuweisung erfolgt anhand der MAC-Adressen. Damit können Benutzer ihren Arbeitsplatz an
persönliche Erfordernisse anpassen. Beim "Volatile Cache" dagegen stellt der Server bei jedem
Neustart den im Basis-Image festgelegten Originalzustand wieder her. Den "Private Mode" schließlich
aktiviert der Administrator, wenn er Änderungen an einem Image vornehmen möchte. Hier werden die
durchgeführten Aktionen direkt ins Image geschrieben und stehen dann für alle Anwender zur
Verfügung. Im Test verhielten sich die Cache-Modi erwartungsgemäß: Im Persistent-Modus
durchgeführte Änderungen waren für den jeweiligen Benutzer dauerhaft gespeichert, der
Volatile-Modus verwarf sie beim nächsten Neustart wieder.
Der Administrator hat die Wahl, Anwendungen direkt in das Betriebssystemabbild zu integrieren
oder über ein separates Image bereitzustellen. Im zweiten Fall streamt der WSM-Server die gerade
benötigten Daten parallel vom Betriebssystem- und vom Application-Set-Image. Um ein Anwendungspaket
zu erstellen, muss das Tool WSM Publisher auf einem Rechner installiert sein, der mit demselben
Betriebssystem läuft, für das die Anwendungen bestimmt sind.
Im Test wurde der Publisher in einer Vmware-Session mit Windows XP installiert, die Mitglied
derselben Domäne war wie der WSM-Server. Um ein Application Set zu erstellen, erzeugt der Admin
zunächst einen so genannten Pre-Installation-Snapshot. Alle Aktionen, die nach diesem ersten
Snapshot ablaufen, zeichnet der Publisher auf. Deshalb sollte man vorbereitende Aufgaben wie das
Einlegen der CD oder das Verbinden der Netzlaufwerke vorher durchführen. Nun installiert der
Administrator die gewünschten Anwendungen auf dem Publisher-Rechner. Dabei unterstützt ihn ein
Wizard, in dem er unter anderem angibt, welche Einstellungen die Anwendungen verwenden sollen, zum
Beispiel Standardpfade für Word etc. Dann erstellt der Systemverwalter einen so genannten
Post-Installation-Snapshot. Damit stellt der Publisher fest, wie sich das ursprüngliche Image
verändert hat. Bevor der zweite Snapshot erzeugt wird, muss der Admin alle Anwendungen mindestens
einmal starten, um sicherzustellen, dass alle erforderlichen Registry-Einträge und sonstigen
Erststartaktionen wie Registrierung bei Microsoft etc. durchgeführt wurden.
Per Abgleich der beiden Snaphshots erzeugt der Publisher die eigentliche Build-Datei, die der
Admin nachbearbeiten kann. Spezielle Makros löschen automatisch bestimmte Einstellungen und
temporäre Dateien wieder aus dem Build, die laut Wyse nicht erforderlich sind. Anhand der fertigen
Build-Datei erzeugt der Publisher zum Abschluss das Application-Set-Image. Es fasst alle .exe-,
.dll- und sonstige Dateien, die für die jeweilige(n) Applikation(en) nötig sind, zu einer Art
.zip-Datei zusammen. Der Systemverwalter gibt dabei auch an, für welche Betriebssysteme das Image
zu verwenden ist. Zudem kann er die Komprimierung Lzxcab aktivieren, die die Paketgröße um etwa 40
Prozent reduziert.
Anwendungen veröffentlichen
Nun kopiert der Administrator die Image-Datei auf den Server und registriert sie mithilfe des
Browser-GUIs. Dabei gibt er an, welche WSM-Server das Image vorhalten sollen, und weist die
gewünschten Benutzer und Gruppen sowie die Lizenzen zu. Der Anwender sieht die für ihn
freigeschalteten Applikationen automatisch über den WSM-Client auf dem Desktop und muss sie nur
noch aktivieren ("subscribe").
Im Test wiesen wir dem V00-Client ein Application-Set mit Microsoft-Office-Anwendungen zu und
starteten ihn dann neu. Nach der Anmeldung öffnete sich automatisch das WSM-Client-Fenster und
zeigte an, dass Office als neue Applikation zur Verfügung steht und aktivierbar ist. Beim Start von
Word erschien jedoch zunächst eine Warnung, dass Word für einen anderen Benutzer installiert wurde
und das Office-Setup erneut auszuführen sei. Eine Rückfrage bei Wyse ergab, dass der
Publisher-Rechner nicht Mitglied einer Domäne sein sollte und die Application Sets als lokaler
Administrator zu erstellen sind, um dieses Berechtigungsproblem zu vermeiden. Nachdem wir das
Office-Paket auf dem richtigen Weg nochmal neu erstellt hatten, ließ es sich ohne Weiteres per
Streaming nutzen. Um das Verhalten von Streaming-Clients bei einem Netzausfall zu testen, zogen wir
von einem Test-Client das Netzwerkkabel ab. Windows XP ließ sich auch ohne Netzwerkverbindung
weiter nutzen – aber eben nur die Anwendungen, die bereits im Arbeitsspeicher geladen waren.
Für das Reporting bietet WSM fünf Standardberichte, die einen detaillierten Überblick zum
Benutzerverhalten liefern, inklusive Nutzung von Anwendungen und Lizenzen. Zum Beispiel wird
angezeigt, wer welche Applikationen aktiviert hat und wie lange die Benutzer mit den Anwendungen
gearbeitet haben. Eine Exportfunktion für die Daten, zum Beispiel nach Excel, ist aber bisher nicht
vorhanden.
Fazit
Der flexible Wyse Streaming Manager eröffnet dem TC-Computing neue Möglichkeiten. Die Fähigkeit,
von Ultra-Thin-Clients bis zu PCs beliebige Desktops einzubinden, überzeugte im Test. Mit der
intuitiv bedienbaren Weboberfläche sollten Administratoren schnell zurecht kommen. Der Preis der
Lösung erscheint angesichts der gebotenen Funktionalität gerechtfertigt: Die Software kostet 225
Euro pro Arbeitsplatz plus 43 Euro pro Jahr und Arbeitsplatz für Software-Maintenance. Der
Flash-lose V00-TC kostet mit 512 MByte RAM 441 Euro, der VR0 mit 256 MByte RAM und 2 GByte Flash
834 Euro. Optional ist dieser mit 4 GByte Flash erhältlich.
Info: Wyse Tel.: 089/460099-0 Web: www.wyse.de
Lesen Sie mehr zum Thema
