Teil 1 – Virtuelle Desktops mit Azure AVD bereitstellen
In der Microsoft-Welt gibt es mittlerweile zahlreiche Möglichkeiten, wie du Nutzern im deinem 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 möchten wir mit je einem Beitrag näher beleuchten, beginnend mit Azure Virtual Desktop.
Zur kompletten Azure Virtual Desktop Beitragsreihe:
- Teil 2 – Azure Virtual Desktop: User-Profil Management mit FSLogix Basics
- Teil 3: Azure Virtual Desktop: User-Profil Management mit FSLogix Konfiguration
- AVD Teil 4 – FSLogix-Profil-Container auf Azure Files
Bevor wir über AVD sprechen, solltest du dir in Erinnerung rufen, 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. Du kannst dann besser beurteilen, welche Vorteile AVD bietet. Mit RDS kannst du in Abhängigkeit deiner 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 differenzierst du nach „sitzungsbasierte Virtualisierung“ und „VDI“. In ersteren Fall nutzt du 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 deinen 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 kannst du dich 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 definierst du 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, du brauchst aber im Minimum zwei Server, weil die Rollen RDSH und Lizensierungsserver auf getrennten Maschinen laufen müssen. Fakt ist, dass du dich 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 musst, einschließlich aller Aspekte, die etwaige Anforderungen im Bereich hoher Verfügbarkeit und Failover-Clustering betreffen.
AVD: RDS auf Azure
Möchtest du 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.
Als Nutzer musst du 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. Du kannst 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öchtest du wahrscheinlich den Zugriff auf deine Remote-Desktop-Umgebungen mit Konten aus deinen Active Directory steuern, weshalb die Abbildung oben eine AD-VM beinhaltet. Du kannst 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 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 kannst du 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 kannst du für den Start verzichten. Für einen minimales Proof-of-Concept-Szenario gehst Du einfach wie folgt vor:
AVD-Bereitstellung in Azure
Suche dazu im Azure-Portal nach „AVD“ (Azure Virtual Desktop) und starte auf der Übersichtsseite mit einem Klick auf „Hostpool erstellen“:
Du benötigst 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, du kannst aber auch mit einem starten. Doch zunächst zum Tab „Grundeinstellung“. Hier brauchst du 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 wir „Desktop“ (Default), damit jeder Nutzer eine vollwertige Desktop-Sitzung erhält“. Ferner musst du 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 kannst du 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 bestimmst du im nächsten Schritt bei der VM-Konfiguration. Der tiefenorientierte Lastausgleich kommt also vor allem einen möglichst kostengünstigen Betrieb zugute, wenn du z. B. mit nur einem oder zwei Hosts starten möchtest. Du musst zwar die Anzahl der VMs initial bestimmen, kannst aber nicht benötigte Hosts ggf. auch ausschalten. Daher darfst du 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 legst du dich 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 kannst du deine Sitzungshosts-VMs in einem Hostpool gemäß einem Zeitplan hoch- bzw. herunterskalieren, um die Bereitstellungskosten zu optimieren. Beachte 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, wenn 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“ spezifizierst du die im Hostpool bereitgestellten Azure-VMs. Du kannst das auch später erledigen. Möchtest du es hier im Assistenten erledigen, markierst du bei „Hinzufügen virtueller Azure-Computer“ die Option „Ja“ und konfigurierst die gewünschte Adure-VM genauso, wie du es von gewöhnlichen Azure-VMs kennst. Die einzige Besonderheit hier ist, dass du bei „Image“ die Möglichkeit hast „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“ platzierst du deinen Host in das gewünschte virtuelle Azure-Netzwerk. Hier hast du die Möglichkeit zu steuern, welche Netzwerkrouten für deine Endbenutzer erlaubt sind, wenn diese Feed-Anforderungen an den jeweiligen Arbeitsbereich senden. Du kannst 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 hast du die Wahl zwischen „Active Directory“ und „Azure Active Directory“. Wie oben erklärt starten wir in diesem Beispiel der Einfachheit halber mit „Letzterem“. Du musst dich dann mit einem Organisationskonto (Cloud-Only oder Hybrid) beim Arbeitsbereich und beim Session-Host anmelden. Du hast 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 du hier den Namen des lokalen Administrators für den virtuellen Computer angeben musst, welches du aber nach der initialen Bereitstellung des virtuellen Computers wieder löschen kannst. Ferner könntest du im Abschnitt „Benutzerdefinierte Konfiguration“ noch den Speicherort einen ARM-Templates zur benutzerdefinierten Konfiguration deines 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 musst du 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.
Du kannst das ggf. auch später machen. Bei den übrigen Einstellungen des Assistenten kannst du 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“ findest du 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. Du bist jetzt eigentlich schon startklar. Verifiziere wenn du magst die Bereitstellung, indem du im Azure Portal zum eben erstellten Hostpool navigierst und z. B. die erstellten Hosts anzeigst.
Im Abschnitt „Verwalten“ findest du deine „Anwendungsgruppen“. Du kannst auch im Azure-Portal danach suchen oder über das AVD-Blade zu „Anwendungsgruppen“ navigieren. Dort findest du alle Anwendungsgruppen über alle Hostpools hinweg. In einer Anwendungsgruppe konfiguriere „Anwendungen“ und „Zuweisungen“. Bei den Anwendungen hatten wir ja im Rahmen der Assistenten-geführten Hostpool-Bereitstellung eine Anwendung von Typ „SessionDesktop“ definiert.
Du könntest bei Bedarf auch eine Anwendungsgruppe vom Typ „RemoteApp“ bereitstellen.
Schließlich musst du deine Anwendungen noch zuweisen. Klicke dazu in deiner Anwendungsgruppe unter „Verwalten / Zuweisungen“ auf „Hinzufügen“ und wählen den gewünschten Nutzer aus deinem 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 deine Virtual-Deskop-Sitzungen und/oder Anwendungen benötigst du entweder den https://client.wvd.microsoft.com/arm/webclient/ AVD-Webaccess oder du installierst 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 solltest du dich 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 ……
…. du kannst dich 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 dein Sitzungshost. Alternativ kann er auch als Hybridgerät in denselben Azure AD-Mandanten eingebunden sein, wie der Sitzungshost. Außerdem muss auf deinem 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 du bisher sämtliche Anweisungen verfolgt hast.
Weitere im Kontext von AVD einsetzbare IAM-Rollen findest du in der https://learn.microsoft.com/de-de/azure/virtual-desktop/rbac AVD-Dokumentation. Möchtest du über den Web-Client zugreifen musst du zudem im Hostpool die RDP-Eigenschaft „targetisaadjoined:i:1“ setzen. Das kannst du z. B. im Azure-Portal erledigen:
Würdest du über die MSTC eines eingebundenen lokalen-PCs zugreifen wollen, musst du 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 kannst du 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 du die oben erwähnten hybriden Voraussetzungen geschaffen hast, kannst du dich mit deinem Azure-AD-Konto an deiner eigenen Sitzung anmelden:
AVD fragt dich dabei, ob du lokale Geräte wie Drucker oder die Zwischenablage in die Remote-Sitzung durchreichen oder die Dateiübertragung aktivieren möchtest.
Das klappt auch mit benutzerdefiniertem Domainnamen. Nach wenigen Sekunden kannst du über deinen persönlichen Cloud-Desktop verfügen:
Dank unseres multisession-fähigen Windows-11-Images kannst du dich jetzt testweise mit einem weiteren Nutzer anmelden.
Lizenzen und Kosten
Du hast nun gesehen, wie (relativ) einfach es ist, im Gegensatz zu RDS oder Windows Terminal Server, mit AVD eine Desktop-Virtualisierungsumgebung aufzusetzen. Was ich allerdings thematisch völlig ausgelassen habe, ist die Lizenz- und Kostenfrage. Hier unterscheiden sich nicht nur Cloud- und OnPremise maßgeblich voneinander, sondern auch Windows-Server und Windows-Client. Die Kosten für AVD resultieren im wesentlich aus denen für die Sitzungshosts, die ausgehende Datenübertragung und den Speicher, welchem du aus der VM heraus nutzen möchtest.
Auch dies habe ich bisher nicht thematisiert. Du könntest persönliche Daten in deinem User-Verzeichnis auf dem Sitzungshost ablegen, wozu du entsprechende großzügig dimensionierte Datenträger in der VM bräuchtest. Insbesondere im Pooled-Modus müsstest du dir Gedanken um die Persistenz machen und landest dann schnell bei Überlegungen zu FSLogix mit entsprechender Kostenfrage rund um einen Dateiserver für Nutzer-Profile, etwa auf Basis von Azure Storage-Dateifreigaben. Wenn du auf der anderen Seite berücksichtigst, dass der Azure-Backbone dem ausgehenden VM-Datenverkehr durchgängig mindestens 100 GBit/s Netzwerkbandbreite bietet, könntest du zugunsten von Onedrive-/, bzw. Sharepoint-Speicher auch auf große VM-Datenträger gänzlich verzichten, denn die Daten lägen ja so oder so in der Cloud.
Hinzu kommen Lizenz-Themen. Würdest du für Sitzungshosts ein Windows-Server-Betriebssystem nutzen, fielen zwar wie bei jeder Azure-Server-VM keine Kosten für Server-CALs an, unter Umständen aber für RDS-CALs, je nachdem aus welchen Vertriebskanal und mit welche Lizenz-Form du deinen Azure Session-Host-Server betreibst. Stichwort „Azure Hybrid Use-Benefit und Software Assurance“. Bei Windows-Client (Windows 11) als Sitzungs-Host, fiele zwar das CAL-Thema weg, du müsstest dich aber je nach Szenario mit VDA-Lizenzen (Virtual Desktop Access License) auseinandersetzen. Im übrigen haben wir uns lizenztechnisch noch gar nicht über die oben erwähnte Software Assurance für das Windows-11-Image für mehrinstanzfähiges Hosting befasst.
Auch über Office 365 haben wir noch nicht gesprochen. So gibt es ja wie oben erwähnt auch ein passendes Windows-11-Mulisession-Image mit vorinstallierten Office365-Client-Apps. Allerdings brauchst du dann entweder einen passenden O365-Lizenz-Plan mit enthaltendem VDA (E3, E5 oder Business Premium) oder du müsstest die VDAs einzeln erwerben und vorhalten. Bei zugreifenden Linux-Clients gilt das ohnehin. Außerdem brauchst du, je nachdem, ob du die O365-Client-Apps auf einem Server- oder Client betreibst am zugreifenden lokalen Windows-Servereine (Remote)-zugriffsberechtige Windows-11-Basis-Version („Professional“ beispielsweise), bzw. die entsprechende SCA. Ich bin kein Lizenz-Spezialist, aber du siehst, dass hier noch einer Reihe von Überlegungen auf dich zukommen, welche du nahezu alle umgehen kannst, wenn du Windows 365 (Cloud PC) in Erwägung ziehst (nächster Artikel), insbesondere, wenn ohnehin jeder Nutzer einen dedizierten Desktop (ohne Pooling) erhalten soll.
Kontakt
„*“ zeigt erforderliche Felder an
powered by Borlabs Cookie