Azure Virtual Desktop ist kein Projekt. Es ist Betrieb. 

Eine Azure-Virtual-Desktop-Umgebung (AVD) kann technisch erfolgreich eingeführt sein und dennoch im Alltag an Qualität verlieren. Nutzungszeiten ändern sich, Profile wachsen, Anwendungen und Betriebssysteme benötigen Updates, Sicherheitsvorgaben werden angepasst und Warnungen müssen bewertet werden. Der Go-live markiert deshalb nicht das Ende des Projekts, sondern den Übergang in einen dauerhaft zu organisierenden Betrieb. 

Microsoft stellt mit Azure Virtual Desktop die Plattform und zentrale Verwaltungsfunktionen bereit. Die Session Hosts sowie deren Betriebssystem, Anwendungen, Images und die angebundenen Identitäts-, Speicher- und Netzwerkkomponenten bleiben jedoch Teil der jeweiligen Kundenumgebung. Welche Aufgaben basecloud übernimmt, legen wir deshalb nicht pauschal, sondern über einen klar definierten Betriebsscope fest. 

Der Go-live verschiebt die Aufgabe vom Projekt in den Betrieb 

Azure Virtual Desktop verwendet für Verbindungen das sogenannte Reverse-Connect-Verfahren. Der Session Host baut dabei die ausgehende Verbindung zur AVD-Infrastruktur auf. Ein eingehender TCP-Port für den Verbindungsaufbau ist nicht erforderlich. Microsoft betreibt die hierfür benötigten Plattformendpunkte, während Erreichbarkeit, DNS, Identitäten und Zugriffe auf kundeneigene Anwendungen oder Daten weiterhin passend zur Zielarchitektur eingerichtet und überwacht werden müssen. [1] 

Diese Aufgabenteilung hat praktische Folgen: Ein erfolgreicher Pilot belegt, dass die gewählte Architektur grundsätzlich funktioniert. Er belegt noch nicht, dass Kapazitätssteuerung, Monitoring, Updates, Benutzerprofile und Reaktionswege für Monate und Jahre geregelt sind. Belastbarer Betrieb entsteht erst durch wiederholbare Abläufe, messbare Zustände und eindeutig benannte Verantwortlichkeiten. 

Was im laufenden AVD-Betrieb zusammenwirkt 

• Host Pools und Session Hosts: Registrierung, Verfügbarkeit, Agent-Zustand, Kapazität und Drain Mode müssen beobachtet werden. Im Drain Mode nimmt ein Session Host keine neuen Sitzungen an; bestehende Sitzungen bleiben bestehen, bis Nutzer sich abmelden oder sie administrativ beendet werden. [2] 

• Autoscale: Scaling Plans verbinden Zeitpläne, Mindestkapazitäten, Auslastungsschwellen und Abmeldeverhalten. Diese Parameter müssen zum tatsächlichen Nutzungsverlauf passen. [3] 

• FSLogix und Profilspeicher: Profilcontainer werden als VHD- oder VHDX-Datei über eine SMB-Freigabe eingebunden. Kapazität, Performance, Berechtigungen und Erreichbarkeit des Speichers wirken sich damit direkt auf Anmeldung und Benutzererlebnis aus. [4] 

• Images und Anwendungen: Änderungen am Basisimage müssen getestet, versioniert und kontrolliert auf Session Hosts ausgerollt werden. Der konkrete Prozess hängt vom verwendeten Bereitstellungs- und Verwaltungsmodell ab. [5] 

• Monitoring und Diagnose: AVD Insights bündelt Telemetrie in Azure Monitor Workbooks, benötigt aber zuvor konfigurierte Diagnosedaten, einen Log-Analytics-Arbeitsbereich, Data Collection Rules und den Azure Monitor Agent auf den Session Hosts. [6] 

• Identität und Zugriff: Conditional Access kann unter anderem Mehr-Faktor-Authentifizierung oder Anforderungen an den Gerätezustand durchsetzen. Richtlinien müssen zur verwendeten AVD-App, zum Client und zum gewünschten Kontrollzeitpunkt passen. [7] 

Diese Bereiche sind voneinander abhängig. Eine gesunde VM allein genügt beispielsweise nicht, wenn das Benutzerprofil nicht eingebunden werden kann oder die erforderlichen Backend-Dienste nicht erreichbar sind. 

Autoscale muss reale Nutzung abbilden 

AVD Autoscale kann Session Hosts anhand definierter Zeitpläne und Kapazitätsschwellen starten, in den Drain Mode versetzen und – abhängig von der Konfiguration – herunterfahren beziehungsweise deallokieren. Scaling Plans unterscheiden Ramp-up-, Peak-, Ramp-down- und Off-Peak-Phasen. Zusätzlich werden unter anderem Mindestanteile aktiver Hosts, Kapazitätsschwellen und das Verhalten gegenüber noch angemeldeten Nutzern festgelegt. [3] 

Damit ist Autoscale keine einmalige „Kosteneinstellung“. Zu knapp gesetzte Grenzen können die verfügbare Kapazität beeinträchtigen; zu großzügige Grenzen lassen mehr Ressourcen laufen als nötig. Änderungen bei Arbeitszeiten, Nutzergruppen oder Anwendungen sollten deshalb anhand von Sitzungs-, Leistungs- und Kapazitätsdaten überprüft werden. Für Wartungsszenarien sind zudem dokumentierte Ausnahmen wichtig: Microsoft weist darauf hin, dass Autoscale den Drain Mode eines Hosts überschreiben kann, sofern der Host nicht über das dafür vorgesehene Ausschluss-Tag vom Scaling Plan ausgenommen wird. [3] 

FSLogix liegt häufig im kritischen Anmeldepfad 

Microsoft empfiehlt FSLogix-Profilcontainer für AVD. Bei der Anmeldung wird der Profilcontainer als virtuelle Festplatte an die Sitzung angefügt; Anwendungen sehen dadurch ein lokales Benutzerprofil, obwohl die Profildaten zentral auf einer SMB-Freigabe liegen. Azure Files ist laut Microsoft für die meisten Kunden eine geeignete Speicheroption. [4] 

Dieser Mechanismus macht den Profilspeicher zu einem wesentlichen Teil des Anmeldepfads. Betriebsrelevant sind daher nicht nur freie Speicherkapazität, sondern auch Performance, Berechtigungen, Authentifizierung, Namensauflösung und Erreichbarkeit. Bei Störungen sollte die Diagnose Host, FSLogix-Protokolle und Speicher gemeinsam betrachten. Sonst wird ein Infrastrukturproblem leicht fälschlich als einzelnes Desktop- oder Benutzerproblem eingeordnet. 

Monitoring wirkt erst mit Datenerfassung und Reaktion 

Azure Virtual Desktop Insights ist ein auf Azure Monitor Workbooks basierendes Dashboard. Die Ansicht allein erzeugt jedoch noch keinen vollständigen Überwachungsprozess. Für die Datenerfassung müssen unter anderem Diagnoseeinstellungen, Log Analytics, Data Collection Rules und der Azure Monitor Agent konfiguriert sein; benötigte Leistungsindikatoren und Ereignisprotokolle sind gezielt auszuwählen. [6] 

Im Betrieb muss außerdem feststehen, welche Abweichungen relevant sind, wer sie bewertet und wann eskaliert wird. Dazu gehören beispielsweise nicht verfügbare Session Hosts, Registrierungsfehler, auffällige Anmeldezeiten, hohe Auslastung oder Fehler beim Laden von Profilen. Ein Dashboard liefert Transparenz – Verlässlichkeit entsteht erst durch Prioritäten, Empfänger, Reaktionszeiten und dokumentierte Maßnahmen. 

Sicherer Zugriff: Reverse Connect und Conditional Access lösen unterschiedliche Aufgaben 

Reverse Connect reduziert die Notwendigkeit, Session Hosts für eingehende AVD-Verbindungen aus dem Internet erreichbar zu machen. Die Hosts benötigen stattdessen ausgehende HTTPS-Verbindungen zu den von Microsoft dokumentierten Endpunkten. Das ersetzt jedoch nicht die interne Netzplanung: Für Domänendienste, DNS, Anwendungen, Datenbanken oder Ressourcen im eigenen Rechenzentrum können weiterhin private Netzwerkverbindungen und passende Firewallregeln erforderlich sein. [1] 

Conditional Access steuert dagegen die Bedingungen einer Anmeldung beziehungsweise eines Zugriffs. Je nach Richtlinie lassen sich etwa Mehr-Faktor-Authentifizierung oder ein konformes Gerät verlangen. Die Regeln sollten mit Pilotgruppen getestet werden, weil Zielressourcen, Clienttyp und Zeitpunkt der Prüfung beeinflussen, wie Nutzer den Zugriff erleben. [7] Reverse Connect und Conditional Access ergänzen sich somit, sind aber keine austauschbaren Sicherheitsmechanismen. 

Images und Session Hosts brauchen einen kontrollierten Lebenszyklus 

Wer Updates dauerhaft direkt auf einzelnen Session Hosts installiert, riskiert unterschiedliche Systemstände. Ein kontrollierter Image-Prozess hält Betriebssystem, Anwendungen und Sicherheitskomponenten in einer versionierten Ausgangsbasis zusammen. Änderungen sollten zunächst in einer Testumgebung validiert und anschließend in planbaren Batches ausgerollt werden. 

Microsoft bietet für Host Pools mit einer Session-Host-Konfiguration die Funktion „Session host update“. Dabei werden bestehende virtuelle Maschinen deallokiert und gelöscht und anschließend anhand der aktualisierten Konfiguration neu erstellt. Microsoft empfiehlt einen Test-Host-Pool und weist ausdrücklich darauf hin, Autoscale während des Updates zu deaktivieren. Außerdem wird der Azure Monitor Agent auf aktualisierten Hosts nicht automatisch installiert, sofern dies nicht beispielsweise über Azure Policy sichergestellt wird. [5] 

Diese Funktion ist nicht mit jedem historischen oder individuell aufgebauten Host Pool gleichzusetzen. Vor dem Einsatz sind deshalb Voraussetzungen, Ausschlusskriterien, Wartungsfenster, Drain Mode, Benutzerkommunikation, Erfolgskontrolle und Rückfalloptionen für die konkrete Umgebung festzulegen. 

Was eine belastbare Übergabe ausmacht 

• Betriebsscope: Für Host Pools, Session Hosts, Profile, Images, Identität, Security, Monitoring und Netzwerk ist dokumentiert, welche Leistungen enthalten sind. 

• Monitoring: Datenquellen und Warnungen sind eingerichtet; Prioritäten, Empfänger und Reaktionswege sind festgelegt. 

• Update-Zyklus: Tests, Freigaben, Wartungsfenster, Batch-Größen und Rückfalloptionen sind vor dem nächsten Update geklärt. 

• Kapazitätssteuerung: Scaling Plans werden anhand realer Nutzungsdaten überprüft; Ausnahmen für Wartung sind dokumentiert. 

• Eskalation: Kritische Vorfälle haben vereinbarte Reaktionszeiten, Vertretungen und Kommunikationswege. 

• Verantwortung: Benannte Ansprechpartner kennen die Umgebung und können Entscheidungen koordinieren. 

So betreiben wir Azure Virtual Desktop nach dem Go-live 

Wir verstehen Azure Virtual Desktop nicht als einmalige Bereitstellung, sondern als dauerhaft zu betreibende Plattform. Gemeinsam mit unseren Kunden legen wir fest, welche Komponenten und Aufgaben zum vereinbarten Scope gehören: zum Beispiel Host-Pool- und Session-Host-Lifecycle, Autoscale, Monitoring, FSLogix, Image- und Update-Prozesse sowie definierte Schnittstellen zu Identität, Security, Netzwerk und Fachanwendungen. 

Für die eingeschlossenen Leistungen vereinbaren wir Zuständigkeiten, Wartungs- und Reaktionsprozesse sowie nachvollziehbare Eskalationswege. Warnungen und Veränderungen werden nicht isoliert betrachtet, sondern im Zusammenhang der gesamten Anmelde- und Sitzungskette bewertet. Dadurch bleibt sichtbar, welche Aufgabe bei Microsoft, bei basecloud oder bei weiteren Verantwortlichen in der Kundenumgebung liegt. 

Wie weit unser Managed Service reicht, hängt von Architektur, Schutzbedarf und Betriebsvereinbarung der jeweiligen Umgebung ab. Genau diese Abgrenzung ist Teil eines professionellen Betriebs: Sie verhindert blinde Flecken und macht aus technischer Funktionsfähigkeit eine verlässlich betreute Arbeitsumgebung. 

Fazit: Azure Virtual Desktop bleibt nur durch geregelten Betrieb verlässlich 

Azure Virtual Desktop nimmt Unternehmen viele Aufgaben einer klassischen Desktop-Infrastruktur ab, beseitigt aber nicht den Bedarf an Betrieb. Host-Kapazität, Profile, Telemetrie, Zugriffsrichtlinien, Images und Abhängigkeiten verändern sich fortlaufend. Wer diese Bereiche mit klaren Rollen, getesteten Abläufen und messbaren Zuständen verbindet, schafft die Grundlage für stabile Benutzererlebnisse und kontrollierbare Änderungen. 

Die entscheidende Frage nach dem Go-live lautet daher nicht nur, ob AVD funktioniert. Sie lautet: Wer erkennt eine Abweichung, wer entscheidet über die Maßnahme und wie wird ihre Wirksamkeit nachgewiesen? 

Microsoft-Quellen 

[1] Microsoft Learn: Network connectivity for Azure Virtual Desktop, aktualisiert am 7. Mai 2026 

[2] Microsoft Learn: Set drain mode on session hosts, abgerufen am 29. Juli 2026 

[3] Microsoft Learn: Create and assign an autoscale scaling plan for Azure Virtual Desktop, abgerufen am 29. Juli 2026 

[4] Microsoft Learn: Store FSLogix profile containers on Azure Files, aktualisiert am 26. Mai 2026 

[5] Microsoft Learn: Update session hosts in Azure Virtual Desktop, aktualisiert am 2. Juli 2026 

[6] Microsoft Learn: Use Insights to monitor Azure Virtual Desktop, abgerufen am 29. Juli 2026 

[7] Microsoft Learn: Set up multifactor authentication for Azure Virtual Desktop, abgerufen am 29. Juli 2026