Heim gen Chrysa entführt. Das möcht' ihn vielleicht versöhnen.
Also redete jener, und setzte sich. Wieder erhub sich
Atreus Heldensohn, der Völkerfürst Agamemnon,
Zürnend vor Schmerz; es schwoll ihm das finstere Herz voll der Galle,
Schwarz umströmt; und den Augen entfunkelte strahlendes Feuer.
19 Remotedesktopdienste (Terminaldienste)
Zu Beginn dieses Kapitels möchte ich zunächst darauf hinweisen, dass Microsoft die vormaligen Terminaldienste ziemlich gründlich umbenannt hat. Ansatz und Technologie sind zwar grundsätzlich gleich geblieben, es gibt aber diverse neue Begriffe zu lernen, Tabelle 19.1 enthält einen Überblick.
| Windows Server 2008 | Windows Server 2008 R2 |
|
Terminaldienste |
Remotedesktopdienste |
|
Terminalserver |
Remotedesktop-Sitzungshost |
|
Terminaldienste Lizenzierung (Terminal Services Licensing) |
Remotedesktoplizenzierung (RD-Lizenzierung) |
|
Terminaldienstegateway (Terminal Services Gateway) |
Remotedesktopgateway |
|
Terminaldienste-Sitzungsbroker (Terminal Services Session Broker) |
Remotedesktop-Verbindungsbroker |
|
Terminaldienste Web Access |
Web Access für Remotedesktop |
|
Terminaldiensteverwaltung |
Remotedesktop-Manager |
|
Terminaldienstekonfiguration |
Konfiguration des Remotedesktop-Sitzungshost |
|
Terminaldienstegateway-Manager |
Remotedesktopgateway-Manager |
|
Terminaldienstelizenzierungs-Manager |
Remotedesktoplizenzierungs-Manager |
|
Terminaldienste RemoteApp Manager |
RemoteApp-Manager |
Für diejenigen unter Ihnen, die auf einen Blick sehen möchten, was in den Remotedesktopdiensten in der R2-Version des 2008-Servers außer der neuen Namensgebung hinzugekommen ist, bringt Tabelle 19.2 eine kurze Zusammenfassung. Sie werden sehen, dass die »kurze Zusammenfassung« gar nicht mal so sehr kurz ist – und das sind nur die Neuerungen von R2 gegenüber der Non-R2-Version. Auch der vorherige Schritt von Windows Server 2003 auf Windows Server 2008 (ohne R2) war schon gewaltig. Sie können daran erkennen, dass Microsoft intensiv an den Terminaldiensten arbeitet – dies dürfte der Bereich mit den meisten Neuerungen in der R2-Version des Windows Server 2008 sein.
| Kategorie | Neuerungen |
|
Remotedesktop-Sitzungshost |
|
|
Remote Desktop-Lizenzierung |
|
|
Remotedesktopgateway |
|
|
Web Access für Remotedesktop |
|
|
Host für die Remotedesktopvirtualisierung |
Dieser völlig neue Rollendienst ermöglicht es, Benutzern den Zugriff auf individuelle (Client-)Betriebssysteminstallationen zu geben. Für diese Funktion passt auch das Stichwort Desktopvirtualisierung. |
|
Remotedesktopdienste-Provider für Windows PowerShell |
Diese Funktion gestattet den PowerShell-Zugriff auf diverse Ressourcen und Funktionen der Remotedesktopdienste. |
|
Desktopdarstellung |
Das Erscheinungsbild einer Remotedesktopdienste-Sitzung kann optisch einem Windows 7-Client angepasst werden. Weiterhin gibt es Funktionen wie das Abspielen von Audio- und Videodateien auf dem lokalen Windows Media Player des Clients, Unterstützung für bis zu 16 Monitore und Audioaufzeichnung. |
Bevor es mit den Remotedesktopdiensten »richtig« losgeht, zunächst eine kurze Rückblende: Im August 1996 erschien der Windows NT 4.0-Server in den USA. Knapp zwei Jahre dauerte es, bis im Juni 1998 der NT4 Server Terminal Service Edition (NT4 TSE) in den USA verfügbar war. Dieses war eine spezielle Edition des NT 4-Servers; mit eigenen Datenträgern, eigenen Service Packs etc.
Seit Windows 2000 Server gehören die Terminaldienste/Remotedesktopdienste zum Server-Betriebssystem, eine spezielle Edition ist nicht mehr erforderlich. Das hat sich weder mit Windows Server 2003 noch mit Windows Server 2008 (R2) geändert.
Seit den Anfängen mit Windows NT 4 Server Terminal Server Edition gibt es zwei Szenarien, zwischen denen sich die Unternehmen und Organisationen entscheiden müssen:
- Man kann die Terminaldienste so einsetzen, wie sie von Microsoft geliefert werden.
- Oder man kauft zusätzlich Citrix XenApp (vormals MetaFrame und Presentation Server) und erweitert so die Terminaldienste/Remotedesktopdienste um einige Features, die insbesondere in größeren Unternehmensumgebungen sinnvoll sind (wie z. B. das Load Balancing von Citrix XenApp).
Die Vergangenheit hat gezeigt, dass Citrix mit den XenApp- beziehungsweise Presentation Server-Features ungefähr ein Release vor Microsoft gewesen ist. In den meisten großen Umgebungen kommt daher die Citrix-Technologie zum Einsatz. Das bedeutet aber nicht, dass eine intensive Beschäftigung mit den Remotedesktopdiensten nicht sinnvoll wäre:
- Schließlich basiert die Citrix-Technologie auf den Terminaldiensten/Remotedesktopdiensten. Das Grundlagenwissen muss also ohnehin aufgebaut werden.
- Falls Ihr Unternehmen bislang noch keine Remotedesktopdienste oder Citrix einsetzt, ist jetzt ein hervorragender Moment, um zu entscheiden, ob für Ihre Zwecke vielleicht die Terminaldienste genügen – eventuell aufgrund der neuen Windows Server 2008-Features.
- Teilweise könnte ein anstehendes Upgrade genutzt werden, um nochmals die Frage zu erörtern, ob mittlerweile nicht doch die Remotedesktopdienste genügen – dies ist vor allem für mittlere Unternehmen ein Thema.
19.1 Die Funktionen aus 10.000 m Höhe 
Für diejenigen Leser, die sich bisher nicht so ganz sicher sind, was genau hinter den Remotedesktopdiensten steckt, folgt hier eine kurze Zusammenfassung:
Das Prinzip der Remotedesktopdienste ist schnell erklärt.
Schauen wir uns zunächst eine klassische Umgebung an (Abbildung 19.1):
- Auf den Clients sind Applikationen installiert, beispielsweise ein Office-Paket, mit dem auf Serverressourcen wie Datenbanken oder Fileserver zugegriffen wird.
- Eine gewisse Herausforderung sind Benutzer, die an einem entfernten Standort oder im Homeoffice mit zentralen Daten arbeiten möchten. Wenn es sich um eine Client-Applikation handelt, die auf eine SQL-Server zugreift, funktioniert das zumeist noch ganz gut, wenn aber auf einer Access-Datenbank (*.mdb) gearbeitet werden muss, ist das eine mittlere Katastrophe. Letzteres ist vor allem deshalb problematisch, weil der Client für die Arbeit mit Accessdatenbanken recht intensiv auf dem Dateisystem schreiben und lesen muss – sehr ungünstig bei einer schmalbandigen WAN-Strecke.
Abbildung 19.1 Die klassische Architektur: Eine auf den Clients ausgeführte Applikation greift auf Serverressourcen zu.
Nun kommen die Remotedesktopdienste ins Spiel (Abbildung 19.2):
- Die Applikationen (z. B. MS Office) werden nicht mehr auf dem PC ausgeführt, sondern auf dem Remotedesktop-Sitzungshost (vormals Terminalserver genannt). Dieser führt also beispielsweise viermal Access (für jeden Client einmal) aus.
- Zwischen Client und Remotedesktop-Sitzungshost werden lediglich Tastatureingaben, Maus-Events und Bildschirmausgaben übertragen. Darüber hinaus ist die Übertragung von Schnittstellendaten oder Sound möglich.
- Der Remotedesktop-Sitzungshost greift auf weitere Serverressourcen zu.
Der PC wird letztendlich zum dummen Terminal, wie es früher in Großrechner- und AS400-Umgebungen üblich war. Auf dem Markt sind übrigens spezielle Thin Clients erhältlich, bei denen es sich nicht mehr um einen »kompletten« PC handelt; diese Geräte dienen lediglich als Terminal, um dem Benutzer die Interaktion mit dem Remotedesktop-Sitzungshost zu ermöglichen.
Die Remotedesktopdienste bieten folgende Vorteile:
- Applikationen müssen nicht auf jedem einzelnen Client, sondern nur auf dem Remotedesktop-Sitzungshost installiert werden. Wenn Sie keine automatische Softwareverteilung verwenden, spart das sehr viel Installations- und Administrationsaufwand.
- Wenn Sie wirklich alle Applikationen auf dem Remotedesktop-Sitzungshost installiert haben, ist der Ausfall eines Benutzer-PCs kein Problem, denn bis auf den Remotedesktopdienste-Client sind dort keine Applikationen notwendig.
Abbildung 19.2 Bei der Verwendung der Remotedesktopdienste werden die Applikationen auf diesen und nicht auf den Clients ausgeführt.
- Da der PC nur noch ein Anzeigegerät ist und dort keine Applikationen mehr ausgeführt werden, sind die Leistungsanforderungen natürlich geringer. Sie ersparen sich eine eventuelle Aufrüstung der PCs und können diese länger einsetzen. Weiterhin können die bereits erwähnten Thin Clients eingesetzt werden.
- Da der Netzwerkverkehr zwischen Client und Remotedesktop-Sitzungshost in vielen Fällen deutlich geringer sein wird als derjenige zwischen Applikation (auf dem Client) und Serverressource, eignet sich dieses Konzept natürlich ganz hervorragend zur Anbindung von Remote-Benutzern an die Unternehmensdaten.
Die folgenden Aspekte kann man vielleicht nicht unbedingt als Nachteil der Remotedesktopdienste-Architektur bezeichnen, dennoch müssen sie bei der Planung berücksichtigt werden:
- Kritisch ist natürlich die Leistung des Servers. Moderne Applikationen sind nicht besonders sparsam, weder in Bezug auf Prozessorleistung noch beim Speicherverbrauch. Auf dem Remotedesktop-Sitzungshost läuft nun nicht nur einmal Word, sondern eventuell zwanzig- oder dreißigmal. Es ist also eine sorgfältige Dimensionierung notwendig.
- Aufallsicherheit: Es ist einleuchtend, dass die Benutzer nicht mehr arbeiten können, wenn der Remotedesktop-Sitzungshost nicht zur Verfügung steht. Je intensiver Sie diese Technologie nutzen, desto mehr sind Sie auf eine hohe Ausfallsicherheit und Redundanz angewiesen. Das gilt natürlich auch für die Netzwerkverbindungen.
- Ich persönlich würde es unbedingt vermeiden, dass Benutzer Daten auf lokalen Festplatten speichern; in vielen Umgebungen ist dies aber üblich. Wenn beispielsweise Office auf einem Serversystem läuft, steht die Client-Festplatte nicht mehr (so ohne Weiteres) zur Verfügung. Im Klartext: Alle Daten müssen auf Serversystemen abgelegt werden (Anmerkung: Es gibt die Möglichkeit, dem Remotedesktop-Sitzungshost lokale Laufwerke zuzuweisen. Solche Tricksereien sollten Sie aber unbedingt vermeiden – auch wenn nur ein Mausklick notwendig ist).
- Dieser Punkt ist letztendlich eine Erweiterung des vorherigen: Wenn komplette Niederlassungen zum Beispiel Office auf einem Remotedesktop-Sitzungshost in der Zentrale nutzen, müssen/sollten sich deren Daten ebenfalls in der Zentrale befinden, ansonsten würde der Remotedesktop-Sitzungshost über die WAN-Verbindung Daten aus der Niederlassung holen. Im Sinne einer zentralisierten Datenhaltung ist dies prinzipiell zu begrüßen. Die Serverkapazitäten in der Zentrale müssen aber vermutlich deutlich ausgebaut werden.
- Wenn ein Benutzer an seinem lokalen PC »herumbastelt« und Einstellungen ausprobiert, ist das fatal genug. Wenn er das auf einem Remotedesktop-Sitzungshost tut, auf den er ja Benutzerzugriff hat, hat das unter Umständen Auswirkungen auf mehrere Dutzend Kollegen. Über Berechtigungen, insbesondere auch über Gruppenrichtlinien, muss sichergestellt werden, dass die Benutzer keine Möglichkeit zum Basteln und Experimentieren haben.
- Der wichtigste Punkt: Nicht alle Applikationen eignen sich für den Einsatz auf dem Remotedesktop-Sitzungshost. Moderne Applikationen wie Office (2000, XP, 2003, 2007) oder die SAP GUI laufen problemlos auf Remotedesktop-Sitzungshosts. Ältere oder sehr »spezielle« (was die technische Umsetzung betrifft) Applikationen sind eventuell nicht stabil zu implementieren. Jede Applikation muss erst auf Remotedesktopdienste-Tauglichkeit geprüft werden.
- Sie müssen sich auch darüber im Klaren sein, dass Sie nicht beliebig viele Applikationen auf einem Remotedesktop-Sitzungshost installieren können. Wenn Ihr Unternehmen über 100 Applikationen verfügt, ist es ausgeschlossen, dass diese alle auf einer Maschine funktionieren. Denken Sie allein an die üblichen Probleme mit den DLL-Versionen: Was auf einem einzelnen PC schon sehr lästig ist, ist auf dem Remotedesktop-Sitzungshost vermutlich schlicht und ergreifend nicht lösbar. Es muss also nicht nur geprüft werden, ob eine Applikation einzeln auf dem Remotedesktop-Sitzungshost ausgeführt werden kann, vielmehr müssen Sie die einzusetzenden Programmpakete in der Kombination testen.
- 16-Bit-Applikationen sind für die Ausführung auf Remotedesktop-Sitzungshosts nicht geeignet.
- Programme, die auf spezielle Hardware zugreifen müssen, beispielsweise auf spezielle Dokumentenscanner oder Steuerungshardware, sind regelmäßig nicht Remotedesktopdienste-fähig.
| Microsoft Application Virtualization |
|
Extrem interessant im Zusammenhang mit den Remotedesktopdienste ist die Applikationsvirtualisierung. Diese geht zwar über den Fokus dieses Buchs hinaus, trotzdem möchte ich Ihnen einen Besuch folgender URL unbedingt empfehlen: www.microsoft.com/softgrid. Die Technologie wurde bislang unter dem Namen Softgrid vertrieben und ist kürzlich in Microsoft Application Virtualization (App-V) umbenannt worden. |
