Sysprep 1, 2, 3 - vorbei!

Man lernt ja tatsächlich niemals aus. ;-)

Heute war ich bei einem Kunden, bei dem wir eine virtuelle XenApp 5-Umgebung (unter VMware vSphere 4) auf Basis von Windows Server 2008 x64 betreiben.

Unser Wunsch war, es das Rapid Deployment der Farm so zu gestalten, dass aus einem ge-sysprep-ten Template alle weiteren Farmmitglieder gecloned werden.

Das ist ein an sich bewährtes Verfahren für "kleine" XenApp-Farmen (ich würde sagen bis hinzu ca. 5 bis 10 logischen Servern) und hat über Jahre hinweg auch sehr gut funktioniert.

Nun weiß man ja, wie das ist: man baut so ein Image hat es fertig und syspreped es. Ach "mérde!" eine Kleinigkeit vergessen, also kurz noch einmal anpassen das Image und noch einmal syspreppen. Dann einen Monat (und viele Microsoft Patchdays) später, kommt die Erkenntnis, dass man mal wieder an das Image ranmüsste. Also ein drittes mal syspreppen. Die Welt ist immer noch in Ordnung.

Versucht man es jetzt aber dann - aus welchem Grund auch immer - ein viertes Mal, wird man bitter enttäuscht.

Beim Versuch Sysprep (mit der Generalisierungs-Option) aufzurufen, hagelt es bitterböse Fehlermeldungen, die unter %windir%\System32\Sysprep\Panther\Setuperr.log nachzulesen sind.

Fehler [0x0f0082] SYSPRP LaunchDll: Fehler beim Ausführen von "C:\Windows\System32\slc.dll, SLReArmWindows', ist aufgetreten Fehlercode-1073425657 zurückgegeben



Fehler [0x0f0070] SYSPRP RunExternalDlls: Fehler beim Ausführen Registrierung Sysprep DLLs, die Ausführung von Sysprep anzuhalten. DwRet =-1073425657



Fehler [0x0f00a8] SYSPRP WinMain: Treffer Fehler während der Verarbeitung Sysprep Anbieter verallgemeinern, hr = 0xc004d307

Tja, googled man ein wenig, findet man in der Microsoft Knowledgebase folgende Hinweise:

Ursache: This error may occur if the Windows Software Licensing Rearm program has run more than three times in a single Windows image.



Lösung: To resolve this issue, you must rebuild the image.

Also, man darf sein Image neu bauen.

Der KB-Artikel von Microsoft verwirrt im ersten Moment ein wenig. Dort heißt es: To work around this issue, use the "SkipRearm" setting in an XML answer file (Unattend.xml) to skip the Rearm process when you build the Windows Vista image.

Von einem Workaround kann aber nicht die Rede sein. Denn was hier nicht steht ist, dass man *vor* dem dritten Mal Syspreppen die unattend.xml hätte erstellen müssen, die das sog. "rearm"-ing des Builds verhindert.

Für mich war das echt neu und somit hielt sich die Begeisterung echt in Grenzen.

Ich kann nur von Glück sagen, dass der Kunde ein nicht ganz frisches Backup (Stand Sysprep zum Ersten) "auf Tasch" hatte. Mit dem Stand hatte ich also noch zwei Schuss frei und konnte somit also das Rapid Deployment der Umgebung durchführen.

Es bestätigte sich also was ich schon seit Jahren predige: Cloneing von XenApp-Servern gilt es zu vermeiden. Automatisierte Installationen (á la WDS, WIM, OSD, NetInstall) oder besser noch die Königslösung mit dem Citrix Provisioning Server sind das einzig wahre.

Wieder ein Stückchen schlauer...

Übrigens: NewSID von Sysinternals funktioniert auch nicht unter Windows Server 2008 x64 und unter 2008 R2 schon mal gar nicht.

Momentan ist mir keine andere Technologie bekannt, mit der ich doch noch Microsoft-konform die SID des Clones anpassen könnte.

Ach ja: Schuld ist natürlich die dämliche (Sorry MS...) Produktaktivierung die trotz eines laufenden KMS keine dritte Aktivierung zulässt.

Lizensierung von Windows Server Betriebssystemen in virtuellen Umgebung

Ich freue mich sehr über Feedback auf unserem Blog und möchte aus diesem Grund gerne auch direkt auf ein anonymes Kommentar zu meinem Artikel "Liebe Microsoft, darf ich das jetzt eigentlich auch virtualisieren?" eingehen.

Microsoft lebt zu einem großen Teil, oder auch zum größten Teil, durch den Verkauf seiner Windows Betriebssysteme. Das Lizensierungsmodell für die Betriebssysteme wurden zu einer Zeit entwickelt zu der Virtualisierung noch eine Nieschenlösung war und Windows Server noch auf physikalische Hardware installiert wurde - soll übrigens heutzutage auch noch vorkommen! ;) Aus diesem Grund sind Windows Server Lizenzen auf eine physikalische Hardware gebunden, auch wenn Sie virtuell genutzt werden.

Mit dem Kauf einer Windows Server Lizenz erhält man immer eine Lizenz zur Installation des Betriebssystems auf eine physikalische oder virtuelle Hardware. Weiterhin gibt es Editionen (Enterprise, Datacenter) die es auch erlauben mehr als eine virtuelle Maschine mit dem Betriebssystem zu bestücken.

• Window Server 2008 Standard beinhaltet eine physikalische und eine virtuelle Lizenz
• Windows Server 2008 Enterprise beinhaltet eine physikalische und vier virtuelle Lizenzen
• Windows Server 2008 Datacenter beinhaltet eine physikalische und unlimitierte virtuelle Lizenzen

Hierbei muss man beachten, dass sich diese Lizensierung auch wieder auf eine Hardware bezieht, d.h. installiere ich auf eine Hardware Windows Server 2008 in der Enterprise Edition, so darf ich auf dieser Hardware, und nur auf dieser Hardware, auch vier virtuelle Windows Server 2008 Instanzen betreiben, z.B. mit Hyper-V.

Nutze ich nun eine andere Virtualisierungslösung wie z.B. VMware vSphere oder Citrix XenServer, darf ich, wenn ich wieder die Windows Server 2008 Enterprise Edition habe, auch hier vier virtuelle Windows Server betreiben, aber nicht fünf - warum? Die erste Lizenz, welche für die physikalische Hardware bestimmt ist, darf auch nur auf physikalischer Hardware installiert werden. Da hier aber nun ESX oder XenServer auf der Physik läuft, fällt diese Lizenz weg.

Möchte ich nun mehr als vier virtuelle Windows Server Instanzen betreiben, muss ich natürlich weitere Lizenzen, entsprechend der Anzahl der zusätzlichen virtuellen Maschinen, kaufen.

Diese Lizensierung bezieht sich momentan nur auf ein physikalische System, welches eine entsprechende Anzahl von virtuellen Maschinen betreibt. Was passiert nun aber wenn ich Features wie VMotion (XenMotion, Live Migration) oder High Availibility (automatischer Neustart einer virtuellen Maschine bei Ausfall eines Hostsystems) nutzen möchte?
In diesem Fall muss ich für die virtuellen Maschinen, welche diese Features nutzen sollen, die Lizenz mehrfach vorhalten! Möchte ich also 10 virtuellen Maschinen ermöglichen via Live Migration auf einen weiteren Virtualisierungsserver (ESX, Hyper-V oder XenServer) umzuziehen, brauche ich auf beiden Virtualisierungsservern (Quelle- und Ziel) jeweils 10 Lizenzen. Habe ich also z.B. 10 Hostsysteme, möchte diese in einem Clusterverbund betreiben und möchte auf jedem Hostsystem 10 virtuelle Maschinen mit Windows betreiben, so brauche ich im Endeffekt 100 Windows Server Lizenzen.

Hier auch nochmal das Rechenbeispiel zu dem anfänglich genannten Blogeintrag:

In einem VMware Cluster mit 10 physikalischen Hosts benötigen wir PRO WINDOWS VM 10 Windows OS Lizenzen, da sich die Windows Workload durch vMotion auf jedem der physikalischen Hosts befinden kann. Fahren beispielsweise 200 Windows VMs in einem 10-Node VMware Cluster, so müssen 2000 Windows Lizenzen bereitgestellt werden, um den vertraglichen Bindungen gerecht zu werden.

Dies ist ein realer Fakt und muss beachtet werden! Grund hierfür ist, wie bereits erwähnt, das Windows Server Lizenzen auf physikalische Hardware gebunden sind.

Nichtsdestotrotz hat man durch die oben genannten Lizensierungsmöglichkeiten (Enterprise, Datacenter) gewisse Einsparungspotentiale, die ich nun in einem kleinen Rechenexample aufzeigen werden. Ich werde hierbei nur die Kosten der Windows Lizenzen und nicht die Kosten der Virtualisierungslösung selbst betrachten.

Von folgenden Preisen gehe ich bei meinen Berechnungen aus:

• Windows Server 2008 Standard kostet pro Server (1-4 CPUs) 719$
• Windows Server 2008 Enterprise Edition kostet pro Server (1-8 CPUs) 2334$
• Windows Server 2008 Datacenter Edition kostet pro CPU-Socket 2381$

Weiterhin gehe ich von einer VMware vSphere Infrastrukur mit 10 Hostsystemen (ESX-Server mit jeweils zwei CPU-Sockets) und 200 Windows VMs aus. Dies entspricht heutzutage einer sehr typischen Architektur.

Bei einer Windows Server 2008 Standard-Lizensierung würde man das ganze wie folgt berechnet:
(10 Hostsysteme x 200 Windows VMs) x 719$ = 1 438 000$

Bei einer Windows Server 2008 Enterprise-Lizensierung würde die Formel wie folgt aussehen:
(10 Hostsysteme x (200 Windows VMs / 4)) x 2334$ = 1 167 000$
Hierbei werden die VMs durch 4 geteilt, da ja eine Enterprise-Lizenz vier virtueller Lizenzen beinhaltet.

Bei einer Windows Server 2008 Datacenter-Lizensierung fällt das Rechenexample wie folgt aus:
(10 Hostsysteme x 2 CPU Sockets) * 2381$ = 47620$
Da hier die Lizensierung auf CPU-Socket-Basis passiert und anschließen eine unlimitierte Anzahl von virtuelle Maschinen auf einer Physik betrieben werden kann, fällt die Anzahl der virtuellen Maschinen bei der Berechnung nicht ins Gewicht.

Man sieht recht schnell, dass sich in einem Virtualisierungsumfeld der Einsatz der zunächst teurer wirkenden Datacenter-Lizenzen auf alle Fälle lohnt. Natürlich kann die Rechnung in einem kleineren Umfeld (2 Host-Systeme und eine handvoll VMs) auch nicht aufgehen und die Lizensierung auf Basis von Standard-Lizenzen günstiger sein.

Microsoft bietet auch hier zwei nette Windows Server Virtualization Calculators, welche bei der Bestimmung der besten Lizensierung hilfreich sind.

Wer sich das ganze im Detail anschauen möchte, den verweise ich gerne auf folgende Dokumente von Microsoft:

1. Windows Server 2008 Licensing Overview
2. Licensing Microsoft Server Products in Virtual Environments
3. Licensing Microsoft Windows Server 2008 to Run with Virtualization Technologies
   

Ich hoffe damit die Lizensierung von Microsoft Windows Server 2008 in virtuellen Umgebungen etwas klarer gemacht zu haben.