Defender pro servery: licence, Arc a účtování

Obsah ověřen k 29. říjnu 2026

Firma má Microsoft 365 E5, na serveru běží senzor Defenderu a zařízení je vidět v bezpečnostním portálu. Znamená to, že je server správně licencovaný? Ne. Uživatelská licence, technické připojení serveru a účtování jeho ochrany jsou tři samostatné části, které musí správce propojit.

Microsoft 365 E5 nenahrazuje serverové oprávnění. Server lze chránit například přes Defender for Business servers, samostatný Defender for Endpoint for servers nebo spotřební Defender for Servers Plan 1 či Plan 2 v Defender for Cloud. Správná volba závisí na velikosti prostředí, požadovaných funkcích a cestě onboardingu. Instalace senzoru sama tuto volbu nevyřeší.

Podobné názvy označují různé nabídky

Nejdřív rozlišujte ochranu uživatelských zařízení a serverových operačních prostředí. Oficiální licenční FAQ Microsoftu výslovně odděluje uživatelské licence od ochrany serverů. Pro samostatné serverové SKU také uvádí, že se serverům nepřiřazuje stejným způsobem jako licence uživatelům v Microsoft 365 admin centru.

Rozlišení samostatného Endpoint server SKU a spotřebních plánů popisuje Microsoft Defender Licensing Guidance. Defender for Servers P1 není totéž co klientský Defender for Endpoint P1. Serverový P1 zahrnuje endpointovou ochranu odpovídající serverové nabídce; označení P1 samo není spolehlivá zkratka pro společnou sadu funkcí napříč produkty.

Proč E5 ani pět zařízení na uživatele nestačí

Server, ke kterému přistupuje licencovaný zaměstnanec, se tím nestává jeho klientským zařízením. Předmět inventury je serverové prostředí a odpovídající nárok. Počet uživatelů na RDS ani to, kdo server spravuje, nejsou náhradou serverové licence.

U Business větve jsou omezení obzvlášť konkrétní. Product Terms pro Microsoft Defender u Defender for Business servers požadují samostatnou licenci pro každé OSE a nejvýše 60 takových licencí na zákazníka. Obecné oprávnění uživatele Defender for Business serverová OSE nepokrývá. Podmínky zde vztahujeme k programu MCA; u jiného kontraktu ověřte příslušnou variantu.

Pro praktické plánování to znamená počítat i virtualizaci. Jeden fyzický virtualizační hostitel a několik Windows Server VM nejsou automaticky jedna chráněná serverová instance. Seznam skutečně připojených operačních prostředí musí být součástí objednávky i následné kontroly.

Azure Arc a Direct onboarding plní jiný účel

Azure Arc propojuje podporovaný neazureový server se správou Azure. Direct onboarding propojuje způsobilý server, který už hlásí do Defender for Endpoint, s plánem Defender for Servers a vybraným Azure předplatným. Nejde o dvě zaměnitelná instalační tlačítka.

Aktuální postup Direct onboardingu uvádí důležitý rozsah: nastavení se vztahuje na existující i budoucí způsobilé neazureové servery připojené do Defender for Endpoint ve stejném Entra tenantu. Nelze v něm vybrat jednotlivé servery ani omezit zapnutí na pilotní skupinu. Samotná operace navíc neinstaluje endpointového agenta.

Model: pilot dvou serverů může zasáhnout celé prostředí

Představme si organizaci s 18 způsobilými neazureovými servery už připojenými do MDE. Správce chce otestovat účtování na dvou a v domnění, že vybírá pilot, zapne Direct onboarding. Výběr fakturačního předplatného ale sám neomezuje populaci na dva stroje.

Rozdíl mezi záměrem a rozsahem je zde 16 serverů. To není výpočet výsledné faktury: ta závisí na plánu, stavu a smluvní cestě. Je to důvod vyhodnotit dopad před zapnutím. Pilot endpointových pravidel a pilot tenantového propojení nejsou stejný test.

Připravte proto úplný seznam dotčených serverů, včetně těch s existující Arc vazbou a jiným způsobem licencování. Zapište, kdo schvaluje změnu účtování. Pak zvolte podporovanou testovací architekturu, jejíž skutečný rozsah odpovídá schválenému záměru.

P2 vyžaduje kontrolu konkrétní funkce

Plan 2 přidává schopnosti pro serverové a cloudové prostředí. Z matice Defender for Servers ale nelze odvodit, že každá funkce funguje na libovolném serveru, v každém cloudu a s libovolnou cestou připojení.

Direct onboarding poskytuje P1 a jen část možností P2. Potřebu Arc proto určujte podle funkce. Stejně tak registrace Arc sama nedokazuje zdravou endpointovou detekci. Technický tým musí otestovat obě vrstvy samostatně.

Pozor i na šíři nasazení: P1 lze zapínat na úrovni prostředku; P2 se zapíná na úrovni předplatného, přičemž lze jednotlivé prostředky vyloučit. Tato odlišnost je důležitá, pokud má mít malá část prostředí jiný plán. Přepínač předplatného nepovažujte za nevinnou změnu jednoho serveru.

Dvě fakturační chyby, které mají různou příčinu

První je překryv už zakoupeného samostatného Defender for Endpoint for servers se spotřebním Defender for Servers. FAQ Defender for Servers popisuje žádost o fakturační úpravu přes podporu. Zohlednění existujícího nároku není automatické a účinnost začíná schválením, nikoli zpětně. Nevztahujte tento postup bez ověření na každou jinou licenci se slovem Defender.

Druhá chyba vzniká při zaměnění stavů virtuálního stroje. Azure VM ve stavu Stopped má stále alokovaný hardware; FAQ ji pro popsané účtování uvádí jako zpoplatněnou. Deallocated je jiný stav. Když někdo vypíná Windows uvnitř VM, samotná tato operace tedy nestačí jako důkaz zastavení příslušných nákladů na ochranu.

Samostatně kontrolujte duplicitní záznamy téhož serveru. Dva záznamy nemusí znamenat dva skutečné servery ani automaticky dvě účtované položky. Porovnejte identifikátory, cestu připojení a aktuálnost agentů; při nesouladu řešte korelaci a fakturační data. Kosmetické odstranění záznamu ze seznamu není nápravou licenčního ani bezpečnostního stavu.

Business tenant posuďte před objednávkou

Firma do 300 uživatelů s menším počtem serverů může zvažovat Business serverový doplněk. Tím se ale výběr neuzavírá: rozhoduje požadovaná funkcionalita, smluvní dostupnost a podporovaný tenantový režim. Business FAQ upozorňuje, že přidání Defender for Cloud nemění zjednodušenou konfiguraci Defender for Business.

Zdroje zde nejsou úplně sjednocené: licenční FAQ popisuje omezení smíšeného serverového licencování a u Business tenantu nepředpokládá běžnou spotřební nabídku. Business FAQ naopak popisuje spolupráci s Defender for Cloud při zachování Business zkušenosti. Nevyvozujeme z toho automatický nárok na libovolný mix. Před změnou si nechte písemně potvrdit konkrétní kombinaci serverových SKU, tenantu a funkcí; obecný marketingový přehled tento rozpor neřeší. Klientskou část rozebíráme samostatně v článku Defender for Business vs. Defender for Endpoint P2.

Pracovní inventura pro nákup i kontrolu faktury

Následující tabulka je model pro redakční vysvětlení. Neobsahuje skutečné zákaznické ceny ani předpoklad, že je jedna nákupní cesta vždy nejlevnější.

Celkem jde o 18 OSE, nikoli 18 uživatelských licencí E5. Ověřený počet můžete porovnat se samostatnými serverovými nároky nebo s populací v Defender for Cloud. K ceně ale potřebujete sazbu, časový profil a případně schválenou úpravu překryvu. Bez těchto vstupů by srovnání měsíčních nákladů bylo zavádějící.

U každého serveru evidujte stabilní identifikátor, OS, vlastníka, umístění, onboarding, plán, zdroj nároku, fakturační předplatné a datum poslední kontroly. To je praktická spojnice mezi bezpečnostní inventurou a fakturou. Tabulka pouhých hostname a „Defender ano/ne“ nedokáže vysvětlit, co firma objednala a co se jí skutečně účtuje.

Co se mění od 1. listopadu 2026

K datu vydání je oznámená další změna. Release notes Microsoftu uvádějí účinnost od 1. listopadu 2026: klientská a produktivní zařízení se v P1 přestávají účtovat jako servery a pro P1 i P2 se zpřesňuje identifikace účtovaných serverů. Kontroly online strojů mají probíhat vícekrát za hodinu a samostatně se počítají i nasazené stroje se společným Arc ID z golden image.

Pro P1 oznámení navíc rozlišuje Windows servery a Linux či jiné ne-Windows servery: u druhé skupiny váže popsané účtování na nasazený MDE agent. U Windows se v připojeném prostředí nelze řídit jen ruční instalací senzoru. Do listopadové kontroly proto přidejte klasifikaci OS a skutečný počet klonovaných instancí. Případná změna účtovaného počtu nemusí znamenat, že někdo právě pořídil nové licence.

Co zkontrolovat po změně

1. Ověřte úplnost dotčené populace proti původní inventuře. Zkontrolujte i servery, které do záměru původně nepatřily.
2. Zkontrolujte endpointovou telemetrii a samostatně plán v Defender for Cloud. Historický záznam zařízení nepovažujte za důkaz aktivní ochrany.
3. Otestujte konkrétní funkce, kvůli kterým byl plán vybraný. Zaznamenejte prostředí a technické předpoklady.
4. Porovnejte evidenci nároků s účtovanými prostředky a řešte případný překryv přes podporu. Uložte datum schválení změny.
5. Nastavte opakovatelnou kontrolu při vzniku nové VM, změně plánu a obnově kontraktu. Aktualizujte vlastníka i rozpočtové přiřazení.

Nová zkušenost Cloud security v Defender portálu je v public preview a u migrovaných předplatných používá Defender Workload Units (DWU). Před srovnáním faktur proto zjistěte i použitou cenovou zkušenost. Pro jiný fakturační model vytvořte odpovídající rozpočet. Při předání práce dokumentujte plán a rozsah změny, ne pouze umístění tlačítka.