Azure Virtual Desktop dnes umí pracovat s externí identitou, ale „externí uživatel“ má v dokumentaci dva různé významy. Dodavatel, který pracuje pro vaši firmu, a zákazník používající vaši prodávanou aplikaci nejsou licenčně stejný případ. Než pošlete pozvánku hostovi, oddělte technické přihlášení, účel použití, licenci v tenantovi a provozní náklady Azure.
Ve vyhledávání stále žijí starší odpovědi, podle nichž AVD nepodporuje B2B hosty. Microsoft Q&A z roku 2022 tuto informaci obsahuje. Současná dokumentace AVD už však externí identity popisuje včetně technických požadavků. Nový správce tak může poctivě číst dva zdroje Microsoftu a dojít k opačným závěrům. Rozhodující je datum a přesný scénář.
Nejasnost pokračuje i po přijetí pozvánky: v nedávném dotazu na Microsoft Q&A host vidí obě organizace, ale nevidí prostředí AVD. Odpověď radí zkontrolovat podmínky externí identity, cross-tenant access a kontext organizace ve Windows App; tazatel však řešení nepotvrdil. Podobné případy se objevují na Redditu. Následující postup proto není slib, že každou chybu vyřeší jedna volba, ale mapa, jak ji rozlišit.
Dvě osy, které se nesmějí míchat
Externí identita znamená, že se člověk přihlašuje například účtem ze svého domovského Entra tenantu a ve vašem tenantovi má B2B hosta. Jde o technický model identity. Externí komerční účel znamená, že firma poskytuje desktop či aplikaci svým zákazníkům jako službu. Jde o licenční účel. Dodavatel může být technicky externí B2B host, a přesto pracovat pro interní potřeby vaší firmy.
Licenční průvodce Microsoftu uvádí příklad externího dodavatele, který pracuje pro firmu: potřebuje odpovídající licenci pro interní použití AVD. Samotná nálepka „Guest“ z něj neudělá zákazníka oprávněného pro per-user access pricing. Tento měřený model je určen pro externí komerční účel, například když poskytovatel prodává přístup ke své aplikaci zákazníkům.
| Scénář | Technická identita | Typ práva k AVD | Častý omyl |
|---|---|---|---|
| Zaměstnanec používá interní desktop | Účet v tenantovi firmy | Způsobilá uživatelská licence pro interní použití | „Azure VM už zahrnuje právo uživatele“ |
| Dodavatel pracuje v interní účetní aplikaci | Může být B2B host | Způsobilá licence pro interní použití přidělená v tenantovi, který AVD poskytuje | „Host se účtuje jako externí zákazník“ |
| Zákazník používá aplikaci, kterou mu jako službu prodáváte | Externí identita podle návrhu služby | Per-user access pricing pro externí komerční účel | „Stačí cizí Microsoft 365 licence“ |
| Pracovník má licenci v jiném tenantovi téže skupiny | B2B či jiné více tenantové uspořádání | Oprávnění se pro AVD v cílovém tenantovi posuzuje samostatně | „Licence se přenese s identitou“ |
Tabulka zjednodušuje rozhodnutí o přístupovém právu k AVD. Nepokrývá automaticky Office, Intune, Defender ani další software v desktopu. U složitější smlouvy a atypického poskytování služby ověřte přesné podmínky v aktuálním Microsoft Product Terms a u licenčního partnera.
Co musí splnit host pool pro B2B přístup
Současná dokumentace externích identit AVD stanoví více technických podmínek. Session host musí být Microsoft Entra joined, host pool musí používat single sign-on a operační systém musí být v podporované verzi. Dokumentace uvádí Windows 11 Enterprise 24H2 či novější s aktualizací od září 2025, případně Windows Server 2025 s aktualizací od ledna 2026. Před nasazením zkontrolujte i omezení identity provideru a klienta Windows App. Starší hybridní konfiguraci nelze pokládat za podporovanou jen proto, že interním zaměstnancům funguje.
Host potřebuje správné přidělení přístupu. Podle postupu Microsoftu patří skupina s hosty do application group. U běžného host poolu má dostat také Azure roli Virtual Machine User Login pro session hosty; výjimka je uvedena pro session host configuration. Host pool musí mít zapnuté SSO. Při diagnostice kontrolujte tyto vrstvy odděleně: přijatou pozvánku, cross-tenant nastavení, skupinu, application group, přihlášení k VM a klientský kontext cílové organizace.
Existují i omezení po úspěšném připojení. Microsoft uvádí, že externí identita nemůže autentizovat k místním zdrojům pomocí Kerberos nebo NTLM. Pokud desktop spoléhá na starou interní aplikaci s těmito protokoly, ověřte její chování ještě před pilotem. Přístup do samotného desktopu není důkazem, že uvnitř poběží všechny aplikace.
Kde má být licence hosta
Právo k AVD nepřenáší B2B pozvánka. Microsoft doporučuje externím spolupracovníkům přidělit odpovídající licenci k jejich objektu v tenantovi, který AVD poskytuje. Licence v domovském tenantovi dodavatele zpravidla nedává práva k AVD nebo dalším produktům v cílovém tenantovi. Totéž obecně platí pro více tenantů jedné organizace; dokumentace vyjmenovává specifickou výjimku pro Entra ID P1, kterou však nelze automaticky vztáhnout na AVD.
Pro Windows 10/11 session hosty při interním použití Microsoft uvádí jako způsobilé například Microsoft 365 Business Premium, E3, E5 a F3, dále vybrané Windows Enterprise nebo Windows VDA licence. U Windows Server session hostů je seznam jiný: například RDS CAL se Software Assurance nebo RDS User Subscription Licenses. Nekupujte oprávnění pouze podle obchodního názvu „AVD“; nejprve určete operační systém hosta, účel použití a konkrétní účet člověka, který se připojuje.
Jestli na vzdálené ploše používá Microsoft 365 Apps, Teams nebo jiné produkty, posuďte jejich práva samostatně. Licenční průvodce AVD výslovně upozorňuje, že per-user access pricing pro externí komerční účel nepřidává automaticky licenci na Office, Defender ani další služby. Podobně licence dodavatele na Office v jeho domovském tenantovi nemusí pokrýt každou funkci, kterou chcete provozovat ve svém tenantovi.
Per-user access pricing není sleva pro hosty
Model per-user access pricing se často vykládá jako způsob, jak připojit libovolného B2B hosta a zaplatit jen za jeho aktivní měsíc. Takto jej Microsoft nedefinuje. Patří pouze k externímu komerčnímu účelu. Není náhradou za interní licencování dodavatele, který pro vás vykonává práci. U skutečného zákazníka služby se měřený přístup platí přes přiřazené předplatné Azure a v daném měsíci se počítá uživatel, který se alespoň jednou připojil.
Před rozhodnutím napište jednu větu: „Tento člověk se připojuje, aby vykonával práci pro naši organizaci“ nebo „Tento člověk jako zákazník používá službu, kterou mu prodáváme“. Pokud nelze větu vyplnit jednoznačně, nejprve vyjasněte obchodní vztah. Technická přítomnost účtu typu Guest není odpověď na licenční účel.
Rozpočet: uživatelské právo je jen jedna položka
Ani správná uživatelská licence neznamená, že běh AVD je bez dalších nákladů. Microsoftův nákladový průvodce odděluje licence od spotřeby Azure: výpočetní výkon session hostů, disky, profilové úložiště, síťový přenos, logování a případné podpůrné služby. V modelu per-user access pricing se přidává měřený poplatek za externí komerční přístup; infrastruktura se účtuje dál.
Pro nabídku zákazníkovi si připravte modelové počty připojených osob, současných relací, hodin provozu hostů, velikosti profilů a odchozího provozu. Neslibujte úsporu oproti Windows 365 bez tohoto modelu. Windows 365 Business má jiný licenční a provozní model; jeho srovnání s Enterprise samo o sobě neodpovídá na to, který AVD host pool je pro konkrétní aplikaci vhodný.
Když host nevidí desktop nebo RemoteApp
Postupujte od identity k pracovní relaci, ne od virtuálního stroje zpět:
- Ověřte účel a právo. Má externista oprávnění pro interní či externí komerční scénář? Je odpovídající licence přidělena v tenantovi poskytujícím AVD?
- Zkontrolujte pozvánku a cross-tenant access. Host musí být správně pozván, mít povolenou spolupráci a projít případnými politikami Conditional Access pro externí uživatele.
- Potvrďte technické předpoklady. Entra joined session host, podporovaný OS a aktualizace, host-pool SSO. Starší návod, podle kterého B2B nelze, neřeší současné podmínky.
- Zkontrolujte přiřazení. Skupina hostů musí mít application group a příslušnou roli přihlášení k VM podle zvoleného typu host poolu.
- Otestujte správný tenant ve Windows App. Host se může ověřit domovskými přihlašovacími údaji, ale AVD prostředky jsou v tenantovi firmy. Zkontrolujte přepnutí organizace a porovnejte podporovaný webový klient. Tím izolujete chybu klientského kontextu od chyby oprávnění.
- Teprve potom řešte aplikaci uvnitř desktopu. Ověřte Office a staré protokoly či přístupy k interním systémům zvlášť.
Na konci pilotu musí host skutečně otevřít zamýšlený desktop nebo RemoteApp a konkrétní pracovní aplikaci. Samotné zobrazení objektu hosta v Entra není testem funkčního AVD.
Často kladené otázky
Podporuje AVD dnes B2B hosty?
Ano, za podmínek uvedených v aktuální dokumentaci Microsoftu. Vyžaduje podporovaný session host, Entra join, SSO a správná přiřazení. Starší odpovědi o nepodporovaných hostech jsou pro dnešní stav zastaralé.
Stačí dodavateli jeho vlastní Microsoft 365 Business Premium?
Nepředpokládejte to. Microsoft obecně doporučuje přidělit způsobilou licenci objektu externího spolupracovníka v tenantovi, který AVD poskytuje; práva z domovského tenantu se běžně nepřenášejí.
Je každý B2B host „external user“ pro per-user pricing?
Ne. Dodavatel vykonávající práci pro vaši firmu patří v tomto modelu k internímu komerčnímu účelu. Per-user access pricing je pro poskytování AVD zákazníkům při externím komerčním účelu.
Pokrývá AVD licence i Word a Excel na virtuální ploše?
Ne automaticky. Právo k přístupu do AVD a právo používat konkrétní aplikace je třeba posoudit odděleně.
Proč host vidí naši organizaci, ale ne RemoteApp?
Přijatá pozvánka potvrzuje jen část cesty. Zkontrolujte cross-tenant nastavení, Conditional Access, podporovaný host pool, application group, přihlášení k VM a tenant kontext ve Windows App. Bez logů konkrétního přihlášení nelze označit jedinou příčinu.
Rozhodnutí před pozvánkou
Před přidáním externisty do skupiny si do jednoho záznamu uložte obchodní účel, typ identity, tenant s AVD, operační systém session hostu, požadovanou uživatelskou licenci, další aplikace a očekávané Azure náklady. Tím zabráníte nejdražšímu omylu: technický účet Guest začne fungovat, ale licenční účel nebo náklady zůstaly neověřené.
