Sysprep schlägt bei (Lenovo) OEM-Systemen fehl

Vor ein paar Tagen bin ich auf ein kurioses Problem gestoßen, welches ich hier kurz adressieren möchte. Der Windows-Befehl sysprep stirbt auf OEM-Systemen (konkret ging es um Lenovo-Rechner) mit der Fehlermeldung "Schwerwiegender Fehler bei der Systemvorbereitung des Computers". Wer braucht sysprep, und warum scheitert es, das wären die Fragen.

Sysprep: Wozu wird das gebraucht?

Sysprep ist ein in Windows enthaltenes Tool (Windows-Ordner system32\sysprep), um eine Windows-Installation vor der Verteilung auf andere Systeme in einen definierten "Anfangszustand" zurückzusetzen. Je nach Optionen lässt sich Windows generalisieren (verallgemeinern) oder in den Out-of-Box-Experience-Modus (OOBE) versetzen. Dieser Modus ermöglicht dem Benutzer beim nächsten Start Windows neu einrichten zu lassen.

Bei der Anwendung von Sysprep werden verschiedene Sachen wie die Security IDs (SID) der Benutzerkonten, die Aktivierung und Hardware-Einstellungen entfernt, so dass es keine Konflikte gibt, wenn mehrere Maschinen in einem Domänennetzwerk eingebunden werden. Nach Anwendung von sysprep kann man die Maschine mit Windows PE booten und über den DISM-Befehl ein Abbild der Installation in eine WIM-Datei speichern lassen. Das Ganze eignet sich zum Erstellen einer Installationsdatenträgers, so dass die Masterinstallation auf mehreren Rechnern ausgerollt werden kann.

Die Wirkungsweise von sysprep ist z.B. in diesem Wikipedia-Artikel skizziert. Die Parameter von sysprep und weitere Informationen finden sich in diesem Technet-Artikel. Anhand dieser Beschreibung dürfte den Blog-Mitlesern wohl klar sein, dass kaum ein normaler Windows-Anwender sysprep einsetzt (und das sollte man tunlichst auch nicht auf dem Produktivsystem tun, da nach 3 sysprep-Einsätzen Schluss ist). Üblicherweise verwendet man eine virtuelle Maschine, um die Installation mit anschließendem sysprep durchzuziehen, dann das Ergebnis zu capturen und als Installationsmedium bereitzustellen. Microsoft hat die Ansätze in seinem Microsoft Deployment Tookit MDT 2012 bzw. in dessen Dokumentation beschrieben. Ich selbst habe mit den Funktionen nur einmal im Rahmen des nachfolgend verlinkten "Windows 7 – Handbuch für Fortgeschrittene"-Buchprojekts herumgespielt.

Weitere Infos zu Windows 7 finden sich in meinen Windows 7-Titeln.

Wo liegt das Problem?

Die letzten Tage habe ich mich mit Fragen zum Erstellen von Windows To Go für einen geplanten Artikel befasst. Dort adressiere ich auch, wie man sich als Anwender eine install.wim basteln kann, wenn der OEM-Hersteller einen im Regen stehen lässt und keinen Windows 8-Datenträger mitliefert. Klappte bei mir auch wunderbar – inklusive sysprep – ich habe in einer virtuellen Maschine mit meinen MSDN-ISO-Installationsabbildern experimentiert.

So weit, so gut, Artikel fertig, gefreut und abgeschickt. Nach ein paar Tagen erreichte mich ein Anruf des verantwortlichen Redakteurs, den ich darum gebeten hatte, die Schritte im Artikel mal auf einem OEM-System nachzuvollziehen. Bei ihm, auf einem Lenovo-System verabschiedete sich sysprep unter Windows 8 mit dem Hinweis "Schwerwiegender Fehler bei der Systemvorbereitung des Computers".  Das war natürlich irgendwie "Scheibenkleister". Ich habe kurz recherchiert, nix gefunden und dann aufgesteckt.

Einen Tag später stoße ich im Microsoft Answers-Forum auf diesen Thread: Jemand will ein eingerichtetes Master-Image von einem Lenovo T530 mit sysprep generalisieren und auf weitere Lenovos in der Firma ausrollen. Er schreibt:

Leider bricht sysprep beim Generalisieren mit der Fehlermeldung "Schwerwiegender Fehler bei der Systemvorbereitung des Computers" ab.
Es ist das erste Mal das sysprep ausgeführt wird. Im Log von sysprep steht folgendes:
2013-04-10 13:49:35, Error SYSPRP SPPNP: Failed to secure driver file C:\Intel\Wireless\WIFIWU\Intel HS Bluetooth.msi. Err = 0x3 2013-04-10 13:49:35, Error SYSPRP SPPNP: Failed to secure driver file C:\Intel\Wireless\WIFIWU\IntelHS.cab. Err = 0x3 2013-04-10 13:49:35, Error SYSPRP SPPNP: Failed to secure driver file C:\Intel\Wireless\WIFIWU\WU_PROSET.msi. Err = 0x3 2013-04-10 13:49:35, Error SYSPRP SPPNP: Failed to secure driver file C:\Program Files\Realtek\Audio\HDA\AERTSr64.exe. Err = 0x2 2013-04-10 13:49:35, Error SYSPRP SPPNP: Failed to secure driver file C:\Windows\system32\igfxpph.dll. Err = 0x2 2013-04-10 13:49:35, Error SYSPRP SPPNP: Failed to secure driver file C:\Windows\system32\igfxress.dll. Err = 0x2 2013-04-10 13:49:35, Error SYSPRP SPPNP: Failed to secure driver file C:\Windows\system32\igfxtray.exe. Err = 0x2 2013-04-10 13:49:35, Error SYSPRP SPPNP: Failed to secure driver file C:\Windows\system32\RCUVCAVS.ax. Err = 0x2 2013-04-10 13:49:35, Error SYSPRP SPPNP: Failed to secure driver file C:\Windows\system32\RTSnMg64.cpl. Err = 0x2 2013-04-10 13:49:35, Error SYSPRP Package Microsoft.VCLibs.110.00_11.0.51106.1_x86__8wekyb3d8bbwe was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image. 2013-04-10 13:49:35, Error SYSPRP Failed to remove apps for the current user: 0x80073cf2. 2013-04-10 13:49:35, Error SYSPRP Exit code of RemoveAllApps thread was 0x3cf2. [gle=0x000000cb] 2013-04-10 13:49:35, Error [0x0f0082] SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'SysprepGeneralize' from C:\Windows\System32\AppxSysprep.dll; dwRet = 0x3cf2[gle=0x000000cb] 2013-04-10 13:49:35, Error SYSPRP ActionPlatform::ExecuteAction: Error in executing action; dwRet = 0x3cf2[gle=0x000000cb] 2013-04-10 13:49:35, Error SYSPRP ActionPlatform::ExecuteActionList: Error in execute actions; dwRet = 0x3cf2[gle=0x000000cb] 2013-04-10 13:49:35, Error SYSPRP SysprepSession::Execute: Error in executing actions from C:\Windows\System32\Sysprep\ActionFiles\Generalize.xml; dwRet = 0x3cf2 2013-04-10 13:49:35, Error SYSPRP RunPlatformActions:Failed while executing SysprepSession actions; dwRet = 0x3cf2 2013-04-10 13:49:35, Error [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x3cf2 2013-04-10 13:49:35, Error [0x0f00a8] SYSPRP WinMain:Hit failure while processing sysprep generalize internal providers; hr = 0x80073cf2

Zwischenzeitlich wird der Thread im Technet-Forum weitergeführt. Ich habe dann noch etwas weiter recherchiert und weitere Fundstellen gefunden.

a1: Sysprep Fails / "Windows could not finish configuring the system (gelöscht)
a2: Windows could not finish configuring the system error after …
a3: ConfigMgr 2007: OSD fails with "Sysprep did not complete … (Vista)
a4: Sysprep fails to write registry, Reseal Fails: Microsoft, Windows XP …
a4: Noch ein sysprep-Problem bei DELL-Rechnern (gelöscht) (Windows 7)

Eine Lösung habe ich noch nicht, möchte aber mal die Ergebnisse meiner Recherche hier zusammen kehren.

Gilt das für alle OEM-Systeme, oder nur für Lenovo?

Erste Überlegung war, dass es vielleicht eine generelle "Schweinerei" ist, die in allen OEM-Systemen mit Windows 7/8 lauert. Ich konnte es adhoc, mangels Windows 8 OEM-Systemen, nicht testen. Die Tatsache, dass ich aber wenig Belastbares  zu "sysprep und OEM systems" im Internet fand, sprach eigentlich gegen ein generelles Problem. Zudem hatten die in der Redaktion einen Lenovo, der oben erwähnte Forenposter ebenfalls – und bei Recherchen stieß ich auch weiterhin vorwiegend auf den Namen Lenovo.

Wie das Leben so Zufall spielt, hatte ich wegen des Themas Win 8: Windows Features werden konfiguriert Kontakt mit den Leuten bei Medion, die für die Erstellung der Master-Images von Windows 8 zuständig sind. Wir haben das sysprep-Problem kurz diskutiert, dort konnte man sich keinen Reim darauf machen. Und wegen anderer Sachen hat mir Medion für ein paar Tage ein Testsystem mit Windows 8 bereitgestellt.

Ich habe also mal flugs auf dem Medion PC MD 8380 einen sysprep-Lauf durchgeführt (Achtung: Nicht zur Nachahmung auf den privaten Rechnern empfohlen).  Das Tool lief durch, führte den von mir erzwungenen Neustart durch, begann, einige Konfigurierungsschritte mit Restarts zu durchlaufen und landete dann im eingestellten OOBE-Modus. Sprich: Ich konnte danach die Sprache auswählen und im Nachgang wurde Windows 8 neu, samt Benutzerkonto, aufgesetzt.  Da ich sysprep unter meinen Standard-Administrator (statt unter dem deaktivierten Konto "Administrator") ausgeführt hatte, lagen anschließend auch zwei Benutzerkonten – das Alte und das neu beim OOBE-Setup eingerichtete Konto vor. Also war die Aussage der Medion-Technik bestätigt, dass es kein generelles OEM-sysprep-Problem gäbe.

Ursachen und Erklärungsversuche

Nun wird's naturgemäß schwierig. Es deutet darauf hin, dass da ein Problem bei Lenovo vorliegt. In diesem Forenthread gibt noch jemand den Hinweis, dass man sysprep in den Audit-Mode neubooten lassen kann. Er hatte die Anmeldung nach dem Neustart mittels der Tastenkombination Strg+Shift+F3 wohl abgewürgt.

Hier im Forenthread findet sich der Hinweis (zu Windows 7), dass eine Medienfreigabe zu Problemen mit der Datei drmv2clt.dll führen kann. Lässt sich nicht so ganz nachvollziehen, aber egal.

Interessanter sind aber folgende zwei Überlegungen. In einem älteren Supportartikel [b1] weist Microsoft auf nicht von sysprep unterstützte Szenarien hin. Eine mögliche Ursache kann ein Upgrade von einem Vorsystem sein. Und Microsoft unterstützt kein sysprep auf OEM-Systemen, wie immer man das interpretieren mag. Hintergrund ist dort aber das lizenzrechtliche Problem, dass Microsoft nicht möchte, dass ein so gezogenes Image auf andere OEM-Maschinen ausgerollt wird. Im deutschen bzw. europäischen Rechtsraum ist diese Position aber nach meiner Einschätzung nicht wirklich haltbar, wenn auf den Zielmaschinen eine OEM-Lizenz vorhanden ist. Aber die Juristen sehen das möglicherweise anders – ist nicht mein Bier und technisch funktioniert es (wie ich beim Medion-System feststellen konnte).

b1: Unsupported Sysprep scenarios

Und in der Forendiskussion unter [b2] kam noch ein interessanter Aspekt zum Vorschein. Ein sysprep lässt sich auf einem System nur drei Mal durchführen (danach muss neu aufgesetzt werden). Ist von Microsoft so vorgesehen. Der Beitrag [b3] verrät zwar den Trick, wie man das umgehen kann. Aber: Wenn Lenovo auf dem Masterimage genau diese drei sysprep-Läufe durchgeführt hat, dann das Image captured und auf seine Distributionsmedien kopiert, wäre das eine Erklärung.

b2: Forendiskussion in einer britischen Community
b3: Sysprep your system for more than 3 times

Im Technet-Forum (bzw. im MS-Answers-Forum) deutet es sich an, dass Lenovo-Apps eine Ursache sind. Auch in anderen Foren habe ich Hinweise gefunden, dass Anwendungen den sysprep-Lauf zum Abstürzen bringen können. Ich behalte es mal im Auge. Falls es neue Erkenntnisse gibt, trage ich das als Kommentar nach. Vielleicht kontaktiere ich auch Lenovo, in der Hoffnung, eine Antwort zu erhalten.

Update: Es scheint so zu sein, dass bei dem Lenovo-System zwei Lenovo Apps die Ursache sind. Der oben erwähnte Nutzer hat zwischenzeitlich seine Erkenntnisse im Technet-Forum mitgeteilt.