Aktualisierung von x86- und x64-Software via System Center Configuration Manager
Donnerstag, 18. November 2010, 15:04
Abgelegt unter: Erkenntnisse | Tags: , , , ,

Wenn ein Hersteller eine neue Version einer von uns verwendeten Software bereitstellt, gehen wir immer nach demselben Schema vor, falls wir die neue Softwareversion bereitstellen wollen:

  • Wir erstellen ein aktualisiertes Paket in der Testumgebung und testen dieses. Dabei kontrollieren wir nicht nur die Funktionstüchtigkeit einer Neuinstallation, sondern überprüfen auch, ob bestehende Installationen vonVorversionen der betreffenden Software aktualisiert werden können.
  • Sobald wir von der Tauglichkeit des neuen Paketes überzeugt sind, stellen wir dieses als zusätzliches Paket in der Produktionsumgebung bereit. Das Paket der Vorversion bleibt daneben unverändert erhalten.
  • Ab diesem Zeitpunkt wird dann normalerweise auf den Clients die neue Version installiert, doch ein Rückgriff auf die Vorversion wäre nötigenfalls immer noch möglich, falls mit der neuen Version unerwartete Probleme auftauchen sollten.
  • Zu einem bestimmten Zeitpunkt – bei uns normalerweise gebündelt mit der monatlichen Microsoft-Updaterunde -  wird dann die Aktualisierung der auf den Clients installierten Vorversionen in Angriff genommen. Hierzu wird unseren Benutzern die Installation des Updates eine Woche lang angeboten; während dieser Zeit kann der Benutzer sich den für ihn geeigneten Installationszeitpunkt selber auswählen. Danach wird die Installation des Updates per Assignment durchgesetzt.
  • Sobald die Aktualisierung aller Clients abgeschlossen ist, kann das veraltete Paket der Vorversion entsorgt werden. (Aber gerade bei diesem Schritt lassen wir uns üblicherweise tüchtig Zeit… )

Wie man Softwarepakete via SCCM verteilt, dürfte wohl jedem Administrator bekannt sein, der sich mit diesem Thema beschäftigt. Doch wie funktioniert der Schritt „Aktualisierung installierter Vorversionen“ genau?

Hierzu erstellen wir jeweils eine Collection, an welche die Installation des Updates dann advertised bzw. assigned werden kann. Die Mitgliedschaft in dieser Collection wird jeweils anhand einer Query definiert, welche bei uns immer folgenden Aufbau hat: „Gesucht sind alle Clients, die eine bestimmte Software installiert haben, jedoch nicht in der von uns aktuell gewünschten Version“. Wie dies in einem konkreten Fall aussieht, möchte ich anhand des kürzlich publizierten Update „Java Version 6 (Update 22) zeigen:

Ein x86-Client mit einer veralteten Java-Version

Wir erkennen hier im Bereich „Programme und Funktionen“ in der Systemsteuerung eines Clients, dass auf diesem noch das Update 20 von Java installiert ist. Genau diese Information können wir auch für folgende WQL-Query zur Definition einer Collection in SCCM verwenden:

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS
on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Java%"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"

Wir suchen also nach Programmen mit der Zeichenkette „Java“ am Anfang des Anzeigenamens, die nicht eine Versionsbezeichnung haben, welche mit „6.0.220“ beginnt. Bei der Versionsnummer gilt es zu beachten, dass es sich hier um eine Zeichenkette und nicht um einen Wert handelt; eine Query in der Form „Version < 6.0.220“ funktioniert nicht. Dass man auch bei der Wahl des Suchbegriffes im Anzeigenamen die nötige Vorsicht walten lassen sollte, dürfte sich von selbst verstehen. Schliesslich möchte man ja nicht ein Java-Update auf einen Client installieren, weil dort auch noch zufälligerweise irgendein „Java-Free-Editor“ (und dummerweise leider nicht in der Version 6.0.220.7) vorhanden ist. Den Suchbegriff sollte man also möglichst spezifisch definieren, nötigenfalls lässt sich auch noch ein Hersteller mit einer weiteren Klausel in der Form „and ..._ADD_REMOVE_PROGRAMS.Publisher like "...%"“ einbeziehen.

Dies funktionierte im vorliegenden Fall bestens und schon hatten wir die passende Collection aller Clients, welche dringend ein Java Update nötig hätten, bereit. Wirklich?

Nein, leider nicht ganz. Denn wir haben nicht nur 32bit (d.h. x86)-Systeme im Einsatz, sondern es sind auch 64bit (d.h. x64)-Systeme vorhanden. Und da sieht das Ganze leicht anders aus:

Ein x64-Client mit zwei veralteten Java-Versionen

Wir erkennen in diesem Screenshot, dass auf diesem Client zwei Java Versionen installiert sind; zwar in beiden Fällen die Version 6u20, aber einmal als 32bit- und einmal als 64bit-Variante. Also galt es dafür zu sorgen, dass überall dort, wo die 32bit-Version installiert ist, auch das 32bit-Update installiert wird und überall dort, wo die 64bit-Version vorhanden ist, auch das entsprechende 64bit-Update geliefert wird.

Leider passt die oben angegebene WQL-Query auch auf „Java(TM) 6 Update 20 (64-bit)“. Und wir beabsichtigen nicht, auf allen Clients die 32bit-Version nachzuinstallieren, auf denen nur die 64bit-Variante installiert ist. Zudem fehlt noch eine passende Collection für die Aktualisierung der 64bit-Variante. Also flugs eine zweite Collection erstellt und die erste modifiziert!

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS
on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Java%"
and SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName not like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS
on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"

Und jetzt: sind wir nun bereit für die Verteilung der beiden Updates? Nein, leider immer noch nicht…

Im Falle der ersten Collection für die 32bit-Variante scheint alles bestens: Es sind genau diejenigen Systeme in der Collection enthalten, welche das 32bit-Update nötig haben. Die zweite Collection ist … leer!?!

Dabei wussten wird doch ganz genau, dass es bei uns Systeme gibt, welche die 64-bit-Java-Version installiert haben. Nach einer längeren Suche nach der Ursache entdeckten wir dann des Rätsels Lösung: Es gibt nicht nur eine Tabelle „SMS_G_System_ADD_REMOVE_PROGRAMS„, sondern auch noch eine zweite Tabelle „SMS_G_System_ADD_REMOVE_PROGRAMS_64„. Die Angaben über die auf einem Client installierte Software werden also in separaten Tabellen für 32-bit- und zu 64-bit-Software gespeichert. Kein Wunder also, dass unsere obige Query ein unbrauchbares Ergebnis liefert und demzufolge die Collection leer bleibt, denn wir suchen schlicht und einfach in der falschen Tabelle!

Wir haben dann die Collection für die 64-bit-Java-Version nochmals angepasst, worauf diese dann tatsächlich das gewünschte Ergebnis lieferte:

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS_64
on SMS_G_System_ADD_REMOVE_PROGRAMS_64.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS_64.Version not like "6.0.220%"

Endlich hatten wir die notwendigen Collections definiert und die Verteilung der beiden Updates konnte starten. Erst später merkten wir dann noch, dass im Falle der ersten Collection für die 32-bit-Java-Version die Erweiterung ..._ADD_REMOVE_PROGRAMS.DisplayName not like "Java%(64-bit)" gar nicht nötig gewesen wäre, da ja in der betreffenden Tabelle gar keine Angaben zu installierten 64bit-Versionen gespeichert sind.



Die Volumenlizenzierung von Windows Server 2008 R2 im virtualisierten Umfeld
Montag, 8. November 2010, 16:12
Abgelegt unter: Erkenntnisse | Tags: , , , ,

Die leider nicht zu vermeidende Vorbemerkung…

Dieser Beitrag entstand im Anschluss an einen Microsoft Lizenzierungsworkshop, den ich vergangene Woche besucht habe, und fasst meine Notizen zu dieser Thematik zusammen. Auch wenn ich mir bei der Erstellung dieses Beitrages grösste Mühe gegeben habe, die präsentierten Informationen möglichst korrekt und vollständig wiederzugeben, muss ich hier folgenden Warnhinweis anfügen:

Ich weise ausdrücklich darauf hin, dass dieser Beitrag keinerlei rechtsverbindlichen Charakter hat, sondern ausschliesslich das Verständnis der Microsoft-Produktlizenzierung verbessern soll. Die einzig rechtsverbindlichen Lizenzinformationen sind in den entsprechenden Endbenutzerlizenzverträgen (als Beilage zu Softwarepaketen) oder Produktbenutzungsrechten der Microsoft Volumenlizenzprogramme zu finden.

Die Grundlagen zur Volumenlizenzierung im virtualisierten Umfeld

Je nach erworbener Windows-Serverlizenz darf eine unterschiedliche Anzahl virtualisierter Instanzen auf einem physischen Server betrieben werden. Dabei sind stets die „Running Instances“ relevant, d.h. die Anzahl Instanzen, die gleichzeitig betrieben werden dürfen:

  • Windows Server 2008 R2 Standard: 1 physische Installation + 1 virtuelle Instanz
  • Windows Server 2008 R2 Enterprise: 1 physische Installation + 4 virtuelle Instanzen
  • Windows Server 2008 R2 Datacenter: 1 physische Installation + unlimitierte virtuelle Instanzen.

Nur ausgeführte Instanzen müssen lizenziert werden. Ist einem physischen Server z.B. 1 Lizenz „Windows Server 2008 R2 Enterprise“ zugewiesen, dürfen auf diesem Server vier virtuelle Instanzen von Windows Server Enterprise (oder Standard) ausgeführt und beliebig viele nicht-ausgeführte Instanzen erstellt werden, welche auch auf einem anderen als dem lizenzierten Server oder in einem SAN gespeichert werden dürfen.

Wurde eine höhere Edition lizenziert, darf auch eine tiefere Edition ausgeführt werden: Wurde ein Server beispielsweise für „Windows Server 2008 R2 Enterprise“ lizenziert, darf darauf auch „Windows Server 2008 R2 Standard“ ausgeführt werden. Während auf einem für „Windows Server 2008 R2 Standard“ lizenzierten Server nur „Windows Server 2008 R2 Standard“ ausgeführt werden darf, ist für die Ausführung von „Windows Server 2008 R2 Datacenter“ die Lizenzierung von „Windows Server 2008 R2 Datacenter“ notwendig. Auf einem für „Windows Server 2008 R2 Datacenter“ lizenzierten Server dürfen alle drei Editionen in beliebiger Anzahl und beliebiger Kombination ausgeführt werden.

Eine Windows-Serverlizenz wird nie der virtualisierten Instanz direkt zugewiesen, sondern muss immer dem physischen Server zugewiesen werden, auf dem die virtualisierte Instanz betrieben werden soll. Eine Hardwarepartition oder ein Blade wird in diesem Zusammenhang als separater physischer Server betrachtet. Dabei ist zu beachten, dass eine Windows-Serverlizenz einem lizenzierten Server mindestens 90 Tage zugewiesen bleiben muss. Erst nach Ablauf dieser 90-Tage-Frist darf eine Lizenz einem anderen Server (und somit auch einem anderen Blade) neu zugewiesen werden. Die Neuzuweisung darf nur dann ausnahmsweise früher erfolgen, wenn der lizenzierte Server (bzw. das lizenzierte Blade) wegen eines dauerhaften Hardwarefehlers ausser Dienst gestellt wird. Sollen die virtualisierten Instanzen vor Ablauf der 90 Tage aus anderen Gründen auf einen anderen, bisher nicht lizenzierten (z.B. neu erworbenen) Server verschoben werden, muss der neue Server (bzw. das neue Blade) separat lizenziert werden.

Einem physischen Server darf auch mehr als eine Lizenz zugewiesen werden, um zusätzliche virtuelle Instanzen auf diesem Server ausführen zu können. Werden beispielsweise einem physischen Server zwei Lizenzen von „Windows Server 2008 R2 Standard“ zugewiesen, dürfen darauf zwei virtuelle Instanzen von „Windows Server 2008 R2 Standard“ betrieben werden, da „Windows Server 2008 R2 Standard“ nur eine virtualisierte Instanz pro Lizenz erlaubt. Werden dem physischen Server hingegen zwei Lizenzen von „Windows Server 2008 R2 Enterprise“ zugewiesen, dürfen darauf insgesamt acht Instanzen von „Windows Server 2008 R2 Standard“ und „Windows Server 2008 R2 Enterprise“ in beliebiger Kombination ausgeführt werden.

Zu beachten ist im weiteren, dass „Windows Server 2008 R2 Standard“ und „Windows Server 2008 R2 Enterprise“ pro Gerät (also pro Server) lizenziert werden, der „Windows Server 2008 R2 Datacenter“ hingegen pro physisch vorhandener Prozessor zu lizenzieren ist, wobei jedoch die Anzahl der Cores pro Prozessor keine Rolle spielt. Bei der Datacenter-Edition müssen zudem minimal 2 Lizenzen pro Maschine erworben werden, der Einsatz der Datacenter-Edition auf Single-Prozessor-Servern ist von Microsoft nicht vorgesehen.

Das Verschieben von virtuellen Instanzen auf einen neuen Server ist erlaubt, sofern durch diese Verschiebung keine Lizenzbestimmungen verletzt werden. So darf z.B. eine Instanz nur dann auf einen mit „Windows Server 2008 R2 Enterprise“ lizenzierten physischen Server verschoben werden, wenn auf diesem erst maximal drei andere Instanzen betrieben werden, da nur maximal vier Instanzen zulässig sind. Ebenso darf eine unter „Windows Server 2008 R2 Enterprise“ betriebene Instanz nicht auf einen mit „Windows Server 2008 R2 Standard“ lizenzierten physischen Server verschoben werden. Dasselbe gilt auch für Instanzen mit „Windows Server 2008 R2 Datacenter“, welche ausschliesslich auf einem für „Windows Server 2008 R2 Datacenter“ lizenzierten Server betrieben werden dürfen. Das Verschieben von Instanzen auf einen für „Windows Server 2008 R2 Datacenter“ lizenzierten Server hingegen ist unproblematisch, da darauf Instanzen beliebiger Editionen in beliebiger Zahl betrieben werden dürfen. Nicht zuletzt aus diesem Grund wird von Microsoft für virtualisierte Serverfarmen die Lizenzierung von „Windows Server 2008 R2 Datacenter“ als „Rundum-Sorglos-Paket“ empfohlen.

Wie funktioniert das ganze nun unter VMWARE bzw. anderen Virtualisierungstechnologien?

Wird VMWARE (oder ein anderes Produkt eines Drittherstellers) als Virtualisierungsschicht eingesetzt, verzichtet man aus Sicht von Microsoft gewissermassen auf den Einsatz der physischen Installation, die entsprechende Lizenz muss aber trotzdem dem entsprechenden physischen Gerät zugewiesen werden. Je nachdem ob dem VMWARE-Device nun eine Standard-, Enterprise, oder Datacenter-Lizenz zugewiesen wird, dürfen darauf nun eine, vier oder beliebig viele Windows-Server mit den jeweils erlaubten Editionen betrieben werden.

Während „Windows Server 2008 R2 Standard“ und „Windows Server 2008 R2 Enterprise“ einfach pro Server bzw. pro Blade zu lizenzieren sind, wird die Anzahl vorhandener physischer Prozessoren auch beim Einsatz von VMWARE bzw. anderer Virtualisierungstechnologien für die Lizenzierung von „Windows Server 2008 R2 Datacenter“ relevant. Es müssen genauso viele Lizenzen erworben werden, wie physische Prozessoren vorhanden sind, auch wenn auf dem betreffenden physischen Device schlussendlich nur vereinzelte Windows-Server-Instanzen neben beliebig unzähligen weiteren z.B. Linux-Instanzen betrieben werden sollen.

Soll zudem Loadbalancing eingesetzt werden und ggf. sogar automatisiert Serverinstanzen von ausgelasteten physischen Server auf weniger belastete Server verschoben werden, wird die Problematik der korrekten Lizenzierung noch zentraler, da in diesem Falle alle physischen Server, auf denen Windows-Serverinstanzen betrieben werden sollen, separat lizenziert sein müssen. Denn gerade hier schlägt die „90-Tage Frist“ zu, welche eine rasche Neuzuweisung von Windows-Server-Lizenzen verbietet, da die Server-Lizenzen – wie bereits erwähnt – immer dem betreffenden ausführenden physischen Server und nicht den herumschiebbaren virtuellen Instanzen zuzuweisen sind.

In heterogenen Umgebungen wird es demzufolge äusserst ratsam, die Windows-Serverinstanzen zu konsolidieren und nur auf dezidierten (und somit zu lizenzierenden) physischen Server zu betreiben und die anderen, z.B. Linux-Instanzen auf anderen physischen Server zu betreiben, auf denen niemals Windows-Serverinstanzen betrieben werden, welche somit nicht lizenziert werden müssen.

Nicht zu vergessen: Die Clientzugriffslizenzen (CAL)

Der Erwerb von Serverlizenzen reicht leider in den wenigsten Fällen aus, einen korrekt lizenzierten Windows Server zu betreiben, denn es werden zusätzlich für alle Zugriffe auf einen Windows Server sogenannte CAL („Client Access License“) benötigt. Das gilt für Windows Server Standard, Enterprise und Datacenter. Zugriffe externer Nutzer können über CALs oder einen „External Connector“ lizenziert werden. Es gibt folgende Arten von CAL:

  • Windows Server 2008 CAL
  • Windows Server 2008 RDS CAL
  • Windows Server 2008 RMS CAL

Dabei gibt es zwei Typen von CAL, welche in beliebiger Kombination verwendet werden dürfen:

  • Eine „Benutzer-Zugriffslizenz“ („User CAL“) wird dauerhaft einem Benutzer zugewiesen und erlaubt diesem, von einem beliebigen Gerät auf Instanzen von Windows Server 2008 R2 auf die lizenzierten Windows-Server zuzugreifen.
  • Eine „Geräte-Zugriffslizenz“ („Device CAL“) wird dauerhaft einem Gerät zugewiesen und erlaubt beliebigen Benutzern dieses Gerätes, auf Instanzen von Windows Server 2008 R2 auf lizenzierten Servern des Unternehmens zuzugreifen.

CAL dürfen zwar neu zugewiesen werden, aber dies nur, wenn die neue Zuweisung „dauerhaft“ sein soll, oder wenn es sich um ein temporäres Ersatzgerät oder eine Aushilfsperson handelt, währenddessen das lizenzierte Gerät ausser Betrieb (z.B „in Reparatur“) bzw. der lizenzierte Benutzer abwesend ist. Somit wird es klar, dass bei der Definition der benötigten CAL keinesfalls irgendeine Zahl gleichzeitig aktiver („concurrent“) Benutzer relevant ist, sondern die effektive Anzahl unterscheidbarer Benutzer bzw. Geräte, die in den meisten Fällen leider wohl deutlich höher liegen dürfte.

Ein „Windows Server 2008 CAL“ wird erforderlich, sobald auf irgendeine Art und Weise auf einen Windows Server zugegriffen werden soll, wozu es allerdings auch Ausnahmen gibt: So ist kein Windows CAL erforderlich für maximal zwei Benutzer bzw. zwei Geräte, wenn der Zugriff ausschliesslich zur Administration des Servers geschieht. Auch wenn der Zugriff unidentifiziert via Internet erfolgt (z.B. anonymer Zugriff auf eine öffentlich zugängliche Website) erfolgt, werden keine CAL benötigt; sobald aber der Benutzer (bzw. das Gerät) beim Zugriff auf irgendwelche Art und Weise identifiziert wird, wird der entsprechende Erwerb der benötigten Anzahl „Windows Server 2008 CAL“ fällig.

Zur Nutzung von Remote Desktop Services (RDS) wird zusätzlich ein „Windows Server 2008 RDS CAL“ pro Benutzer oder pro Gerät benötigt, dieser berechtigt zudem dazu, „Application Virtualization für Terminaldienste“ zu nutzen. Zur Nutzung der Rights Management Services (RMS) von Windows Server 2008 R2 wird analog ein „Windows Server 2008 RMS CAL“ benötigt.

Auch externe Benutzer (wie Geschäftspartner und Kunden) könnten grundsätzlich über einzelne CALs pro externen Benutzer lizenziert werden, doch gerade in diesem Umfeld wird es sehr schwierig, die genaue Anzahl der benötigten CAL zu bestimmen; der „pauschal“ lizenzierende „External Connector“ vereinfacht dies deutlich. Wie zu erwarten, gibt es neben dem Basis „Windows Server 2008 External Connector“ auch je einen „Windows Server 2008 RDS External Connector“ und einen „Windows Server 2008 RMS External Connector“. Ein „External Connector“ unterliegt zudem ebenfalls der 90-Tage-Frist für die Neuzuweisung analog zu den Windows-Server-Lizenzen.

Weitere Serverprodukte… und weitere CAL…

Werden auf den virtualisierten Instanzen von Windows Server weitere Server (wie Exchange, Sharepoint, System Center Produkte, usw.) betrieben, sind diese jeweils gemäss den Anforderungen zum jeweiligen Produkt zu lizenzieren. Wird nun eine derartige Instanz von Windows Server auf einen anderen physischen Server verschoben, muss die entsprechende Lizenz mitverschoben werden. Im Gegensatz zum Windows Server profitieren diese Server-Produkte jedoch zumeist von der sog. „License Mobility“, d.h. bei diesen Produkten existiert keine 90-Tage-Frist für die Neuzuweisung der Lizenz, sondern diese Lizenzen dürfen je nach Bedarf neuen Servern zugewiesen werden, sofern diese zur selben „Serverfarm“ gehören. Welche Lizenzen konkret von „License Mobility“ profitieren, ist mit „LM (License Mobility)“ im Microsoft Dokument „Product Use Rights“ dokumentiert.

Auch hier müssen für die jeweiligen Server-Produkte vielfach entsprechende CAL lizenziert werden, damit diese Produkte nicht nur installiert, sondern auch von den Benutzern (bzw. von den entsprechenden Devices her) genutzt werden dürfen.

Eine umfassende Zusammenstellung der Lizenzierungmöglichkeiten aller Serverprodukte würde jedoch den Rahmen dieses Beitrages bei weitem sprengen. Der Leser sei diesbezüglich auf die Dokumentationen von Microsoft zum jeweiligen Produkt verwiesen (siehe Links am Ende des Beitrages).

CAL-Suiten

Um die Lizenzierung zu vereinfachen, bietet Microsoft zwei sog. „CAL-Suiten“ an, welche den Clientzugriff für mehrere Produkte in einem Schritt lizenzieren:

  • Die sog. „Microsoft Core Cal Suite“ umfasst folgende Clientzugriffslizenzen:
    • Windows Server CAL
    • Exchange Server Standard CAL
    • SharePoint Server Standard CAL
    • SC Configuration Manager Client ML
  • Die umfassendere „Microsoft Enterprise CAL Suite“ enthält alle Clientzugriffslizenzen der „Microsoft Core Cal Suite“ und bringt zusätzlich folgende Clientzugriffslizenzen mit:
    • Windows Rights Management Services (RMS) CAL
    • Exchange Server Enterprise CAL
    • SharePoint Server Enterprise CAL
    • SC Client Management Suite (SCOM, SCDPM; und SCSM Client ML)
    • OCS Standard CAL (Lync Server Standard CAL)
    • OCS Enterprise CAL (Lync Server Enterprise CAL)
    • Forefront Protection Suite
    • Forefront Unified Access Gateway CAL

Einzig die „Remote Desktop Services CAL“ ist in keiner Suite enthalten und muss deshalb immer separat lizenziert werden.

Abschliessende Worte und weiterführende Links:

Soweit also mein Versuch, diese komplexe Thematik in diesem Beitrag zusammenzustellen. Falls Fragen auftauchen sollten, wie nun ein bestimmtes Szenario konkret lizenziert werden müsste, dürfte der einzig sinnvolle Ansprechspartner wohl der jeweilige Handelspartner („Large Account Reseller LAR“) sein, über den die Volumenlizenzen beschafft werden.

Zum Abschluss dieses Beitrages nun noch einige weiterführende Links:

2 Kommentare