Der Frage nach der Zukunft lokaler Active-Directory-Infrastrukturen hat Microsoft zumindest mittelfristig etwas von ihrer Brisanz genommen. Denn Windows Server 2025 hat das Active Directory (AD) noch an Bord und bringt für den lokalen Verzeichnisdienstbetrieb sogar neue Funktionen mit. Die können aber nicht darüber hinwegtäuschen, dass die Musik längst woanders spielt. So entwickelt Microsoft sein Portfolio rund um die Azure-Cloud und deren Verzeichnisdienst Entra ID deutlich rasanter weiter und versucht zunehmend, IT-Verantwortlichen die Migration in die Cloud schmackhaft zu machen.

Der klassische Weg in die Cloud führte für viele Unternehmen bislang über hybride Szenarien, in denen ein lokales AD weiterhin die führende Instanz für Identitäten war und mitsamt Entra ID Connect das Fundament bildete. Doch eine solche hybride Bereitstellung ist komplex und hat ihren Preis durch Kosten für Betrieb und Hochverfügbarkeit der Domänencontroller (DC), technische Erblasten durch Legacy-Abhängigkeiten, Remotezugriff via VPN als Engpass und Sicherheitsrisiken durch veraltete Authentifizierungsmechanismen. Microsoft skizziert entsprechend unter der Überschrift der "Active Directory Minimization" [1] Ansätze, die Abhängigkeit von einem lokalen AD zu reduzieren oder sich ganz davon zu verabschieden.

Eine solche Abhängigkeit brachte bislang auch der Betrieb einer Virtual Desktop Infrastructure (VDI) in Microsoft Azure Virtual Desktop (AVD) mit sich. AVD stellt komplette Desktops sowie einzelne RemoteApps als Desktop-as-a-Service (DaaS) aus der Azure-Cloud bereit. Damit nimmt Microsoft Ihnen die Aufgabe ab, die nötigen Infrastrukturdienste in Eigenregie zu betreiben. Sämtliche aus einer lokalen Installation der Remotedesktopdienste bekannten Rollen, wie Gateway, Web-Access, Broker und Loadbalancer, wandern in die Cloud, wo Microsoft sie verwaltet. Sie können sich folglich auf Ihr Kerngeschäft konzentrieren, nämlich Bau und Pflege der Desktop- und Server-Images, die die in Ihrem Unternehmen benötigten individuellen Applikationen enthalten – sofern Sie über eine passende Lizenz verfügen.

Remote-Desktop-Services-Client-Access-Lizenzen (RDS-CAL) mit aktiver Software Assurance (SA) berechtigen zum Betrieb von Remote-Desktop-Session-Hosts auf Basis von Windows Server 2019 aufwärts in der Cloud. Virtuelle Desktops auf Basis der Client-Betriebssysteme Windows 10 und 11 erfordern Lizenzen der Typen Windows E3, E5, A3, A5 oder Microsoft 365 E3, E5, A3, A5, F3, Business Premium [2]. Hinzu addieren sich die Betriebskosten, der Azure-Compute- und -Storage-Ressourcen, die Ihre AVD-Hostpools verwenden. Die VMs werden aber wie Linux- VMs abgerechnet und es entstehen keine weiteren Lizenzkosten für die Windows-Betriebssysteme der VMs.

Ähnlich einer lokalen VDI fasst in AVD ein Hostpool gleichartige Desktop-VMs zusammen. Als weitere logische Einheiten zur Verwaltung nutzt AVD Anwendungsgruppen und Arbeitsbereiche. Erstere beinhalten die zu veröffentlichenden Applikationen und Desktops. Auf Basis dieser Anwendungsgruppen vergeben Sie Berechtigungen zum Zugriff auf die freigegebenen Ressourcen an Endanwender. Die Arbeitsbereiche dienen der logischen Gruppierung der Ressourcen im Web-frontend und in der Windows-App. Jede Anwendungsgruppe muss genau einem Arbeitsbereich zugeordnet sein. Ein Arbeitsbereich nimmt mehrere Anwendungsgruppen auf und dies auch Hostpool-übergreifend, aber mit der Beschränkung, dass alle Hostpools in derselben geografischen Azure-Region angesiedelt sein müssen.

Haben Sie bereits On-Premises-Erfahrungen mit dem VDI-Betrieb gesammelt, ergänzt um Erweiterungen wie etwa Citrix Virtual Apps and Desktops oder Omnissa Horizon, finden Sie sich auch in AVD schnell zurecht. Sie werden jedoch auch ebenso schnell den Komfort der etablierten Lösungen vermissen. So erfordert das Image-Management in AVD noch viel manuelle Arbeit und die Verwaltung von Desktops, Anwendungen und darauf berechtigten Benutzern im großen Maßstab gestaltet sich alles andere als intuitiv. Hier hat Microsoft noch Freiraum für Drittanbieter gelassen, das Ganze mit zusätzlichen Tools zu vereinfachen. Gleich zwei teils kostenlose Werkzeuge, inzwischen unter der Haube des Softwareherstellers Login VSI, stammen vom Microsoft Azure MVP Marcel Meurer [3].

Als praktische Hilfe erweist sich WVD-Admin. Mit dieser kostenfrei verfügbaren nativen Windows-Anwendung erzeugen, ändern und löschen Sie Hostpools, Anwendungsgruppen, Anwendungen und Desktops. Weiterhin verwalten Sie die Zugriffsrechte für Benutzer, senden Nachrichten an laufende Benutzersitzungen, melden diese ab oder spiegeln sie zwecks Remoteunterstützung. Ebenso können Sie die zugehörigen virtuellen Maschinen herunterfahren sowie mitsamt Festplatten und Netzwerkkarten löschen, um belegte Ressourcen in Azure zu sparen. All dies erledigt WVDAdmin per GUI und kommuniziert dazu direkt über API-Aufrufe mit der Azure-Cloud, ohne die PowerShell zu bemühen. Noch mehr Funktionen bietet die cloudnative Anwendung "Hydra for AVD", die Sie direkt aus dem Azure-Marketplace in Ihren Azure-Tenant ausrollen können. Für die Vorbereitungen zu unserem Artikel stellte uns Marcel Meurer dankenswerterweise eine Testumgebung zur Verfügung, in der Hydra bereits eingerichtet war.

Hydra ist in der Community-Edition sogar bei kommerzieller Verwendung für bis zu fünf Hosts innerhalb eines einzigen Azure-Tenants kostenfrei zu haben. Möchten Sie mehr Hosts oder unterschiedliche Azure-Tenants damit verwalten, müssen Sie mit 5 US-Dollar pro gleichzeitigen Benutzer (Concurrent User; CCU) und Monat kalkulieren. Je nach Ausstattung der VMs spart diese Variante den Geldbetrag aber schnell wieder ein, wenn sie verhindert, dass ungenutzte Maschinen rund um die Uhr laufen oder teuren Storage belegen. Für unser Vorhaben relevant ist, dass Hydra auf einfache Weise auch die Konfiguration von FSLogix erledigt – darauf werden wir gleich zurückkommen.

Anfangs wollten Desktop-VMs in AVD für den vollen Funktionsumfang bereits beim Erstellen eines Hostpools einer Domäne beitreten. Sie benötigten dazu ein virtuelles Netz, das den Zugriff auf mindestens einen herkömmlichen DC oder aber die "Microsoft Entra Domain Services" (ehemals Azure Active Directory Domain Services) erlaubte. In beiden Fällen musste sich die klassische Windows-Domäne per Entra ID Connect mit der Cloud synchronisieren.

Bereits im Jahr 2021 hatte Microsoft die Möglichkeit nachgereicht, VMs eines Hostpools direkt mit Entra ID zu koppeln. Eine solche Bereitstellung brachte allerdings zunächst noch einige technische Beschränkungen mit sich. So ist ein kritischer Punkt bei zustandslosen (non-persistent) Desktops das Benutzerprofil. Hier bringt sich Microsofts eigenes Profilmanagement FSLogix in Stellung, das Benutzerprofile in virtuelle Festplatten-Images (VHDX) auslagert. FSLogix erstellt pro Benutzer ein solches Image in einer Dateifreigabe und hängt dieses zur Laufzeit ein. Somit entfällt die Notwendigkeit, Daten bei der Anmeldung aus dem Netzwerk ins lokale Dateisystem der jeweiligen Maschine zu kopieren und bei Abmeldung wieder zurückzuschreiben. Die Software dient somit als Ersatz sowohl für die herkömmlichen servergespeicherten Profile als auch für die Ordnerumleitung der Gruppenrichtlinien. Den Details von FSLogix hatten wir bereits einen früheren Artikel gewidmet [4].

Anfänglich konnten Sie in einer reinen Cloudumgebung ausschließlich lokale Benutzerprofile, nicht aber FSLogix verwenden. Marcel Meurer beschreibt in seinem Blog einen Workaround, mit dem Sie auch ohne lokales AD für Cloud-only-Identitäten FSLogix-Profile in einer per Azure Files bereitgestellten Dateifreigabe nutzen [5].

Diesen Workaround benötigen Sie inzwischen aber nur noch, falls Sie Ressourcen per AVD auch für externe Cloudidentitäten bereitstellen möchten. Für Benutzerkonten unter Ihrer Hoheit ist dies nicht mehr erforderlich, denn Ende letzten Jahres hat Microsoft bekanntgegeben, dass die Kerberos-Authentifizierung von SMB-Zugriffen auf Dateifreigaben in Azure Files nun auch mit reinen Cloudidentitäten funktioniert und dies ganz ohne herkömmlichen DC [6].

Bis zum Redaktionsschluss befand sich die Funktion zwar noch im Status einer "Public Preview", sie funktionierte im Rahmen unserer Tests für diesen Artikel aber bereits tadellos. In diesem Fall stellt Microsoft Entra ID die benötigten Kerberos-Tickets aus. Zu beachten ist dabei allerdings, dass pro Speicherkonto nur genau eine Identitätsquelle aktiv sein darf. Doch wenden wir uns zunächst den grundlegenden Schritten für einen Einstieg in AVD zu.

Haben Sie AVD bislang noch gar nicht genutzt, navigieren Sie zunächst im Azure-Portal zum Bereich "Kostenverwaltung + Abrechnung / Kostenverwaltung / Azure-Abonnements" und wählen dort Ihr Abonnement aus. In dessen Eigenschaften begeben Sie sich dann zum Unterpunkt "Ressourcenanbieter", suchen den Anbieter "Microsoft.DesktopVirtualization" und registrieren diesen [7]. Je nach Wunsch nutzen Sie eine bereits bestehende Ressourcengruppe oder legen eine neue nur für AVD an. Letzteres vereinfacht später das Zuweisen von Berechtigungen. Wir hatten daher für unser Vorhaben eine dedizierte Ressourcengruppe mit einem neuen virtuellen Netzwerk darin und weiterhin zwei Testbenutzer in Entra ID erstellt.

Weiter geht es dann im Portal unter "Alle Dienste", wo Sie den Dienst "Azure Virtual Desktop" finden. Der versammelt sämtliche Funktionen zur Konfiguration der Desktops unter einer Haube und positioniert die Aktion "Hostpool erstellen" prominent an oberster Stelle. Für den produktiven Einsatz empfiehlt es sich natürlich, zunächst ein auf Ihren Bedarf angepasstes individuelles VM-Image zu erzeugen. Doch zum Kennenlernen tut es auch eins der im Azure-Katalog vorhandenen Images. Beginnen Sie also mit der Konfiguration eines Hostpools.

Auf der ersten Registerkarte wählen Sie die gewünschte Ressourcengruppe und geben dem Pool einen Namen. Weiterhin stoßen Sie hier auf das Drop-down-Feld "Standort". Es handelt sich dabei nicht um den Standort, an dem die VMs des Hostpools laufen werden, sondern nur um die geografische Region, in der die Metadaten des Pools lagern. Davon unabhängig können Sie im zweiten Dialogschritt des Assistenten den VM-Standort separat bestimmen. Entscheiden Sie weiterhin, ob Sie einen kompletten Desktop oder einzelne Anwendungen veröffentlichen.

Im Drop-down-Feld des Typs bestimmen Sie die Zuordnung von Benutzern zu Hosts: "Persönlich" weist Benutzer einem Host statisch zu, "In Pool" bezeichnet eine dynamische Zuordnung, bei der ein Anwender zufällig auf einer der freien Maschinen landet. In diesem Fall ist der Lastenausgleich-Algorithmus relevant. Der Standardwert "Breitenorientierter Lastausgleich" verteilt reihum die Benutzer über alle verfügbaren Hosts. Das sorgt für eine optimale Lastverteilung sowie den geringsten Schaden, sollte ein Host ausfallen. Ein "Tiefenorientierter Lastausgleich" füllt dagegen erst einen Host bis zum konfigurierten maximalen Session-Limit, bevor es der nächsten VM Benutzer zuweist. Dies hilft bei einer möglichst sparsamen Ressourcennutzung, da nur so viele Hosts laufen müssen, wie tatsächlich aktuell benötigt werden.

Auf der nächsten Seite wählen Sie den Standort und die Größe der Desktop-VMs. Bestimmen Sie die Anzahl der VMs und ein Präfix für die Namen ihrer Maschinenkonten. Als VM-Typ wählen Sie standardmäßig die "Azure-VM", es sei denn, Sie verfügen über eine per Azure Arc verwaltete lokale Infrastruktur in Ihrem eigenen Rechenzentrum. Für erste Gehversuche verzichten Sie auf Verfügbarkeitsoptionen und wählen Sie eines der von Microsoft vorgefertigten Images, etwa mit "Windows 11 Enterprise multi-session, Version 25H2 + Microsoft 365 Apps" die mehrbenutzerfähige Variante von Windows.

Diese Variante stellt Microsoft abseits von Azure und Azure Local weder zur Installation on-premises noch für andere Cloudprovider zur Verfügung. Die Vorteile des Multi-Session-Betriebs liegen auf der Hand: So bringen Sie mehrere Benutzer auf einer VM unter und sparen damit Ressourcen. Gleichzeitig müssen Sie sich nicht den Kopf über Unterschiede zwischen Client- und Server-Betriebssystemen zerbrechen. Für Endanwender sieht die Arbeitsumgebung immer identisch aus – ganz gleich, ob sie in einer Single- oder Multi-Session-Umgebung arbeiten. Alle Multi-Session-Images haben zudem den Client für FSLogix bereits ab Werk an Bord.

Im Abschnitt "Domäne für Beitritt" wechseln Sie nun vom Active Directory auf Microsoft Entra ID und haben daraufhin die Wahl, ob sich Ihre VMs zusätzlich auch in Intune registrieren sollen – was passende Lizenzen und eine entsprechende Konfiguration in Intune erfordert. Wir verzichten an dieser Stelle darauf. Legen Sie nun noch ein lokales Administratorkonto mit einem ausreichend langen und komplexen Passwort fest. Daraufhin fragt der Assistent, ob Sie eine Desktop-App-Gruppe registrieren möchten und in welchem Arbeitsbereich diese verortet sein soll. Wählen Sie hier einen Namen für einen neuen Arbeitsbereich und erstellen Sie den Hostpool.

Anschließend konfigurieren Sie dessen Einstellungen über das Azure-Portal. Rufen Sie den Verwaltungsbereich für "Azure Virtual Desktop" auf und dort unter "Verwalten / Hostpools" Ihren neu erstellten Pool. Sobald die Desktop-VMs betriebsbereit sind, erscheinen sie auf der Kachel "Kann eine Verbindung herstellen". Ein Klick auf diese Kachel führt zu einer tabellarischen Übersicht über die Maschinen. Dass die VMs hier nur mit ihrem relativen Namen ohne Domäne erscheinen, zeigt, dass es sich um ausschließlich in Entra ID verwaltete Maschinen handelt. In hybriden Szenarien würden VMs hier mit ihrem vollqualifizierten Domänennamen erscheinen.

Zurück in der Übersicht über den Hostpool wählen Sie nun aus dem Menü zur Linken den Punkt "Einstellungen / RDP-Eigenschaften", mit dem Sie im Detail Sitzungsverhalten, Geräteumleitung und Anzeigeeinstellungen konfigurieren. Wechseln Sie dort auf der Registerkarte "Verbindungsinformationen" im Drop-down-Feld "Einmaliges Anmelden in Microsoft Entra" von der Einstellung "Nicht konfiguriert" auf "Verbindungen verwenden Microsoft Entra-Authentifizierung, um einmaliges Anmelden zu ermöglichen" (Bild 1). Weiterhin fügen Sie auf der Registerkarte "Erweitert" im Textfeld der "RDP-Eigenschaften" noch den Wert "targetisaadjoined:i:1;" hinzu und speichern die Änderungen.

Navigieren Sie nun zurück zur Übersicht von "Azure Virtual Desktop" und dort in den Bereich "Verwalten / Anwendungsgruppen". Eine solche hatte der Assistent bereits beim Erstellen des Hostpools zusammen mit dem Arbeitsbereich automatisch angelegt. Rufen Sie die Eigenschaften der Anwendungsgruppe auf und wählen Sie "Verwalten / Zuweisungen". Fügen Sie hier die Benutzerkonten hinzu, welche die virtuellen Desktops nutzen sollen. Zu guter Letzt fehlt diesen Benutzern noch die grundlegende Berechtigung, sich überhaupt aus der Ferne an einer VM anzumelden. Vergeben Sie diese Berechtigung auf der Ebene der Ressourcengruppe, dürfen die Benutzer automatisch sämtliche existierenden und auch zukünftigen Desktop-VMs verwenden.

Dazu navigieren Sie zu den Eigenschaften Ihrer Ressourcengruppe und dort in den Bereich der "Zugriffssteuerung (IAM)". Rechts auf der Seite rufen Sie die Registerkarte "Rollenzuweisungen" auf und fügen eine solche hinzu. Nach welcher Auftragsfunktionsrolle Sie auf der folgenden Seite suchen müssen, hängt davon ab, ob Sie das Portal auf Deutsch oder auf Englisch verwenden. In letzterem Fall heißt die gesuchte Rolle "Virtual Machine User Login". Im Deutschen hat Microsoft dies etwas unglücklich mit "Anmeldeinformationen für VM-Benutzer" übersetzt. Weisen Sie den gewünschten Benutzerkonten diese Rolle zu. Doch Obacht, unabhängig von der Sprache des Portals gibt es noch eine Rolle mit dem Namen "Virtual Machine Local User Login", die nicht zum gewünschten Ergebnis führt.

Damit haben Sie den ersten Schritt gemeistert. Melden Sie einen der zugewiesenen und berechtigten Benutzer in der Windows-App oder im Webclient von AVD an. Auf beiden Wegen finden Sie den Arbeitsbereich und können eine Sitzung auf einer Desktop-VM starten (Bild 2). Die Sitzung läuft zwar noch ohne FSLogix, doch darum kümmern wir uns nun und richten die Kerberos-Authentifizierung an Azure Files für unsere Benutzerkonten ein [8].

Wählen Sie aus dem Hauptmenü des Azure-Portals den Bereich "Speicherkonten" und erstellen Sie dort ein neues Konto in der Ressourcengruppe und der geografischen Region, in der sich auch die Desktop-VMs befinden. Der Speicherkontoname muss über alle Kunden der Azure-Cloud hinweg global eindeutig sein. Legen Sie als bevorzugten Speichertyp "Azure Files" fest.

Für unseren Testaufbau verzichten wir auf Redundanzen und wählen den lokal redundanten Speicher (LRS). Die folgenden Dialogschritte "Erweitert", "Netzwerk", "Datenschutz" und "Verschlüsselung" belassen Sie im Testbetrieb auf Standardeinstellungen. Bei produktiver Nutzung empfiehlt es sich, den Netzwerkzugriff ein- zuschränken, und bei hohen Sicherheitsanforderungen auch, auf kundenseitig verwaltete Schlüssel zu wechseln.

Navigieren Sie zur Übersicht Ihres neuen Speicherkontos und dort zum Menüpunkt "Datenspeicher / Dateifreigaben". Auf der rechten Seite ist hier der identitätsbasierte Zugriff noch nicht konfiguriert. In hybriden Szenarien empfiehlt Microsoft die Steuerung der Zugriffe auf Freigabeebene mittels Azure-RBAC-Rollen. In Verbindung mit Identitäten ausschließlich in Entra ID funktionieren lediglich die Standardberechtigungen auf Freigabeebene [9].

Klicken Sie auf den Link "Nicht konfiguriert" neben dem identitätsbasierten Zugriff und dann auf der Kachel "Microsoft Entra Kerberos" auf "Einrichten". Aktivieren Sie die Option und lassen Sie die Felder für Domaindienste leer. Diese sind nur in hybriden Szenarien relevant.

Im Hauptmenü des Azure-Portals navigieren Sie zu "Microsoft Entra ID" und in dessen Untermenü zum Bereich "Verwalten / App-Registrierungen". Rechter Hand klicken Sie auf die Schaltfläche "Alle Anwendungen im Verzeichnis anzeigen". Auf der folgenden Registerkarte "Alle Anwendungen" rufen Sie dann Ihr Speicherkonto auf, in unserem Beispiel den Anzeigenamen "[Storage Account] itadministratorcloudonly.file.core.win-dows.net". In dessen Untermenü wählen Sie den Punkt "Verwalten / API-Berechtigungen". Im rechten Bereich der Seite finden Sie daraufhin die konfigurierten Berechtigungen, wo Sie die Administratorzustimmung für alle vorhandenen Berechtigungen erteilen.

Nun navigieren Sie im Untermenü weiter zum Eintrag "Verwalten / Manifest". Im JSON-Editor für das Microsoft Graph-App-Manifest auf der rechten Seite suchen Sie das Attribut "tags" und fügen hier die Eigenschaft ""kdc_enable_cloud_group_ sids"" hinzu [10]. Begeben Sie sich zurück zum Menüpunkt "Datenspeicher / Dateifreigaben" Ihres Speicherkontos. Auf der rechten Seite sind die Standardberechtigungen auf Freigabeebene noch deaktiviert. Klicken Sie auf den entsprechenden Link und legen Sie auf der folgenden Seite weiter unten die Berechtigungen fest. Aktivieren Sie hier die "Standardberechtigungen auf Freigabeebene für alle authentifizierten Benutzer und Gruppen". Wählen Sie dabei die Rolle "Mitwirkender für Speicherdateien-SMB-Freigabe" und speichern Sie die Änderung.

Nun erstellen Sie eine neue Dateifreigabe für unsere Testzwecke ohne Backup. Sobald diese bereit ist, wählen Sie dazu aus deren Untermenü den Punkt "Durchsuchen" und fügen dort ein Verzeichnis für die FSLogix-Profile hinzu. Die Option "Zugriff verwalten" im Kontextmenü des Ordners erscheint nur, wenn Sie das Azure-Portal über einen spezifischen Link aufrufen, den Sie in Microsofts Onlinedokumentation finden [11]. Auf diesem Weg konfigurieren Sie die von Microsoft für FSLogix empfohlenen Berechtigungen für das Dateisystem [12].

Zu guter Letzt müssen Sie nur noch die Hosts für das Abrufen von Cloud-Kerberos-Tickets während der Anmeldung konfigurieren und FSLogix aktivieren. Mangels herkömmlichem AD scheidet der klassische Weg mittels Gruppenrichtlinien allerdings aus. Sie können stattdessen ein individuelles Betriebssystem-Image bauen und diesem die passenden Registrierungsschlüssel direkt implantieren. Dies ist allerdings unflexibel und funktioniert nicht mit den vorgefertigten Images von Microsoft.

Als Alternative bleibt die Integration mit Intune oder Hydra. Die grundlegenden Schritte zur Einrichtung von Hydra waren in unserer Testumgebung bereits erledigt. So blieb uns nur noch, mit einer weiteren Rollenzuweisung das Dienst-Prinzipalobjekt von Hydra zum Zugriff auf unsere Ressourcengruppe zu berechtigen [13]. Daraufhin kann Hydra die Hostpools in AVD steuern.

Im Webfrontend von Hydra finden Sie Ihren Hostpool im Bereich "Dashboard / AVD Host Pools". Navigieren Sie in der Detailansicht des Pools auf die Registerkarte "Hosts" und aktivieren Sie dort die "FSLogix Profile Settings". Tragen Sie im Feld "VHD Locations" den Pfad zum Verzeichnis in der Dateifreigabe in Azure Files ein und aktivieren Sie weiter unten die Option "Use Entra ID Kerberos" (Bild 3). Neue Maschinen, die Sie nun dem Hostpool hinzufügen, erhalten diese Einstellungen automatisch. Im Falle der bestehenden Maschinen müssen Sie deren Konfiguration aktualisieren. Wechseln Sie dazu auf die Registerkarte "Script Schedules" und fügen Sie einen Zeitplan zur Ausführung der Skriptsammlung "Re-Apply OS Settings" hinzu.

Hat Hydra die Skriptsammlung ausgeführt, melden Sie erneut einen unserer Testbenutzer auf dem virtuellen Desktop an. Der Benutzer sollte nun automatisch ein FSLogix-Profil erhalten. Ob dies der Fall ist, prüfen Sie, indem Sie innerhalb der Desktopsitzung mit den Anmeldeinformationen des lokalen Administrators die Computerverwaltung öffnen. Im Bereich "Storage / Disk Management" sollten Sie einen separaten Datenträger für das Profil vorfinden und passend dazu in Azure Files auch einen Ordner mit dem Namen und der SID des Benutzers, wie in Bild 4 gezeigt.

Mit der Kerberos-Authentifizierung gegenüber Entra ID ist ein gewichtiger Grund für hybride Infrastrukturen Geschichte. Mit AVD, Azure Files und FSLogix bauen Sie eine VDI ganz ohne herkömmlichen Domaincontroller auf und ermöglichen so auch in einer cloudnativen Welt weiter den Zugriff auf Ihre geschäftskritischen Windows-Applikationen. Ein solche Umgebung verbindet die Vorteile von AVD – Multi-Session-Hosts, flexible Images, fein steuerbare Kosten – mit einem modernen Identitäts- und Berechtigungsmodell. Bei der Administration hilft Hydra for AVD und dies für kleinere Umgebungen sogar ohne weitere Kosten.