Licencjonowanie Windows Server: jak poprawnie obliczyć licencje na rdzenie (Core) i CAL?

Od czego zacząć obliczenia: dwa niezależne elementy licencjonowania

Licencje na rdzenie a licencje dostępowe CAL

Licencjonowanie Windows Server składa się zwykle z dwóch odrębnych warstw: licencji serwerowych na rdzenie fizyczne oraz licencji dostępowych CAL. Najczęstszy błąd polega na założeniu, że zakup licencji Windows Server Core załatwia całość. Nie załatwia. Licencje Core dają prawo do uruchamiania systemu Windows Server na odpowiednio licencjonowanym sprzęcie lub w środowisku wirtualnym, natomiast CAL dotyczą osób albo urządzeń korzystających z usług tego serwera.

W praktyce trzeba odpowiedzieć na dwa różne pytania. Pierwsze brzmi: ile fizycznych rdzeni ma serwer, na którym będzie działał Windows Server? Drugie: ilu użytkowników lub ile urządzeń będzie uzyskiwać dostęp do usług udostępnianych przez ten serwer? Wynik pierwszego obliczenia określa pulę licencji Core. Wynik drugiego wskazuje liczbę licencji Windows Server CAL, a czasem również dodatkowych licencji, takich jak RDS CAL.

Windows Server CAL nie jest licencją na sam system operacyjny ani licencją na zdalny pulpit. To licencja dostępowa, która co do zasady uprawnia użytkownika lub urządzenie do korzystania z usług Windows Server. Może chodzić o dostęp do udziałów plikowych, drukarek, Active Directory, usług uwierzytelniania, serwera aplikacji, zasobów sieciowych lub innych funkcji systemu. Osoba, która nigdy nie widzi pulpitu serwera, nadal może wymagać CAL, jeśli korzysta z jego usług.

Osobną kategorią są RDS CAL, potrzebne przy dostępie do usług pulpitu zdalnego, gdy użytkownicy lub urządzenia korzystają z sesji Remote Desktop Services. Zakup zwykłej Windows Server CAL nie zastępuje RDS CAL. Analogicznie, RDS CAL nie zastępuje bazowej Windows Server CAL. Te licencje pełnią inne funkcje, dlatego ich mieszanie często kończy się błędnym arkuszem i nieprzyjemną niespodzianką przy weryfikacji dokumentacji.

Przykład: firma poprawnie licencjonuje serwer z 16 rdzeniami, instalując Windows Server Standard. Na serwerze działają udział plikowy i Active Directory, z których korzysta 25 pracowników. Sama licencja Core nie oznacza jeszcze, że 25 osób ma prawo do dostępu. Trzeba dodatkowo zapewnić odpowiednią liczbę Windows Server User CAL albo Device CAL, zależnie od wybranego modelu.

Dane potrzebne przed wyborem pakietów

Licencjonowanie Windows Server warto rozpocząć od inwentaryzacji, a nie od porównywania cen pakietów 2-Core i 16-Core. Tani pakiet kupiony przed policzeniem wymagań potrafi być droższą decyzją niż właściwie przygotowany zakup. Szczególnie gdy po kilku miesiącach okazuje się, że host ma obsługiwać więcej maszyn wirtualnych niż zakładano. ^[2]

Do rzetelnej kalkulacji potrzebne są co najmniej następujące dane:

• liczba serwerów fizycznych, na których Windows Server może być uruchamiany,
• liczba fizycznych procesorów w każdym serwerze,
• liczba fizycznych rdzeni w każdym procesorze,
• wybrana edycja: Windows Server Standard lub Windows Server Datacenter,
• liczba planowanych maszyn wirtualnych Windows Server na każdym hoście,
• informacja, czy host realizuje wyłącznie funkcję wirtualizatora, czy także inne role,
• topologia klastra, mechanizmy failover i możliwe migracje maszyn wirtualnych,
• liczba użytkowników, liczba urządzeń oraz sposób korzystania z zasobów,
• informacja o dostępie przez Remote Desktop Services,
• typ klientów: pracownicy, współpracownicy, urządzenia współdzielone, partnerzy lub użytkownicy zewnętrzni,
• kanał zakupu i posiadane prawa licencyjne, w tym ewentualne Software Assurance lub inne uprawnienia wynikające z umowy.

Nie należy opierać kalkulacji na starym zestawieniu znalezionym w internecie, opisie aukcji czy zrzucie ekranu sprzed kilku lat. Zasady licencjonowania mogą zależeć od wersji produktu, edycji, daty nabycia oraz programu licencyjnego. Punktem odniesienia powinny być aktualne Microsoft Product Terms, dokumentacja konkretnego kanału licencyjnego oraz warunki dotyczące posiadanych licencji.

Najpierw architektura, potem koszyk zakupowy

Dobry arkusz licencyjny zaczyna się od mapy infrastruktury. Każdy host fizyczny powinien mieć osobny wiersz z liczbą procesorów, rdzeni, planowaną liczbą instancji Windows Server i informacją, czy jest członkiem klastra. Dopiero potem można ocenić, czy Standard będzie wystarczający, czy przy większej liczbie maszyn wirtualnych bardziej logiczna stanie się edycja Datacenter. ^[3]

Druga część arkusza powinna dotyczyć dostępu. Trzeba rozdzielić użytkowników od urządzeń, ponieważ model User CAL i Device CAL daje inne korzyści. Nie wystarczy wpisać „30 pracowników”, jeśli z zasobów korzystają także terminale produkcyjne, urządzenia magazynowe, komputery współdzielone na zmianach albo konta należące do współpracowników zewnętrznych.

Takie przygotowanie eliminuje wiele błędów jeszcze przed zakupem. Licencjonowanie Windows Server jest znacznie łatwiejsze, gdy najpierw opisze się faktyczne użycie środowiska, a nie próbuje dopasować środowisko do przypadkowo kupionej liczby licencji.

Błąd nr 1: liczenie tylko rdzeni „używanych” przez Windows Server

Dlaczego przypisanie kilku vCPU nie zawsze zmniejsza liczbę licencji

W środowisku zwirtualizowanym łatwo pomylić trzy pojęcia: rdzenie fizyczne, wątki logiczne i vCPU. Administrator może utworzyć maszynę wirtualną z 4 vCPU na hoście mającym 24 fizyczne rdzenie, ale nie oznacza to automatycznie, że wystarczy licencjonować tylko 4 rdzenie. W standardowym modelu licencjonowania Windows Server punktem wyjścia jest liczba fizycznych rdzeni serwera, na którym uruchamiane są instancje systemu.

vCPU to zasoby przypisane konkretnej maszynie wirtualnej. Są istotne dla wydajności, planowania pojemności i zarządzania środowiskiem, lecz same w sobie nie określają podstawowej liczby licencji Windows Server Core wymaganych dla hosta. Ograniczenie VM do dwóch lub czterech vCPU może być rozsądne technicznie, ale nie powinno służyć jako skrót myślowy w kalkulacji licencyjnej.

Równie ważne jest odróżnienie rdzeni fizycznych od wątków logicznych. Procesor z 8 rdzeniami fizycznymi i technologią Hyper-Threading może być widoczny w systemie jako 16 procesorów logicznych. Do podstawowego licencjonowania Core liczą się jednak rdzenie fizyczne, nie liczba wpisów w Menedżerze zadań. W przeciwnym razie tabela licencji potrafi szybko zamienić się w sudoku, tylko bez satysfakcji po rozwiązaniu.

Przed dokonaniem zakupu należy potwierdzić parametry sprzętu w wiarygodnym źródle: dokumentacji producenta, konfiguracji serwera, danych BIOS/UEFI lub raporcie narzędzia inwentaryzacyjnego. Przy serwerach po modernizacji szczególnego znaczenia nabiera aktualna konfiguracja, a nie pierwotna specyfikacja z faktury sprzed kilku lat.

Minimalne progi licencjonowania na serwer i procesor

W typowym modelu licencjonowania Windows Server obowiązują minima, które trzeba uwzględnić nawet wtedy, gdy sprzęt ma niewiele rdzeni. Zgodnie z zasadami dla licencji rdzeniowych należy licencjonować co najmniej:

• 8 rdzeni na każdy fizyczny procesor,
• 16 rdzeni na każdy serwer fizyczny.

Oznacza to, że serwer jednoprocesorowy z procesorem 6-rdzeniowym nie jest licencjonowany na 6 rdzeni. Minimum dla całego serwera wynosi 16 rdzeni, więc trzeba pokryć licencjami 16 rdzeni. Podobnie serwer z dwoma procesorami po 6 rdzeni wymaga zastosowania minimum 8 rdzeni na procesor, co również prowadzi do łącznej wartości 16 rdzeni.

Jeżeli serwer ma dwa procesory po 10 rdzeni, obowiązek licencyjny obejmuje 20 rdzeni, ponieważ rzeczywista liczba fizycznych rdzeni jest wyższa niż minima. Z kolei serwer z jednym procesorem 24-rdzeniowym wymaga licencji na 24 rdzenie. Minimalny próg 16 nie ogranicza licencjonowania większej konfiguracji; stanowi jedynie dolną granicę.

Licencje są oferowane w określonych pakietach, na przykład 2-Core lub 16-Core, zależnie od kanału zakupu. Trzeba więc policzyć nie tylko wymaganą liczbę rdzeni, ale również sprawdzić, czy wybrane pakiety rzeczywiście pokrywają całą pulę. Zakup jednego pakietu 16-Core dla serwera z 20 rdzeniami nie wystarczy, nawet jeżeli system technicznie zainstaluje się i będzie działał bez protestu.

Jak policzyć rdzenie poprawnie

Bezpieczny schemat obliczenia wygląda następująco:

1. Ustal liczbę fizycznych procesorów w serwerze.
2. Sprawdź liczbę fizycznych rdzeni w każdym procesorze.
3. Dla każdego procesora zastosuj minimum 8 rdzeni, jeśli procesor ma ich mniej.
4. Zsumuj liczbę rdzeni objętych licencjonowaniem.
5. Jeżeli suma jest niższa niż 16, przyjmij minimum 16 rdzeni na serwer.
6. Zweryfikuj, czy liczba licencji odpowiada edycji i liczbie uruchamianych instancji systemu.
7. Zachowaj dowody konfiguracji oraz dokumenty zakupu i przypisania licencji.

Przykład: serwer ma dwa procesory, każdy po 12 rdzeni fizycznych. Obliczenie jest proste: 12 + 12 = 24. Minimum 8 na procesor nie zmienia wyniku, ponieważ każdy procesor ma więcej niż 8 rdzeni. Minimum 16 na serwer także nie zmienia wyniku, ponieważ serwer ma łącznie 24 rdzenie. Podstawowa pula do licencjonowania wynosi zatem 24 rdzenie. ^[1]

Drugi przykład: serwer ma jeden procesor 4-rdzeniowy. Z perspektywy sprzętowej są cztery rdzenie, jednak zasada minimum 16 rdzeni na serwer powoduje, że wymagane jest pokrycie 16 rdzeni. Taka konfiguracja może być technicznie mała, ale licencyjnie nie korzysta z proporcjonalnie małej liczby licencji.

Dokumentacja sprzętowa jako element zgodności

Przy obliczeniach liczy się nie tylko prawidłowy wynik, lecz także możliwość wykazania, skąd się wziął. Dla każdego hosta dobrze jest przechowywać specyfikację producenta, numer seryjny urządzenia, raport inwentaryzacyjny, informację o liczbie procesorów i rdzeni oraz zestawienie licencji przypisanych do serwera.

Dokumentacja jest szczególnie potrzebna po wymianie procesorów, rozbudowie serwera, migracji do klastra lub zmianie dostawcy obsługi IT. Bez niej następna osoba analizująca środowisko musi odtwarzać historię z fragmentów faktur, nazw maszyn i pamięci osób, które akurat mogą już nie pracować w organizacji.

Błąd nr 2: kupowanie Windows Server Standard bez policzenia praw do wirtualizacji

Co zmienia liczba uruchamianych maszyn wirtualnych

Edycja Windows Server Standard jest często właściwym wyborem dla prostego środowiska z ograniczoną liczbą maszyn wirtualnych. Problem pojawia się wtedy, gdy zakup obejmuje tylko podstawowe pokrycie rdzeni hosta, ale plan zakłada uruchomienie większej liczby instancji Windows Server niż wynika z praw do wirtualizacji.

Po pełnym licencjonowaniu wszystkich fizycznych rdzeni serwera edycja Standard zapewnia prawa do uruchamiania ograniczonej liczby środowisk systemu operacyjnego Windows Server. W powszechnie stosowanym modelu pełne pokrycie rdzeni hosta Standard daje prawo do uruchomienia dwóch środowisk systemu operacyjnego, czyli zwykle dwóch maszyn wirtualnych z Windows Server, pod warunkiem spełnienia odpowiednich zasad użycia. ^[4]

Jeśli na tym samym hoście mają działać cztery maszyny wirtualne Windows Server, nie wystarczy dołożyć licencji tylko dla części rdzeni. Trzeba ponownie licencjonować wszystkie fizyczne rdzenie tego hosta, tworząc drugi pełny zestaw licencji. Każdy kolejny zestaw pełnego pokrycia rdzeni zwiększa liczbę uprawnionych instancji Windows Server zgodnie z warunkami edycji Standard.

Przykład: host ma 16 fizycznych rdzeni. Jeden pełny zestaw Windows Server Standard obejmujący 16 rdzeni może zapewnić prawa do dwóch VM z Windows Server. Dla czterech takich VM potrzebne są dwa pełne zestawy, czyli licencje Standard na łącznie 32 rdzenie przypisane do tego samego hosta. Dla sześciu VM należy rozważyć trzeci zestaw. To nie jest błąd w mnożeniu; to mechanizm nazywany często „stackingiem” licencji Standard.

Rola hosta fizycznego ma znaczenie

Licencjonowanie hosta wymaga także ustalenia, co działa w fizycznym środowisku systemu operacyjnego. Jeżeli host jest wykorzystywany wyłącznie do uruchamiania i zarządzania zwirtualizowanymi środowiskami Windows Server, fizyczna instancja może pełnić funkcje związane z wirtualizacją bez zużywania jednego z praw do uruchomienia instancji przewidzianych dla edycji Standard.

Sytuacja zmienia się, gdy fizyczny host pełni dodatkowe role, na przykład jest równocześnie serwerem plików, kontrolerem domeny, serwerem aplikacji, serwerem wydruku albo obsługuje usługi produkcyjne. Wtedy trzeba przeanalizować, czy nadal można traktować fizyczną instalację wyłącznie jako warstwę wirtualizacyjną. Nie wystarczy nazwać serwer „Hyper-V”, jeśli obok hypervisora realizuje on codzienne usługi dla użytkowników.

W dokumentacji środowiska dobrze wskazać, które role pracują na hoście fizycznym, a które wewnątrz VM. To pomaga nie tylko przy licencjonowaniu Windows Server, ale też podczas odtwarzania awaryjnego, modernizacji infrastruktury oraz kontroli zmian.

Kiedy edycja Datacenter może być logiczniejsza

Windows Server Datacenter licencjonuje się również według rdzeni fizycznych, z tymi samymi minimalnymi progami na procesor i serwer. Kluczowa różnica dotyczy praw do wirtualizacji. Po pełnym licencjonowaniu rdzeni hosta edycja Datacenter zapewnia prawo do uruchamiania nieograniczonej liczby środowisk systemu operacyjnego Windows Server na tym licencjonowanym serwerze, zgodnie z obowiązującymi warunkami produktu.

W praktyce Datacenter staje się interesujący wtedy, gdy liczba maszyn wirtualnych na hoście jest duża, dynamicznie rośnie albo regularnie się zmienia. Przy kilku stabilnych VM edycja Standard może być bardziej proporcjonalna kosztowo. Gdy jednak kolejne pełne zestawy Standard zaczynają się kumulować, różnica cenowa powinna zostać porównana z kosztem Datacenter dla całego hosta.

Nie chodzi wyłącznie o stan „na dziś”. Host z czterema VM może za kilka miesięcy obsługiwać dodatkowy serwer aplikacyjny, system kopii zapasowych, usługę monitoringu lub kolejną domenę testową. Jeżeli każda nowa maszyna wymaga następnego pełnego pokrycia rdzeni licencjami Standard, kalkulacja powinna uwzględniać planowany rozwój, a nie tylko aktualną listę VM.

Jak rozpoznać moment, w którym Standard przestaje być wygodny

Sygnałem ostrzegawczym nie jest sama liczba maszyn wirtualnych, lecz liczba pełnych zestawów Standard potrzebnych dla danego hosta. Im więcej razy trzeba pokryć wszystkie rdzenie tego samego serwera, tym bardziej zasadne staje się porównanie obu edycji.

• Standard zwykle dobrze sprawdza się przy niewielkiej i przewidywalnej liczbie VM z Windows Server.
• Datacenter może być rozsądniejszy przy gęstej wirtualizacji, częstym tworzeniu nowych VM, środowiskach laboratoryjnych i hostach o stale rosnącym obciążeniu.
• W klastrze należy analizować każdy host, na którym maszyny mogą zostać uruchomione po migracji lub awarii.
• Jeżeli środowisko korzysta z mechanizmów mobilności licencji, trzeba sprawdzić warunki konkretnego programu licencyjnego, w tym ewentualne uprawnienia wynikające z Software Assurance.

Przykładowo, organizacja może mieć host przeznaczony dziś dla pięciu VM produkcyjnych, ale jednocześnie utrzymywać kilka VM testowych uruchamianych okresowo. Jeżeli te maszyny mogą działać równolegle na tym samym hoście, należy uwzględnić ich rzeczywisty scenariusz użycia. Licencjonowanie nie powinno opierać się na założeniu, że „testowe” oznacza automatycznie niewidoczne w kalkulacji.

Skutek błędnego wyboru edycji

Najczęstszym skutkiem jest niedolicencjonowanie po rozbudowie środowiska. Firma kupuje Standard dla początkowych dwóch VM, a potem dodaje kolejne systemy bez aktualizacji przypisania licencji. Problem może wyjść na jaw przy audycie, podczas odnowienia umowy, po incydencie awaryjnym albo przy porządkowaniu środowiska przed migracją do nowego sprzętu.

Drugi skutek jest mniej widoczny, ale równie istotny: przepłacenie. Zdarza się, że organizacja dokupuje kolejne zestawy Standard mechanicznie, mimo że po przekroczeniu określonego poziomu wirtualizacji bardziej przewidywalna i ekonomiczna byłaby edycja Datacenter. Dlatego decyzję należy oprzeć na porównaniu kosztu dla konkretnego hosta i planowanej liczby instancji, a nie na przekonaniu, że jedna edycja zawsze jest „tańsza”.

Lepsze rozwiązanie: policz scenariusz docelowy, nie tylko stan bieżący

Przed wyborem edycji przygotuj krótką prognozę na okres, w którym infrastruktura ma działać bez większej przebudowy. Wystarczy wskazać planowaną liczbę VM z Windows Server, rolę hostów, możliwość migracji między nimi oraz zapas na usługi, które mają powstać w najbliższym czasie.

Dobrą praktyką jest zapisanie dwóch wariantów: „minimum na teraz” oraz „wariant na 12–36 miesięcy”. Następnie dla każdego hosta można porównać liczbę wymaganych pełnych zestawów Standard z kosztem licencjonowania Datacenter. Taka analiza nie musi być rozbudowanym projektem finansowym; ważne, aby dało się wyjaśnić, dlaczego wybrano konkretną edycję.

Błąd nr 3: traktowanie CAL jako dodatku, który można „dokupić kiedyś”

Licencje dostępowe są często odkładane na później, ponieważ nie instalują się na serwerze i nie ograniczają technicznie logowania użytkowników. System może działać prawidłowo, udział plikowy będzie dostępny, a katalog Active Directory nie wyświetli komunikatu o brakującej licencji. To jednak nie oznacza, że dostęp jest objęty prawami licencyjnymi.

CAL powinny zostać zaplanowane równolegle z wdrożeniem usługi, do której użytkownicy lub urządzenia uzyskują dostęp. Odkładanie zakupu do czasu kontroli, rozbudowy lub problemu z dokumentacją zwykle kończy się nerwowym odtwarzaniem list użytkowników i urządzeń.

Dlaczego brak CAL szkodzi

W przypadku licencji User CAL liczba wymaganych licencji zależy od osób korzystających z usług Windows Server, a nie od liczby kont założonych w domenie. Konto techniczne, nieużywany profil byłego pracownika czy konto administracyjne nie zawsze opisują faktyczną skalę dostępu. Z drugiej strony pracownik korzystający z serwera z laptopa, telefonu i komputera domowego nadal może być objęty jedną właściwie przypisaną User CAL.

Przy Device CAL licencjonowane jest urządzenie uzyskujące dostęp. Ten model może być korzystny w środowiskach zmianowych, na stanowiskach wspólnych, terminalach magazynowych, komputerach produkcyjnych albo recepcji, gdzie z jednego urządzenia korzysta wiele osób.

Błąd pojawia się, gdy firma kupuje licencje dla liczby pracowników zatrudnionych na etacie, ale pomija współpracowników, pracowników tymczasowych, użytkowników zewnętrznych, osoby pracujące zdalnie lub urządzenia współdzielone. W praktyce dostęp do usług serwera może mieć znacznie więcej podmiotów niż wynika z prostego zestawienia kadrowego.

Jak rozpoznać, czy lepsze będą User CAL czy Device CAL

Nie trzeba wybierać jednego typu CAL dla całej organizacji. Można stosować oba modele, pod warunkiem że sposób przypisania jest logiczny i udokumentowany. Najważniejsze jest unikanie podwójnego liczenia tej samej potrzeby oraz przypisywania licencji wyłącznie „na oko”.

• User CAL zwykle pasuje do pracownika korzystającego z kilku urządzeń: laptopa, telefonu, komputera stacjonarnego i sprzętu domowego.
• Device CAL może być lepsza dla wspólnego terminala, stanowiska zmianowego lub urządzenia obsługiwanego przez wielu operatorów.
• Przy pracy hybrydowej częściej wygodniejszy jest model User CAL, ponieważ jedna osoba używa wielu punktów dostępu.
• Przy dużej rotacji pracowników należy regularnie aktualizować przypisania i listę aktywnych użytkowników.

Krótki przykład: w magazynie pracuje 30 osób na trzy zmiany, korzystających z 10 wspólnych terminali podłączonych do usług Windows Server. W takim układzie analiza Device CAL może być bardziej racjonalna niż przypisywanie licencji każdemu pracownikowi. Z kolei dział handlowy z 15 osobami pracującymi na laptopach i telefonach zwykle lepiej analizować w modelu User CAL.

Nie pomijaj dostępu pośredniego

Ryzykownym skrótem myślowym jest założenie, że CAL nie są potrzebne, gdy użytkownik nie loguje się bezpośrednio do pulpitu Windows Server. Dostęp może odbywać się pośrednio, na przykład przez aplikację biznesową, portal, system raportowy lub urządzenie komunikujące się z usługą serwerową. Sposób technicznego połączenia nie zawsze eliminuje obowiązek licencyjny.

W takich sytuacjach trzeba ustalić, kto faktycznie korzysta z funkcjonalności udostępnianej przez Windows Server. Jeśli aplikacja pośrednicząca jest używana przez pracowników, klientów albo partnerów, warto przeanalizować model dostępu przed wdrożeniem, a nie dopiero po uruchomieniu produkcyjnym.

RDS CAL to osobna analiza

Jeżeli użytkownicy korzystają z usług pulpitu zdalnego w scenariuszu wymagającym licencjonowania RDS, same Windows Server CAL nie wystarczą. Należy wówczas przeanalizować również odpowiednie RDS CAL, w wariancie User lub Device, stosownie do sposobu korzystania z usługi.

Typowy błąd polega na kupieniu Windows Server User CAL dla wszystkich pracowników i uznaniu, że temat zdalnego pulpitu jest zamknięty. Jeżeli organizacja udostępnia pełne pulpity sesyjne, aplikacje publikowane przez Remote Desktop Services albo inne funkcje objęte wymaganiami RDS, potrzebna jest dodatkowa warstwa licencji dostępowych.

Przykład: 12 pracowników ma dostęp do udziałów plikowych i uwierzytelniania domenowego, a sześć osób dodatkowo pracuje na publikowanych aplikacjach przez Remote Desktop Services. W takim środowisku należy przeanalizować licencje dostępowe dla wszystkich użytkowników korzystających z Windows Server oraz RDS CAL dla osób używających usług pulpitu zdalnego.

Lepsze rozwiązanie: prowadź rejestr przypisań CAL

Najprostszy rejestr może mieć formę arkusza lub danych w systemie zarządzania zasobami. Powinien wskazywać, czy dana licencja została przypisana użytkownikowi czy urządzeniu, jaki jest jej typ, kiedy została przypisana oraz czy użytkownik lub urządzenie nadal aktywnie korzysta z usług.

Warto także ustalić zdarzenia, które uruchamiają przegląd licencji: zatrudnienie nowej osoby, wdrożenie aplikacji dostępnej przez serwer, otwarcie nowej lokalizacji, zakup terminali współdzielonych, uruchomienie pracy zdalnej lub rozbudowa RDS. Dzięki temu CAL przestają być „zakupem kiedyś”, a stają się elementem zwykłego procesu wdrożeniowego.

Checklista przed zatwierdzeniem zakupu

• Czy dla każdego hosta określono właściwą edycję Windows Server oraz liczbę pełnych zestawów licencji potrzebnych dla planowanych VM?
• Czy uwzględniono wszystkie hosty klastra, na których maszyny wirtualne mogą zostać uruchomione?
• Czy rola systemu fizycznego została oddzielona od ról realizowanych wewnątrz VM?
• Czy porównano koszt Standard i Datacenter dla docelowej, a nie tylko bieżącej liczby maszyn wirtualnych?
• Czy lista użytkowników i urządzeń obejmuje pracowników zdalnych, współpracowników, stanowiska wspólne i urządzenia zmianowe?
• Czy dla każdej grupy dostępu wybrano świadomie User CAL albo Device CAL?
• Czy sprawdzono, czy używane scenariusze zdalnego pulpitu wymagają dodatkowych RDS CAL?
• Czy zachowano dokumenty zakupu, przypisania licencji, specyfikacje hostów i aktualny rejestr zmian w środowisku?
• Czy warunki wybranego kanału zakupu oraz wersji produktu zostały potwierdzone w aktualnej dokumentacji licencyjnej Microsoft lub u autoryzowanego partnera?

Źródła

• [1] Microsoft – Windows Server 2025 Licensing Guidance ↑
• [2] Microsoft – Microsoft Windows Server — Licensing Resources ↑
• [3] Microsoft – Windows Server 2025 Licensing Guide ↑
• [4] Microsoft – Core Based Licensing Models Licensing Guidance ↑
• [5] Microsoft – Windows Server 2025 Licensing & Pricing