RD Modern Infrastructure: Die nächste Generation der Remote Desktop Services erfordert Azure

Diese herkömmliche Architektur lässt sich grundsätzlich auch in Azure auf Basis von virtuellen Maschinen implementieren, in die man die einzelnen Rollen installiert. Allerdings kann ein solches "Lift and Shift" kaum die Vorteile der Cloud nutzen. Anfangs ließ sich für ein hoch verfügbares Gateway nicht einmal Azure SQL einsetzen, vielmehr erforderte auch dies die Installation von SQL Server in einer VM.

Azure RemoteApp brachte dann eine engere Integration mit den PaaS-Diensten, so dass die Authenti­fizierung über Azure AD erfolgte und ein Deployment auch Zugriff auf Azure SQL hatte. Microsoft stellte den Service jedoch vor einem Jahr ein und empfahl Citrix XenDesktop Express als Alternative.

Wie sich nun bei der Ankündigung der Modern Infrastructure (RDmi) herausstellte, hat Microsoft damit seine Pläne für die RDS aus der Cloud keineswegs begraben. Vielmehr vertieft es die Integration mit Azure, indem weitere Komponenten eines RDS-Deployments als Plattform­dienste realisiert wurden.

RDS-Rollen als PaaS-Dienste

Das betrifft in jedem Fall das Gateway, den Broker und Web Access. Der Lizenz-Server ist ebenfalls ein Kandidat dafür, bis zur Ignite-Konferenz war aber noch nicht klar, ob eine Implemen­tierung als PaaS-Dienst für die Version 1 der RDmi noch fertig wird.

Hinzu kommt noch ein Diagnostics-Service für das Monitoring und Usage-Tracking. Für User Profile Disks steht Azure Files zur Verfügung.

In der Praxis bedeutet diese Architektur für Anwender, dass sie keine VMs in der Cloud benötigen, um dort etwa das Gateway oder Web Access bereitzustellen. Diese RDS-Infrastruktur­dienste lassen sich nach dem gleichen Muster buchen wie etwa Azure AD oder Storage-Dienste.

Anders als typische On-Prem-Installationen von RDS gehören die RDmi-Dienste keiner Domäne an. Ein Nebeneffekt dieses Designs besteht darin, dass sich eine RD Modern Infrastructure mandantenfähig betreiben lässt. Die Session Hosts oder virtuellen Desktops können dann ihrerseits Mitglied in verschiedenen Domänen sein.

Mehr Sicherheit durch Azure AD

Neben einem vereinfachten Deployment verspricht Microsoft noch weitere Vorteile durch die Auslagerung der RDS-Infrastruktur in die Cloud. Dazu gehört die Elastizität der Azure-Services, die mit steigender oder abnehmender Last automatisch skalieren. Dadurch müssen die Anwender nicht wie in der Vergangenheit physikalische Hardware vorhalten, die für Spitzenlasten ausgelegt ist.

Die Anbindung an das Azure AD erschließt den RDS zudem zusätzliche Sicherheits­funktionen, allen voran die Multifaktor-Authentifizierung und Conditional Access ("Bedingter Zugriff"). Außerdem vereinfacht sich damit für mobile User der Zugang zu den Anwendungen im Unternehmen.

RDVH-Rolle entfällt

Architektonische Änderungen stehen mit RDmi auch im Back-end an. Dort entfällt künftig die Rolle des Virtualization Host (RDVH). Stattdessen erhält jeder virtuelle Desktop einen Agent, der direkt mit dem Broker kommuniziert.

Dieser Agent läuft künftig auch auf den Session Hosts und hält über Port 443 den Kontakt mit der Infrastruktur in der Cloud. Daher muss in der Firewall kein Port für eingehende Verbindungen zum RDSH geöffnet werden, was die Sicherheit für die Anwendungen erhöht. Session Hosts und virtuelle Desktops können wahlweise in der Cloud oder im Rechen­zentrum des Unter­nehmens laufen.

Limitierungen der ersten Version

Allerdings leidet die Version 1.0 der RDmi unter Einschränkungen, die eine hybride Bereitstellung nicht sonderlich attraktiv machen, vor allem für Firmen, die der Cloud eher reserviert gegenüber­stehen. Zum einen führt vorerst kein Weg an Azure AD vorbei, erst in einer späteren Version soll ADFS unterstützt werden.

Problemtisch ist zumindest in der aktuellen Preview, dass RDP-Verbindungen immer über die RDmi in der Cloud laufen, selbst wenn sich der Session Host und der Client im gleichen LAN befinden. Daraus könnten sich hohe Latenzen ergeben. Ob sich das bis zum ersten Release noch ändert, ließ der Vortrag zu RDmi auf der Ignite offen.

Die Rolle Web Access liefert im Gegensatz zu der bisherigen Implementierung kein gebrauchs­fertiges Web-Interface, sondern nur einen Feed. Wenn man daraus eine eigene Ober­fläche bauen möchte, dann bietet dieser Ansatz große Flexibilität, aber gleichzeitig entstehen Kosten, wenn man damit einen Partner beauftragt.

Kein RDP über UDP

Wie häufig beim Refactoring komplexer Systeme entfallen in der ersten Version einige bisher vorhandene Features. Diese Erfahrung musste auch schon Citrix beim Architekturwechsel von XenApp machen.

So bleibt bei RDmi vorerst RDP über UDP auf der Strecke, das mit Windows Server 2012 eingeführt wurde. Darüber hinaus kennt es nur Lizenzen pro User und keine pro Gerät.

Außerdem fällt vorerst ein wesentlicher Vorteil des Cloud-Deployments unter den Tisch, nämlich weltweit verteilte Instanzen, zu denen sich die Clients abhängig von ihrem Standort verbinden. Auch dies soll später nachgeliefert werden.

Obwohl die RD Modern Infrastructure schon ab Mitte 2018 in einer ersten Ausführung verfügbar sein soll, bleibt derzeit noch eine Reihe von Fragen offen. So ist noch nicht klar, ob zumindest eine Lizenz für die Basisversion von Azure AD in den RDmi enthalten sein wird (so wie bei Office 365).

Verschiedene Update-Intervalle für RDmi und Session Hosts

Ein weiteres Thema sind die getrennten Entwicklungs­zyklen für die Cloud-basierten RDS-Rollen und Windows Server mit Desktop Experience, der für Session Hosts erforderlich ist. Im Semi-Annual Channel erscheinen nur neue Releases von Server Core, so dass Innovationen für die RDSH-Rolle bis zu 3 Jahre warten müssen. Dagegen wird RDmi einem wesentlich schnelleren Update-Rhythmus folgen.

Gänzlich unklar ist bis dato, was jene Anwender zu erwarten haben, die keine Cloud-Dienste in Anspruch nehmen möchten. Von Microsoft gibt es keine Aussage dazu, ob die herkömmlichen Rollen im nächsten LTSC-Release von Windows Server noch enthalten sein werden oder ob der Hersteller sie auf Azure Stack verweisen wird.

Immerhin möchte Microsoft für eine reibungslose Migration der vorhandenen Bereitstellungen unter Windows 2012 R2 und 2016 sorgen. Dort soll es ausreichen, den neuen Agent auf dem Session Host oder in virtuellen Desktops zu installieren, um diese an die neue Infrastruktur anzubinden.