Microsoft hat sich beim SQL-Server-Lizenzmodell etwas einfallen lassen, das ungefähr so transparent ist wie eine Beton-Glasscheibe. Wer nicht aufpasst, zahlt entweder doppelt oder findet beim nächsten Audit Briefe, die deutlich weniger nett gemeint sind als sie aussehen. Dieser Artikel räumt auf — mit Theorie, drei Praxisbeispielen aus dem Beratungsalltag und einer gesunden Portion Schadenfreude.

Es gibt drei Themen, bei denen IT-Verantwortliche nachts schweißgebadet aufwachen: Active Directory ohne Backup, ein Domain Controller im Rohbau und SQL-Server-Lizenzierung. Letztere hat den unangenehmen Vorteil, dass sie nicht knallt, sondern leise tickt — bis irgendwann der freundliche Mensch vom „Microsoft Software Asset Management“ anruft und höflich fragt, ob man kurz Zeit für ein paar Fragen hätte. Spoiler: Hat man nicht. Aber er nimmt sie sich.

Die SQL-Server-Lizenzierung ist eines dieser Themen, bei dem 90 Prozent aller Beteiligten denken, sie hätten es im Griff. Die ehrliche Wahrheit ist: Etwa 60 Prozent davon haben sich verschätzt — meistens zu ihren Ungunsten. Die anderen 40 Prozent haben so viel überlizenziert, dass die Differenz das Jahresgehalt eines Junior-Admins finanzieren würde. Beides ist ärgerlich, beides ist vermeidbar.

Dieser Artikel schaut sich die SQL-Server-Lizenzierung von vorne bis hinten an. Was die Modelle taugen, wo die Stolperfallen lauern und warum „läuft doch“ kein belastbares Lizenzkonzept ist. Am Ende gibt es drei Beispiele aus dem echten Leben, einen Disclaimer (wir sind ja seriös) und mein Beratungsangebot — falls du jetzt feststellst, dass dein eigenes Lizenzkonstrukt eher Bastelei als Architektur ist.

01 Die Lizenzmodelle im Schnelldurchlauf

SQL Server kommt in mehreren Editionen, und jede Edition hat eigene Lizenzregeln. Wer denkt, eine Edition lasse sich nach Bauchgefühl auswählen, irrt grundsätzlich und teuer. Hier ist die Übersicht — ohne Marketing-Geblubber.

Wichtig: Nur Standard bietet die Wahl zwischen Core- und Server+CAL-Lizenzierung. Enterprise gibt es ausschließlich Core-basiert — das war mal anders, ist aber seit SQL Server 2012 Geschichte. Wer noch eine alte Server-Lizenz für Enterprise im Schrank hat, soll sie unbedingt aufheben, falls jemand mal Mid-Century-Memorabilia für IT-Museen sucht.

02 Core-Lizenzierung: Wo aus Kernen Kosten werden

Die Core-Lizenzierung ist seit SQL Server 2012 das dominante Modell und für Enterprise sogar die einzige Option. Das Prinzip ist einfach: Du lizenzierst nicht den Server, sondern die physischen Cores, auf denen SQL Server läuft. Kompliziert wird es, sobald jemand „virtualisiert“ sagt — aber dazu gleich mehr.

Drei Regeln musst du im Schlaf können:

• Mindestens 4 Core-Lizenzen pro physischem Prozessor. Auch wenn dein Sockel nur einen Dual-Core trägt — du zahlst für vier. Microsoft hat das so entschieden, und Microsoft ist nicht für demokratische Abstimmungen bekannt.
• Lizenzen werden in 2-Core-Packs verkauft. Ungerade Anzahlen gibt es nicht. Wer 5 Cores braucht, kauft 6. Wer 7 Cores braucht, kauft 8. Mathematik der Microsoft-Sorte.
• Hyperthreading zählt nicht — physische Cores zählen. Außer in der Cloud, da gelten dann doch wieder eigene Regeln, weil sonst wäre es ja zu logisch.

Skizze 1 — Acht Cores pro Sockel, zwei Sockel: 16 Core-Lizenzen, gekauft als acht 2-Core-Packs. Bei einem 2-Core-Sockel müsstest du trotzdem 4 Core-Lizenzen kaufen. Microsoft-Mathematik.

03 Server + CAL: Das vermeintlich einfache Modell

Die zweite Variante — ausschließlich für Standard verfügbar — ist das klassische Server+CAL-Modell. Du kaufst eine Server-Lizenz pro SQL-Server-Instanz und für jeden zugreifenden Benutzer (User CAL) oder jedes zugreifende Gerät (Device CAL) eine CAL. Klingt einfach, ist es auch — solange niemand auf die kreative Idee kommt, eine Webanwendung dazwischenzubauen.

User CAL oder Device CAL?

Mischen ist erlaubt. Du kannst für 50 Mitarbeiter User CALs kaufen und für 30 Schichtterminals Device CALs. Wichtig ist nur: Jeder Zugriff braucht eine CAL. Auch der eine Praktikant, der jeden Mittwoch von zu Hause draufschaut, weil er „nur kurz Daten abgleicht“.

Multiplexing — der Klassiker, der aus jeder Server-CAL einen Audit-Fund macht

Multiplexing ist der Begriff, mit dem Microsoft die Vorstellung beerdigt hat, man könne mit einer einzigen technischen Verbindung („Service-Account“) beliebig viele User auf SQL Server zugreifen lassen. Die Lizenzbedingungen sind hier glasklar: Jede Person und jedes Gerät hinter einem Multiplexer braucht eine eigene CAL. Auch wenn technisch nur ein einziger Connection-Pool aufmacht.

Skizze 2 — Die Webanwendung „bündelt“ zwar alle User-Verbindungen zu einer einzigen technischen Connection. Lizenzrechtlich ändert das genau gar nichts.

Wann Server+CAL sinnvoll ist — und wann nicht

Die Faustregel: Sobald deine User-Zahl zweistellig wird und du eine Webanwendung als Frontend hast, ist Server+CAL fast immer das falsche Modell. Sobald externe User dazukommen — Kunden, Partner, das Internet — wird es richtig spaßig, weil du dann eigentlich einen External Connector bräuchtest oder eben Core-Lizenzen. Server+CAL funktioniert wirtschaftlich am besten in internen, überschaubaren Szenarien mit klar abgegrenzter Nutzergruppe.

04 Software Assurance — was sie wirklich bringt

Software Assurance (SA) ist ein optionales Wartungsprogramm zu deinen SQL-Server-Lizenzen. Microsoft preist sie an wie ein Premium-Paket, und in vielen Fällen ist sie das auch tatsächlich — allerdings nicht aus den Gründen, die im Vertriebsfolder stehen. SA ist primär dann interessant, wenn du virtualisierst, hochverfügbar betreibst oder Lizenzen flexibel verschieben willst.

SA kostet typischerweise rund 25 % des Lizenzpreises pro Jahr. Über drei Jahre also etwa 75 % einer Vollanschaffung. Das ist nicht trivial. Andererseits: Wer ohne SA virtualisiert und produktiv betreibt, baut sich oft eine Lizenzlandschaft, in der jede VM-Migration ein 90-Tage-Wartezimmer auslöst. Spätestens beim ersten ungeplanten Failover gibt es dann lustige Diskussionen mit der Compliance-Abteilung.

05 Virtualisierung — wo es richtig spannend wird

Sobald SQL Server in einer VM läuft — und das tut er heute fast immer — kommt die Frage: Lizenziere ich die VM oder den Host? Die Antwort hängt davon ab, welche Edition du nutzt und ob du Software Assurance hast. Hier ist die Entscheidungsmatrix.

Skizze 3 — Bei Enterprise + SA wird die Host-Lizenzierung zur eigentlichen Sparoption: Alle physischen Cores des Hosts werden lizenziert, dafür darf eine beliebige Anzahl SQL-VMs auf diesem Host laufen.

06 Hochverfügbarkeit — wer was darf, wer was zahlt

Hochverfügbarkeit ist das zweitliebste Lieblingsthema der Lizenzauditoren, gleich nach Multiplexing. Die Regeln sind feinkörnig, und jede Wirtschaftlichkeit hängt an Software Assurance.

Passive Sekundärinstanz — der einzige Freifahrtschein

Mit Software Assurance darfst du pro Primärlizenz eine passive Sekundärinstanz betreiben, ohne sie zu lizenzieren. „Passiv“ heißt: Auf dieser Instanz finden keine User-Workloads statt, keine Lese-Anfragen, kein Reporting, keine Backups (technisch dürfen Backups, aber lies bitte ganz genau die aktuellen Lizenzbedingungen — die Definition von „Backup“ wird gerne sportlich ausgelegt).

Skizze 4 — Eine passive Sekundärinstanz pro Primary ist mit SA inklusive. Sobald aber irgendjemand auf einer Replica liest — sei es das BI-Team mit ein paar harmlosen Reports — wird sie aktiv und damit lizenzpflichtig.

FCI vs. Always On — kurzer Lizenz-Faktencheck

Bei einem klassischen Failover Cluster Instance (FCI) mit Active/Passive-Setup ist die passive Node mit SA frei. Ein Active/Active-FCI braucht beide Nodes lizenziert — was der Active/Active-Setup ja gerade rechtfertigen soll. Bei Always On Availability Groups gilt: Jede Replica, die nicht komplett passiv ist, wird voll lizenziert. „Komplett passiv“ bedeutet: kein Lese-Traffic, kein Reporting, keine sonstige aktive Nutzung. Backups sind unter bestimmten Bedingungen erlaubt — die Bedingungen lies bitte im aktuellen Licensing Guide nach, die ändern sich gerne.

— Praxisteil —

07 Drei Beispiele aus dem echten Leben

Genug Theorie. Hier sind drei Fälle, die ich in dieser oder ähnlicher Form mehr als einmal gesehen habe. Die Firmennamen sind, wie üblich, frei erfunden — die Probleme leider nicht.

08 Was du heute mitnehmen solltest

Wenn du nur drei Sätze aus diesem Artikel mitnimmst, dann diese:

• Multiplexing ist die häufigste Lizenzlücke. Jede Person hinter einer Webanwendung braucht eine eigene CAL — oder du wechselst auf Core.
• Software Assurance ist in virtualisierten Setups keine Option, sondern fast immer eine wirtschaftliche Notwendigkeit. Live-Migration ohne SA ist eine tickende Uhr.
• „Aktiv“ ist alles, was nicht ausschließlich auf Failover wartet. Lese-Replicas sind aktiv. Punkt. Auch wenn dein BI-Architekt das anders sieht.

Ein vernünftiges Lizenzkonzept besteht aus drei Bausteinen: einer aktuellen Lizenzbilanz (was habe ich, was nutze ich, wo ist die Lücke), einer Architektur, die zur Lizenzierung passt (oder umgekehrt), und einem jährlichen Review. Wer diese drei Dinge dokumentiert hat, kann beim nächsten Audit die Tür öffnen, ohne unter dem Schreibtisch zu verschwinden.

— Beratungsangebot —

Du willst nicht erst beim Audit erfahren,

wie deine Lizenzbilanz aussieht?

Ich biete strukturierte SQL-Server-Lizenzbewertungen für Mittelstand und Konzern. Pragmatisch, technisch fundiert, ohne Vertriebs-Choreographie. Drei Bausteine, einzeln buchbar oder als Paket.

→ Erstgespräch anfragen unter info@boddenberg.de