Korrupter Windows Server nach Windows Update
Wenn ein Windows Update fehlschlägt oder der Server während des Updateprozesses unerwartet ausgeschaltet wird, sollte die Gesundheit der Systemdateien anschließend mit Hilfe des Tools sfc /scannow oder DISM überprüft werden. Doch was ist zu tun, wenn das System nicht automatisch repariert werden kann?
Das Systemdatei-Überprüfungsprogramm (SFC.exe)
Microsoft empfiehlt die Verwendung des System File Checker Tools, um geschützte Windows Ressourcen zu scannen und gegebenenfalls zu reparieren. In unserem Beispiel wurde nach einem fehlgeschlagenen Update das gesamte System gescannt. Dazu wird eine Eingabeaufforderung (cmd) als Administrator geöffnet und folgender Befehl ausgeführt:
sfc /scannow
Dies ist nach 44% der Überprüfung mit der Meldung Windows Resource Protection could not perform the requested operation fehlgeschlagen.
Wenn diese Operation fehlschlägt, kann als nächstes das Tool DISM für die Überprüfung genutzt werden.
Das Tool „Abbildverwaltung für die Bereitstellung“ (DISM)
Seit Windows 8 bzw. Windows Server 2012 kann ebenfalls das Tool DISM genutzt werden, um Windows auf Beschädigungen von Systemdateien zu überprüfen. Insbesondere bei Problemen mit Windows Updates und Upgrades ist diese Überprüfung sinnvoll, da ein Update unter Umständen nicht installiert werden kann, wenn Systemdateien beschädigt sind.
Da wir in unserem Beispiel von einer Beschädigung ausgehen, die mit Hilfe von sfc nicht behoben werden konnte, führen wir DISM mit den Parametern Online, Cleanup-Image und Restorehealth aus, um das aktuelle laufende Windows System (Parameter Online) zu überprüfen und reparieren (Parameter Cleanup-Image). Der gesamte Befehl wird in einer Eingabeaufforderung (cmd) als Administrator ausgeführt:
DISM /Online /Cleanup-Image /Restorehalth
In unserem Fall schlug die Überprüfung mit folgender Meldung fehl:
Error: 1726
The remote procedure call failed.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
Das erwähnte Logfile hat in unserem Fall keine weiteren Erkenntnisse geliefert. Der zugehörige RPC Dienst war auf der Maschine ebenfalls gestartet. Die Firewall und Antivirus konnten als Fehlerquelle ausgeschlossen werden.
Ein weiteres wichtiges Logfile, das von DISM erstellt wird, ist das CBS.log. Es befindet sich unter %windir%/Logs/CBS/CBS.log. Hier wurden unter anderem folgende Probleme in der Zusammenfassung gelistet:
[…]
(p) CBS Catalog Missing Package_6757_for_KB4480961~31bf3856ad364e35~amd64~~10.0.1.3
(p) CBS Catalog Missing Package_6758_for_KB4480961~31bf3856ad364e35~amd64~~10.0.1.3
Summary:
Operation: Detect only
Operation result: 0x0
Last Successful Step: CSI store detection completes.
Total Detected Corruption: 118
CBS Manifest Corruption: 118
CBS Metadata Corruption: 0
CSI Manifest Corruption: 0
CSI Metadata Corruption: 0
CSI Payload Corruption: 0
[…]
Es ist zu erkennen, dass insgesamt 118 CBS Manifest Corruptions gefunden wurden. Diese beziehen sich alle auf das Update KB4480961 (das Log wurde zur besseren Lesbarkeit abgeschnitten). Dieses Update wurde bereits einige Monate zuvor installiert. Wie kann man die fehlenden Dateien nun zum Windows Image hinzufügen?
Windows Update mit DISM einspielen
Da wir das problematische Windows Update erfolgreich identifizieren konnten, können wir es im nächsten Schritt vom Microsoft Update Catalogue herunterladen und installieren.
Das Update wird mit dem Namen windows10.0-kb4480961.msu im Ordner C:\temp gespeichert. Damit das Update hinzugefügt werden kann, muss es zunächst entpackt werden.
Expand -F:* windows10.0-kb4480961.msu C:\temp\4480961
Nach dem Entpacken kann die zugehörige cab-Datei mit DISM zu unserem Image hinzugefügt werden:
DISM /online /Add-Package /PackagePath:c:\temp\4480961\Windows10.0-kb4480961-x64.cab
Wenn diese Operation erfolgreich durchgeführt wurde, können wir den Status des Systems erneut überprüfen:
DISM /Online /Cleanup-Image /Scanhealth
Erfreulicherweise erhalten wir nun die Meldung, dass keine component store corruptions mehr erkannt wurden. Wir können also erneut die Überprüfung mit sfc starten:
sfc /scannow
Leider erhalten wir hierbei erneut dieselbe Fehlermeldung wie am Anfang. Ein anschließendes Reparieren mit Hilfe von DISM schlägt ebenfalls fehl:
DISM /Online /Cleanup-Image /Restorehealth
Wie können wir nun die letzten Beschädigungen des Systems ausfindig machen und beheben?
Die Ausgabe der in diesem Abschnitt beschriebenen Befehle sind in Abbildung 1 zu sehen.
Manuelles Ersetzen einer beschädigten Systemdatei
Da in unserem Fall die automatische Reparatur mit sfc nicht erfolgreich ist, müssen wir uns die beschädigten Dateien zunächst ausgeben lassen, bevor wir diese manuell ersetzen können:
sfc /verifyonly
Die hier aufgeführten Dateien unterscheiden sich je nach Problem, weshalb ich hier den Platzhalter Pfad_und_Dateiname verwende. Dieser muss entsprechend angepasst werden. Die Dateien müssen zum Schluss von einem funktionsfähigen System importiert werden. Damit dieser Vorgang erfolgreich durchgeführt werden kann, muss zunächst die Ownership geändert werden:
takeown /f Pfad_und_Dateiname
Anschließend geben wir den Administratoren Vollzugriff auf die Dateien:
icacls Pfad_und_Dateiname /GRANT ADMINISTRATORS:F
Im letzten Schritt können die beschädigten Dateien ausgetauscht werden.
Nach Austausch der Dateien ist unser System wieder in einem gesunden Status, was wir mit sfc überprüfen können.
MEHR BLOG-KATEGORIEN
- ASP.NET
- Active Directory
- Administration Tools
- Allgemein
- Backup
- ChatBots
- Configuration Manager
- DNS
- Data Protection Manager
- Deployment
- Endpoint Protection
- Exchange Server
- Gruppenrichtlinien
- Hyper-V
- Intune
- Konferenz
- Künstliche Intelligenz
- Linux
- Microsoft Office
- Microsoft Teams
- Office 365
- Office Web App Server
- Powershell
- Remote Desktop Server
- Remote Server
- SQL Server
- Sharepoint Server
- Sicherheit
- System Center
- Training
- Verschlüsselung
- Virtual Machine Manager
- Visual Studio
- WSUS
- Windows 10
- Windows 8
- Windows Azure
- Windows Client
- Windows Server
- Windows Server 2012
- Windows Server 2012R2
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
- Zertifikate