Azure Virtual Desktop (AVD) Workshop Teil 1 - Architektur und Bereitstellung

In der Microsoft-Welt gibt es mittlerweile zahlreiche Möglichkeiten, wie Sie Nutzern in ihrem Unternehmen Desktop-Arbeitsplätze aus der Cloud zur Verfügung stellen kannst. Nehmen wir zur weiteren Eingrenzung an, dass Control-Plane und Compute-Knoten in Azure laufen sollen, was z. B. Compliance- und Governance-Aspekte dank Entra ID (ehemals Azure AD) und RBAC erheblich vereinfacht, wären das der „Cloud PC“ (Windows 365), „RDS auf Azure VMs“ und „Azure Virtual Desktop“ (AVD – ehemals Windows Virtual Deskop). Cloud PC und AVD werden wir mit je einem Beitrag näher beleuchten, beginnend mit Azure Virtual Desktop.

Bevor wir über AVD sprechen, rufen Sie sich in Erinnerung, was Windows Server mit der einbauten RDS-Rolle bereits von Haus bietet und zwar in allen Versionen ab 2008R2 bis 2022 und auch die für 2025 oder 2026 erwartete Windows Server-Version wird RDS-Support enthalten. Sie können dann besser beurteilen, welche Vorteile AVD bietet. Mit RDS können Sie in Abhängigkeit ihrer Umgebung Microsofts Windows-Server basierte RDS-Lösung wahlweise für sitzungsbasierte Virtualisierung oder für eine Virtual-Desktop-Infrastruktur (VDI) oder als Kombination daraus nutzen.

Damit ergeben sich faktisch 4 relevante Nutzungsszenarien. Zunächst differenzieren Sie nach „sitzungsbasierte Virtualisierung“ und „VDI“. In ersteren Fall nutzen Sie die Rechenleistung von Windows Server, um eine kostengünstige Multisession-Umgebung auf Grundlage eines oder mehrerer RDSHs für die täglichen Workloads deiner Nutzer bereitzustellen.

Im Falle der VDI-Option ist das Zielsystem hingegen ein virtualisierter Windows-Client auf Basis eines einzelnen oder mehrerer RDVHs. Dieser bietet ihren Nutzern hohe Leistung, eine sehr hohe App-Kompatibilität und eine vertraute Windows-Desktop-Umgebung, d. h. jeder Nutzer bekommt eine eigene von Hyper-V bereitgestellte Client-VM. Aber Achtung: Hier handelt es sich um eine 1:1-Beziehung zwischen User-Desktop und VM, denn Client-Betriebssysteme sind prinzipiell erstmal nicht multisession-fähig – im Gegensatz zum Windows Server mit der Session-Host-Rolle. Es gibt zwar ein multissessionfähiges Image für Windows 1o/11, aber nur in Azure (AVD) und für Azure Stack HCI.

Innerhalb des jeweiligen Szenarios können Sie sich dann entscheiden zwischen vollständigen Desktops, was ideal für Nutzer ist, welche den bereitgestellten Desktop als primäre Arbeitsstationen nutzen oder RemoteApps. In diesem Fall definieren Sie lediglich einzelne Anwendungen, die auf dem virtuellen Computer gehostet/ausgeführt werden. Aus Sicht des zugreifenden Nutzers verhalten sich diese so, als würden sie wie lokale Anwendungen auf dem eigenen Desktop ausgeführt und erscheinen sogar mit einem eigenen Eintrag in der Taskleiste.

Übrigens ist RDS skalierbar, Sie brauchen aber im Minimum zwei Server, weil die Rollen RDSH und Lizensierungsserver auf getrennten Maschinen laufen müssen. Fakt ist, dass Sie sich bei RDS (auch wenn du RDS auf Azure-VMs betreibst) um das Bereitstellen und Betreiben der Rollen „Remotedesktop-Sitzungshost“, „Remotedesktop-Verbindungsbroker“, „Remotedesktop-Gateway“ und „Remotedesktop-Webzugriff“ sowie um den oben erwähnten Remotedesktop-Lizenzierungsserver“ selbst kümmern müssen, einschließlich aller Aspekte, die etwaige Anforderungen im Bereich hoher Verfügbarkeit und Failover-Clustering betreffen.

AVD: RDS auf Azure

Möchten Sie dagegen die Remotedesktop-Dienste auf Azure bereitstellen, laufen alle beteiligten RDS-Rollen auf VMs, wobei die Komponenten im oberen Teil der folgenden Abbildungen, welche mit Connection-Broker, Gateway, Lizenzierungsserver und Web-Access zum sogenannten Control-Plane gehören, vollständig von Microsoft verwaltet und betrieben werden, einschließlich eines öffentlichen Loadbalancers, um den Zugriff auf die Plattform von außen über öffentliche Leitungen zu ermöglichen.

Aus administrativer Sicht müssen Sie lediglich die Session-Hosts dimensionieren, welche in Host-Pools zusammengefasst werden, um bei Bedarf Skalierbarkeit zu ermöglichen. Die Session-Host sind letztlich gewöhnliche Azure-VMs. Im Gegensatz zu RDS On Premise müssen das aber nicht zwingend Windows-Server sein. In AVD unterstützt Microsoft nämlich auch das Hosten mehrerer Desktop-Sitzungen auf Basis eines Windows-11-Images für mehrinstanzfähiges Hosting. Im einfachsten Fall sieht eine AVD-Architektur in Azure dann wie folgt aus:

Der „File-Server“ ist nicht zwingend und wird z. B. für das Hosten von Benutzerprofilen auf Basis von FSLogix benötigt. FSLogix ermöglicht eine konsistente Benutzeroberfläche für Windows-Benutzerprofile in virtuellen Desktop-Umgebungen. Sie können diese Basis-Architektur nach Belieben erweitert, z. B. durch eine hochverfügbare Bereitstellung von RD-Webserver und Gatewayserver oder mit der RDS-Berteistellung über den AD-Anwendungsproxy, um z. B. RD-Webserver/Gatewayserver ohne internetseitigen Einstiegspunkt verwenden zu können. Darüber hinaus möchten Sie wahrscheinlich den Zugriff auf ihre Remote-Desktop-Umgebungen mit Konten aus ihrem Active Directory steuern, weshalb die Abbildung oben eine AD-VM beinhaltet. Sie können den Betrieb von Domaincontrollern in Azure aber auch an einen Plattform-Service wie die Azure Active Directory Domain Services delegieren. Das sieht dann so aus:

In Enterprise-Umgebungen sähe eine sicherere, performante und hochverfügbare AVD-Bereitstellung vermutlich aber eher so aus, wie in der offiziellen AVD-Dokumentation von Microsoft:

Strenggenommen sind bei dieser Abbildung aber nur der AVD Control-Plane und die VMs in Desktop-Subnet der eigentlichen AVD-Architektur zuzuordnen. Der Rest dient hier dazu, dass Nutzer in großen Unternehmen über eine sichere und performante private Leitung (Express Route) geschützt durch eine Azure Firewall mit Hilfe synchronisierte ADDS-Konten im Azure AD auf Basis der Active Directory Domain Services und durch Intune-Richtlinien berechtigte Endpunkte auf die AVD-Umgebung zugreifen.

Für einen einfachen und schnellen Start können Sie aber zunächst auch mit Hilfe von Cloud-Only-Identitäten auf Basis von Azure AD (Intra ID) starten. Auch auf einen Dateiserver für FSLogix können Sie für den Start verzichten. Für einen minimales Proof-of-Concept-Szenario gehen Sie einfach wie folgt vor:

AVD-Bereitstellung in Azure

Suchen Sie dazu im Azure-Portal nach „AVD“ (Azure Virtual Desktop) und starten auf der Übersichtsseite mit einem Klick auf „Hostpool erstellen“:

Sie benötigen den Hostpool als übergeordnete Entität für das einfache Verwalten von „Zuweisungen“, „Anwendungsgruppen“ oder Einstellungen für deine gesamte Organisation. Ein solcher Hostpool kann mehrere Session-Hosts aufnehmen, Sie können aber auch mit einem starten. Doch zunächst zum Tab „Grundeinstellung“. Hier brauchen Sie neben den üblichen Angaben wie Subscription, Ressourcengruppe, Hostpoolname und Standort vor allem zwei wichtige Einstellungen:

Zunächst geht es um den bevorzugten „App-Gruppentyp“. Zur Wahl stehen hier „Desktop“ und „RemoteApp“. In diesem Beispiel verwenden Sie „Desktop“ (Default), damit jeder Nutzer eine vollwertige Desktop-Sitzung erhält“. Ferner müssen Sie einen „Hostpooltyp“ wählen. Zur Wahl stehen „Persönlich“ oder „In Pool“ (engl. „pooled“). In ersterem Fall erhält jeder Nutzer-Desktop einen vollständigen Sitzungs-Host für sich allein, was zwar performant, aber nicht sonderlich kosteneffizient ist. Daher wählen wir für dieses Beispiel „In Pool“, was die Auswahl eines „Lastenausgleichsalgorithmus“ erfordert.

Zur Wahl stehen „Breitenorientierter- und „Tiefenorientierter Lastausgleich“. Ersterer verteilt sämtlicher Nutzer-Sitzungen gleichmäßig über alle Sitzungshost im Hostpool, was auch bei steigender Sitzungszahl eine gleichbleibende Performance ermöglicht. Beim tiefenorientierten Lastausgleich wird immer zuerst der erste Sitzungshost bis zur maximal definierten Sitzungszahl bestückt, bevor der zweite Host im Cluster Sitzungen erhält. Die maximal gewünschte Anzahl von Sitzungen können Sie dann mit der gleichnamigen Option ganz unten einrichten. Diese hängt natürlich von der gewählten VM-Größe seine Sitzungshosts und von der Art der Workloads ab.

Die Anzahl der VMs im Hostpool bestimmen Sie im nächsten Schritt bei der VM-Konfiguration. Der tiefenorientierte Lastausgleich kommt also vor allem einen möglichst kostengünstigen Betrieb zugute, falls Sie z. B. mit nur einem oder zwei Hosts starten möchten. Sie müssen zwar die Anzahl der VMs initial bestimmen, können aber nicht benötigte Hosts ggf. auch ausschalten. Daher dürfen Sie den tiefen- oder breitenorientierten Lastausgleich von AVD nicht mit der Funktion von Azure-VM-Skalierungsgruppen verwechseln. Letztere adressieren vor allem statuslose Workloads die horizontale Skalierung unterstützen auf VMs. Beim AVD-Hostpool legen Sie sich grundsätzlich auf eine Host-Anzahl fest. Der Lastausgleichsalgorithmus entscheidet nur über die Platzierung von Sitzungen.

Eine mit Scalesets eher vergleichbare Funktion bietet hingegen das neue und daher derzeit noch in Vorschau befindliche Feature „Skalierungsplan für die Autoskalierung“ in Azure Virtual Desktop. Hierbei könnten Sie ihre Sitzungshosts-VMs in einem Hostpool gemäß einem Zeitplan hoch- bzw. herunterskalieren, um die Bereitstellungskosten zu optimieren. Beachten Sie aber, dass die Autoskalierung bei gepoolten Hostpools den eben erwähnten Lausausgleichsalgorithmus überschreibt. Diese Autoskalierung der Sitzungshosts kann die VMs-Hosts in jeder Phase des Skalierungsplanzeitplans automatisch einschalten, sobald die verwendete Hostpoolkapazität den Kapazitätsschwellenwert überschreitet oder Hosts auch ausschalten, wenn die Kapazität nicht benötigt wird.

Im nächsten Reiter „VM-Details“ spezifizieren Sie die im Hostpool bereitgestellten Azure-VMs. Sie können das auch später erledigen. Möchten Sie es hier im Assistenten erledigen, markieren Sie bei „Hinzufügen virtueller Azure-Computer“ die Option „Ja“ und konfigurieren die gewünschte Azure-VM genauso, wie Sie es von gewöhnlichen Azure-VMs kennen. Die einzige Besonderheit hier ist, dass Sie bei „Image“ die Möglichkeit haben, „Windows 11 Enterprise multi-session, Version 22H2“ oder „Windows 11 Enterprise multi-session + Microsoft 365 Apps, Version 21H2“ auszuwählen.

Im Abschnitt „Netzwerk und Sicherheit“ platzieren Sie ihren Host in das gewünschte virtuelle Azure-Netzwerk. Hier haben Sie die Möglichkeit zu steuern, welche Netzwerkrouten für ihre Endbenutzer erlaubt sind, wenn diese Feed-Anforderungen an den jeweiligen Arbeitsbereich senden. Sie können entweder den öffentlichen Zugriff (mit öffentlichen IP-Adressen) erlauben oder den privaten Zugriff (mit privaten Endpunkten) aktivieren. 

Wichtig wird es wieder im Abschnitt „Domäne für den Beitritt“. Hier haben Sie die Wahl zwischen „Active Directory“ und „Azure Active Directory“. Wie oben erklärt starten wir in diesem Beispiel der Einfachheit halber mit „Letzterem“. Sie müssen sich dann mit einem Organisationskonto (Cloud-Only oder Hybrid) beim Arbeitsbereich und beim Session-Host anmelden. Sie haben zusätzlich noch die Wahl, diese VM auch bei Intune zu registrieren. Trotzdem wird, wie bei jeder gewöhnlichen Azure-VM auch, immer zunächst ein lokales Benutzerkonto angelegt, weshalb Sie hier den Namen des lokalen Administrators für den virtuellen Computer angeben müssen, welches Sie aber nach der initialen Bereitstellung des virtuellen Computers wieder löschen können.

Ferner könnten Sie im Abschnitt „Benutzerdefinierte Konfiguration“ noch den Speicherort einen ARM-Templates zur benutzerdefinierten Konfiguration ihres Sitzungshosts angeben. Dieses könnte dann entweder ein eingebettetes Bereitstellungsskript oder eine DSC-Konfiguration beinhalten; das ARM-Template kann dann aber keine anderen Azure-Ressourcen erzeugen.

Im nächsten Schritt des Assistenten müssen Sie einen so genannten Arbeitsbereich (Workspace) definieren; auch dies eine definierte AVD-Begrifflichkeit, nicht zu verwechseln mit einem Log Analytics Workspace. In diesem wird von Assistenten mit Aktivieren der gleichnamigen Option eine neue „Desktop-App-Gruppe“ registriert.

Sie können das ggf. auch später machen. Bei den übrigen Einstellungen des Assistenten können Sie die Default-Werte übernehmen und auf „Überprüfen und Erstellen“ klicken. Wir haben im Beispiel nur 2 Sitzungen pro Host zugelassen, um mit bei 2 Hosts im Hostpool die Funktionsweise vom tiefen- oder breitenorientierten Lastausgleich schneller evaluieren zu können.

Anwendungen und Zuweisungen

Die vom Assistenten eingerichteten „Arbeitsbereiche“ und „Anwendungsgruppen“ finden Sie später im AVD-Hauptmenü wieder. Ein Arbeitsbereich ist eine logische Gruppierung von Anwendungsgruppen in AVD. Jede -Anwendungsgruppe muss mit einem Arbeitsbereich verknüpft sein, damit die Benutzer die für sie veröffentlichten Desktops und Anwendungen sehen. Sie sind jetzt eigentlich schon startklar. Verifizieren Sie falls gewollt noch die Bereitstellung, indem Sie im Azure Portal zum eben erstellten Hostpool navigieren und z. B. die erstellten Hosts anzeigen.

Im Abschnitt „Verwalten“ finden Sie ihre „Anwendungsgruppen“. Sie können auch im Azure-Portal danach suchen oder über das AVD-Blade zu „Anwendungsgruppen“ navigieren. Dort finden Sie alle Anwendungsgruppen über alle Hostpools hinweg. In einer Anwendungsgruppe konfigurieren Sie „Anwendungen“ und „Zuweisungen“.  Bei den Anwendungen hatten wir ja im Rahmen der Assistenten-geführten Hostpool-Bereitstellung eine Anwendung von Typ „SessionDesktop“ definiert.

Die Anwendungsgruppen eines Hostpools mit ihren Anwendungen.

Sie könnten bei Bedarf auch eine Anwendungsgruppe vom Typ „RemoteApp“ bereitstellen.

Schließlich müssen Sie ihre Anwendungen noch zuweisen. Klicken Sie dazu in ihrer Anwendungsgruppe unter „Verwalten / Zuweisungen“ auf „Hinzufügen“ und wählen den gewünschten Nutzer aus ihrem AzureAD/EntraID, denn wir haben unseren Host-Pool ja explizit mit AzureAD-Integration konfiguriert. In hybriden- und Enterprise-Umgebungen wäre die Konfiguration hingegen etwas umfangreicher.

Client-Zugriff konfigurieren

Für den Zugriff auf ihre Virtual-Deskop-Sitzungen und/oder Anwendungen benötigen Sie entweder den https://client.wvd.microsoft.com/arm/webclient/ AVD-Webaccess oder Sie installieren den nativen Client. Den gibt es als https://go.microsoft.com/fwlink/?linkid=2139369 Windows-Desktop-Client, https://aka.ms/AVDStoreClient AVD-Store-App für Windows, MacOS-Client sowie wie für iOS und Android.

In unserem Beispiel sollten Sie sich jetzt zwar mit einer Azure-AD-Identität z. B. im Web-Access anmelden können und auch den oder die dir zugewiesenen Workspaces angezeigt bekommen, einschließlich des in diesem enthaltenen SessionDesktops, bzw. ggf. noch weitere RemoteApps ……

…. Sie können sich aber nur dann von deinem lokalen PC aus über die Windows-Client-App am SessionDesktop anmelden, wenn dieser in denselben Azure AD-Mandanten eingebunden ist, wie ihr Sitzungshost. Alternativ kann er auch als Hybridgerät in denselben Azure AD-Mandanten eingebunden sein, wie der Sitzungshost. Außerdem muss auf ihrem lokalen PC Windows 11 oder Windows 10 (Version 2004 oder höher) laufen.

Wir verwenden daher hierfür der Einfachheit den Webaccess. Eine weitere Voraussetzung ist (egal welcher Client) ist, dass der betreffende Nutzer in IAM für den Workspace die Rolle „Desktopvirtualisierungsbenutzer“ besitzt, was aber der Fall sein sollte, wenn Sie bisher sämtliche Anweisungen befolgt haben.

Weitere im Kontext von AVD einsetzbare IAM-Rollen finden Sie in der https://learn.microsoft.com/de-de/azure/virtual-desktop/rbac AVD-Dokumentation. Möchten Sie über den Web-Client zugreifen, müssen Sie zudem im Hostpool die RDP-Eigenschaft „targetisaadjoined:i:1“ setzen. Das können Sie z. B. im Azure-Portal erledigen:

Würden Sie über die MSTC eines eingebundenen lokalen-PCs zugreifen wollen, müssen Sie in den erweiterten MSTC-Einstellungen die Option „Verwenden eines Webkontos zum Anmelden beim Remote-Computer“ aktivieren.

Ferner gilt beim RDP-Zugriff auf einen direkt im Azure-AD eingebundenen Windows 10/11-PC mit Hilfe eines AzureAD-Benutzerkontos, dass den betreffenden Nutzern eine der beiden Azure-Rollen „Anmeldeinformationen des VM-Administrators“ oder „Anmeldeinformationen für VM-Benutzer“ zugewiesen sein muss. Das können Sie in der deiner Ressourcengruppe oder auf dem Hostpool tun.

Schließlich muss auf der betreffenden VM (Sitzungs-Hosts) die Extension „AADLoginForWindows“ aktiviert sein. Das erledigt AVD zwar auch automatisch, es kann aber passieren, dass das Provisioning der Extension fehlschlägt und ggf. manuell wiederholt werden muss.

Sobald Sie die oben erwähnten hybriden Voraussetzungen geschaffen haben, können Sie sich mit ihrem Azure-AD-Konto an ihrer eigenen Sitzung anmelden:

AVD fragt dabei, ob Sie lokale Geräte wie Drucker oder die Zwischenablage in die Remote-Sitzung durchreichen oder die Dateiübertragung aktivieren möchten. Das klappt auch mit benutzerdefiniertem Domainnamen. Nach wenigen Sekunden können Sie  über ihren persönlichen Cloud-Desktop verfügen: