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.

Group Policy Drive Maps und UAC (User Account Control)

Wer schon mal Laufwerke per Gruppenrichtlinie verbunden hat, hat sich vielleicht auch schon gewundert, warum das auf Servern mit Windows Server 2008 nicht zu funktionieren scheint. Der Grund ist die standardmäßig aktivierte UAC!

Das Laufwerk wird beim Anmelden quasi nur mit dem vollen Administrator-Token verbunden und ist mit dem eingeschränkten Token dann nicht sichtbar.

Um das Laufwerk sichtbar zu machen, muß man in der Registry-Wert ein DWORD namens "EnableLinkedConnections" unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" erstellen und auf den Wert "1" setzen.

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.

Und jetzt räumt Microsoft das (Servervirtualisierungs-)Feld von hinten auf: Hyper-V 2008 R2

Microsoft betreibt gerade sehr stark virales Marketing, auf allen Microsoft affinen Blogs ist etwas über die neue, kommende Hyper-V Version 2008 R2 zu lesen und das zu recht.

Microsoft räumt das Servervirtualisierungsfeld von hinten auf und setzt mit vielen neuen Features den Mitbewerb unter Druck.

Features:

• Live Migration - VMotion bzw. XenMotion aus dem Hause Microsoft, d.h. Verschieben von virtuellem Maschinen im laufenden Betrieb
• Fail-over Clustering - auch unter Restart HA bekannt, stürzt ein Hostsystem ab so werden die Workloads auf einem anderen Host automatisch neugestartet
• 64 logische Prozessoren (Cores) am Hostsystem
• 1TB RAM am Hostsystem
  
• 384 laufende virtuelle Maschinen und 512 virtuelle Prozessoren pro Server
• CPU Core Parking - erlaubt es nicht genutzte CPU Cores auszuschalten um Strom zu sparen, ganz im Sinne von Green IT
• Processor Compatibility - die Möglichkeit virtuelle Maschinen im laufenden Betrieb zu migrieren, auch wenn sich die CPUs unterscheiden (z.B. zwischen einem System mit Core 2 Duo und Core 7i (Nehalem), nicht aber zw. AMD und Intel)
  
• Jumbo Frames in virtuellen Maschinen
  
• Hot add / remove von virtuellen SCSI Festplatten - hinzufügen und entfernen von virtuellen Festplatten im laufenden Betrieb
  
• VM Chimney (TCP offloading support in virtuellen Maschinen) - die Möglichkeit virtuellen Maschinen eine dedizierte Netzwerkkarten zuzuweisen und somit die virtuelle Netzwerkkarte zu umgehen

und das Beste zum Schluss: alle diese Features sind in der kostenfreien Edition, dem Microsoft Hyper-V Server 2008 R2 enthalten.

Diesen kann man sich aktuell als Release Candidate bereits für Proof-of-Concept und Pilotumgebung herunterladen.

Viele weitere Features (z.B. P2V, Patch-Management uvm.) kommen mit dem Einsatz des System Center Virtual Maschine Managers R2 noch hinzu, und das nicht zu knapp. Diese werden allerdings ein andermal besprochen.