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.
