19Remotedesktopdienste (Terminaldienste)

Heim gen Chrysa entführt. Das möchte’ 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.

Zu Beginn dieses Kapitels möchte ich zunächst darauf hinweisen, dass Microsoft die vormaligen Terminaldienste mit Windows Server 2008 R2 ziemlich gründlich umbenannt hat – und die neuen Namen sind auch in 2012 R2 noch aktuell. Ansatz und Technologie sind zwar grundsätzlich gleich geblieben, es gibt aber diverse neue Begriffe zu lernen. Tabelle 19.1 enthält einen Überblick.

Tabelle 19.1 Neue Namen für die Terminaldienste

Früher (bis Windows Server 2008)	Neu (2008 R2/2012/2012 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-Sitzungshosts
Terminaldienstegateway-Manager	Remotedesktopgateway-Manager
Terminaldienstelizenzierungs-Manager	Remotedesktoplizenzierungs-Manager
Terminaldienste RemoteApp Manager	RemoteApp-Manager

Beginnen möchte ich mit einer kurzen Zusammenfassung der wichtigsten Neuerungen bei den Remotedesktopdiensten.

Neuerungen 2008 R2 zu 2012

• Bereitstellungen virtueller Desktopinfrastrukturen (VDI)
• Sitzungsvirtualisierungsbereitstellungen
• Zentrale Veröffentlichung von Ressourcen
• Leistungsfähige Benutzerumgebungen mit RDP (Remotedesktopprotokoll)

Neuerungen 2012 zu 2012 R2

• Session Shadowing (Helpdesk kann sich in die Session eines Benutzers »reinhängen«, um ihn zu supporten)
• Online Storage Deduplication (Deduplizierung von Daten zur Platzersparnis)
• Improved RemoteApp behavior (Verbesserung der Darstellung)
• Quick reconnect for remote desktop clients (schnellerer Verbindungsaufbau nach Trennung der Verbindung)
• Improved compression and bandwidth usage (bessere Performance für Endanwender)
• Dynamic display handling (RDP stellt sich beispielsweise auf Displays ein, die die Orientierung ändern)
• RemoteFX virtualized GPU supports DX11.1 (bezieht sich auf die Funktion der Grafik-Bibliothek)

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 die 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 Serverbetriebssystem, 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 von 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/Remotedesktopdienste 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-Generation 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.
• Sollte Ihr Unternehmen bislang noch keine Remotedesktopdienste oder Citrix einsetzen, ist dies ein hervorragender Moment, um herauszufinden, ob für Ihre Zwecke vielleicht die Terminaldienste/Remotedesktopdienste 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 ausreichen – dies ist vor allem für mittlere Unternehmen ein Thema.

19.1 Die Funktionen aus 10.000 Metern 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 stellen Benutzer dar, die an einem entfernten Standort oder im Homeoffice mit zentralen Daten arbeiten möchten. Wenn es sich um eine Clientapplikation handelt, die auf einen 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 Access-Datenbanken 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 »komplette« PCs 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. Nutzen Sie keine automatische Softwareverteilung, 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 dem Remotedesktop-Sitzungshost 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. Außerdem 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 Remotebenutzern 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 die Prozessorleistung noch beim Speicherverbrauch. Auf dem Remotedesktop-Sitzungshost läuft nun nicht nur einmal Word, sondern eventuell 20 oder 30 Mal. Es ist also eine sorgfältige Dimensionierung notwendig.
• Ausfallsicherheit: Es liegt auf der Hand, 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 Clientfestplatte 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 wäre.)
• Dieser Punkt ist letztendlich eine Erweiterung des vorherigen: Wenn komplette Niederlassungen zum Beispiel Office auf einem Remotedesktop-Sitzungshost in der Zentrale nutzen, müssen und 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 (2007, 2010, 2013) 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 werden kann, 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 Steuerungshardware oder spezielle Dokumentenscanner, sind regelmäßig nicht Remotedesktopdienste-fähig.

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.