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

Download:
- ZIP, ca. 104 MB
Buch bestellen
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
Galileo 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


Galileo Computing - Zum Seitenanfang

19.12 Remotedesktopdienste-Farmen mit Netzwerklastenausgleich und Remotedesktopdienste-Verbindungsbroker Zur nächsten ÜberschriftZur vorigen Überschrift

Außer in ganz kleinen Umgebungen, in denen wirklich nur ein Remotedesktop-Sitzungshost benötigt wird, plant man eine Remotedesktopdienste-Farm, also einen »Zusammenschluss« von mehreren Remotedesktop-Sitzungshosts. Dies geschieht aus zwei Gründen:

  • Performance: Wenn zweihundert, fünfhundert oder dreitausend Benutzer die Remotedesktopdienste nutzen, ist das von einem einzelnen Server nicht mehr zu leisten. Die Last muss also verteilt werden.
  • Ausfallsicherheit: Da ein Server durchaus auch ausfallen könnte, macht es ohnehin Sinn, mindestens zwei Server einzusetzen.

Das Load Balancing in einer Remotedesktopdienste-Umgebung funktioniert auf Basis von IP-Load Balancing und nicht etwa wie bei Citrix XenApp (aka Presentation Server) auf Applikationsebene. In Abbildung 19.95 ist der Ablauf skizziert:

  • Der Client verbindet sich mit dem Load Balancer, und dieser leitet den Client nach einem bestimmten Algorithmus zu einem Remotedesktop-Sitzungshost weiter.
  • Beachten Sie, dass eine einmal initiierte Sitzung von ein und demselben Remotedesktop-Sitzungshost abgewickelt wird.

Die Zeichnung ist letztendlich »abstrahierend«, denn in der Praxis wird man keinen Hardware-Load-Balancer einsetzen, sondern den Microsoft Netzwerklastenausgleich einsetzen, der recht ausführlich in Abschnitt 20.3 erläutert wird.

Abbildung 19.95 Das Load Balancing in einer Remotedesktopdienste-Umgebung funktioniert auf Basis von IP-Load Balancing.

Nun ist folgendes Problem denkbar:

  • Der Client bricht die Remotedesktopdienste-Sitzung ab. Die Sitzung läuft, sofern nicht anders konfiguriert, zunächst weiter, und der Benutzer könnte sich wieder verbinden.
  • Bei einem späteren erneuten Zugriff leitet das Network Load Balancing den Benutzer zu einem anderen Remotedesktop-Sitzungshost, obwohl bereits eine Sitzung auf einem anderen Server existiert.

Bei diesem Problem hilft der Remotedesktopdienste-Verbindungsbroker, der schlicht und ergreifend speichert, welche Benutzersitzungen auf welchem Remotedesktop-Sitzungshost laufen. Das Gesamtbild wird wie in Abbildung 19.96 gezeigt verändert:

  • Der Client gelangt via Network Load Balancing zu dem Remotedesktop-Sitzungshost.
  • Der Remotedesktop-Sitzungshost fragt beim Verbindungsbroker nach, ob für diesen Benutzer eine aktive Sitzung vorhanden ist.
  • Wenn keine Sitzung aktiv ist, beginnt der Remotedesktop-Sitzungshost eine neue Sitzung für diesen Benutzer, ansonsten wird der Benutzer zu dem Server mit der aktiven Sitzung geleitet und mit dieser verbunden.

Abbildung 19.96 Der Sitzungsbroker Session Directory sorgt dafür, dass Clients mit einer bestehenden Sitzung verbunden werden.


Hinweis

Seit Windows Server 2008 gibt es weitere gute Nachrichten: In einer Windows Server 2003-Umgebung mussten die Terminalserver, die mit dem Sitzungsbroker kommunizieren sollten, mit der Enterprise Edition des Betriebssystems aufgesetzt werden. In einer Windows Server 2008-Umgebung genügt auf allen Systemen die Standard Edition.



Galileo Computing - Zum Seitenanfang

19.12.1 Installation Zur nächsten ÜberschriftZur vorigen Überschrift

In diesem Abschnitt zeige ich Ihnen den Aufbau einer Remotedesktopdienste-Farm mit zwei Remotedesktop-Sitzungshosts.

Die Installation der Remotedesktop-Sitzungshost wird hier nicht nochmals gezeigt. Die Darstellung geht davon aus, dass beide Remotedesktop-Sitzungshosts bereits installiert und voll funktionsfähig sind.

Installation des Verbindungsbrokers

Den Remotedesktopdienste-Verbindungsbroker zu installieren, ist der einfachste Teil der Einrichtung. Es empfiehlt sich, diese Rolle nicht auf einem der Remotedesktop-Sitzungshosts zu installieren, was nichtsdestotrotz möglich ist. Der Remotedesktopdienste-Verbindungsbroker ist ein Rollendienst der Remotedesktopdienste; in Abbildung 19.97 sehen Sie den Auswahldialog zur Installation. Im Fall der Umgebung, die ich für dieses Buch aufgebaut habe, läuft auf dem Verbindungsbroker-Server zusätzlich Web Access für Remotedesktop.

Abbildung 19.97 Der Remotedesktop-Verbindungsbroker ist ein separat installierbarer Rollendienst.

Die eigentliche Installation ist nach ein paar Augenblicken abgeschlossen, ohne dass Sie weitere Eingaben vornehmen müssten. Bei der Installation wird auf der Maschine eine lokale Gruppe namens Sitzungsbrokercomputer angelegt, der Sie die Computerkonten der Remotedesktop-Sitzungshosts der Farm hinzufügen (Abbildung 19.98).

Ich würde Ihnen empfehlen, wie immer vorsichtshalber einen Blick in das Ereignisprotokoll zu werfen und zu überprüfen, ob der neu installierte Dienst (Anzeigename: Remotedesktop-Verbindungsbroker) auch tatsächlich gestartet wurde.

Abbildung 19.98 Der Gruppe Sitzungsbrokercomputer auf dem Verbindungsbroker-Server müssen die Remotedesktop-Sitzungshosts der Farm hinzugefügt werden.

Installation und Konfiguration des Features »Netzwerklastenausgleich«

Damit der Netzwerklastenausgleich (NLB) genutzt werden kann, müssen Sie zunächst das gleichnamige Feature auf den Remotedesktop-Sitzungshosts installieren. Zusätzlich müssen Sie einen neuen Netzwerklastenausgleich-Cluster konfigurieren.

An dieser Stelle sei nochmals darauf hingewiesen, dass sich Abschnitt 20.3 recht ausführlich mit dem Thema Netzwerklastenausgleich beschäftigt.

Installation

Die Installation des Netzwerklastenausgleichs ist simpel, es muss lediglich das gleichnamige Feature hinzugefügt werden. Diesen Vorgang starten Sie wie üblich aus dem Server-Manager (Abbildung 19.99).


Auf jedem Server durchführen

Denken Sie daran, dass dieser Installationsschritt auf jedem Server der Farm durchgeführt werden muss!

Ist der Verbindungsbroker, wie empfohlen, nicht auf einem der Remotedesktop-Sitzungshosts installiert, wird diese Maschine natürlich nicht in den Netzwerklastenausgleich aufgenommen – sie ist ja auch kein Remotedesktop-Sitzungshost.


Abbildung 19.99 Auf den Remotedesktop-Sitzungshosts wird das Feature »Netzwerklastenausgleich« installiert.

Nach der Installation werden Sie in den Eigenschaften der Netzwerkverbindung sehen, dass das Element Netzwerklastenausgleich vorhanden aber noch nicht aktiviert ist (Abbildung 19.100). Das ist so absolut korrekt, die Funktion wird während des NLB-Cluster-Einrichtungsvorgangs automatisch aktiviert.

Abbildung 19.100 Nach der Installation wird in den Eigenschaften der Netzwerkkarte der Netzwerklastenausgleich angezeigt werden.

Konfiguration

Wenn das Feature Netzwerklastenausgleich auf allen Servern des zukünftigen NLB-Clusters installiert ist, kann der neue Cluster eingerichtet werden. Wie Sie an den Screenshots sehen können, geht das auch ganz prima von einem Windows 7-Client aus, auf dem die Windows Server 2008 R2-Administrationswerkzeuge installiert sind.

  • Wählen Sie also im Netzwerklastenausgleich-Manager den Menüpunkt ClusterNeu (Abbildung 19.101).

Abbildung 19.101 Im Netzwerklastenausgleich-Manager wird ein neuer Cluster eingerichtet.

  • Auf der ersten Dialogseite des Assistenten verbinden Sie sich mit dem ersten Server des NLB-Clusters und wählen eine Netzwerkschnittstelle aus (Abbildung 19.102, links).
  • Auf der zweiten Dialogseite geben Sie die zu verwendenden IP-Adressen dieser Netzwerkkarte an (Abbildung 19.102, rechts).

Abbildung 19.102 Der erste Host wird dem NLB-Cluster hinzugefügt.

Nun wird es interessant (Abbildung 19.103):

  • Der NLB-Cluster erhält eine oder mehrere IP-Adressen, auf die er reagiert.
  • Weiterhin legen Sie den Clusterausführungsmodus fest. In diesem Fall ist Unicast die richtige Wahl.

Abbildung 19.103 Die Cluster-IP-Adresse und der Ausführungsmodus werden festgelegt.


Unicast versus Multicast in virtualisierten Umgebungen

Falls Sie zunächst eine virtualisierte Testumgebung aufbauen, werden Sie feststellen, dass sich die Virtualisierungslösungen mit einem NLB-Cluster im Unicast-Ausführungsmodus »verheddern«. Das heißt, die Kommunikation ist zum Teil nicht mehr möglich. Dieser Punkt wird auch in Abschnitt 20.3.2 angesprochen.

In einer virtualisierten Umgebung würde ich die Konfiguration als Multicast-Cluster wählen.


Ein sehr wichtiger Konfigurationsaspekt sind die Portregeln. In Abbildung 19.104 sehen Sie die entsprechenden Dialoge:

  • Wichtig ist, dass Sie als Filterungsmodus Mehrfachhost angeben, was auch standardmäßig vorgegeben ist.
  • Daneben ist die Affinität für Ihren Erfolg entscheidend:
    • Wählen Sie Keine, wenn Sie den Sitzungsbroker verwenden, was wir in diesem Beispiel tun.
    • Falls Sie in Ihrer Installation aus welchen Gründen auch immer den Sitzungsbroker nicht verwenden, ist Einfach die richtige Einstellung.

Abbildung 19.104 Bei den Portregeln wählen Sie, wenn Sie »den Sitzungsbroker verwenden«, als Affinität »Keine«.


Hinweis

Ich gehe hier auf die Bedeutung der einzelnen Konfigurationsmöglichkeiten der Portregeln nicht näher ein, da dies in Abschnitt 20.3.2 besprochen wird.


Nach Abschluss der Einrichtung durch den Assistenten sollte im Netzwerklastenausgleich-Manager nun ein neuer Cluster mit einem Knoten angezeigt werden. Sie können nun direkt weitermachen und im Kontextmenü des Clusters den Menüpunkt Host dem Cluster hinzufügen wählen, um den nächsten Server hinzuzufügen (Abbildung 19.105).

Beim Hinzufügen von weiteren Knoten wird der Assistent Ihnen die Dialogseiten aus Abbildung 19.102 präsentieren; im Wesentlichen müssen Sie dort die IP-Adresse des Servers eintragen, den Sie hinzufügen wollen.

Nach Abschluss der Konfiguration sollte sich in etwa das Szenario aus Abbildung 19.106 ergeben: Alle Remotedesktop-Sitzungshosts sind erfolgreich zum Netzwerklastenausgleich-Cluster hinzugefügt worden.

Abbildung 19.105 Sie können weitere Hosts zum bestehenden Cluster hinzufügen.

Abbildung 19.106 Ein funktionierender Netzwerklastenausgleich-Cluster mit zwei Servern

DNS-Eintrag vornehmen

Da die Benutzer die Remotedesktopdienste-Farm nicht mit der »nackten« IP-Adresse des NLB-Clusters ansprechen sollten, müssen Sie im DNS noch einen Hostnamen für die Cluster-IP-Adresse angeben. Zur Erinnerung zeigt Abbildung 19.107, wie das gemacht wird.

Abbildung 19.107 Den Eintrag für den NLB-Cluster nehmen Sie im »DNS-Manager« vor.

PING-Test

Einen ersten kleinen Test, ob der neue NLB-Cluster funktioniert, können Sie durchführen, indem Sie die Cluster-IP-Adresse (bzw. den eingetragenen Hostnamen) anpingen. Wie in Abbildung 19.108 gezeigt, sollten Sie eine Antwort erhalten.

Anzumerken wäre, dass so ein PING-Test nicht dafür bürgt, dass alles funktioniert. Allerdings wird umgekehrt schon ein Schuh draus: Es ist ein ziemlich schlechtes Zeichen, wenn sogar der PING-Test misslingt.

Abbildung 19.108 Kein perfekter Test, aber ein erster Anhaltspunkt: ein PING auf die Cluster-IP-Adresse

Ein weiterer einfacher Test ist das Ansprechen des RDP-Ports mittels Telnet (telnet farmname 3389). Hierbei sollte sofort eine Verbindung zustande kommen.

Remotedesktop-Sitzungshosts für die Nutzung des Verbindungsbrokers konfigurieren

Zum Schluss müssen die Remotedesktop-Sitzungshosts noch dazu gebracht werden, sich der Farm zugehörig zu fühlen. Dazu rufen Sie das Werkzeug Konfiguration des Remotedesktop-Sitzungshosts auf, öffnen die Eigenschaften und wechseln auf die Registerkarte Remotedesktop-Verbindungsbroker (Abbildung 19.109):

  • Wichtig ist, dass der Farmname auf allen Remotedesktop-Sitzungshosts identisch (!) ist. Ein Tippfehler führt dazu, dass Sie aus Sicht des Sitzungsbrokers über zwei Farmen verfügen, was zu sehr merkwürdigem Verhalten führt. Sie können einen beliebigen Namen eintragen.
  • Nach Abschluss des ersten Konfigurationsschritts (Eintragen von Verbindungsbroker und Farmnamen) müssen Sie noch die Checkbox Teilnahme am Verbindungsbroker-Lastenausgleich aktivieren und eine bei erneuter Verbindung zu verwendende IP-Adresse auswählen. Letztere sollte die IP-Adresse des NLB-Clusters sein (Abbildung 19.110).

Abbildung 19.109 Die Remotedesktop-Sitzungshosts müssen für die Nutzung des Verbindungsbrokers konfiguriert werden.

Abbildung 19.110 Vergessen Sie nicht, den Lastenausgleich anzuschalten und die IP-Adresse für erneute Verbindungen festzulegen.

Zertifikate anpassen

Auch im Umfeld der Remotedesktopdienste verfolgt Sie das schöne Thema Zertifikate. Auf Abbildung 19.111 ist folgendes typisches »Farmproblem« zu sehen:

  • Auf die Computer in der gezeigten Umgebung wird automatisch ein Zertifikat ausgerollt, das auf den FQDN ausgestellt ist.
  • Dieses Zertifikat wird den sich verbindenden Remotedesktopclients präsentiert.
  • Da der Client nun ubinfRDSFarm aufruft, das Zertifikat aber auf den Namen der Maschine ausgestellt ist, gibt es eine Zertifikatwarnung.

Was ist zu tun?

  • Erzeugen Sie ein Zertifikat, das auf den Namen der Farm ausgestellt ist, und installieren Sie es jeweils in den Zertifikatspeicher des Computerkontos auf den Remotedesktop-Sitzungshosts.
  • Rufen Sie dann das Werkzeug Konfiguration des Remotedesktop-Sitzungshosts auf. Wählen Sie den Eigenschaftendialog der Verbindung.
  • Ganz unten auf der Registerkarte Allgemein findet sich die Schaltfläche Auswählen. Mit dieser starten Sie einen Dialog, in dem Sie das zu verwendende Zertifikat bestimmen können (Abbildung 19.112).

Abbildung 19.111 Wenn Sie automatisch Zertifikate an Computer ausrollen, wird es eine Zertifikatwarnung geben.

Abbildung 19.112 Hier kann ein anderes Zertifikat ausgewählt werden.


Galileo Computing - Zum Seitenanfang

19.12.2 Überwachen Zur nächsten ÜberschriftZur vorigen Überschrift

Vermutlich fragen Sie sich, ob der Netzwerklastenausgleich funktioniert und die Server wirklich einigermaßen gleichmäßig verwendet werden. Prüfen Sie das wie folgt (Abbildung 19.113):

  • Öffnen Sie den Remotedesktopdienste-Manager.
  • Fügen Sie alle Remotedesktop-Sitzungshosts einer Gruppe hinzu.
  • Wenn Sie die Gruppe auswählen, werden die Benutzer, Sitzungen und Prozesse aller Server dieser Gruppe zusammengefasst angezeigt.

In Abbildung 19.113 sind zwar nicht aufregend viele Benutzer angemeldet, aber Sie können erkennen, dass sich diese auf die beiden Server verteilen. Dazu ist zu sagen, dass die Benutzer sich von verschiedenen Computern aus unter Verwendung des NLB-Clusternamens verbunden haben.

Abbildung 19.113 Fügt man in der »Remotedesktopdienste-Manager« alle Remotedesktop-Sitzungshosts der Farm einer Gruppe hinzu, kann man sehen, dass sich die Benutzer über die Server der Farm verteilen.


Galileo Computing - Zum Seitenanfang

19.12.3 RemoteApp-Programme »umpaketieren« topZur vorigen Überschrift

An dieser Stelle möchte ich daran erinnern, dass bei der Erstellung einer RDP-Datei bzw. eines MSI-Pakets zur Verteilung von RemoteApp-Programmen ein Server angegeben wird. In einer Farm-Umgebung muss unbedingt der Name der Farm (also der DNS-Name!) angegeben werden, ansonsten kommt es nicht zu einer gleichmäßigen Nutzung.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Windows Server 2008 R2

Windows Server 2008 R2
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows 7 für Administratoren






 Windows 7 für
 Administratoren


Zum Katalog: Konzepte und Lösungen für Microsoft-Netzwerke






 Konzepte und
 Lösungen für
 Microsoft-Netzwerke


Zum Katalog: Office SharePoint Server 2007 und Windows SharePoint Services 3.0






 Office SharePoint
 Server 2007 und
 Windows SharePoint
 Services 3.0


Zum Katalog: Exchange Server 2007 und Office Communications Server 2007






 Exchange Server 2007
 und Office
 Communications
 Server 2007


Zum Katalog: Citrix XenApp 5






 Citrix XenApp 5


Zum Katalog: PC-Netzwerke






 PC-Netzwerke


Zum Katalog: VMware vSphere 4






 VMware vSphere 4


Zum Katalog: VMware vSphere 4 - Videotraining






 VMware vSphere 4
 - Videotraining


Zum Katalog: VirtualBox






 VirtualBox


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 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.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de