VDI-Lösung nutzt Windows Server 2008 Release 2, Teil 1
27. April 2011
Das Thema Desktop-Virtualisierung verfügt über viele Facetten. Hier sind Schlagwörter zu nennen wie Applikations-Virtualisierung, Roaming Profiles, Ordner-Umleitungen und die Betriebssystem-Virtualisierung. Diese verschiedenen Techniken waren Gegenstand der Artikelreihe
„Planung von Desktop-Umgebungen“ und zwar als Teil 1 und Teil 2.
Wer die einzelnen Bestandteile elegant kombiniert, bekommt eine sehr dynamische Benutzerumgebung – ganz wie sie benötigt wird – sei es mit lokalen Betriebssystemen, mit einer Präsentations-Virtualisierungs-Plattform (wie sie die Remote Desktop Services, RDS) darstellen oder aber als komplette Virtual Desktop Infrastructure (VDI).
In dieser Beitragsreihe wird gezeigt, wie sich eine reinrassige Microsoft-VDI-Lösung aufsetzen lässt, die dabei auf den Windows Server 2008 Release 2 (R2), genauer gesagt auf dem Hyper-V 2008 Release 2, basiert.
Ehe die Aufgabe am System angegangen wird, empfiehlt es sich, die notwendigen Dienste für eine erfolgreiche VDI-Implementierung zu bestimmen.
Die Voraussetzungen
In Abbildung 1 sind die grundlegenden Schritte skizziert, die man für die VDI-Funktionalität benötigt. Dabei wird der komplette Zyklus – vom ersten benutzerkontakt bis hin zu einer aktiven VDI-Session gezeigt. Dabei sind allerdings die „angrenzenden Technologien“, wie Microsoft Application Virtualization (App-V), die Roaming Profiles, etc. nicht inbegriffen.
In diesen Vorgang im Bild 1 sind sieben verschiedene Schritte zu erkennen. Zuerst müssen die Benutzer den „remoten Desktop“ finden, mit dem sie sich verbinden können. Dazu können prinzipiell Sitzungen an einem Terminaldienste-Server, publizierte Applikationen und VDI-Sitzungen gehören.
Auch wenn eine RDP-Datei erzeugt und auf verschiedene Methoden für Benutzer bereitgestellt werden kann, so gilt doch der Einsatz der Rolle “Remote Desktop Web Access” ein dynamischerer Ansatz. Er liefert dem Anwender Browser-basiert eine Liste aller verfügbaren Verbindungen, aus denen der Benutzer auswählen kann.
Eine Alternative für Anwender, die sich im Browser eine Website mit dynamisch publizierten Verbindungen und Applikationen ansehen müssen, ist der Einsatz des Features von Windows 7: "RemoteApp and Desktop Connections". Damit können sie einen RSS-basierten Feed von den Remote Desktop Web Access Servern abonnieren und erhalten so automatisch die verfügbaren Verbindungen. Das lässt sich dann zum Beispiel über ein, durch die Gruppenrichtlinien verteiltes Skript konfigurieren. Das hat eine elegante Auswirkung: Die Benutzer sehen die publizierten Dienste direkt in ihrem Startmenü.
Im zweiten Schritt geht es um das Erzeugen einer Liste mit den publizierten Applikationen und Verbindungen, die dem Benutzer angezeigt werden sollen. Dazu kommuniziert der Remote Desktop Web Access Server mit dem Remote Desktop Connection Broker. Denn dieses System kennt die VDI-Pools, die persönlichen Desktops und andere publizierte Verbindungen und Applikationen. Dazu kommuniziert der Remote Desktop Connection Broker mit den konfigurierten Quellen für die RemoteApps.
Im dritten Schritt spricht der Remote Desktop Connection Broker mit dem Active Directory (AD) und bestimmt damit den Zugriff des Benutzers. In dieser Kommunikation sind dann auch alle Informationen über jegliche Konfigurationen des “Personal Desktops” enthalten.
Egal welche Methodik genommen wird – sei es der Remote Desktop Web Access, das Feature RemoteApp and Desktop Connections oder auch nur eine bereitgestellte RDP-Datei – den Benutzern liegt nun eine RDP-Datei vor, mit deren Hilfe sie eine Verbindung initiieren können (Schritt 4). Wenn sich ein Anwender außerhalb des Unternehmensnetzwerks befindet, wird eine direkte RDP-Verbindung von den meisten Firewalls der Unternehmen blockiert werden.
Absicherung des Zugangs ist nötig
Doch man muss deswegen keine sichere VPN-Verbindung aufbauen. Es besteht eine alternative Lösung, die keinerlei Endbenutzer-Aktion oder zusätzliche Software auf den Client-Systemen erfordert:
Windows Server 2008 brachte das Terminal Services Gateway. Es erlaubt das Einkapseln des RDP-Verkehrs in HTTPS-Pakete (HTTPS nutzt den Port 443). Bei Windows Server 2008 R2 wurde das Terminal Services Gateway umbenannt zu Remote Desktop Gateway.
Mit der Komponente Remote Desktop Gateway in dieser Architektur wird der Server mit dem Remote Desktop Gateway in der demilitarisierten Zone (DMZ) oder – noch sicherer – hinter einer Art von Firewall oder Proxy platziert. Die Clients verbinden sich mit dem RDP-Zielpunkt über das Remote Desktop Gateway. Dazu muss der Remote Desktop Gateway Server ein Teil der RDP-Datei-Konfiguration sein, der an die Clients verteilt wird. Der Client kapselt den RDP-Verkehr dann im HTTPS und sendet die so verpackten RDP-Daten an das Remote Desktop Gateway. Hier findet dann die Extraktion der RDP-Daten aus HTTPS statt und dann werden die reinen RDP-Daten an den RDP-Zielpunkt weitergeleitet.
Kommt RDP-Verkehr von dem RDP-Zielpunkt zurück, der an den Client gerichtet ist, kapselt das Remote Desktop Gateway die RDP-Daten wieder in das HTTPS und sendet diese Daten dann an den Client. Mit diesem Ansatz haben die Anwender außerhalb des Unternehmensnetzwerks nach wie vor den Zugriff auf die RDP-Ressourcen, ohne zusätzliche Schritte machen oder weitere Software verwenden zu müssen.
Benutzer im Unternehmensnetzwerk würden dagegen das Remote Desktop Gateway umgehen und könnten direkt mit dem RDP-Ziel kommunizieren. Die Authentifizierung gegenüber dem Remote Desktop Gateway kann über die traditionelle Authentifizierung von Windows erfolgen oder aber über Smartcards. Dabei steht auch die Möglichkeit offen, sich über die aktuellen Anmeldeinformationen zu authentifizieren. Dazu bräuchte man allerdings seine Anmeldeinformationen nicht nochmals eingeben.
Im fünften Schritt benötigt der Benutzer einen anfänglichen RDP-Verbindungspunkt, da der Zielort für die VDI-Client-VM (Virtual Machine) noch nicht bekannt ist, solange der Anwender noch keinen konfigurierten Personal Desktop besitzt.
Ein Remote Desktop Session Host ist im Redirection-Modus konfiguriert. Das bedeutet, dass der Server als Verbindungspunkt für die RDP-Verbindung des Benutzers agiert. Dann leitet er den Client an den echten Endpunkt um, die VDI-Session.
Der Remote Desktop Session Host kommuniziert mit dem Remote Desktop Connection Broker, um zu bestimmen, welches RDP-Ziel für den anfragenden Client gelten soll. Der Remote Desktop Session Host und der Remote Desktop Connection Broker agieren auf demselben Host-System in dieser Architektur – doch das muss man nicht so machen. Das Zusammenlegen der beiden Rollen auf einer Hardware erweist sich aber durchaus als sinnvoll, weil die beiden Rollen sehr eng zusammenarbeiten müssen.
Im sechsten Schritt kommuniziert der Remote Desktop Connection Broker mit dem Rollendienst des Remote Desktop Virtualization Host, der beim Hyper-V aktiviert sein muss. Damit wird der Zustand der VMs geprüft, die VM wenn nötig gestartet und alle nötigen Informationen abgefragt, wie etwa die IP-Adresse des Client-VM-Betriebssystems. Diese Infos gehen dann an den Remote Desktop Connection Broker zurück, ebenso an den Remote Desktop Session Host im Redirection-Modus und dann zurück zum Client.
Im nächsten Schritt, dem siebten, macht der Client eine RDP-Verbindung zur Ziel-Client-VM über das Remote Desktop Gateway (wenn man sich von außerhalb des Unternehmensnetzwerks anbindet). Dann ist die Verbindung eingerichtet. Beim Anmeldevorgang wird das Profil über die Roaming Profiles heruntergeladen – zusammen mit den Daten, die über die Ordner-Umleitung und den Applikationen, die über App-V bereitgestellt werden.
Auch wenn das Verbinden mit einem gehosteten Desktop eine Vielzahl von Schritten – und auch Komponenten – benötigt, so ist es trotzdem ein schneller und problemloser Vorgang – zumindest aus Sicht des Anwenders. Dabei steht dem Anwender ein kompletter Desktop über RDP zur Verfügung.
Eine Komponente aus Abbildung 1, die bislang noch nicht besprochen wurde, ist Microsofts System Center Virtual Machine Manager (SCVMM). Auch wenn der SCVMM nicht in jedem Fall für eine VDI-Umgebung nötig ist, so erleichtert er doch viele Aufgaben im Bezug auf das Verwalten der VDI-Umgebung. Denn mit diesem Tool stehen Möglichkeiten für das Management von ganzen Hyper-V-Farmen, von Libraries und auch die Unterstützung der Powershell bereit.
Für eine reine VDI-Umgebung kann man getrost die frei verfügbare Variante des Hyper-V-Servers nehmen und sich die Ausgaben für den Windows Server 2008 R2 sparen. Der kostenpflichtige Windows Server 2008 R2 bietet dieselbe Hyper-V-Fähigkeiten wie die kostenlose Variante des Hyper-V Servers R2 – doch es kommen neben den Virtualisierungs-Funktionen auch noch andere Fähigkeiten beim kostenpflichtigen Server mit ins Spiel.
Zwar hat der Hyper-V im Windows Server 2008 R2 zusätzliche Lizenzrechte, um virtuelle Serverinstanzen anzulegen – die man allerdings in der reinen VDI-Umgebung nicht benötigt.
Wenn man sich all diese Schritte ansieht, die zu dem Verbindungsaufbau-Prozess gehören, gibt es fünf RDS-Rollen zu betrachten. Wer sich dazu entschließt, das Protokoll RemoteFX (das mit dem Servicepack 1 für Windows Server 2008 R2 und Windows 7 zur Verfügung steht) einzusetzen sogar deren sechs Remote Desktop Rollendienste.
Der Einsatz eines jeden Remote Desktop Rollendienstes bedeutet für die Clients, dass sie über RDS-CALs (Client Access Licenses) verfügen. Dazu kommen noch die Lizenzierung für jeden Virtual-Desktop-Zugriff oder die entsprechenden Software Assurance Rechte.
Im nächsten Teil diese Beitragsreihe geht es detailliert um die einzelnen Dienste und die zugehörigen Überlegungen, wenn man damit eine VDI-Umgebung aufbauen möchte. Weitere Informationen zum Einsatz einer VDI bietet Microsofts Technet-Seite zum Thema “Getting Started: Remote Desktop Services”.
