Firma má v adresáři osm tisíc hostů. Nákup připravuje osm tisíc prémiových licencí, správce ukazuje necelou tisícovku aktivních partnerů a bezpečnostní tým navíc zavádí pokročilé přezkumy přístupu. Každý pracuje s jiným počtem. Rozpočet nepůjde uzavřít, dokud neoddělíte uložené účty, aktivní identity a konkrétní placené funkce.
MAU znamená měsíčně aktivního uživatele, nikoli počet přihlášení, MFA výzev nebo pozvánek. Základní External ID a Governance pro hosty navíc nepoužívají stejnou událost pro vznik účtované aktivity. Bezplatné pásmo základní nabídky proto neznamená bezplatné použití každého doplňku ani právo hosta k libovolné aplikaci.
Obsah ověřen k 21. říjnu 2026. Článek řeší především B2B hosty ve firemním workforce tenantu. Rozlišuje je od zákaznického external tenantu a od běžných zaměstnanců. Číselné příklady jsou vlastní hypotetické modely, nikoli výsledky měření zákazníka nebo cenová nabídka.
Nejprve určete tenant a druh účtu
Přehled účtování External ID popisuje workforce tenant, kam zvete partnery ke spolupráci, i external tenant pro zákaznické aplikace. Nejde o dvě zaměnitelná umístění stejného řešení. Liší se podporovanými funkcemi, nastavením a použitelnými doplňky.
U B2B spolupráce dokumentace pracuje s hostovskými identitami a vlastností UserType. Vlastnosti B2B uživatelů současně rozlišují zdroj přihlašovacích údajů a vztah uživatele k organizaci. Samotná adresa s cizí doménou ani přejmenování účtu nejsou dostatečnou inventurou. Zapište také původ identity a účel přístupu.
Aktuální přehled uvádí i interní hosty přihlašované interními údaji. Z toho však neodvozujte, že změna Member na Guest vyřeší licencování zaměstnance ve všech službách. Klasifikace identity, účtování ověřování a oprávnění k cílovému produktu jsou samostatné otázky. Tento článek nepočítá běžné zaměstnanecké účty jako externí obchodní partnery.
| Scénář | První kontrola | Co nelze automaticky předpokládat |
|---|---|---|
| Externí partner jako B2B Guest ve workforce tenantu | Původ identity, UserType a propojené účtování | Že potřebuje stejný nákup jako zaměstnanec |
| Zaměstnanec jako Member | Zaměstnanecké nároky pro skutečně používané funkce | Že jej pokryje bezplatné hostovské pásmo |
| Uživatel zákaznické aplikace v external tenantu | Podporu funkce a aktuální External ID model | Že se na něj vztahuje celý workforce návrh |
| Strojové volání bez člověka v external tenantu | Samostatný M2M model, pokud je použit | Že každé vydání tokenu představuje lidského MAU |
Tato tabulka je třídění pro návrh, nikoli návod převádět účty kvůli nižšímu počtu licencí. Pokud přehled účtů nerozlišuje uvedené případy, přesný počet objednávaných oprávnění zatím nemáte.
Jeden aktivní host se nepočítá za každé přihlášení
Základní MAU model sleduje unikátní uživatele s ověřovací aktivitou v kalendářním měsíci. Opakovaná přihlášení stejného způsobilého hosta v témže měsíci z něj nevytvoří další MAU. Počet událostí v sign-in logu proto není bez další úpravy počet účtovaných lidí.
Aktuální cenová stránka uvádí prvních 50 000 MAU základní nabídky zdarma. Toto pásmo se týká základního produktu; prémiové doplňky mají vlastní pravidla a nemají automaticky stejné bezplatné pásmo. Přehled účtování navíc sčítá MAU z workforce a external tenantů připojených k předplatnému. Nepřiřazujte tedy každé aplikaci nebo adresáři nové samostatné bezplatné pásmo bez ověření fakturačního uspořádání.
Hypotetický příklad: v jednom posuzovaném workforce tenantu existuje 8 000 způsobilých B2B hostů. Za měsíc se ověří 900 různých hostů. Někteří opakovaně, takže log obsahuje 27 000 přihlášení. Pro zjednodušení nejsou k témuž předplatnému připojené žádné další tenanty přispívající do výpočtu.
| Zjištěný údaj | Hodnota | Význam pro model |
|---|---|---|
| Uložené účty hostů | 8 000 | Inventář, nikoli automaticky měsíční aktivita |
| Různí hosté s ověřovací aktivitou | 900 | Základní MAU v tomto vymezeném modelu |
| Události přihlášení | 27 000 | Nelze je zaměnit za 27 000 MAU |
| Další aktivita z připojených tenantů | 0 podle předpokladu | Předpoklad je nutné ověřit, ne jen vynechat z reportu |
Základních 900 MAU je v modelu pod uvedeným bezplatným pásmem. Výsledek neříká nic o ceně SMS ověřování, pokročilého Governance ani přístupu k dalším produktům. Odpověď „ověřování hostů se vejde do pásma“ není souhrnná faktura celé spolupráce.
Governance měří jinou aktivitu
Governance pro hosty popisuje samostatný model: v měsíčním vyúčtování je záznam pro každého hosta s jednou nebo více relevantními governance akcemi v tomto měsíci. Účtují se funkce vyhrazené ID Governance. Dokument výslovně odlišuje akce Entra P2, které se tímto doplňkem neúčtují, a nevyžaduje pro ně propojení Azure předplatného.
Seznam účtovaných událostí obsahuje například určité pokročilé žádosti o access package, přiřazení s vlastními rozšířeními, automatické přiřazení nebo použití vybraných pokročilých přezkumů. Rozhoduje konkrétní funkce a událost uvedená v aktuálním seznamu. Slovo „přezkum“ bez popisu jeho nastavení nestačí k zařazení každé akce do placeného Governance.
Měřidlo nevychází pouze z počtu lidí, kteří se osobně přihlásili. Událost může provést správce či workflow vůči cílovému hostovi. Proto hledejte cílovou identitu v auditních záznamech, ne pouze účty aktérů a jejich sign-in aktivitu.
Pokračování hypotetického příkladu: v měsíci vznikne relevantní účtovaná Governance aktivita pro 70 různých hostů. Padesát z nich patří také mezi 900 přihlášených; dvacet se nepřihlásilo, ale bylo cílem příslušné governance akce.
| Výpočet | Správné čtení |
|---|---|
| 900 základních MAU | Měřidlo základního ověřování v modelu |
| 70 Governance MAU | Unikátní cíloví hosté s příslušnou aktivitou |
| Průnik 50 hostů | Překryv mezi dvěma různými měřidly |
| 70 × smluvní sazba g | Modelová částka Governance, bez vymyšlené měny a ceny |
Číslo 970 nesmí být prezentované jako 970 různých osob v organizaci ani jako jediné společné měřidlo External ID. Současně nelze 70 Governance MAU odečíst z bezplatného základního pásma a tím jejich samostatnou sazbu vynulovat. Přiřazení v předchozím měsíci také samo o sobě nedokazuje novou účtovanou akci v dalším měsíci; dokumentace výslovně zmiňuje případ dříve automaticky přiděleného přístupu bez nové aktivity.
Jak doložit, kteří hosté vytvořili Governance spotřebu
Microsoft u účtovaných akcí uvádí auditní vlastnosti TargetId, TargetUserType = Guest a GovernanceLicenseFeatureUsed = True. Pro vlastní kontrolní přehled použijte měsíc události, cílové Object ID, typ funkce a úspěšnou relevantní akci. Opakované události stejného hosta v měsíci nesčítejte jako další unikátní hosty.
Zachovejte i detail původních událostí. Souhrn sedmdesáti Object ID řekne počet, ale neobjasní, která nově zavedená politika spotřebu změnila. Porovnání seznamu funkcí před a po nasazení je užitečnější než připsat zvýšení každému novému pozvání do Teams.
Propojení Azure předplatného podle příslušného návodu ověřte přímo v tenantu. Při předání potřebujete vlastníka nákladů, správné předplatné a schopnost najít odpovídající měřidlo. Nestačí vědět, že organizace někde Azure používá. Rozpočet základního ověřování a Governance připravte odděleně.
Přihlášení ještě neopravňuje k aplikaci
External ID řeší identitu a její přístupové scénáře. Z toho neplyne, že základní MAU poskytne licenci Power Automate, Power Apps nebo každé jiné aplikace, kterou host otevře. Například podpora hostů v Power Automate požaduje příslušnou licenci z hostitelského nebo domovského tenantu. Přenositelnost posuzujte podle konkrétní služby, nikoli podle obecné věty „host si přinese licenci“.
Stejně oddělte licenční model od technického MFA. Ověřování a Conditional Access pro B2B rozlišuje důvěru k MFA tvrzení domovského tenantu a požadavky cílové organizace. Partner může mít MFA doma, ale bez odpovídajícího nastavení důvěry dostat další výzvu. Správný výpočet MAU to sám neopraví.
Pokud chráníte také zaměstnance, navazuje Conditional Access: kdo potřebuje licenci. Pravidla interních uživatelů nekopírujte bez rozlišení na hosty a hostovské měřidlo zase nepoužívejte jako pokrytí celé vlastní organizace.
Co připravit před rozšířením spolupráce
- Rozlište workforce a external tenanty, zdroje přihlašovacích údajů a skutečné UserType hodnoty.
- Sepište konkrétní funkce: ověřování, Conditional Access, jednotlivé governance scénáře a cílové aplikace.
- Zkontrolujte všechna předplatná a tenanty vstupující do souhrnného MAU výpočtu.
- Získejte unikátní aktivní identity za kalendářní měsíc; oddělte je od počtu sign-in událostí.
- Pro Governance vytvořte samostatný přehled cílových hostů podle příslušných auditních vlastností a událostí.
- Ověřte práva k cílovým produktům a technický přístup na reprezentativním partnerském účtu.
- Po změně funkcí porovnejte konfiguraci, audit a skutečné účtování. Náklady nevysvětlujte pouze růstem adresáře.
Často kladené otázky
Znamená osm tisíc hostů osm tisíc měsíčně placených licencí?
Ne automaticky. Inventář účtů není totéž co základní MAU ani aktivita placeného doplňku. Nejprve určete používanou funkci a její měřidlo.
Je 50 000 MAU totéž co 50 000 přihlášení?
Ne. Základní MAU počítá unikátní aktivní uživatele v kalendářním měsíci. Opakované ověření téhož uživatele nevytváří nového člověka.
Je Governance zdarma, když se vejdeme do základního pásma?
Ne jako obecné pravidlo. Prémiové doplňky mají vlastní účtování; u Governance rozhodují uvedené pokročilé akce a cíloví hosté.
Musí se host přihlásit, aby mohl být započten v Governance?
Nespoléhejte jen na sign-in log. Některé relevantní události provádí správce nebo workflow vůči hostovi. Rozhoduje aktuální seznam účtovaných akcí a jejich cílové identity.
Pokryje MAU licenci každé aplikace pro hosta?
Ne. Oprávnění k cílovému produktu posuzujte samostatně. Pravidla Power Automate nebo jiné služby nenahrazuje účetní model External ID.
