Ein AVD-Enterprise-SetupEin AVD-Enterprise-Setup

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.

Die AVS-Architektur, Quelle: Microsoft®
Die AVS-Architektur, Quelle: Microsoft®

Ü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:

AVD-Control-Plane mit AD, Quelle Microsoft®
AVD-Control-Plane mit AD, Quelle Microsoft®

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:

AVD-Control-Plane mit AAD DS, Quelle Microsoft®
AVD-Control-Plane mit AAD DS, Quelle Microsoft®

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:

Ein AVD-Enterprise-Setup
Ein AVD-Enterprise-Setup, Quelle 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“:

Die Startseite einer AVD-Bereitstellung im Azure-Portal
Die Startseite einer AVD-Bereitstellung im Azure-Portal.

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.

Das Erstellen eines Hostpools. Entscheidend ist der "Hostpooltyp".
Das Erstellen eines Hostpools. Entscheidend ist der „Hostpooltyp“.

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.

Das gewählte bestimmte entscheidend die spätere User-Experience.
Das gewählte bestimmte entscheidend die spätere User-Experience.

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.

Der Domänen-Beitritt für den Hostpool beeinflusst maßgeblich, wo dein User-Management stattfinden kann.
Der Domänen-Beitritt für den Hostpool beeinflusst maßgeblich, wo dein User-Management stattfinden kann.

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.

Die VMs eines Hostpools im AVD-Portal
Die VMs eines Hostpools im AVD-Portal.

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.
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.

Das Zuweisen von Benutzern zu Anwendungen.
Das Zuweisen von Benutzern zu Anwendungen.

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 ……

Das Anmelden am Webaccess mit einem AzureAD-Account.
Das Anmelden am Webaccess mit einem AzureAD-Account.

…. 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.

Ein Teil der benötigten IAM-Berechtigungen.
Ein Teil der benötigten IAM-Berechtigungen.

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:

Die für den WebAccess benötigte RDP-Eigenschaft.
Die für den WebAccess benötigte RDP-Eigenschaft.

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.

AzureAD-joined VMs benötigen beim RDP-Zugriff die Rolle „Anmeldeinformationen VM-Benutzer“.
AzureAD-joined VMs benötigen beim RDP-Zugriff die Rolle „Anmeldeinformationen VM-Benutzer“.

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:

Das Anmelden am Sitzungs-Host mit AzureAD-Anmeldeinformationen.
Das Anmelden am Sitzungs-Host mit AzureAD-Anmeldeinformationen.

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:

Zwei Sitzungen auf dem gleichen Sitzungshost mit Windows-11.
Zwei Sitzungen auf dem gleichen Sitzungshost mit Windows-11.

Lizenzen und Kosten

Sie haben 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. Sie könnten persönliche Daten in ihrem User-Verzeichnis auf dem Sitzungshost ablegen, wozu Sie aber entsprechende großzügig dimensionierte Datenträger in der VM bräuchten. Insbesondere im Pooled-Modus müssten Sie sich  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 Sie auf der anderen Seite berücksichtigst, dass der Azure-Backbone dem ausgehenden VM-Datenverkehr durchgängig mindestens 100 GBit/s Netzwerkbandbreite bietet, könnten Sie 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ürden Sie 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 Si ihren Azure Session-Host-Server betreiben. Stichwort „Azure Hybrid Use-Benefit und Software Assurance“. Bei Windows-Client (Windows 11) als Sitzungs-Host, fiele zwar das CAL-Thema weg, Sie müssten sich dann 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 brauchen Sie dann entweder einen passenden O365-Lizenz-Plan mit enthaltendem VDA (E3, E5 oder Business Premium) oder Sie müssten die VDAs einzeln erwerben und vorhalten. Bei zugreifenden Linux-Clients gilt das ohnehin.

Außerdem brauchen Sie, je nachdem, ob Sie die O365-Client-Apps auf einem Server- oder Client betreiben am zugreifenden lokalen Windows-Servereine eine (Remote)-zugriffsberechtige Windows-11-Basis-Version („Professional“ beispielsweise), bzw. die entsprechende SCA. Ich bin kein Lizenz-Spezialist, aber Sie sehen, dass hier noch einer Reihe von Überlegungen auf Sie zukommen, welche Sie nahezu alle umgehen können, wenn Sie Windows 365 (Cloud PC) in Erwägung ziehen (nächster Artikel), insbesondere, wenn ohnehin jeder Nutzer einen dedizierten Desktop (ohne Pooling) erhalten soll. 

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.