Azure Virtual Desktop unterstützt externe Identitäten. In der Dokumentation kann „externer Nutzer“ aber zweierlei bedeuten: ein Dienstleister arbeitet für Ihr Unternehmen oder ein Kunde nutzt eine Anwendung, die Sie als Dienst anbieten. Lizenzrechtlich sind das verschiedene Fälle. Trennen Sie vor einer B2B-Einladung Anmeldemethode, Nutzungszweck, Lizenz im Zielmandanten und Azure-Betriebskosten.
Ältere Antworten behaupten noch, AVD unterstütze keine B2B-Gäste. Eine Microsoft-Q&A-Antwort von 2022 enthält diese Aussage. Die aktuelle AVD-Dokumentation beschreibt dagegen externe Identitäten und ihre technischen Voraussetzungen. Entscheidend sind das Datum der Quelle und das konkrete Szenario.
Auch nach Annahme der Einladung kann ein Gast beide Organisationen sehen, aber keine AVD-Ressource. Ein aktueller Fall in Microsoft Q&A empfiehlt die Prüfung von externer Identität, mandantenübergreifendem Zugriff und Organisationskontext in der Windows App; der Fragesteller hat keine Lösung bestätigt. Ähnliche Fragen gibt es auf Reddit. Die folgende Diagnose trennt mögliche Ursachen, statt eine einzelne Einstellung als allgemeine Lösung auszugeben.
Identität und Nutzungszweck getrennt betrachten
Externe Identität beschreibt die Anmeldung: Eine Person nutzt beispielsweise ihr Konto aus dem eigenen Entra-Mandanten und ist in Ihrem Mandanten als B2B-Gast vertreten. Externer kommerzieller Zweck beschreibt dagegen das Geschäftsmodell, etwa eine App, die Sie Kunden als Dienst bereitstellen. Ein Dienstleister kann technisch B2B-Gast sein und trotzdem für interne Zwecke Ihres Unternehmens arbeiten.
Microsofts Lizenzleitfaden nennt einen externen Dienstleister, der für ein Unternehmen arbeitet: Er benötigt ein geeignetes Recht für die interne AVD-Nutzung. Der Kontotyp „Guest“ macht ihn nicht zum Kunden für Per-User-Access-Pricing. Dieses verbrauchsabhängige Modell gilt für einen externen kommerziellen Zweck, etwa den Verkauf des Zugangs zu Ihrer Anwendung an Kunden.
| Szenario | Technische Identität | AVD rechter Typ | Ein häufiger Fehler |
|---|---|---|---|
| Mitarbeiter nutzt einen internen Desktop | Konto im Unternehmensmandanten | Geeignete Benutzerlizenz für interne Nutzung | Azure-VM-Kosten decken bereits Benutzerrechte ab |
| Dienstleister arbeitet in einer internen Buchhaltungs-App | Kann B2B-Gast sein | Geeignete Lizenz für interne Nutzung im AVD-Mandanten | Ein Guest-Konto gilt als externer Kunde |
| Kunde nutzt eine von Ihnen angebotene App | Externe Identität je nach Dienstmodell | Per-User-Access-Pricing für externe kommerzielle Nutzung | Die Lizenz im Kundenmandanten genügt |
| Mitarbeiter hat eine Lizenz in einem anderen Konzernmandanten | B2B oder anderes Multi-Tenant-Modell | AVD-Recht im Zielmandanten gesondert prüfen | Rechte wandern mit der Identität mit |
Die Tabelle vereinfacht das AVD-Zugriffsrecht. Sie deckt Office, Intune, Defender und andere Software im Desktop nicht automatisch ab. Bei komplexen Verträgen und ungewöhnlichen Dienstmodellen prüfen Sie die aktuellen Microsoft Product Terms und klären den Fall mit Ihrem Lizenzpartner.
Technische Voraussetzungen für B2B-Zugriff
Die aktuelle AVD-Dokumentation nennt mehrere technische Voraussetzungen. Der Sitzungshost muss Microsoft Entra joined sein, der Hostpool Single Sign-On nutzen und das Betriebssystem unterstützt werden. Genannt werden Windows 11 Enterprise 24H2 oder neuer mit Updates ab September 2025 sowie Windows Server 2025 mit Updates ab Januar 2026. Prüfen Sie auch Einschränkungen des Identitätsanbieters und der Windows App. Eine ältere Hybridkonfiguration ist nicht schon deshalb unterstützt, weil interne Mitarbeiter sie nutzen können.
Der Gast braucht außerdem Zugriffszuweisungen. Nach Microsofts Anleitung wird die Gruppe mit Gästen einer Application Group zugewiesen. Bei einem üblichen Hostpool kommt die Azure-Rolle Virtual Machine User Login für die Sitzungshosts hinzu; für „Session Host Configuration“ nennt Microsoft eine Ausnahme. Prüfen Sie Einladung, mandantenübergreifenden Zugriff, Gruppe, Application Group, VM-Anmeldung und den Zielmandanten in der Windows App einzeln.
Auch nach erfolgreicher Anmeldung gibt es Grenzen. Laut Microsoft kann eine externe Identität für lokale Ressourcen nicht Kerberos oder NTLM verwenden. Wenn eine ältere interne Anwendung davon abhängt, testen Sie sie vor dem Rollout. Ein geöffneter Desktop beweist noch nicht, dass jede App darin funktioniert.
Wo erhält der Gast seine Lizenz?
Eine B2B-Einladung überträgt kein AVD-Nutzungsrecht. Microsoft empfiehlt, externen Mitarbeitern eine geeignete Lizenz für ihr Gastobjekt im Mandanten zuzuweisen, der AVD bereitstellt. Rechte aus dem Heimatmandanten des Dienstleisters gelten in der Regel nicht automatisch für AVD oder andere Produkte im Zielmandanten. Ähnliches gilt bei mehreren Mandanten derselben Organisation. Microsoft nennt eine spezielle Ausnahme für Entra ID P1, die nicht pauschal auf AVD übertragen werden darf.
Für Windows-10/11-Sitzungshosts zur internen Nutzung nennt Microsoft unter anderem Microsoft 365 Business Premium, E3, E5 und F3 sowie bestimmte Windows-Enterprise- oder Windows-VDA-Lizenzen als geeignete Rechte. Für Windows-Server-Sitzungshosts gilt eine andere Liste, beispielsweise RDS CAL mit Software Assurance oder RDS User Subscription Licenses. Prüfen Sie die AVD-Lizenzübersicht für Betriebssystem und Bereitstellungsmodell.
Wenn im Desktop Microsoft 365 Apps, Teams oder andere Produkte laufen, prüfen Sie deren Rechte getrennt. Der AVD-Lizenzleitfaden stellt klar: Per-User-Access-Pricing für externe kommerzielle Nutzung enthält nicht automatisch Office-, Defender- oder andere Produktlizenzen. Auch die Office-Lizenz eines Dienstleisters im Heimatmandanten muss nicht alle Nutzungen in Ihrem Mandanten abdecken.
Per-User-Preise sind kein Gastrabatt
Per-User-Access-Pricing wird manchmal als günstiger Weg für beliebige B2B-Gäste verstanden, bei dem nur aktive Monate zählen. Microsoft beschreibt es anders: Ein Dienstleister, der für Ihre Organisation arbeitet, benötigt Rechte für die interne Nutzung. Das verbrauchsabhängige Modell ist für Kunden bestimmt, denen Sie AVD als externen kommerziellen Dienst bereitstellen. Für diese Kunden wird im jeweiligen Monat ein Nutzer gezählt, sobald er sich mindestens einmal verbunden hat.
Formulieren Sie vor der Entscheidung einen Satz: „Diese Person verbindet sich, um für unsere Organisation zu arbeiten“ oder „Diese Person nutzt als Kunde einen Dienst, den wir ihr verkaufen“. Falls das nicht eindeutig möglich ist, klären Sie zuerst die Geschäftsbeziehung. Der technische Kontotyp „Guest“ beantwortet die Lizenzfrage nicht.
Mehr als Benutzerlizenzen budgetieren
Auch mit der richtigen Benutzerlizenz verursacht AVD weitere Kosten. Microsofts Kostenleitfaden trennt das Nutzungsrecht vom Azure-Verbrauch: Rechenleistung der Sitzungshosts, Datenträger, Profilspeicher, Netzwerkverkehr, Protokollierung und mögliche Zusatzdienste. Bei Per-User-Access-Pricing kommt der gemessene Zugang für externe kommerzielle Nutzer hinzu; die Infrastruktur wird weiterhin abgerechnet.
Ermitteln Sie für ein Angebot die Zahl der Nutzer, gleichzeitige Sitzungen, Betriebsstunden der Hosts, Größe der Profile und ausgehenden Datenverkehr. Ohne dieses Modell sollten Sie keine Einsparung gegenüber Windows 365 versprechen. Windows 365 Business hat ein anderes Lizenz- und Betriebsmodell; der Vergleich mit Enterprise entscheidet nicht über den passenden AVD-Hostpool.
Wenn der Gast keinen Desktop sieht
Gehen Sie bei der Fehlersuche von der Identität bis zur Arbeitssitzung vor:
- Nutzungszweck und Rechte prüfen. Arbeitet die Person intern für Ihr Unternehmen oder nutzt sie einen externen kommerziellen Dienst? Ist die benötigte Lizenz im AVD-Mandanten zugewiesen?
- Einladung und mandantenübergreifenden Zugriff prüfen. Ist der Gast eingeladen, ist Zusammenarbeit erlaubt und lässt Conditional Access die Anmeldung zu?
- Technische Voraussetzungen prüfen. Sind Sitzungshosts Entra joined, Betriebssystem und Updates unterstützt und SSO im Hostpool aktiv?
- Zuweisungen prüfen. Weisen Sie die Gastgruppe der Application Group und je nach Hostpool-Konfiguration der passenden VM-Anmelderolle zu.
- Richtigen Mandanten in der Windows App wählen. Die Anmeldung nutzt das Konto aus dem Heimatmandanten, die AVD-Ressourcen liegen jedoch in Ihrem Mandanten. Ein Vergleich mit dem unterstützten Webclient grenzt Kontextfehler ein.
- Erst dann die App im Desktop testen. Prüfen Sie Office-Rechte, alte Authentifizierungsprotokolle und den Zugriff auf interne Systeme gesondert.
Am Ende des Piloten muss der Gast den vorgesehenen Desktop oder die RemoteApp und die konkrete Arbeitsanwendung tatsächlich öffnen können. Dass sein Gastobjekt in Entra sichtbar ist, beweist noch nicht, dass AVD funktioniert.
Häufig gestellte Fragen
Unterstützt AVD inzwischen B2B-Gäste?
Ja, wenn die aktuellen Microsoft-Voraussetzungen erfüllt sind: unterstützte Sitzungshosts, Entra Join, SSO und passende Zuweisungen. Ältere Antworten mit einem generellen Nein sind überholt.
Genügt Business Premium im Heimatmandanten des Dienstleisters?
Davon sollten Sie nicht ausgehen. Microsoft empfiehlt im Regelfall, dem Gastobjekt im AVD-Mandanten geeignete Rechte zuzuweisen. Lizenzen aus dem Heimatmandanten übertragen sich normalerweise nicht.
Gilt jeder B2B-Gast als externer Nutzer für Per-User-Access-Pricing?
Nein. Wer für Ihr Unternehmen arbeitet, ist ein Fall interner Nutzung. Per-User-Access-Pricing gilt für AVD-Dienste, die Sie Kunden für einen externen kommerziellen Zweck bereitstellen.
Deckt das AVD-Recht auch Word und Excel ab?
Nicht automatisch. Prüfen Sie das Zugriffsrecht auf AVD und die Rechte für jede Anwendung im Desktop getrennt.
Warum sieht der Gast unsere Organisation, aber keine RemoteApp?
Die angenommene Einladung ist nur ein Schritt. Prüfen Sie mandantenübergreifende Einstellungen, Conditional Access, Hostpool, Application Group, VM-Anmelderechte und den Organisationskontext in der Windows App. Die genaue Ursache zeigen erst die Anmeldeprotokolle.
Vor der Einladung entscheiden
Dokumentieren Sie vor der Gruppenzuweisung Geschäftszweck, Identitätstyp, AVD-Mandant, Betriebssystem des Sitzungshosts, erforderliches Benutzerrecht, weitere Anwendungen und erwartete Azure-Kosten. Ein funktionierendes Guest-Konto belegt weder den passenden Lizenzzweck noch die tatsächlichen Betriebskosten.
