Azure Virtual Desktop ist technisch schnell aufgesetzt. Ein Host Pool, ein Image, ein paar Session Hosts, und nach zwei Tagen kann sich der erste Nutzer anmelden. Genau deshalb unterschätzen viele Projekte, was danach kommt. Die Probleme entstehen nicht beim Aufbau, sondern im Betrieb: bei 200 gleichzeitigen Anmeldungen um acht Uhr morgens, bei Profilen, die nicht mehr laden, und bei Kosten, die niemand vorhergesagt hat.
AVD-Projekte scheitern selten an der Technik
In der Praxis kippen AVD-Plattformen an vier Stellen: am Profilmanagement, an falsch geschnittenen Host Pools, an Autoscaling-Regeln, die nicht zur tatsächlichen Arbeitszeit passen, und am Image-Lifecycle. Alle vier Punkte sind lösbar, aber sie müssen vor dem Rollout entschieden werden, nicht danach.
Der teuerste Fehler ist, eine AVD-Umgebung wie eine klassische Terminalserver-Farm zu behandeln. Die Konzepte ähneln sich, das Betriebsmodell nicht: Kapazität ist elastisch, Images sind flüchtig, und Profile liegen nicht mehr auf dem Server, auf dem gearbeitet wird.
Host-Pool-Design: Dichte gegen Stabilität
Windows 11 Multi-Session erlaubt hohe Nutzerdichte pro VM. Das ist der wesentliche Kostenhebel gegenüber dedizierten Cloud PCs. Die Frage ist nur: wie viele Nutzer pro Host? Die ehrliche Antwort lautet, dass es keine allgemeingültige Zahl gibt. Ein Sachbearbeiter mit Office und Browser verhält sich völlig anders als ein Entwickler mit Container-Runtime oder ein Konstrukteur mit CAD-Anwendung.
Was sich bewährt hat: Nutzergruppen mit ähnlichem Lastprofil in eigene Host Pools trennen, statt einen großen Pool für alle zu bauen. Das kostet minimal mehr Verwaltung, verhindert aber, dass ein einzelner Ressourcenfresser die Sitzungen von dreißig anderen ausbremst. Bei größeren Umgebungen kommen zusätzlich Pools nach Region oder Standort dazu, damit die Latenz zum Nutzer stimmt.
Der zweite Designfehler ist die Wahl der VM-Familie nach Preis statt nach Profil. Zu wenig RAM pro Nutzer führt zu Paging und macht die Sitzung zäh, obwohl die CPU-Auslastung im Monitoring harmlos aussieht. GPU-Workloads gehören in eigene Pools mit passenden VM-Größen, nicht in den allgemeinen Pool.
FSLogix entscheidet über die Anmeldezeit
Wenn Nutzer sich über eine AVD-Umgebung beschweren, geht es in den meisten Fällen um zwei Dinge: die Anmeldung dauert zu lange, oder Einstellungen sind verschwunden. Beides führt fast immer zum Profilmanagement.
FSLogix legt das Nutzerprofil in einen Container, der beim Logon eingebunden wird. Das funktioniert gut, solange der darunterliegende Speicher schnell genug ist, die Exclusions sauber gesetzt sind und niemand den Container versehentlich vom Virenscanner durchsuchen lässt. Diese drei Punkte stehen bei Beschwerden über langsame Anmeldungen als Erstes auf der Prüfliste.
Dazu kommt die Frage, was überhaupt ins Profil gehört. Ein Container, der über Monate auf 30 GB anwächst, weil Teams-Caches und heruntergeladene Dateien mitwandern, verlängert jeden Logon und jedes Backup. Regelmäßiges Compacting und klare Redirections sind kein Feintuning, sondern Grundbetrieb.
Wer hier Transparenz braucht, kommt an Monitoring nicht vorbei: Wie lange dauert das Anhängen des Containers wirklich? Welche Profile sind beschädigt? Welche Sitzungen laufen ohne Container weiter und verlieren am Ende Daten? Fragen dieser Art waren der Grund, warum aus meiner Betriebspraxis mehrere offene Werkzeuge für die FSLogix-Community entstanden sind.
Autoscaling spart Geld, wenn die Randzeiten stimmen
Der größte Kostenvorteil von AVD entsteht dadurch, dass Kapazität nachts und am Wochenende verschwindet. Dieser Hebel wird oft zu vorsichtig eingestellt: Wer die Hosts erst um 22 Uhr herunterfährt und um 5 Uhr wieder hochfährt, verschenkt einen erheblichen Teil der möglichen Einsparung.
Umgekehrt gilt: Wer zu aggressiv skaliert, produziert Beschwerden. Wenn morgens dreißig Nutzer gleichzeitig anmelden, während gerade erst der zweite Host startet, ist die gewonnene Ersparnis den Ärger nicht wert. Die Lösung liegt in realen Nutzungsdaten (Anmeldezeiten über mehrere Wochen, nach Wochentagen getrennt) statt in Annahmen aus dem Projektworkshop.
Ein Detail, das oft übersehen wird: Drain-Modus und Ablaufsteuerung beim Herunterfahren. Sitzungen dürfen nicht mitten in der Arbeit beendet werden, nur weil eine Skalierungsregel ausgelöst hat. Sauber konfiguriert bekommt der Nutzer davon nichts mit.
Images: der unterschätzte Betriebsaufwand
Ein AVD-Image ist kein einmaliges Artefakt, sondern ein Prozess. Jeden Monat kommen Windows-Updates, Anwendungsaktualisierungen und Sicherheitseinstellungen dazu. Wer das manuell macht, hat nach einem halben Jahr drei Images im Umlauf, von denen niemand mehr weiß, welches wo läuft.
Was funktioniert: ein definierter Bauprozess mit nachvollziehbaren Schritten: Basis-Image, Optimierungen, Anwendungen, Härtung, Sysprep-Vorprüfung, Versionierung. Ob das über Azure Image Builder, ein Skript-Framework oder eine Pipeline läuft, ist zweitrangig. Entscheidend ist, dass der Prozess reproduzierbar ist und dokumentiert, was im Image steckt.
Zur Optimierung gehören Punkte, die einzeln banal wirken und in Summe deutlich spürbar sind: nicht benötigte Dienste und Apps entfernen, Defender-Ausnahmen für FSLogix-Container korrekt setzen, Multimedia-Umleitung und RDP Shortpath vorbereiten, Energieeinstellungen anpassen. Bei einer Plattform mit tausenden Sitzungen entscheidet genau das über die wahrgenommene Geschwindigkeit.
Woran der Erfolg tatsächlich gemessen wird
Für die IT ist eine AVD-Plattform ein Architekturthema. Für die Nutzer ist sie eine einzige Zahl: die Zeit zwischen Klick und arbeitsfähigem Desktop. Wenn die Anmeldung zuverlässig schnell ist, akzeptieren Nutzer fast jede Umstellung. Wenn sie es nicht ist, hilft kein Architekturdiagramm.
Deshalb lohnt es sich, vor dem Rollout festzulegen, welche Werte gemessen werden: Logon-Dauer nach Phasen aufgeschlüsselt, Container-Anbindungszeit, Sitzungsdichte pro Host, Auslastung in Spitzenzeiten. Ohne diese Basis lässt sich später nicht unterscheiden, ob eine Beschwerde ein Einzelfall oder ein strukturelles Problem ist.
Bei einer Plattform dieser Größe zahlt sich ein vorsichtiger Start aus: ein kleiner Pilot mit echten Nutzern und Messwerten, danach schrittweise Ausweitung. Erst alle zu migrieren und danach zu optimieren, kostet deutlich mehr.