Die Remote Desktop Services bringen in Windows Server 2012 eine Reihe von Neuerungen, unter anderem das erweiterte RemoteFX und zusätz­liche Optionen für den Betrieb von virtuellen Desktops. Auch bei der Installation und Verwaltung der Terminaldienste hat sich einiges getan. Dazu gehören einerseits ein vereinfachtes Setup, andererseits aber auch der Wegfall von Features.

Windows Server 2008 führte die Installation von Rollen mit Hilfe des Server Managers ein. Sie erleichterte auch das Einrichten eines Terminal-Servers, auch wenn man sich selbst darum kümmern musste, dass alle erforderlichen Komponenten hinzugefügt und anschließend konfiguriert wurden.

Szenario-basierte Installation

Windows Server 2012 fasst die notwendigen Schritte zur Installation von Session-Based Desktop Deployments, wie die Terminaldienste neuerdings heißen, in einen Vorgang zusammen. Für ihre Verwaltung hat Microsoft die gewohnten MMC-Snap-ins zugunsten eines zentralen Managements weitgehend eliminiert. Vorerst noch vorhanden sind der RD Gateway Manager und der RD Lizenz-Manager.

Zuständig für die zentrale Einrichtung und Konfiguration einer Session-Host-Umgebung ist wie für viele andere Aufgaben der neue Server Manager. Führt man aus seinem Dashboard oder dem Verwalten-Menü den Befehl Rollen und Features hinzufügen aus, dann öffnet sich zu diesem Zweck ein eigener Assistent. Dieser bietet die Wahl zwischen der Einrichtung verschiedener Rollen und der Szenario-basierten Installation der Remote Desktop Services.

Quick Start auf einem Server

Gleich zu Beginn steht die Entscheidung zwischen virtuellen und sitzungsbasierten Desktops an, wobei Letztere die vertrauten Sessions auf einem Terminal-Server sind. Im darauf folgenden Schritt besteht die Auswahl zwischen einer Standardbereitstellung und Schnellstart. Erstere ermöglicht eine Konfiguration, bei der die einzelnen Rollen auf verschiedene Server verteilt werden und die mehrere Session Hosts umfasst.

Dagegen ist der Schnellstart dafür gedacht, alle Rollen auf einem Server zu installieren. Dabei werden auch gleich einige Programme als RemoteApp veröffentlicht. Diese Konstellation eignet sich primär für Testumgebungen oder kleine Installationen für den produktiven Einsatz.

Session Host ist immer Teil einer Bereitstellung

Ein Session Host ist grundsätzlich Mitglied einer Bereitstellung (Deployment), zu der mindestens ein Connection Broker, ein Lizenz-Server und RD Web Access gehören. Wenn man den ersten Terminal-Server einrichtet, dann erwartet der Wizard, dass man auch gleich weitere Komponenten eines Deployments installiert.

Fügt man jedoch einen weiteren Terminal-Server zu einer schon vorhandenen RDS-Bereitstellung hinzu, dann installiert man die Rolle von jenem Server Manager aus, der das gesamte RDS-Deployment verwaltet. Dazu muss man den künftigen Session Host erst über den Befehl Verwalten => Server hinzufügen in den Pool der Maschinen aufnehmen, die der Server Manager betreut. Anschließend kann man die Terminaldienste remote in der Bereitstellungsübersicht (Kontextmenü von Remotedesktop-Sitzungshost) einrichten.

Mitgliedschaft in einer Domäne erforderlich

Will man nun beim Einrichten einer neuen Bereitstellung fortfahren, dann stößt man auf eine Veränderung in Server 2012, falls er einer Workgroup angehört. Man wird nämlich mit der Meldung konfrontiert, dass die Installation den Beitritt der Maschine zu einer AD-Domäne erfordert.

Die durchaus nicht ganz unübliche Konfiguration eines Terminal-Servers in einer Workgroup ist über das neue zentrale Management nicht mehr möglich. Das bedeutet nicht, dass sie deshalb gänzlich unmöglich wäre, aber sie setzt eine durchgängige manuelle Konfiguration mit Hilfe von PowerShell oder lokalen Gruppenrichtlinien voraus. Die alten MMC-Tools für Server 2008 R2 lassen sich für den neuen Server nämlich nicht mehr nutzen.

Keine gemeinsame Installation von AD DS und RDS

Wenn man sich eine solche Prozedur nicht antun will, dann kann man bei kleinen Installationen, beispielsweise in Filialen und Außenstellen, die Verzeichnisdienste aber nicht zusammen mit den RDS auf einem Server installieren. Eine solche Konfiguration war auch bisher keine Best Practice, nun lässt sie sich jedoch nicht mehr einrichten.

Falls nur eine Maschine bereitsteht, dann wird der einfachste Weg darin bestehen, sie mit Hyper-V zu virtualisieren. Bereits die Standard Edition von Server 2012 erlaubt die Ausführung von zwei OS-Instanzen in VMs, so dass zumindest aus Sicht der Lizenzen keine zusätzlichen Kosten für ein solches Modell hinzukommen.

Eigene Installation für Lizenz-Server und RD Gateway

Die abschließenden Schritte in einer Standardbereitstellung sehen vor, dass man die Rollen RD Verbindungsbroker, RD Web Access und RD Session Host den dafür vorgesehenen Servern zuteilt. Nach erfolgter Einrichtung der gewählten Konfiguration muss man den Lizenz-Server und ein RD Gateway separat hinzufügen.

Auch diese Prozedur lässt sich aus dem Server Manager anstoßen. Entweder man nutzt dafür erneut den Assistenten zum Hinzufügen von Rollen und Features oder man wechselt zur Topologie-Darstellung der bisherigen Konfiguration und klickt auf die grünen Plus-Symbole für die fehlenden Komponenten.

Hochverfügbarkeit für Connection Broker

Diese Ansicht ist auch der Ausgangspunkt für die Installation eines weiteren neuen RDS-Features unter Server 2012. Er bietet nun eine Failover-Option für den Connection Broker, und zwar ohne dass man dafür ein Windows-Cluster einrichten muss. Ein weiterer Vorteil dieser neuen Funktion besteht in der Active-Active-Konfiguration, bei der die Arbeitslast über alle Knoten verteilt wird und somit eine bessere Skalierbarkeit gegebenen ist.

Das HA-Feature beruht darauf, dass die einzelnen Instanzen des Connection Brokers keine lokale Datenbank mehr verwenden. Vielmehr setzt die Installation voraus, dass ein SQL Server für alle beteiligten Server erreichbar ist. Außerdem muss auf jeder Broker-Maschine ein SQL Client eingerichtet werden.

Keine Spiegelung von RD Sessions mehr

Nicht nur die Installation von sitzungsbasierten Desktops erfolgt über den Server Manager, sondern er ist auch weitgehend für ihre Verwaltung zuständig. Für Administratoren wird ein wesentlicher Teil der Umstellung darin bestehen, die gewohnten Management-Funktionen in der neuen Umgebung zu finden.

Dabei werden sie aber nach einem Feature vergeblich suchen: Auf der Strecke blieb das Session Mirroring. Das Spiegeln von Sitzung wurde bisher gerne vom Helpdesk genutzt, um sich auf die Session eines Benutzers aufzuschalten. Erst in Windows Server 2012 R2 kehrt das Shadowing wieder.

Nächster Schritt: Session Hosts in Sammlungen organisieren

Nach der Einrichtung einer RDS-Bereitstellung oder dem Hinzufügen weiterer Terminal-Server zu einem bestehenden Deployment stehen die neuen Session Hosts für Benutzer noch nicht zur Verfügung.

Vielmehr müssen sie im nächsten Schritt in eine Collection aufgenommen werden, die alle Ressourcen der dort versammelten Hosts verwaltet