Ryzyko finansowe i odpowiedzialność osobista administratora
Modele licencjonowania per core, per user i CAL na papierze wyglądają jak temat stricte prawniczy. W praktyce to jeden z obszarów, gdzie zły wybór administratora IT przekłada się bezpośrednio na faktury, a czasem także na odpowiedzialność osobistą kierownika IT. Audyt licencyjny dużego producenta oprogramowania potrafi wygenerować nieplanowane koszty, które zjedzą cały roczny budżet na infrastrukturę. Część tych kosztów wynika z nieświadomych błędów: złego liczenia rdzeni, braku CAL-i dla zewnętrznych użytkowników czy zbyt swobodnego podejścia do kont usługowych.
Administrator jest zwykle najbliżej infrastruktury. Wie, ilu jest realnych użytkowników, ile jest urządzeń, jak wygląda wirtualizacja i klastrowanie. Jeżeli ta wiedza nie spotyka się z poprawnym rozumieniem licencjonowania, powstaje luka: środowisko „działa”, ale nie ma pokrycia w licencjach. W razie audytu producenci oprogramowania zwracają się w pierwszej kolejności do zarządu, ale pytania techniczne trafiają właśnie do administratora, który musi wytłumaczyć, kto, z czego i w jaki sposób korzysta.
Do tego dochodzi presja czasu. Zakup serwera bywa zgłaszany w ostatniej chwili, tuż przed wdrożeniem systemu. Jeżeli IT nie ma przygotowanego, przemyślanego modelu licencjonowania, decyzje podejmuje się nerwowo, często wybierając „pierwszą sensowną ofertę” od integratora albo hurtowni. A to z kolei może oznaczać nadmierne przepłacanie przez kolejne lata.
Typowe sytuacje wyjściowe w firmach
Większość administratorów nie zaczyna od zielonej kartki. Najczęściej dziedziczy się środowisko, w którym:
brakuje kompletnej dokumentacji licencji,
nikt dokładnie nie wie, jakie licencje zostały kupione i do czego są przypisane,
sprzęt i systemy były rozbudowywane latami ad hoc, bez spójnego planu licencyjnego,
w firmie „zawsze tak się robiło”, bez weryfikacji aktualnych zasad producenta.
Druga typowa sytuacja to szybka rozbudowa środowiska: wdrożenie nowego systemu ERP, migracja poczty, wejście w wirtualizację czy budowa klastra HA. Gdzieś w tle pojawia się pytanie o licencjonowanie per core, licencje CAL, licencje serwerowe. Jeżeli na tym etapie nie zostanie wybrany spójny model licencjonowania, w kolejnych krokach każdy serwer i każda rola będą dokupowane „jak wyjdzie”, co w dłuższej perspektywie podnosi koszty.
Coraz częściej dochodzi też migracja do chmury lub modelu hybrydowego. Część usług zostaje on‑premise, część ląduje w Microsoft 365 lub innych platformach. Modele licencjonowania zaczynają się mieszać: subskrypcje użytkowników, licencje serwerowe per core, uprawnienia hybrydowe. Bez chłodnego, techniczno-finansowego spojrzenia da się łatwo „zapłacić podwójnie” – raz w chmurze, drugi raz lokalnie – albo przeciwnie, nie mieć pokrycia licencyjnego dla części scenariuszy.
„Działa” kontra „jest legalne i opłacalne”
Z punktu widzenia sieci i systemów hasło „działa” oznacza, że usługi odpowiadają, użytkownicy się logują, serwery nie zgłaszają krytycznych błędów. Producenta oprogramowania to nie obchodzi. Podczas audytu pytanie brzmi: „czy na ten sposób użycia oprogramowania są właściwe licencje i czy są przypisane zgodnie z zasadami?”. Można mieć perfekcyjnie działające środowisko, które jednocześnie jest licencyjną miną.
Druga część równania to „opłacalność”. Często da się spełnić wymagania licencyjne na kilka sposobów: licencją per core, per user, kombinacją CAL + serwer, subskrypcją hybrydową itd. Różnica w kosztach bywa kilkukrotna. Tani w zakupie model okazuje się drogi przy rozroście środowiska, a bardziej skomplikowany na papierze wariant per core wychodzi taniej przy dużej liczbie użytkowników i intensywnej wirtualizacji. Administrator, który rozumie podstawy, może świadomie zaproponować model minimalizujący koszty przy zachowaniu zgodności.
Kto faktycznie decyduje o licencjach w organizacji
W wielu firmach licencje „leżą” w kilku działach jednocześnie. IT zna potrzeby techniczne i architekturę, dział zakupów pilnuje budżetu i negocjuje oferty, zarząd podejmuje decyzje strategiczne (np. wejście w chmurę), a integrator daje własne rekomendacje. Problemy pojawiają się, gdy te cztery perspektywy nie są zgrane:
zakupy kupują tańszy, ale nieoptymalny model licencji, bo różnica w kosztach wyjściowych wygląda atrakcyjnie,
integrator sprzedaje to, co zna lub co jest promowane przez producenta,
zarząd oczekuje łatwej skalowalności, ale nikt nie przelicza konsekwencji licencyjnych,
IT musi potem „jakoś to obsłużyć”, godząc się z liczącymi się w tysiącach złotych ograniczeniami.
Administrator lub kierownik IT, który umie w prosty sposób wytłumaczyć różnice: per core vs per user vs CAL oraz pokazać proste scenariusze kosztowe, zyskuje realny wpływ na decyzje. To nie jest tylko „papierologia” – to narzędzie do obrony sensownych budżetów i unikania zbędnych wydatków.
Podstawowe pojęcia licencyjne dla administratora IT
Licencja wieczysta, subskrypcyjna i dostępowa
Większość produktów serwerowych i klienckich można podzielić na kilka głównych typów licencji:
Licencja wieczysta – jednorazowy zakup prawa do używania danej wersji oprogramowania bez ograniczenia czasowego. Aktualizacje do nowych wersji nie są w cenie (chyba że osobno wykupiono Software Assurance lub odpowiednik). Przykład: klasyczna licencja Windows Server lub SQL Server w modelu on‑premise.
Licencja subskrypcyjna – prawo do używania oprogramowania w zamian za opłatę cykliczną (miesięczną, roczną). Zwykle obejmuje ona też aktualizacje do najnowszych wersji przez cały okres subskrypcji. Przykład: Microsoft 365, część licencji serwerowych w modelu CSP.
Licencja dostępowa (CAL) – nie daje prawa do instalacji oprogramowania, lecz do dostępu do usług na licencjonowanym serwerze. Jest przypisywana do użytkownika lub urządzenia, które korzysta z usług serwera (loguje się do domeny, czyta pliki, łączy się z bazą danych przez aplikację itp.).
W modelach per core, per user i CAL trzeba mieć z tyłu głowy, że często łączy się licencję serwerową (wieczystą lub subskrypcyjną) z licencjami dostępowymi. Przykładowo: Windows Server licencjonowany jest per core, ale użytkownicy i urządzenia, które korzystają z usług, wymagają osobnych CAL-i – chyba że zastosowano edycję lub model, który wyraźnie zwalnia z tej potrzeby w określonym scenariuszu.
Co oznacza „uprawniony użytkownik” i „uprawnione urządzenie”
W dokumentacji licencyjnej często pojawia się termin uprawniony użytkownik (licensed user, authorized user) oraz uprawnione urządzenie. Są to kluczowe pojęcia dla licencjonowania per user i per device.
Uprawniony użytkownik to osoba fizyczna, której przypisano licencję. Zwykle może ona korzystać z oprogramowania na wielu urządzeniach (np. komputer służbowy, laptop, tablet, telefon), o ile produktywnie korzysta z nich ta sama osoba. Ogólnie: płaci się za człowieka, nie za sprzęt.
Uprawnione urządzenie to konkretny komputer, terminal, thin client czy inny sprzęt, który ma prawo korzystać z oprogramowania lub usług serwera. Wtedy z jednego urządzenia może korzystać kilku pracowników (np. praca zmianowa na stanowisku produkcyjnym), ale oprogramowanie jest licencjonowane „na maszynę”.
Licencjonowanie per user jest korzystne, gdy jeden pracownik używa kilku urządzeń, a per device – gdy wiele osób korzysta z jednego, wspólnego urządzenia (kasa fiskalna, stanowisko w magazynie, komputer na hali). Łatwo tutaj popełnić błąd, wybierając model „na czuja”, bez policzenia konkretnych scenariuszy.
Posiadanie nośnika a prawo do używania
Posiadanie instalatora, obrazu ISO, klucza produktu czy nawet faktury za sprzęt OEM nie oznacza automatycznie legalnego prawa do używania oprogramowania w dowolnym scenariuszu. Liczy się treść licencji i umowy (EULA, Product Terms, warunki programu licencyjnego). Kilka istotnych różnic:
nośnik / instalator – to tylko medium techniczne,
klucz produktu – to narzędzie techniczne do aktywacji, nie dowód prawa do używania,
prawo do używania – wynika z konkretnej licencji (OEM, BOX, Volume, CSP itp.) i jej warunków.
Na przykład: posiadanie obrazu ISO Windows Server 2022 nie daje prawa do zainstalowania go na dowolnej liczbie serwerów. Każde uruchomione środowisko (fizyczne lub wirtualne) musi mieć przypisaną odpowiednią licencję serwerową. Do tego dochodzą licencje CAL dla użytkowników lub urządzeń korzystających z usług.
OEM, BOX, Volume, CSP – wpływ na elastyczność
Typ licencji ma duże znaczenie dla elastyczności i zarządzania kosztami:
OEM – licencja przypisana na stałe do sprzętu, z którym została sprzedana. Zwykle tańsza, ale ograniczona: nie można przenosić na inny serwer, nie ma praw do wirtualizacji lub są one mocno ograniczone. Z punktu widzenia środowisk wirtualnych i klastrów to często kiepski wybór na dłuższą metę.
BOX (retail) – licencje w pudełku dla pojedynczych stanowisk lub serwerów. Bywa elastyczniejsza od OEM, można przenosić między urządzeniami, ale skala zarządzania w większej organizacji jest uciążliwa.
Volume Licensing – licencje zbiorcze, bardziej elastyczne w zakresie przenoszenia między serwerami, z możliwością śledzenia i dokumentowania licencji w jednym portalu. Często łączone z Software Assurance, co wprowadza prawa do nowych wersji, wirtualizacji i przeklasyfikowywania licencji.
CSP / licencje chmurowe – subskrypcje rozliczane miesięcznie lub rocznie, często w połączeniu z usługami w chmurze. Dają dużą elastyczność skalowania (dostawanie i oddawanie licencji), ale wymagają pilnowania liczby aktywnych użytkowników i usług.
Przy licencjonowaniu per core, per user i CAL typ programu licencyjnego wpływa na to, czy da się licencje przenosić między hostami, jak często, w jaki sposób wolno licencjonować środowiska wirtualne i czy można korzystać z uprawnień hybrydowych (np. lokalny serwer plus usługa w chmurze w ramach jednej licencji).
Źródło: Pexels | Autor: Markus Spiske
Licencje per core – logika, zasady, pułapki
Na czym polega licencjonowanie per core
Model licencjonowania per core polega na tym, że płaci się za moc obliczeniową serwera (fizycznego lub wirtualnego), a nie za liczbę użytkowników czy urządzeń. Jest to typowe dla nowoczesnych edycji serwerów baz danych (np. SQL Server), systemów operacyjnych serwerowych (np. Windows Server) oraz części innych produktów serwerowych.
Ogólna logika jest następująca:
producent definiuje jednostkę licencyjną – np. „pakiet 2 rdzeni”,
należy policzyć wszystkie rdzenie procesora w serwerze fizycznym lub przypisane do konkretnej maszyny wirtualnej,
istnieje minimalna liczba rdzeni, którą trzeba licencjonować na serwer (np. minimum 16 rdzeni na serwer, minimum 8 rdzeni na procesor), nawet jeśli fizycznie jest ich mniej,
czasem licencjonowanie per core eliminuje konieczność kupowania osobnych CAL-i, ale tylko dla wybranych produktów (np. SQL Server Enterprise per core).
Taki model dobrze skaluje się w dużych środowiskach, gdzie liczba użytkowników jest zmienna lub bardzo duża, a dostęp odbywa się przez wiele aplikacji pośrednich. Trudno wtedy zliczyć wszystkich użytkowników końcowych, ale dość łatwo policzyć liczbę rdzeni przypisanych do obsługi danego systemu.
Przykładowe zasady na typowym serwerze
Na konkretnym przykładzie fizycznego serwera z dwoma procesorami po 10 rdzeni każdy:
łącznie serwer ma 20 fizycznych rdzeni,
producent wymaga licencjonowania wszystkich rdzeni w serwerze,
licencje sprzedawane są w pakietach po 2 rdzenie,
często jest minimalne wymaganie 16 rdzeni na serwer, ale ponieważ serwer ma 20 rdzeni, trzeba licencjonować 20.
Oznacza to konieczność zakupu 10 pakietów po 2 rdzenie. Jeżeli później dołożysz kolejne procesory lub wymienisz serwer na mocniejszy z większą liczbą rdzeni, model per core wymaga dokupienia licencji odpowiadających nowym rdzeniom. I tutaj często powstają ukryte koszty: sprzęt staniał, ale oprogramowanie per core podbiło całkowity koszt projektu.
Licencjonowanie hosta a maszyn wirtualnych
W modelu per core szczególnie istotne jest rozróżnienie między licencjonowaniem hosta fizycznego a środowiskami wirtualnymi (VM). W uproszczeniu są dwa najczęstsze podejścia:
licencjonowanie całego hosta fizycznego – płacisz za wszystkie rdzenie fizyczne i zyskujesz prawo do uruchomienia określonej liczby maszyn wirtualnych, czasem nieograniczonej (w wyższych edycjach),
licencjonowanie konkretnych VM‑ek – płacisz za rdzenie przypisane do maszyny wirtualnej, niezależnie od mocy całego hosta.
W praktyce organizacje o stabilnym, przewidywalnym środowisku (dużo stałych VM na tych samych hostach) często wychodzą taniej, licencjonując całe hosty, zwłaszcza przy wyższych edycjach z prawem do nieograniczonej liczby VM. Z kolei tam, gdzie środowisko jest małe, ale mocne hosty są współdzielone (np. z innymi działami, projektami) – bezpieczniej i często taniej bywa licencjonowanie pojedynczych VM.
Kluczowy szczegół: przy licencjonowaniu per core w wirtualizacji baza wyliczeń to zawsze rdzenie logiczne przydzielone do danej warstwy – fizyczne rdzenie hosta albo wirtualne vCPU VM‑ki (przy czym produkt może nakazywać licencjonowanie co najmniej tylu rdzeni, ile ma host, nawet jeśli VM faktycznie ma mniej vCPU).
Dynamiczne przenoszenie VM a przenoszenie licencji
Mechanizmy typu vMotion, Live Migration czy inne formy HA kuszą do częstego przerzucania maszyn wirtualnych między hostami. Z licencjami jest gorzej – nie każda licencja może “skakać” tak swobodnie. Typowe ograniczenia:
część licencji on‑premise można przenosić między serwerami co 90 dni lub rzadziej,
w licencjach subskrypcyjnych i chmurowych często jest większa elastyczność, ale nadal pod kontrolą warunków programu (np. przypisanie do konkretnego tenant/hostingu),
w niektórych scenariuszach prawo do dynamicznego przenoszenia VM bez ponownego licencjonowania wymaga dodatkowego składnika (np. Software Assurance lub odpowiednika).
Jeżeli klaster jest mocno “ruchliwy”, trzeba zdecydować: albo licencjonujesz wszystkie hosty w klastrze (droższe, ale spokojniejsze administracyjnie), albo ograniczasz reguły przenoszenia VM (np. tylko między wybranymi hostami), co obniża koszt licencji, ale wymaga większej dyscypliny konfiguracji.
Pułapki licencjonowania per core w praktyce
W modelu per core najwięcej kłopotów powodują sytuacje przejściowe: wymiana sprzętu, migracja do chmury, rozbudowa klastrów, testowe środowiska “na chwilę”. Typowe pułapki:
modernizacja serwera bez przeliczenia licencji – nowy host ma więcej rdzeni, a licencji nie doskalowano; przy audycie wychodzi niedolicencjonowanie, choć “tylko wymieniliśmy serwer na mocniejszy”,
zbyt agresywne oversizingowanie – platforma wirtualna ma 2–3 razy więcej rdzeni niż realnie potrzeba, bo „takie były w promocji” albo „może urosnąć”, ale per core płaci się od pierwszego dnia za całą moc,
pomylenie rdzeni z wątkami – przy włączonym Hyper‑Threadingu administrator wpisuje do arkusza licencyjnego liczbę wątków zamiast rdzeni fizycznych i kupuje za dużo (albo błędnie raportuje do audytu),
środowiska testowe i deweloperskie – VM “tylko na chwilę” żyją miesiącami, a licencje serwerowe per core nie są przewidziane w budżecie; nierzadko taniej użyć dedykowanych licencji deweloperskich lub subskrypcji dev/test niż pełnych produkcyjnych licencji per core.
Z perspektywy kosztów bezpieczniej jest lekko przewymiarować licencje niż sprzęt – serwer możesz jeszcze dociążyć innymi usługami, licencji per core nie “pożyczysz” z kolejnego kwartału bez dopłaty.
Licencjonowanie per core w chmurze
W publicznej chmurze (Azure, AWS, GCP) model per core pojawia się w dwóch postaciach:
licencje wliczone w cenę maszyny (np. VM z preinstalowanym systemem / bazą),
scenariusze BYOL (Bring Your Own License), gdzie przenosisz własne licencje per core on‑premise do chmury, jeśli umowa to dopuszcza.
Przy licencjach wliczonych w cenę płacisz “per godzinę” czy “per sekundę” za rdzenie danej maszyny. To wygodne przy krótkotrwałych projektach lub środowiskach o zmiennym obciążeniu – nie zamrażasz budżetu w licencjach, które leżą nieużywane poza godzinami szczytu.
Scenariusze BYOL zwykle mają sens przy stałych, dużych obciążeniach: dłużej działające VM w chmurze mogą wykorzystać już kupione licencje per core, o ile produkt i program licencyjny przewiduje takie przeniesienie (np. uprawnienia hybrydowe). Tutaj trzeba bardzo uważać na liczenie “dwóch światów”: rdzenie w on‑premise i rdzenie w chmurze nie mogą korzystać z tej samej licencji w tym samym czasie, chyba że wprost na to pozwala warunek licencyjny.
Licencje per user / per device – kiedy użytkownik jest „tańszy” niż procesor
Logika licencjonowania per user
W modelu per user licencja jest przypisana do człowieka. Najczęściej daje mu to prawo do korzystania z określonego zestawu usług lub produktów na wielu urządzeniach – laptop, PC, telefon, tablet, VDI.
Taki model jest szczególnie sensowny, gdy:
pracownicy korzystają z kilku urządzeń równolegle (biuro, dom, praca w terenie),
stawia się na elastyczne formy pracy: home office, hot‑desking, BYOD,
dominującym kosztem jest “obsługa użytkownika” (poczta, pliki, Teams/komunikatory, aplikacje SaaS), a nie ciężkie procesy serwerowe.
Zwykle w licencjach per user producent precyzuje, ile “instancji klienta” może jednocześnie używać licencjonowany użytkownik. Jest to istotne przy pakietach biurowych, klientach pocztowych, aplikacjach desktopowych dostarczanych w modelu subskrypcyjnym. W środowiskach VDI/Remote Desktop trzeba sprawdzić, czy licencja per user faktycznie obejmuje również dostęp z sesji zdalnej, czy wymaga dodatkowych licencji (jak osobne CAL‑e RDS).
Licencjonowanie per device – kiedy opłaca się „płacić za komputer”
Model per device (czasem nazywany per urządzenie, per stanowisko) sprawdza się w miejscach, gdzie wiele osób korzysta z jednego komputera lub terminala:
stanowiska produkcyjne na halach,
komputery w magazynie, kasach, recepcjach,
infokioski, terminale w przychodniach, bibliotekach.
Jeżeli na jednym komputerze w trakcie dnia loguje się kilku pracowników w różnych zmianach, płacenie za pojedynczą licencję per device jest często znacząco tańsze niż kupowanie licencji per user dla każdej osoby. To szczególnie widoczne przy dużej rotacji pracowników (sezonowość), gdzie utrzymywanie listy “aktywowanych użytkowników” byłoby logistycznie droższe niż przypisanie licencji do jednego, stałego urządzenia.
Mieszane środowiska: per user i per device razem
W praktyce mało która organizacja trzyma się jednego modelu. Zwykle istnieje mikstura licencji per user i per device, dobrana do stanowisk. Przykładowo:
dla pracowników biurowych, działu IT, menedżerów – licencje per user,
dla magazynierów, pracowników produkcji, stanowisk obsługi klienta – licencje per device na wspólne terminale.
Pod kątem budżetu sprawdza się prosty zabieg: zamiast kupować “z rozpędu” licencje per user dla całego działu, osobno przeanalizować stanowiska wspólne. Nierzadko przełączenie kilkunastu maszyn z licencjonowania per user na per device redukuje koszt roczny o kilkanaście–kilkadziesiąt procent, bez zmiany funkcjonalności dla użytkowników.
Ryzyka przy licencjonowaniu per user / per device
Najczęstsze problemy wynikają z braku aktualnej listy przypisania licencji. Przykładowe sytuacje:
pracownik odchodzi z firmy, licencja nie zostaje formalnie “odzyskana” i od lat widnieje jako zajęta na nieistniejącym koncie,
komputer jest wycofywany z użytku, a licencja per device w systemie producenta nadal przypisana jest do tego urządzenia,
zastąpiono urządzenia cienkiego klienta nowymi terminalami, ale licencje per device nie przepisano na nowe identyfikatory sprzętowe.
Efekt: płacisz za licencje, które niczego już nie chronią. Prosta, kwartalna inwentaryzacja kont użytkowników i urządzeń (połączona z arkuszem licencyjnym) rozwiązuje większość tych problemów bez drogiego software asset management.
Źródło: Pexels | Autor: hitesh choudhary
Czym są i jak działają licencje CAL
CAL użytkownika i CAL urządzenia – dwa smaki tego samego problemu
CAL (Client Access License) to licencja dostępu do usług serwera, a nie prawo do instalacji oprogramowania. W wielu produktach serwerowych występują dwie odmiany:
User CAL – przypisany do konkretnego użytkownika, umożliwia mu dostęp z wielu urządzeń,
Device CAL – przypisany do urządzenia, z którego może korzystać wiele osób.
Logika opłacalności jest identyczna jak przy modelach per user / per device: jeśli jeden człowiek korzysta z wielu urządzeń, CAL per użytkownik zwykle wychodzi taniej; jeśli wiele osób korzysta z jednego wspólnego stanowiska, CAL per urządzenie jest korzystniejszy.
CAL‑e dotyczą dostępu, co oznacza, że nawet gdy użytkownik czy aplikacja łączy się z serwerem “pośrednio” (np. aplikacja biznesowa używa bazy danych na serwerze), nadal może być wymagany CAL do tego serwera, chyba że produkt oferuje alternatywny model licencjonowania (np. per core bez CAL–i).
CAL standardowy a specjalistyczne dodatki
Niektóre produkty serwerowe oprócz bazowego CAL‑a mają dodatkowe licencje dostępowe dla specyficznych funkcji. Przykłady:
CAL systemu serwerowego + dodatkowe CAL‑e do usług zdalnego pulpitu (RDS),
CAL pocztowy + ewentualne licencje na funkcje archiwizacji, compliance, zaawansowaną ochronę itp. sprzedawane osobno.
W arkuszu kosztowym dobrze te elementy rozdzielić. Bazowe CAL‑e często są stosunkowo tanie, ale dodatkowe “dopalacze” dla każdej osoby mogą pomnożyć budżet. Przy wdrażaniu funkcji premium (np. rozszerzona ochrona poczty tylko dla zarządu) nie trzeba kupować tych dodatków dla wszystkich – można ograniczyć je do grupy najbardziej narażonych użytkowników.
Scenariusze, w których CAL nie jest wymagany
Część produktów i edycji oferuje model, w którym licencja per core zastępuje konieczność kupowania CAL‑i. Typowe przykłady:
wyższe edycje serwerów baz danych licencjonowanych per core – dostęp z dowolnej liczby użytkowników / urządzeń,
niektóre usługi udostępniane wyłącznie przez protokoły publiczne (np. HTTP/HTTPS dla anonimowych klientów), gdzie producent wyraźnie stwierdza, że klienci zewnętrzni nie wymagają CAL.
To często klucz do optymalizacji kosztów: przy dużej liczbie nieprzewidywalnych użytkowników (np. partnerzy, klienci zewnętrzni, integracje B2B) podejście “licencja per core bez CAL‑i” bywa znacznie łatwiejsze do ogarnięcia niż śledzenie, kto dokładnie ma dostęp i czy ma przypisany odpowiedni CAL.
Najczęstsze błędy w licencjonowaniu CAL
Problemy z CAL‑ami wynikają zwykle z braku świadomości, że są potrzebne. Kilka typowych pomyłek:
założenie, że licencja serwerowa “załatwia wszystko” – zakup samego systemu serwerowego bez CAL‑i dla użytkowników łączących się z domeną, udziałami sieciowymi czy drukarkami udostępnionymi z serwera,
traktowanie użytkowników zewnętrznych jak “gości”, mimo że mają pełnoprawne konta w domenie lub aplikacji wewnętrznej – często wtedy również wymagają CAL,
ignorowanie pośredniego dostępu – aplikacja korzysta z bazy danych na serwerze, ale zespół zakłada, że skoro użytkownik nie loguje się “bezpośrednio”, to CAL nie jest potrzebny (co bywa niezgodne z warunkami licencji).
Dla małych i średnich środowisk pomaga prosty arkusz: lista serwerów, przy każdym informacja, czy wymaga CAL, jaki typ (user/device) oraz szacowana liczba użytkowników / urządzeń. Bez wielkich narzędzi SAM można wtedy szybko sprawdzić, czy liczby się spinają.
Zestawienie: per core vs CAL vs per user – różnice praktyczne
Perspektywa kosztowa i elastyczność
Wybór modelu licencjonowania to zawsze balans między elastycznością a przewidywalnością kosztów.
Per core – koszt rośnie wraz z mocą sprzętu, a nie liczbą użytkowników. Opłacalne przy dużej i trudnej do policzenia populacji użytkowników, ale wrażliwe na rozbudowę hostów.
Per user / per device / CAL – jak przekłada się to na budżet
W licencjach przypisanych do ludzi lub urządzeń kluczowa jest przewidywalność. Wiesz, że masz 120 pracowników biurowych i 30 terminali wspólnych – po kilku prostych rachunkach znasz koszt roczny, niezależnie od tego, czy serwer stoi na fizyku, czy w chmurze i czy ma 8, czy 64 core’y.
Per user – koszt ściśle rośnie z liczbą osób, co jest intuicyjne dla działu HR i finansów. Łatwo planować budżet przy stabilnym zatrudnieniu i przewidywalnym przyroście.
Per device / Device CAL – wygodne tam, gdzie stanowisk jest mniej niż ludzi. Daje sporą oszczędność przy pracy zmianowej i rotacji pracowników sezonowych.
User CAL – rozsądny kompromis, gdy użytkownicy korzystają z wielu serwerów tego samego producenta; jedna licencja użytkownika “otwiera drzwi” do kilku usług.
Przy licencjach dostępowych nie da się całkowicie uciec od arkusza kalkulacyjnego. Minimum sensownej kontroli to tabela: użytkownik / urządzenie → do jakich serwerów ma prawo. Na początek wystarczy prosty plik w SharePoint czy na dysku sieciowym, aktualizowany przy onboardingu i offboardingu.
Ryzyko „niewidzialnego wzrostu” kosztów
Modele per user i CAL są wrażliwe na to, jak szybko rośnie organizacja. Wzrost o kilka osób w kwartale jest łatwy do ogarnięcia, ale szybkie skalowanie zespołów sprzedaży, call center czy działów sezonowych potrafi zrobić dziurę w budżecie, jeśli licencje dokupuje się ad hoc i bez kontroli.
Przydatnym podejściem jest wyznaczenie progu, po przekroczeniu którego robi się przegląd modelu licencjonowania. Przykład: co 50 nowych kont użytkowników dział IT razem z finansami przelicza, czy nadal się opłaca per user + CAL, czy nie jest tańszy wariant per core dla części systemów (np. bazy danych, serwisy API używane przez wielu partnerów). Taki “bezpiecznik” kosztowy zmniejsza ryzyko, że po dwóch latach odkryjesz trzycyfrową liczbę CAL‑i kupionych trochę “przy okazji”.
Per core zamiast CAL – kiedy ma to sens biznesowy
Licencje per core, które eliminują konieczność kupowania CAL‑i, opłacają się szczególnie w dwóch sytuacjach:
duża, zmienna liczba użytkowników (zewnętrzni partnerzy, klienci, integracje B2B/B2C),
brak realnej możliwości policzenia i zarządzania dostępami na poziomie osób/urządzeń.
Jeżeli system jest wystawiony na świat i korzysta z niego “kto wejdzie” (portal klienta, bramka integracyjna, system zgłoszeniowy), czas poświęcony na pilnowanie, kto dokładnie powinien mieć CAL, bywa zwyczajnie droższy niż dopłata do edycji per core. Często też wymagałoby to zbyt ścisłej kontroli biznesu, której nikt nie będzie utrzymywał w praktyce.
Warto porównać dwa warianty: “tańsza” edycja serwera z CAL‑ami vs droższa per core bez CAL‑i. W wielu przypadkach różnica w cenie serwera zwróci się przy kilkudziesięciu–kilkuset użytkownikach, zwłaszcza jeśli planowany jest dalszy wzrost i integracje z zewnętrznymi systemami.
Modele mieszane – jak nie zgubić się w kombinacjach
Większość producentów dopuszcza stosowanie różnych modeli równolegle, o ile w ramach jednego “kontekstu” zachowana jest spójność. Typowe kombinacje:
serwer bazy danych – licencjonowany per core bez CAL,
warstwa aplikacyjna – serwery z licencją serwerową + CAL‑e użytkowników,
system pocztowy – licencje per user w subskrypcji,
stanowiska wspólne (kioski, produkcja) – osobne Device CAL‑e lub licencje per device do wybranych usług.
Przy podejściu mieszanym krytyczne jest ustalenie prostych zasad, żeby nie mnożyć wyjątków. Przykładowo: “użytkownicy biurowi zawsze per user, tylko magazyn i produkcja per device”; “serwery frontowe zawsze per core, serwery zaplecza na CAL‑ach, dopóki liczba użytkowników nie przekroczy X”. Dzięki temu nowy administrator albo podwykonawca nie musi za każdym razem zgadywać, jak licencjonować kolejny serwer.
Źródło: Pexels | Autor: Markus Spiske
Jak policzyć licencje w typowych scenariuszach infrastruktury
Scenariusz 1: Klasyczna domena, serwer plików i drukarek
Środowisko bardzo częste w małych i średnich firmach:
jeden lub kilka kontrolerów domeny,
serwer plików,
serwer wydruku,
ok. 80–150 pracowników biurowych.
Najprostszy i zwykle najtańszy wariant to licencjonowanie dostępu do tych usług za pomocą User CAL dla każdego pracownika, który:
loguje się do domeny,
korzysta z udziałów sieciowych,
drukuje przez serwer wydruku.
Jeśli występują stanowiska wspólne (np. recepcja czynna w kilku zmianach), można zamienić część User CAL‑i na Device CAL‑e, ale tylko tam, gdzie rotacja użytkowników jest rzeczywiście wysoka, a liczba stanowisk stała. W praktyce często kończy się na modelu, gdzie zdecydowana większość to User CAL‑e, a pojedyncze Device CAL‑e dotyczą magazynu, recepcji czy produkcji.
Do policzenia licencji wystarczy lista kont z AD przefiltrowana o konta techniczne oraz tabelka, która pokazuje, ile z nich należy do “realnych” ludzi korzystających z usług domeny. Na start wystarczy eksport do CSV + proste filtrowanie po OU lub grupach.
Scenariusz 2: Serwer aplikacyjny + baza danych
Tu pojawia się pytanie, czy licencjonować bazę danych per core, czy per CAL. Dwa główne warianty:
Baza danych na CAL‑ach – kupujesz licencję serwerową bazy danych + CAL‑e (user/device) dla wszystkich, którzy korzystają z aplikacji, nawet jeśli łączą się pośrednio. Ten model ma sens, gdy:
liczba użytkowników aplikacji jest stosunkowo mała i przewidywalna,
brak integracji z dużą liczbą partnerów zewnętrznych,
to głównie użytkownicy wewnętrzni, łatwi do policzenia.
Baza danych per core – płacisz za moc serwera bazodanowego (liczbę rdzeni fizycznych/logicznych zgodnie z zasadami producenta) i nie martwisz się CAL‑ami. Ta opcja zwykle jest droższa “na wejściu”, ale skaluje się lepiej, gdy:
aplikacja jest udostępniana klientom, partnerom, kontrahentom,
planowane jest otwarcie API lub szybki wzrost liczby użytkowników,
organizacja nie ma czasu na rygorystyczne liczenie wszystkich pośrednich dostępów.
Przy wyborze warto policzyć dwa scenariusze dla horyzontu 3–5 lat, nawet bardzo zgrubnie: ile osób będzie mieć dostęp do aplikacji oraz ile rdzeni realnie potrzebuje serwer bazy danych (z marginesem na wzrost). Do takiego porównania często wystarczy konsultacja z dostawcą aplikacji + krótkie pomiary obciążenia na środowisku testowym lub pilotażowym.
Scenariusz 3: Remote Desktop / VDI
Środowiska RDS/VDI są podatne na błędy licencyjne, bo łączą kilka warstw:
system serwerowy,
CAL‑e do systemu serwerowego,
CAL‑e lub subskrypcje RDS/VDI,
licencje na aplikacje działające w sesji (pakiet biurowy, klient poczty, aplikacje specjalistyczne).
Typowa i relatywnie ekonomiczna kombinacja dla firm, które korzystają z RDS w ograniczonym zakresie:
User CAL do systemu serwerowego dla pracowników, którzy korzystają z RDS,
User CAL RDS (albo licencja subskrypcyjna per user na dostęp RDS) dla tych samych osób,
licencje per user na pakiet biurowy, jeżeli użytkownicy pracują z aplikacjami zarówno lokalnie, jak i w sesji zdalnej.
Jeśli stanowi się osobną pulę stanowisk “terminalowych” na halach czy w punktach obsługi, często korzystniej jest wybrać Device CAL RDS + Device CAL do systemu serwerowego dla każdego terminala, zamiast przypisywać licencje per user wszystkim pracującym zmianowo osobom.
W RDS szczególnie ważne jest, aby jedna osoba nie “zjadała” dwóch niezależnych zestawów licencji (np. osobno per device lokalnie i per user w sesji), jeśli da się to ujednolicić. Taki przegląd konfiguracji co rok zwykle pokazuje kilka prostych oszczędności bez żadnych zmian technicznych.
Scenariusz 4: Hybryda – część usług on‑prem, część w chmurze
Coraz częściej poczta, komunikacja i część usług katalogowych przenoszona jest do chmury, podczas gdy aplikacje biznesowe i baza danych zostają on‑prem. Daje to ciekawą mieszankę modeli:
subskrypcje per user dla usług chmurowych (poczta, współdzielenie plików, komunikator),
CAL‑e do serwerów lokalnych,
czasem licencje per core dla baz danych lub serwerów API.
Dla administratora ważne jest, aby nie “dublować” licencji. Przykład: jeżeli przeniesiono wszystkie skrzynki pocztowe do chmury i serwer pocztowy on‑prem służy już tylko jako przekaźnik lub archiwum techniczne, często można ograniczyć liczbę licencji lub obniżyć edycję. Podobnie przy magazynach plików – jeśli większość folderów użytkowników trafia do chmury, a na serwerze zostają tylko zasoby aplikacyjne, liczba potrzebnych CAL‑i może istotnie spaść.
Na początek wystarczy jedna tabela zbierająca użytkownika i wszystkie typy licencji, które są mu przypisane (on‑prem + chmura). Po jej uzupełnieniu zwykle dość szybko widać, gdzie organizacja płaci “podwójnie” za podobną funkcjonalność.
Scenariusz 5: Dostęp partnerów i klientów zewnętrznych
Systemy udostępniane partnerom, resellerom czy klientom końcowym to typowe miejsce, gdzie modele CAL zaczynają być problematyczne. Z punktu widzenia administracji:
liczba kont rośnie i maleje dynamicznie,
część użytkowników jest nieaktywna przez długi czas, ale kont nie usuwa się ze względu na historię danych,
trudno wytłumaczyć biznesowi, że “każdy partner to kolejny koszt CAL”.
Dlatego w tych scenariuszach zwykle lepiej działa podejście:
rdzeniowe systemy (baza danych, serwery API, bramki integracyjne) – licencjonowane per core,
narzędzia wewnętrzne (dostęp administracyjny, raportowanie, systemy back‑office) – na CAL‑ach lub per user.
Jeżeli warunki licencyjne producenta dopuszczają specjalne typy licencji dla użytkowników zewnętrznych (np. “External Connector”, licencje na portal kliencki), zwykle wychodzi to taniej niż próba licencjonowania każdego partnera osobno. To dobry przykład miejsca, gdzie warto raz na jakiś czas porozmawiać z partnerem handlowym producenta – ogólne zasady są stałe, ale dostępne pakiety i programy licencyjne potrafią się zmieniać co kilka lat.
Praktyczny workflow liczenia licencji dla administratora
Żeby nie utknąć w wielomiesięcznym projekcie, da się wprowadzić prosty, powtarzalny schemat, który w średniej organizacji zamyka się w kilku dniach roboczych:
Inwentaryzacja serwerów i usług – z CMDB, VMware/Hyper‑V, chmury lub zwykłej listy w arkuszu:
nazwa serwera / usługi,
producent i produkt,
czy wymaga CAL, czy jest per core/per server,
czy użytkownicy są głównie wewnętrzni, czy zewnętrzni.
Mapowanie użytkowników/urządzeń do usług – na bazie grup w AD, list systemowych lub po prostu konsultacji z właścicielami aplikacji:
kto realnie korzysta z danej aplikacji/serwera,
czy korzysta z jednego, czy z kilku serwerów tego samego typu.
Wybór modelu per user vs per device vs per core dla każdego produktu:
tam, gdzie przeważają użytkownicy biurowi na wielu urządzeniach – per user / User CAL,
tam, gdzie mamy mało stanowisk wspólnych – Device CAL / per device,
tam, gdzie trudno policzyć użytkowników – per core.
Policzenie braków i nadwyżek – porównanie stanu “powinno być” z tym, co jest w portalach licencyjnych i umowach. Najpierw wyłapać oczywiste nadwyżki (ex‑pracownicy, wycofane serwery), dopiero potem braki.
Proste reguły na przyszłość – kilka linijek w polityce IT:
jak licencjonujemy nowe serwery danego typu,
jak licencjonujemy nowe stanowiska i użytkowników,
kiedy robimy przegląd modelu (np. po przekroczeniu określonej liczby użytkowników).
Najważniejsze punkty
Nieznajomość modeli licencjonowania to realne ryzyko finansowe – błędne liczenie rdzeni, brak odpowiednich CAL-i czy źle dobrany model subskrypcji potrafią wygenerować koszty, które zjadają roczny budżet IT, a część odpowiedzialności spada bezpośrednio na administratora lub kierownika IT.
Środowisko może działać technicznie bez zarzutu, a jednocześnie być poważnie niezgodne licencyjnie – audyt nie weryfikuje, czy serwer odpowiada, tylko czy każdy sposób użycia jest pokryty właściwą licencją i poprawnie przypisany.
Dziedziczone, chaotycznie rozbudowywane środowiska (brak dokumentacji licencji, zakupy ad hoc) są klasycznym źródłem „licencyjnych min”; bez uporządkowania stanu posiadania i zasad przypisania licencji trudno cokolwiek sensownie planować.
Brak przemyślanego modelu licencjonowania przy wdrożeniach (ERP, poczta, wirtualizacja, klastry HA, chmura) skutkuje dokładaniem kolejnych licencji „jak wyjdzie”, co zwykle oznacza przepłacanie przez lata zamiast jednorazowego, spokojnego przeliczenia per core vs per user vs CAL.
Środowiska hybrydowe (on‑prem + chmura) łatwo prowadzą do podwójnego płacenia za te same funkcje lub do luk w uprawnieniach; konieczne jest chłodne, techniczno-finansowe policzenie, które licencje mają być „w chmurze”, a które lokalnie.
Bibliografia i źródła
Product Terms. Microsoft – Oficjalne zasady licencjonowania produktów Microsoft, w tym per core, CAL, subskrypcje
Microsoft Volume Licensing Reference Guide. Microsoft – Przegląd modeli licencjonowania Microsoft, definicje licencji serwerowych i dostępowych
Oracle Licensing Guide for Server and Cloud Environments. Oracle – Modele licencjonowania procesorowe i użytkownikowe w środowiskach serwerowych
IBM Passport Advantage and Passport Advantage Express Licensing Guide. IBM – Zasady licencjonowania IBM, PVU, użytkownicy uprawnieni, środowiska wirtualne
ISO/IEC 19770-1:2017 Information technology — IT asset management. ISO (2017) – Norma zarządzania zasobami IT, w tym kontrola zgodności licencyjnej
ITIL Foundation: ITIL 4 Edition. AXELOS (2019) – Rola zarządzania aktywami i licencjami w procesach IT i odpowiedzialność działu IT
Software Asset Management: A Best Practice Guide. BCS, The Chartered Institute for IT (2012) – Praktyki SAM, ryzyka finansowe i audyty licencyjne w organizacjach
