Mit AVD können Benutzer von überall und von beliebigen Endgeräten auf ihre Arbeitsumgebung zugreifen, ohne dass Unternehmen eine RDS-Infrastruktur selbst aufbauen müssen. Dennoch ist der Einsatz von AVD nicht trivial, speziell bei der Integration einer On-prem-Umgebung. Bei den Kosten sind kaum Einsparungen zu erwarten.
Microsoft bietet mit Azure Virtual Desktop (AVD) schon seit gut drei Jahren eine voll integrierte VDI-Lösung in der Cloud an. AVD hieß ursprünglich Windows Virtual Desktop (WVD), eine Bezeichnung, die Microsoft nach der Freigabe von Windows 365 offenbar als ungünstig betrachtete.
Remote Desktop in der Cloud
Azure Virtual Desktop versteht sich quasi als Weiterentwicklung von Microsofts Remote Desktop Services (RDS), nur dass AVD komplett aus der Cloud geliefert wird. Sie brauchen bei AVD nicht zwingend On-Premises-Komponenten, können aber bei Bedarf welche andocken. Außerdem nimmt Ihnen AVD im Gegensatz zu RDS einen Großteil des Plattform-Managements ab. Um die Bereitstellung von RD Connection Broker, RD Licensing Server, RD Gateway Server und ggf. RD Web Server sowie um eventuelle Load-Balancer müssen sich Kunden nicht mehr kümmern.
Die Windows Virtual Desktop Control Plane sorgt unter anderem dafür, dass Benutzer stets auf der richtigen Azure-VM landen, sobald sie eine Verbindung initiieren. Bei RDS übernehmen RDS-Server-Rollen wie RD Gateway und der Connection Broker diese Aufgabe.
Das folgende Diagramm zeigt die typische Architektur für Azure Virtual Desktop. In diesem Beispiel erweitert ExpressRoute das lokale Netzwerk in die Azure-Cloud, wobei sich Azure AD Connect um die Integration der Active Directory Domain Services (AD DS) des Kunden mit dem Azure AD kümmert.
Für AVD sind letztlich nur die VMs, welche die Desktops hosten (stets Bestandteil eines Host-Pools), die File-Services auf der rechten Seite als Datenablage und der Windows Virtual Desktop Control Plane relevant. Für den Zugriff auf AVD müssen Sie sich an zwei Stellen authentifizieren: Einmal beim Azure AD und gegen die VM selbst. Das geht am einfachsten durch Synchronisation eines Domain-Kontos mit Azure AD, das für AVD berechtigt ist.
Azure Virtual Desktop hat einen eigenen Eintrag im Azure-Portal, sodass Sie von dort aus sehr komfortabel mit dem Einrichten einer Umgebung starten können, beginnend mit dem Anlegen eines Host-Pools.
Multiuser-Version von Windows 10 / 11
Über die Funktionalität einer DaaS-Lösung hinaus bietet AVD einige Besonderheiten. Eine ist der Windows-10-Multisession-Support. Suchen Sie im Azure-Portal beim Erstellen eine gewöhnlichen VM nach Windows-Images, dann finden Sie dort den Eintrag Windows 10 Pro, version 21H2 – Gen1.
Wählen Sie dieses aus, dann müssen Sie bestätigen, dass Sie über eine „berechtigte Windows 10-Lizenz mit Rechten für mehrinstanzenfähiges Hosting“ verfügen. Das Image ist also offensichtlich für AVD gedacht und lässt sich demzufolge auch bei der Konfiguration Ihres Hostpools auswählen.
Windows 10 Multi-Session ist ein Betriebssystem, das mehrere Benutzer auf nur einer virtuellen Maschine (VM) zusammenfasst. Da hier das gewohnte Look and Feel eines Windows 10 Clients erhalten bleibt, müssen sich die Nutzer nicht umgewöhnen. Dies ist ein Vorteil gegenüber den lokalen RDS, wo sich Benutzer ein Server-OS teilen oder wo jeder User eine eigene Instanz des Client-Betriebssystems erhält.
Management von Benutzerprofilen
Eine weitere Besonderheit von AVD ist der Support für persistente Benutzerprofile, welche unabhängig von der virtuellen Maschine des aktuell verwendeten Desktops sind. Sie sorgen für eine Nutzerfahrung wie bei einem normalen PC.
Die Profile werden in Containern gespeichert, welche getrennt von der Desktop-VM in Azure abgelegt sind. Ermöglicht wird dies durch das in Azure AVD enthaltene FSLogix. Seit 2020 ist FXLoigx in der RDS-Lizenz enthalten und kann mithin auch on-prem eingesetzt werden. In AVD müssen Sie für den FSLogix-Support beim Typ des Hostpools „In Pool“ (früher „Pooled“) auswählen.
Hierbei bezieht sich „Pooled“ auf eine Sammlung von VMs, aus welcher der Lastenausgleichsalgorithmus des Brokers („breitenorientiert“ oder „tiefenorientiert“) dem Benutzer beim Anmelden einen virtuellen PC für die jeweilige Sitzung zuweist.
Dabei erhält jeder Benutzer theoretisch bei jeder Anmeldung eine andere VM. Deshalb ist hier der FXLogix-Support interessant, weil er die Benutzerprofile in jede Session einblendet. Zudem könnte man auf diesem Weg auch etwaige File-Server- bzw. Azure-Dateifreigaben einbinden. „Persönlich“ bedeutet hingegen, dass jeder Benutzer immer auf der gleichen VM landet, und zwar alleine.