Windows Server lizenzieren: Kerne, CALs und die Wahl zwischen Standard und Datacenter

Kernlizenzen: die Rechnung an der Hardware

Windows Server wird nach physischen Kernen lizenziert. Die Regel dahinter ist kurz: Für jeden physischen Kern des Servers muss eine Kernlizenz zugeordnet werden, weitere Kerne werden in Schritten von zwei lizenziert, und Microsoft verkauft die Lizenzen in Paketen zu zwei oder zu sechzehn. Damit ist die Grundrechnung erledigt, sobald du weißt, wie viele Kerne in der Maschine stecken. Was regelmäßig fehlt, ist genau diese Zahl, weil in Beschaffungsunterlagen der Prozessortyp steht und nicht die Kernzahl.

Darüber liegen zwei Untergrenzen, die gleichzeitig gelten und sich nicht gegenseitig aufheben. Jeder physische Prozessor braucht mindestens acht Kernlizenzen, und jeder physische Server mindestens sechzehn, ausdrücklich auch dann, wenn er nur einen Prozessor besitzt. Ein Einzelprozessorserver mit sechs Kernen wird also mit sechzehn Kernlizenzen lizenziert, weil die Servergrenze greift. Ein Server mit vier Prozessoren zu je vier Kernen wird dagegen mit zweiunddreißig Kernlizenzen lizenziert, weil die Untergrenze von acht Kernlizenzen für jeden der vier Prozessoren einzeln gilt, obwohl er physisch nur sechzehn Kerne hat.

Diese Untergrenzen haben eine praktische Folge, die vor jeder Beschaffung bedacht gehört: Viele kleine Server sind lizenzrechtlich teuer, wenige große sind es nicht. Wer eine Last, die auf einen Host mit zweiunddreißig Kernen passt, aus Vorsicht auf vier Maschinen mit je acht Kernen verteilt, zahlt vier mal sechzehn statt einmal zweiunddreißig, also das Doppelte für dieselbe Rechenleistung. Hochverfügbarkeit ist ein guter Grund, mehrere Hosts zu betreiben, aber sie ist ein bewusst getroffener Kompromiss und kein Nebeneffekt.

Standard oder Datacenter: die Rechnung an der Virtualisierung

Beide Editionen haben denselben Lizenzierungsmechanismus über Kerne, dieselben Untergrenzen und dieselbe CAL-Pflicht. Sie unterscheiden sich in dem, was du mit dem lizenzierten Server anfangen darfst. Standard erlaubt zwei Betriebssystemumgebungen, physisch oder virtuell, dazu einen Hyper-V-Host, unbegrenzt viele Windows-Container und bis zu zwei Container mit Hyper-V-Isolation. Datacenter erlaubt unbegrenzt viele virtuelle Maschinen und unbegrenzt viele Container in beiden Varianten.

Der entscheidende Mechanismus heißt Stapelung. Willst du auf einem mit Standard lizenzierten Server mehr als zwei Umgebungen betreiben, lizenzierst du denselben Server ein weiteres Mal vollständig, also mit derselben Zahl an Kernlizenzen. Microsoft formuliert das in seinem Lizenzleitfaden so, dass für jedes weitere Paar an Umgebungen die gleiche Zahl an Kernlizenzen erneut zugeordnet werden muss. Daraus folgt die Rechnung, die du in einer Zeile machen kannst: Teile den Preis eines Datacenter-Satzes durch den Preis eines Standard-Satzes für dieselbe Kernzahl und verdopple das Ergebnis. Das ist die Zahl virtueller Maschinen, ab der Datacenter günstiger wird.

Bei den unverbindlichen Listenpreisen, die Microsoft auf der eigenen Preisseite ausweist, landet dieser Wert im niedrigen zweistelligen Bereich. Rechne ihn trotzdem mit deinen eigenen Einkaufspreisen nach, denn Vertragsart, Volumen und Partner verschieben das Verhältnis spürbar. Und nimm nicht den heutigen Bestand als Grundlage, sondern die geplante Belegung des Hosts über seine Lebensdauer, weil die Stapelung nachträglich immer teurer ist als die richtige Entscheidung am Anfang.

Neben der Rechnung gibt es einige Funktionen, die es nur in Datacenter gibt und die die Entscheidung unabhängig von der Zahl der Maschinen vorwegnehmen. Storage Spaces Direct, der Network Controller und die Unterstützung für abgeschirmte virtuelle Maschinen über den Host Guardian Service sind in Standard nicht enthalten. Auch die GPU-Partitionierung steht in Standard nur für einzelne Server bereit, während der Betrieb im Cluster Datacenter voraussetzt. Wenn eine dieser Funktionen zum Zielbild gehört, brauchst du die Preisrechnung gar nicht erst zu machen.

CALs: die zweite Rechnung, die im Betrieb unsichtbar bleibt

Kernlizenzen decken den Server ab, nicht den Zugriff darauf. Für den Zugriff verlangt Microsoft eine Client Access License, und zwar für jede Person oder jedes Gerät. Die Wahl zwischen beiden Varianten ist eine reine Zählfrage. Eine User CAL wird für eine Person gekauft, unabhängig davon, mit wie vielen Geräten sie zugreift. Eine Device CAL wird für ein Gerät gekauft, unabhängig davon, wie viele Personen es benutzen. Wer mehr Geräte als Personen hat, nimmt User CALs, wer mehr Personen als Geräte hat, etwa im Schichtbetrieb an gemeinsamen Terminals, nimmt Device CALs.

Die Regel, die bei Migrationen am häufigsten übersehen wird, betrifft die Version. CALs decken die eigene Version und frühere Versionen ab, aber keine neueren. Microsofts Lizenzleitfaden hält fest, dass CALs und External Connectors für Windows Server 2025 den Zugriff auf Windows Server 2025 und auf frühere Versionen erlauben. Umgekehrt gilt das nicht. Sobald also der erste Server einer Umgebung auf die neue Version wechselt, richtet sich der CAL-Bedarf für alle Personen, die darauf zugreifen, nach dieser Version. Diese Folge muss aus dem Betrieb an die Lizenzstelle gemeldet werden, denn technisch passiert dabei nichts Auffälliges.

Für Zugriffe von außerhalb des Unternehmens gibt es statt einzelner CALs den External Connector. Er wird einem physischen Server zugeordnet und erlaubt dann den Zugriff durch beliebig viele externe Personen, solange dieser Zugriff dem Unternehmen dient und nicht der externen Person selbst. Weil er je Server gilt, entscheidet der Zuschnitt der Umgebung über die Kosten: Ein extern erreichbarer Dienst, der auf zwei Servern liegt, braucht zwei External Connectors. Rechne beide Varianten durch, denn bei kleinen, klar abgegrenzten Nutzergruppen sind einzelne CALs oft günstiger.

Manche Rollen verlangen zusätzlich zur Windows-Server-CAL ein eigenes Zugriffsrecht. Microsoft nennt dafür ausdrücklich die Remote Desktop Services und die Active Directory Rights Management Services. Für eine Terminalumgebung brauchst du also beides nebeneinander, und die RDS-CAL ersetzt die Windows-Server-CAL nicht. Der einzige Fall, in dem die Windows-Server-CAL entfällt, ist das nutzungsabhängige Abrechnungsmodell über Azure Arc, und selbst dort bleiben die RDS-CALs erforderlich.

Was Software Assurance an der Rechnung ändert

Software Assurance wird im Einkauf häufig als reiner Aufpreis für künftige Versionswechsel behandelt. Das greift zu kurz, weil daran inzwischen Leistungen hängen, die im Betrieb Geld sparen oder Aufwand ersparen. Microsoft bindet die Verwaltungsleistungen unter dem Namen Windows Server Management enabled by Azure Arc ausdrücklich an Windows-Server-Lizenzen mit aktiver Software Assurance oder an aktive Abonnementlizenzen. Dazu gehören unter anderem der Azure Update Manager, die Änderungsnachverfolgung, Windows Admin Center in Azure und die Bewertung nach Best Practices, jeweils ohne zusätzliche Kosten über den Netzwerk-, Speicher- und Protokollverbrauch hinaus.

Der Haken daran ist eine Formalie, die reihenweise übersehen wird: Die Berechtigung ergibt sich nicht automatisch daraus, dass ein Server mit Azure Arc verbunden ist. Microsoft verlangt eine ausdrückliche Bestätigung im Portal oder über PowerShell, und ohne diese Bestätigung werden dieselben Leistungen berechnet. Wer Software Assurance bezahlt und die Bestätigung nicht setzt, bezahlt zweimal.

Der zweite an Software Assurance und Abonnementlizenzen gebundene Punkt betrifft die Auslagerung. Der Flexible Virtualization Benefit erweitert die Möglichkeiten, eigene Lizenzen bei autorisierten Dienstleistern auf geteilter Hardware einzusetzen. Für Häuser, die einen Teil ihres Serverbetriebs abgeben wollen, ist das die Stelle, an der eine bestehende Vereinbarung über den Zuschnitt des Vertrags mitentscheidet. Auch das gehört in die Aufstellung, die der Betrieb dem Einkauf vor einer Verlängerung liefert.

Was diese Seite leistet und was sie ausdrücklich nicht ist

Diese Seite erklärt die Rechenlogik hinter der Lizenzierung von Windows Server, damit du im Gespräch mit Einkauf und Lizenzgeber die richtigen Fragen stellst und die technischen Entscheidungen kennst, die eine vertragliche Folge haben. Sie ersetzt keine Lizenzberatung, und der verbindliche Stand für deinen konkreten Fall liegt allein beim Lizenzgeber und in den Produktbedingungen, die für deinen Vertrag gelten.

Das ist keine Formalie, sondern eine praktische Einschränkung. Produktbedingungen ändern sich, Programme werden umgestellt, und die Regeln für Volumenverträge, für Verträge über Partner und für nutzungsabhängige Abrechnung weichen voneinander ab. Auch dieselbe Zahl an Kernen kann je nach Vertragsart zu unterschiedlichen Bestellmengen führen. Lass dir deshalb jede Auslegung, die im konkreten Fall Geld bewegt, schriftlich von der Stelle bestätigen, die dafür geradesteht.

Was du aus dem Haus heraus liefern kannst und musst, ist die Grundlage für diese Prüfung: eine belastbare Aufstellung der physischen Kerne je Server, der Zahl der Betriebssystemumgebungen je Host, der zugreifenden Personen und Geräte, der eingesetzten Serverversionen und der Rollen mit zusätzlichem Zugriffsbedarf. Diese Aufstellung ist die eigentliche Arbeit, und sie ist in jedem Vertragsmodell dieselbe. Wer sie gepflegt hat, verwandelt eine Lizenzprüfung in eine Abfrage von wenigen Minuten.