Der Weg zum Desktop: vier Tore, ein Fehlerbild

Die Anmeldung gelingt — und trotzdem ist da nichts

Eine Nutzerin meldet sich an. Passwort akzeptiert, zweiter Faktor bestätigt, kein Fehler. Dann steht sie vor einer leeren Liste: kein Desktop, keine Anwendung. Ihre Kollegin in derselben Abteilung sieht beides. Nichts an diesem Bild deutet darauf hin, wo die Kette gerissen ist — und genau das ist das Problem dieses Moduls.

Der Weg von einem Klick bis zum laufenden Desktop führt durch mehrere voneinander unabhängige Tore. Jedes kann für sich scheitern, und mehrere erzeugen dasselbe Symptom: eine leere Liste oder eine Verbindung, die nicht zustande kommt. Wer den Weg nicht als Kette kennt, prüft an der falschen Stelle — meist am Session Host, der noch gar nicht beteiligt war.

Vier Bausteine, die ständig verwechselt werden

Bevor der Pfad Sinn ergibt, müssen vier Begriffe sitzen. Sie klingen nach Hierarchie, sind aber teils orthogonal — und die häufigste Fehlersuche scheitert daran, dass jemand am falschen Objekt nach der Zuweisung sucht.

Session Host — Eine virtuelle Maschine, auf der die Sitzung tatsächlich läuft. Laut Microsoft-Dokumentation sollen alle Session Hosts eines Host Pools aus demselben Abbild stammen, damit das Erlebnis einheitlich bleibt.

Host Pool — Eine Sammlung von Session Hosts. Der Pool trägt die technischen Eigenschaften — Pooltyp, Lastverteilung, Sitzungsgrenze. Nutzer werden nicht an einen Host Pool zugewiesen.

Anwendungsgruppe — Das Objekt, an dem die Zuweisung hängt. Sie steuert, ob Nutzer einen vollständigen Desktop oder einzelne veröffentlichte Anwendungen aus genau einem Host Pool erhalten. Eine Anwendungsgruppe gehört zu genau einem Host Pool.

Workspace — Eine logische Sammlung von Anwendungsgruppen. Jede Anwendungsgruppe muss einem Workspace zugeordnet sein, sonst sehen Nutzer die veröffentlichten Ressourcen nicht — und eine Anwendungsgruppe kann nur zu einem einzigen Workspace gehören.

Der Weg zum Desktop als Kette

Die Microsoft-Dokumentation trennt diesen Weg ausdrücklich in drei Authentifizierungsphasen: die *Cloud service authentication* gegenüber dem Dienst, die *Remote session authentication* gegenüber der Sitzungs-VM und die *In-session authentication* gegenüber Anwendungen innerhalb der Sitzung. Diese Trennung ist keine Doktorarbeit, sondern das schärfste Diagnosewerkzeug des Tracks: Jede Phase hat eigene Fehlermeldungen, eigene Protokolle und eigene Stellschrauben.

Feed leer

Die Anmeldung war erfolgreich. Es fehlt die Zuweisung, der Workspace oder der Typ stimmt nicht — der Session Host war nie beteiligt.

Feed da, Verbindung scheitert

Zuweisung steht. Das Problem liegt am Gateway, am Netzweg oder an einer Richtlinie, die erst beim Verbinden greift.

Verbindung steht, Anmeldung scheitert

Gateway passiert. Jetzt zählt die Identität am Host: Domänenanbindung, Profilzugriff, Anmelderecht.

Desktop oder Anwendung — und was Nutzer davon sehen

Eine Anwendungsgruppe hat genau einen von zwei Typen. Desktop liefert den vollständigen Windows-Desktop und ist mit gepoolten wie persönlichen Host Pools möglich. RemoteApp liefert einzeln veröffentlichte Anwendungen und ist laut Dokumentation nur mit gepoolten Host Pools verfügbar.

• Je Host Pool ist genau eine Desktop-Anwendungsgruppe möglich — mehrere gehen nicht.
• Mehrere RemoteApp-Anwendungsgruppen am selben Host Pool sind erlaubt; ein Nutzer, der mehreren zugewiesen ist, sieht die Vereinigungsmenge ihrer Anwendungen.
• Nutzer können Anwendungsgruppen über mehrere Host Pools hinweg zugewiesen sein — so entstehen unterschiedliche Ressourcenbilder für verschiedene Rollen.

Der bevorzugte Anwendungsgruppentyp: der stille Ausschluss

Hier liegt die Erklärung für die leere Liste aus dem ersten Abschnitt — und sie ist kontraintuitiv genug, dass sie regelmäßig als Fehler gemeldet wird, obwohl sie dokumentiertes Verhalten ist.

Ein gepoolter Host Pool trägt die Einstellung Preferred application group type. Ist einem Nutzer am selben Host Pool sowohl eine Desktop- als auch eine RemoteApp-Anwendungsgruppe zugewiesen, erhält er ausschließlich die Ressourcen des bevorzugten Typs. Die Ressourcen des anderen Typs erscheinen nicht — ohne Fehlermeldung, ohne Hinweis, ohne Protokolleintrag, der wie ein Problem aussieht.

Nur Desktop zugewiesen

Nutzer sieht den Desktop. Die Einstellung spielt keine Rolle.

Nur RemoteApp zugewiesen

Nutzer sieht die Anwendungen. Die Einstellung spielt keine Rolle.

Beides zugewiesen, Einstellung `Desktop`

Nutzer sieht nur den Desktop. Die RemoteApps fehlen stillschweigend.

Beides zugewiesen, Einstellung `RemoteApp`

Nutzer sieht nur die Anwendungen. Der Desktop fehlt stillschweigend.

Beides zugewiesen, keine Einstellung gesetzt

Desktop wird erzwungen. Microsoft rollt diese Erzwingung für Host Pools ohne gesetzten Typ in alle Regionen aus.

Der Ausschluss gilt nur innerhalb eines Host Pools. Liegt die Desktop-Gruppe an hp01 und die RemoteApp-Gruppe an hp02, sieht dieselbe Person beides. Das ist zugleich die Lösung, wenn beide Ressourcenarten wirklich gebraucht werden: zwei Host Pools statt einer Einstellung.

Welcher Client — und welcher ausdrücklich nicht

Nutzer verbinden sich mit Windows App oder dem Remote Desktop client, von Windows, macOS, iOS/iPadOS, Android/Chrome OS oder aus dem Webbrowser. Das ist keine Empfehlung, sondern eine Supportgrenze.

Praktisch heißt das für den Support: Die erste Frage bei „Verbindung geht nicht“ lautet nicht „welcher Fehler“, sondern „womit verbindest du dich“. Ein nicht unterstützter Client erzeugt Fehlerbilder, die zu keiner der drei Authentifizierungsphasen passen.

Wer überhaupt Nutzer sein kann

Der Feed beantwortet nur Anfragen von Konten, die der Dienst kennt. Zwei Sätze aus der Dokumentation entscheiden darüber, und beide werden in Migrationsprojekten regelmäßig zu spät gelesen.

• Das Benutzerkonto muss in dem Microsoft-Entra-Mandanten existieren, der für Azure Virtual Desktop genutzt wird.
• Persönliche Microsoft-Konten werden nicht unterstützt — auch dann nicht, wenn sie als Gast im Mandanten auftauchen.
• Identitäten, die ausschließlich in einem lokalen Active Directory existieren, sind nicht unterstützt. Das schließt eigenständige AD-Installationen mit Active Directory Federation Services ein.

Externe Identitäten sind möglich, aber an Bedingungen geknüpft, die weit über eine Einladung hinausgehen: Die Session Hosts müssen Entra-eingebunden sein, für den Host Pool muss Single Sign-on konfiguriert sein, und das Betriebssystem muss ein aktueller Stand sein — Windows 11 Enterprise ab Version 24H2 mit dem kumulativen Update von September 2025 oder Windows Server 2025 mit dem kumulativen Update von Januar 2026.

Eine zweite Einschränkung trifft die Verwaltung: Intune-Gerätekonfigurationsrichtlinien, die einer externen Identität zugewiesen sind, greifen auf dem Session Host nicht. Sie müssen stattdessen dem Gerät zugewiesen werden. Das verschiebt die Steuerung von der Person auf den Host — und damit auf alle, die auf diesem Host arbeiten.

Conditional Access trifft zwei Anwendungen, nicht eine

Eine Verbindung mit aktiviertem Single Sign-on berührt zwei Microsoft-Entra-Anwendungen an unterschiedlichen Punkten. Wer nur eine davon in seiner Richtlinie erfasst, erzeugt Aufforderungen zur Mehrfaktor-Authentifizierung an Stellen, die niemand erwartet.

9cdead84-a844-4324-93f2-b2e6bb768d07

Azure Virtual Desktop — greift beim Abonnieren der Ressourcen, bei der Authentifizierung am Gateway und beim Senden von Diagnosedaten.

270efc09-cd0d-444b-a71f-39af4910ec45

Windows Cloud Login — greift bei der Anmeldung am Session Host, wenn Single Sign-on aktiviert ist.

50e95039-b200-4007-bc97-8d5790743a63

Azure Virtual Desktop ARM Provider — dient nur dem Abruf des Feeds und darf nicht in eine Richtlinie mit Mehrfaktor-Anforderung.

0af06dc6-e4b5-4f28-818e-e78e62d137a5

Windows 365 — Windows App authentifiziert sich auch hiergegen, selbst wenn der Nutzer ausschließlich AVD-Ressourcen hat.

• Richtlinien auf alle Cloud-Apps erfassen auch die AVD-Anwendungen — sie sind die häufigste Ursache für unerwartete Blockaden.
• Eine Richtlinie, die Gerätekonformität verlangt, kann scheitern: Entra-eingebundene Session Hosts erfüllen Konformitätsrichtlinien, die für Endnutzergeräte entworfen wurden, nicht zwangsläufig.
• Standortbasierte Regeln bewerten für die AVD-Anwendung die Client-IP; für Windows Cloud Login kann die von Conditional Access gesehene IP je nach Netzweg abweichen. Beide Wege getrennt testen.
• Klassische benutzerbezogene Mehrfaktor-Authentifizierung neben Conditional Access erzeugt auf Entra-eingebundenen Hosts die Meldung, die Anmeldemethode sei nicht zulässig. Sie gehört abgeschaltet.

Anmeldehäufigkeit — und was dabei still ausfällt

Die Anmeldehäufigkeit (*sign-in frequency*) legt fest, wann ein neues Zugriffstoken eine erneute Anmeldung verlangt. Sie wirkt auf beiden Anwendungen unterschiedlich — und das ist der Grund für einen der lästigsten Fehlkonfigurationen im Betrieb.

Auf der Azure Virtual Desktop-Anwendung erzwingt sie die erneute Anmeldung beim Abonnieren, beim manuellen Aktualisieren der Ressourcenliste und bei der Gateway-Authentifizierung. Läuft der Zeitraum ab, scheitern Feed-Aktualisierung im Hintergrund und Diagnose-Upload laut Dokumentation stillschweigend, bis sich der Nutzer das nächste Mal interaktiv anmeldet. Ein Feed, der veraltet ist, ohne dass jemand einen Fehler sieht.

• Eine laufende Sitzung wird nicht unterbrochen, auch wenn sie länger dauert als die eingestellte Häufigkeit — erneut angemeldet wird nur, wenn ein neues Token gebraucht wird.
• Eine Netzstörung, die die Sitzung neu aufbauen lässt, erzwingt hingegen die erneute Anmeldung. Auf instabilen Netzen führt eine strenge Einstellung deshalb zu spürbar mehr Aufforderungen.
• Unterschiedliche Häufigkeiten auf den beiden Anwendungen erzeugen Aufforderungen zu unerwarteten Zeitpunkten. Die Dokumentation empfiehlt, sie aufeinander abzustimmen.

Die Verbindung kommt von innen

Ein Punkt, der den Netzentwurf entlastet und trotzdem regelmäßig falsch umgesetzt wird: Clients bauen eine Reverse Connection zum Dienst auf. Es muss kein eingehender Port geöffnet werden. Standardmäßig läuft das über TCP auf Port 443.

Für schnellere Sitzungen kann RDP Shortpath einen direkten, UDP-basierten Transport herstellen — für verwaltete Netze und für öffentliche Netze in je eigener Ausprägung. Das ist eine Ergänzung des Transports, keine Änderung des Zugriffsmodells: Die Steuerung bleibt bei Feed, Zuweisung und Gateway.

Reverse Connection — Der Session Host und der Client bauen die Verbindung jeweils von sich aus nach außen zum Dienst auf; der Dienst führt beide zusammen. Deshalb braucht keine Seite eine eingehende Öffnung — und deshalb ist eine offene 3389 kein Betriebserfordernis, sondern eine zusätzliche Angriffsfläche.

Diagnose: die Kette Tor für Tor