Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1528-2
Pfeil 19 Remotedesktopdienste (Terminaldienste)
Pfeil 19.1 Die Funktionen aus 10.000 m Höhe
Pfeil 19.2 Installation
Pfeil 19.3 Feature »Desktopdarstellung« installieren
Pfeil 19.4 Benutzerzugriff
Pfeil 19.5 Installation von Anwendungen
Pfeil 19.6 Desktop bereitstellen
Pfeil 19.7 RemoteApp-Programme
Pfeil 19.8 Administration und Verwaltung
Pfeil 19.8.1 Konfiguration des Remotedesktop-Sitzungshosts
Pfeil 19.8.2 Benutzeradministration
Pfeil 19.8.3 Remotedesktopdienste-Manager
Pfeil 19.8.4 Loopback-Verarbeitung
Pfeil 19.8.5 Remotedesktopdienste-Lizenzierungung
Pfeil 19.9 Drucken, Easy Print
Pfeil 19.9.1 Installation von Easy Print
Pfeil 19.9.2 Kurze Überprüfung
Pfeil 19.9.3 Gruppenrichtlinien
Pfeil 19.10 Web Access für Remotedesktop
Pfeil 19.11 RemoteApp- und Desktopverbindungen mit Windows 7
Pfeil 19.12 Remotedesktopdienste-Farmen mit Netzwerklastenausgleich und Remotedesktopdienste-Verbindungsbroker
Pfeil 19.12.1 Installation
Pfeil 19.12.2 Überwachen
Pfeil 19.12.3 RemoteApp-Programme »umpaketieren«
Pfeil 19.13 Remotedesktopdienste-Farmen mit DNS Round Robin bzw. Verbindungsbroker
Pfeil 19.14 Remotedesktopgateway
Pfeil 19.14.1 Anwendung und Architektur
Pfeil 19.14.2 Installation
Pfeil 19.14.3 Konfiguration
Pfeil 19.14.4 Clientkonfiguration und Verbindungsaufbau
Pfeil 19.14.5 Überwachung
Pfeil 19.14.6 NAP und das Remotedesktopgateway
Pfeil 19.15 Host für Remotedesktopvirtualisierung
Pfeil 19.15.1 Funktionsweise
Pfeil 19.15.2 Installation
Pfeil 19.15.3 Virtuelle Maschinen konfigurieren
Pfeil 19.15.4 Benutzer administrieren
Pfeil 19.15.5 Testen und verwenden
Pfeil 19.16 Schlussbemerkung

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.


Tabelle 19.1 Neue Namen für die Terminaldienste

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.


Tabelle 19.2 Die wichtigsten Neuerungen der Remotedesktopdienste in der R2-Version

Kategorie Neuerungen

Remotedesktop-Sitzungshost

  • Bei der Installation des Rollendienstes kann bereits bestimmt werden, welche Features in der Client-Umgebung zur Verfügung stehen (z. B. Windows 7-Optik).
  • RemoteApps können individuell Benutzern oder Benutzergruppen zugewiesen werden. Zur Erinnerung: In der Non-R2-Version hatten alle Benutzer Zugriff auf eine RemoteApp.
  • Fair Share CPU Scheduling sorgt für eine gleichmäßigere Verteilung zwischen den Benutzersitzungen auf einem Remotedesktop-Sitzungshost. Wichtigstes Ergebnis: Hohe Last in einer Sitzung führt nicht zu einem signifikant schlechteren Performanceverhalten in anderen Sitzungen.
  • Verbesserte Kompatibilität mit dem Windows-Installer sorgt für vereinfachte Installationsvorgänge von Anwendungssoftware auf dem Remotedesktop-Sitzungshost. Dies bezieht sich insbesondere auf Softwareprodukte, die eine Pro-Benutzer-Installation benötigen.
  • Die Cache-Begrenzung für servergespeicherte Benutzerprofile ermöglicht es, per Gruppenrichtlinie eine Maximalgröße für die insgesamt auf einem Remotedesktop-Sitzungshost zwischengespeicherten Benutzerprofile anzugeben. Bei Überschreitung dieses Werts werden die ältesten zwischengespeicherten Profile gelöscht.
  • Remote Desktop IP-Virtualisierung: Es gibt Anwendungsprogramme, die pro Instanz eine eigene IP-Adresse benötigen, was bislang auf einem Terminalserver/Remotedesktop-Sitzungshost nicht möglich war. Die RD-IP-Virtualisierung ermöglicht individuelle IP-Adressen auf Sitzungs- oder Anwendungsebene. Konfiguriert wird diese Einstellung in den Eigenschaften des Remotedesktop-Sitzungshost.

Remote Desktop-Lizenzierung

  • Die automatische Erkennung eines Lizenzservers wird von den Remotedesktop-Sitzungshosts nicht mehr unterstützt. Stattdessen wird mit einem Eintrag (SCP, Service Connection Point) im Active Directory gearbeitet.
  • Neuer Assistent um Remotedesktopdienste-CALs zu verwalten: Dieser unterstützt die Migration von CALs zwischen Lizenzservern und kann die Lizenzdatenbank neu aufbauen.

Remotedesktopgateway

  • Beim Gateway sind die Grenzwerte für inaktive Verbindungen und Sitzungstimeouts konfigurierbar. Hierdurch ist eine bessere Anpassung an die Lastsituation in der jeweiligen Umgebung möglich.
  • Bei inaktiven Benutzern, die sich wieder anmelden, kann die Authentifizierung unter bestimmten Voraussetzungen ohne Benutzerinteraktion im Hintergrund erfolgen.
  • Am Gateway kann nun konfiguriert werden, dass Clients sich nur an Remotedesktop-Sitzungshosts anmelden können, die eine Erzwingung für die Client-Umleitung unterstützen (mittels NAP). Auf diese Weise kann sichergestellt werden, dass nur Clients, die den Richtlinien für die Vermeidung von Schadcode/Viren entsprechen, angemeldet werden.
  • In Zusammenhang mit NAP kann das Gatway Clients, die nicht den Richtlinien entsprechen, aktualisieren. Auf diese Weise wird es einfacher, Remote-Clients »kompatibel« zu halten.
  • Eher für Entwickler interessant dürfte die Möglichkeit sein, zusätzliche Authentifizierungsprovider in das Gateway zu integrieren – Benutzername und Kennwort muss nicht das Maß aller Dinge sein.

Web Access für Remotedesktop

  • Beim ersten Zugriff auf Web Access für Remotedesktop wird Ihnen auffallen, dass nun auch die formularbasierte Authentifizierung unterstützt wird. Das hat insbesondere Vorteile, wenn sich Benutzer an unsicheren Computern, beispielsweise einem öffentlichen Internetterminal, befinden.
  • Die Möglichkeit, RemoteApps individuell bestimmten Benutzern zuzuweisen, ist natürlich auch bei der Nutzung von Web Access für Remotedesktop sehr hilfreich.

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.

Galileo Computing - Zum Seitenanfang

19.1 Die Funktionen aus 10.000 m Höhe topZur vorigen Überschrift

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.




Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows Server 2012 R2






 Windows Server
 2012 R2


Zum Katalog: Office 365






 Office 365


Zum Katalog: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Vmware vSphere 5






 Vmware vSphere 5


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de