Windows 10 Enterprise: Upgrade-Hürden per Log gemeistert

Bei einem Funktionsupdate von Windows 10 auf eine neue Build kann ja einiges schief gehen. Mitunter hilft aber die Auswertung der Protokolldateien, um eine Idee für den Grund des Updatefehlers herauszufinden.

Ich bin zufällig auf diesen Blog-Beitrag gestoßen, wo jemand Probleme beim Upgrade von Windows 10 Enterprise Version 1607 auf die Version 1709 hatte. Es sollten ca. 70 Maschinen schlicht auf die Version 1709 aktualisiert werden. Der Administrator betreut einen Park von ca. 600 Windows 10-Maschinen, wobei die Updates per SCCM (System Center Configuration Manager) verwaltet werden.

Upgrade-Installation bleibt bei 44% hängen

Das Fehlerbild, was der Administrator auf den Maschinen bekam, dürfte manchem Windows 10-Nutzer bekannt vorkommen. Während die meisten Maschinen keine Probleme beim Upgrade machten, scheiterte dieses bei vier Maschinen. Die Installation lief bis zur Anzeige 44% durch, um dann abzubrechen. 

Es erschien nur der Hinweise von Windows-Setup "Windows Setup could not configure Windows on this computer's hardware." – und nach dem Anklicken der OK-Schaltfläche erfolgte ein Rollback auf die vorherige Version.

Verschiedene Stufen während der Installation

Windows 10 verwendet bei der Installation von Funktionsupdates (Feature-Upgrades) einen gestuften Installationsvorgang, der in 4 Schritten (und ggf. einem fünften Fehlerschritt) besteht, siehe folgendes Bild.

(Quelle: Microsoft)

Das obige Schema zeigt die Phasen einer erfolgreichen Installation. Die Installation gliedert sich in folgende Phasen:

• Downlevel phase (Phase 1): Läuft unter dem alten Windows, wo die zu installierenden Komponenten und Informationen gesammelt werden. Die Phase umfasst 0-30% des Installationsvorgangs.
• Safe OS phase (Phase 2): In dieser Phase wird die Recovery Partition konfiguriert und das Upgrade wird installiert. Das findet unter Windows PE statt und dort wird ein Rollback vorbereitet. Die Fortschrittsanzeige bewegt sich dort zwischen 0 und 30%.
• First boot phase (Phase 3): Das ist die Phase wo Windows nach der Safe OS-Phase zum ersten Mal gebootet wird. Dort zeigt die Fortschrittsanzeige Werte zwischen 31 und 74 %.
• Second boot phase (Phase 4): Während dieser Phase werden die endgültigen Einstellungen gesetzt. Die Phase ist auch als OOBE boot phase geläufig. Hier zeigt die Fortschrittsanzeige Werte zwischen 75 und 100 %.
• Uninstall phase: Diese Phase wird nur eingeleitet, wenn das Upgrade nicht erfolgreich durchgeführt werden kann.

Diese Stufen hatte ich im Blog-Beitrag Windows 10: Upgrade-Fehler analysieren und beheben detaillierter beschrieben. Werden während dieser Phasen Fehler festgestellt und kommt es zu Rollback, lässt sich über den Fehlercode erkennen, in welcher Phase ein Fehler aufgetreten ist und gegebenenfalls, was die Ursache ist.

(Quelle: WZor/Twitter)

Die Eingangs gegebenen Informationen benennen aber keinen Fehlercode, sondern nur ein Rollback bei 44 % des Installationsvorgangs. An Hand der obigen Phasen lässt sich aber erkennen, dass es in Phase 3 zum Installationsabbruch gekommen sein muss. Ich hatte dies im Blog-Beitrag Windows 10 (Version 1803): Beschleunigte Featureupdates versprochen (und im Beitrag Windows 10 V1709: Microsoft erklärt das Rollout) bereits skizziert.

Übliche Maßnahmen scheitern

Der Betroffene versuchte dann noch eine Upgrade-Installation per DVD, scheiterte dann aber mit dem Fehlercode 0x80070570 – 0x2000c, "Die Installation war nicht erfolgreich. In der Phase SAFE-OS ist während des Vorganges APPLY-IMAGE ein Fehler aufgetreten." Deckt sich also mit den obigen Erkenntnissen.

Die üblichen Maßnahmen wie Prüfung von Windows auf Beschädigungen mittels sfc /scannow, eine Festplattenprüfung etc. scheiterten. Der Betreffende hat das alles in seinem Blog-Beitrag geschildert.

Auswerten der Protokolldatei

Um die Fehlerursache einzugrenzen, bleibt nur die Auswertung der Protokolldateien der Installation. Ich hatte das Thema im Blog-Beitrag Windows 10: Protokolldateien bei Upgrade-Fehlern analysieren behandelt. Dieses Microsoft-Dokument benennt ebenfalls die erzeugten Log-Dateien.

Nach Auswertung der log-Dateien blieben nur einige Einträge, die ein Scheitern während des SysPrep-Laufs berichteten. Die Datei:

DLL C:\Windows\System32\inetsrv\iissyspr.dll

konnte nicht geladen werden. Diese DLL-Datei gehört zum IIS-Webserver, der sich unter Windows über Features optional installieren lässt. Da der IIS auf den Maschinen nicht benutzt wurde, hat der Administrator die IIS 6-Verwaltungskonsole in den Features deaktiviert (siehe auch die Erklärung hier). Nach einem Neustart konnten auch diese Maschinen auf die Version 1709 aktualisiert werden. Interessant ist die Erklärung des Betroffenen, warum der IIS 6 auf den Systemen überhaupt aktiviert war.

Ähnliche Artikel:
Windows 10: Update-Protokolldatei auslesen
Windows 10: Protokolldateien bei Upgrade-Fehlern analysieren
Windows Fehler entschlüsseln
Windows 10: Upgrade-Fehler analysieren und beheben
Windows 10: Update-Fehlercodes 0x8024…. entschlüsselt
Windows lädt permanent Updates neu
Windows 10 V1709: Microsoft erklärt das Rollout
Windows 10 (Version 1803): Beschleunigte Featureupdates versprochen