Wartung einer WSUS-Instanz im lokalen Intranet

31. Oktober 2015

Eigentlich sollte ein System wie die "Windows Server Update Services" (oder auch kurz WSUS genannt) den Administratoren helfen, ohne großen Aufwand die Verteilung von Updates in einem Netzwerk zu organisieren. Durch die zentrale Verwaltung behält der Administrator den Überblick und kann, was sehr wichtig ist, bei hartnäckigen Update-Fehlern eingreifen. Es kann nämlich sein, dass ein Computer bei jedem Start versucht, ein bestimmtes Update zu installieren, dabei scheitert und sich der Benutzer wundert, warum die Festplatte die ganze Zeit rödelt und der Computer so langsam ist. Um das Problem zu beseitigen, muss der Administrator allerdings erst einmal von der Sache Kenntnis erhalten, wofür die WSUS-Verwaltungsoberfläche normalerweise auch auf hervorragende Art und Weise sorgt. Der untenstehende Screenshot zeigt das Dashboard der WSUS-Software, mit dessen Hilfe man sich schnell einen Überblick über den Gesundheitszustand des gesamten Systems verschaffen kann:

Dashboard der WSUS-Software

So weit so gut. Wie sich allerdings im Laufe der Zeit herausgestellt hat, spart das System aber nicht nur Zeit, sondern benötigt auch selbst einige Aufmerksamkeit, um reibungslos zu funktionieren. In diesem Bericht finden sich zu diesem Thema einige Anleitungen. Mit etwas mehr Mühe und Sorgfalt hätte man diese Wartungsarbeiten auch wieder automatisieren können, so dass das ganze System wartungsfrei wäre. Schade eigentlich - aber worüber sollte ich sonst schreiben :-)?

Es fehlt eine automatische Erfassung von Produkten

Grundsätzlich ist es so, dass man als Systemverwalter einstellen kann, für welche Produkte das WSUS-System Updates herunterladen und verteilen soll. Im Laufe der Zeit ist die Menge der Produkte, die man für die Versorgung mit WSUS auswählen konnte, reichlich unübersichtlich geworden. Selbst als jemand, der sich einigermaßen mit dem ganzen Kram auskennt, weiß ich nicht, was sich hinter jeder Produktbezeichnung verbirgt. Für Windows XP gab es noch genau einen Eintrag. Wenn ich im Netzwerk mindestens einen Windows XP-Rechner hatte, musste ich dieses Produkt ankreuzen und musste mich um nichts mehr kümmern. Wie untenstehender ScreenShot zeigt, ist die Menge der zur Auswahl stehenden Produkte bei Windows 10 auf 6 Produkte angeschwollen.

WSUS-Produktauswahl für Windows 10

Gut, man kann ja schnell im Internet recherchieren, was die einzelnen Produktbezeichnungen bedeuten, es wäre allerdings viel besser, wenn das System, die im Einsatz befindlichen Produkte bzw. Komponenten erfassen und man in der WSUS-Produktauswahl sehen könnte, welche Produkte im betreffenden Netzwerk im Einsatz sind. Man könnte sich dann die Einstellung: "Alle Microsoft-Produkte im Netzwerk automatisch in die Updates einbeziehen" vorstellen. Dann müsste man sich um den Punkt nicht mehr kümmern.

Abstürzender Assistent zur Serververeinigung

In der Vergangenheit ist es auf von mir betreuten Servern schon vorgekommen, dass der "Assistent zur Serverbereinigung" losläuft und beim Löschen nicht verwendeter Updates und Update-Revisionen steckenblieb. Ich dachte immer, dass Microsoft das Problem schon irgendwann beheben würde und bin zur Tagesordnung übergegangen. Als das aber nicht passierte und die Verzeichnisse mit den WSSUS-Dateien und die Datenbank immer weiter wuchsen, habe ich mich im Internet auf die Suche nach einer möglichen Ursache gemacht und bin zum Beispiel auf diese sehr interessante Diskussion gestoßen.

In einem sehr interessanten Beitrag ungefähr in der Mitte in dieser Diskussion analysiert der Benutzrer justUnplugIt das Problem als Timeout beim Löschen eines Updates mit besonders vielen Revisionen. Die Datenbank benötigt für die Operation schlicht zu lange und ein Timeout beendet diesen Vorgang, ohne dass das Update gelöscht würde.

Wie man dieses Problem löst und wie man zum Zwecke der Wartung und der Kontrolle besseren Kontakt zum WSUS-System bekommt, schreibe ich in den nächsten Abschnitten.

Verbindung zur WSUS-Datenbank

Zuallererst ist es sinnvoll, sich dem Datenbankserver, der die Tabellen des WSUS-System beherbergt, zu nähern. Zu diesem Zweck ist es das einfachste, das Management-Studio des SQL-Servers auf dem entsprechenden Windows-Server zu installieren.

Wenn man mit diesem Ziel im Internet nach "SQL Server 2008 R2 Management Studio Express" sucht, gelangt man per Google zu dieser Microsoft-eigenen Seite. Hier ist dann zwar nicht mehr von "R2" die Rede, ich finde allerdings auf den Microsoft-Seiten nichts neueres zu den obigen Suchbegriffen. Wie dem auch sei: Mit dem obigen Download (64 bit-Version) habe ich gerade vor ein paar Tagen eine WSUS-Installation auf die weiter unten beschriebene Art und Weise repariert. Für die Operation ist es not­wen­dig, direkten Kontakt mit der WSUS-Datenbank aufzunehmen: Wenn man dem WSUS-System bei der Installation einen eigenen SQL-Server zur Verfügung gestellt hat, sollte man die Zugangs­daten ent­­­spre­chend kennen. Wenn die Standard-Option gewählt wurde, installiert das WSUS-In­stallations­pro­gramm die sogenannte "Interne Datenbank". Falls man das SQL Server Management Studio auf dem ent­sprechen­den Server erfolgreich installiert hat, kann man sich mit dem Server der internen Datenbank verbinden. Und zwar wählt man bei den Eigenschaften der Verbindung "Named Pipe" und als Server-Namen bis Windows Server 2008 (R2)

\\.\pipe\mssql$Microsoft##SSEE\sql\query

und ab Server 2012

\\.\pipe\Microsoft##WID\tsql\query

Man kann sich, wie der folgende Screenshot zeigt, mit Hilfe dieser Verbindungsangaben dann mit der internen Windows Datenbank verbinden:

Windows Internal Database

Installation von SQLCMD, wenn keine Management-Konsole auf dem Server verfügbar ist

Wenn man keine Management-Konsole auf dem Server verfügbar hat, kann man sich das Befehlszeilen­programm sqlcmd.exe auf dem Computer installieren. Dazu lädt man sich zunächst die » ODBC-Treiber für den MS-SQL-Server und dann das eigentlich » Programmpaket für das Programm sqlcmd direkt von Microsoft herunter und installiert sie dann in dieser Reihenfolge. Die untenstehenden SQL-Routinen speichert man sich als Datei ab und richtet sich eine Batchdatei ein, welche den Aufruf übernimmt. Diese sieht dann zum Beispiel folgendermaßen aus:

sqlcmd -S np:\\.\pipe\Microsoft##WID\tsql\query -i d:\local\sql\WsusDBMaintenance.sql

pause

Bereinigung aller zum Löschen anstehenden Updates durch eine T-SQL-Prozedur

Führt man nun auf der WSUS-Datenbank die Stored Procedure spGetObsoleteUpdatesToCleanup mit Hilfe des Kommandos EXEC spGetObsoleteUpdatesToCleanup aus, so werden alle Updates angezeigt, die nach Meinung des System gelöscht werden können. Baut man nun diese Stored Procedure in eine kleine übergeordnete Prozedur ein, so kann man alle obsoleten Updates aus der Datenbank entfernen, ohne dass es zu irgendwelchen Timeouts kommt:

DECLARE @var1 INT 
DECLARE @msg nvarchar(100) 
CREATE TABLE #results (Col1 INT) INSERT INTO #results(Col1) 
EXEC spGetObsoleteUpdatesToCleanup 
DECLARE WC Cursor FOR SELECT Col1 FROM #results 
OPEN WC 
FETCH NEXT FROM WC INTO @var1 WHILE (@@FETCH_STATUS > -1) 
BEGIN SET @msg = 'Deleting ' + CONVERT(varchar(10), @var1) RAISERROR(@msg,0,1) WITH NOWAIT 
EXEC spDeleteUpdate @localUpdateID=@var1 
FETCH NEXT FROM WC INTO @var1 
END 
CLOSE WC 
DEALLOCATE WC 
DROP TABLE #results

Alternative Lösung durch Änderung des Timeouts

Bei der obigen Lösung kann man dem SQL-Server wunderbar dabei zuschauen, wie er seine Arbeit macht und die obsoleten Updates löscht. Ich habe aber hier noch einen Lösungsansatz gefunden, wie man den Timeout in der Verbindungsschnittstelle direkt deaktiviert. Ganz konkret wird in den Servereinstellungen das Timeout für Remoteabfragen hochgesetzt oder gleich mit Hilfe des Wertes 0 komplett deaktiviert. Diese Änderung der Einstellungen hat zur Folge, dass der Bereinigungsassistent dann wieder ohne weiteres Zutun durchläuft.

Allgemeine Wartung der WSUS-Datenbank

Wenn wir schon mal dabei sind, können wir uns gleich der Anhebung des allgemeine Gesundheitszustandes der WSUS-Datenbank widmen: Ich habe hier das untenstehende Skript gefunden, das der WSUS-Datenbank allgemeine Wartungsoperationen unterzieht.

/****************************************************************************** 
This sample T-SQL script performs basic maintenance tasks on SUSDB 
1. Identifies indexes that are fragmented and defragments them. For certain 
   tables, a fill-factor is set in order to improve insert performance. 
   Based on MSDN sample at http://msdn2.microsoft.com/en-us/library/ms188917.aspx 
   and tailored for SUSDB requirements 
2. Updates potentially out-of-date table statistics. 
******************************************************************************/ 
 
USE SUSDB; 
GO 
SET NOCOUNT ON; 
 
-- Rebuild or reorganize indexes based on their fragmentation levels 
DECLARE @work_to_do TABLE ( 
    objectid int 
    , indexid int 
    , pagedensity float 
    , fragmentation float 
    , numrows int 
) 
 
DECLARE @objectid int; 
DECLARE @indexid int; 
DECLARE @schemaname nvarchar(130);  
DECLARE @objectname nvarchar(130);  
DECLARE @indexname nvarchar(130);  
DECLARE @numrows int 
DECLARE @density float; 
DECLARE @fragmentation float; 
DECLARE @command nvarchar(4000);  
DECLARE @fillfactorset bit 
DECLARE @numpages int 
 
-- Select indexes that need to be defragmented based on the following 
-- * Page density is low 
-- * External fragmentation is high in relation to index size 
PRINT 'Estimating fragmentation: Begin. ' + convert(nvarchar, getdate(), 121)  
INSERT @work_to_do 
SELECT 
    f.object_id 
    , index_id 
    , avg_page_space_used_in_percent 
    , avg_fragmentation_in_percent 
    , record_count 
FROM  
    sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'SAMPLED') AS f 
WHERE 
    (f.avg_page_space_used_in_percent < 85.0 and f.avg_page_space_used_in_percent/100.0 * page_count < page_count - 1) 
    or (f.page_count > 50 and f.avg_fragmentation_in_percent > 15.0) 
    or (f.page_count > 10 and f.avg_fragmentation_in_percent > 80.0) 
 
PRINT 'Number of indexes to rebuild: ' + cast(@@ROWCOUNT as nvarchar(20)) 
 
PRINT 'Estimating fragmentation: End. ' + convert(nvarchar, getdate(), 121) 
 
SELECT @numpages = sum(ps.used_page_count) 
FROM 
    @work_to_do AS fi 
    INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id 
    INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id 
 
-- Declare the cursor for the list of indexes to be processed. 
DECLARE curIndexes CURSOR FOR SELECT * FROM @work_to_do 
 
-- Open the cursor. 
OPEN curIndexes 
 
-- Loop through the indexes 
WHILE (1=1) 
BEGIN 
    FETCH NEXT FROM curIndexes 
    INTO @objectid, @indexid, @density, @fragmentation, @numrows; 
    IF @@FETCH_STATUS < 0 BREAK; 
 
    SELECT  
        @objectname = QUOTENAME(o.name) 
        , @schemaname = QUOTENAME(s.name) 
    FROM  
        sys.objects AS o 
        INNER JOIN sys.schemas as s ON s.schema_id = o.schema_id 
    WHERE  
        o.object_id = @objectid; 
 
    SELECT  
        @indexname = QUOTENAME(name) 
        , @fillfactorset = CASE fill_factor WHEN 0 THEN 0 ELSE 1 END 
    FROM  
        sys.indexes 
    WHERE 
        object_id = @objectid AND index_id = @indexid; 
 
    IF ((@density BETWEEN 75.0 AND 85.0) AND @fillfactorset = 1) OR (@fragmentation < 30.0) 
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE'; 
    ELSE IF @numrows >= 5000 AND @fillfactorset = 0 
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD WITH (FILLFACTOR = 90)'; 
    ELSE 
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD'; 
    PRINT convert(nvarchar, getdate(), 121) + N' Executing: ' + @command; 
    EXEC (@command); 
    PRINT convert(nvarchar, getdate(), 121) + N' Done.'; 
END 
 
-- Close and deallocate the cursor. 
CLOSE curIndexes; 
DEALLOCATE curIndexes; 
 
 
IF EXISTS (SELECT * FROM @work_to_do) 
BEGIN 
    PRINT 'Estimated number of pages in fragmented indexes: ' + cast(@numpages as nvarchar(20)) 
    SELECT @numpages = @numpages - sum(ps.used_page_count) 
    FROM 
        @work_to_do AS fi 
        INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id 
        INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id 
 
    PRINT 'Estimated number of pages freed: ' + cast(@numpages as nvarchar(20)) 
END 
GO 
 
 
--Update all statistics 
PRINT 'Updating all statistics.' + convert(nvarchar, getdate(), 121)  
EXEC sp_updatestats 
PRINT 'Done updating statistics.' + convert(nvarchar, getdate(), 121)  
GO 

Windows 10-Computer werden als Windows-Vista-Rechner erkannt

Es ist schon etwas peinlich für Microsoft, aber es ist tatsächlich passiert: Unser WSUS-System hat die Windows-10-Computer in unserem Netzwerk als Windows Vista-Systeme erkannt. Das hat zwar weiter keine negativen Auswirkungen, da die Updates trotzdem richtig erkannt und installiert werden werden, trotzdem sieht das aber natürlich hässlich oder zumindest irritierend aus. Man kann das Problem händisch beseitigen: Wenn man gemäß der obigen Beschreibungen eine Verbindung zu der WSUS-Datenbank hat, kann man mit der folgenden SQL-Anweisung diese Unschönheit beseitigen:

UPDATE [SUSDB].[dbo].[tbComputerTargetDetail] 
SET [OSDescription] = 'Windows 10' 
WHERE [OSMajorVersion] = '10' AND
   [OSMinorVersion] = '0' AND
   [OldProductType] = '1' AND
   ([OSDescription] <> 'Windows 10' or [OSDescription] IS NULL)

Client-Computer mit Update-Problemen reparieren (Windows Vista-7)

Es kommt immer wieder vor, dass sich bei einzelnen Computern bestimmte Updates ums Verrecken nicht installieren lassen. Es zeigt sich auch nach diversen Neustarts immer wieder dieses Bild in der Systemsteuerung Abteilung Updates:

WSUS Wartung Windows Update Error

Mit der im folgenden beschriebenen Methode habe ich in der Vergangenheit auch die hartnäckigsten Update-Probleme gelöst.

Als ersten Schritt lädt man sich das "Systemupdate Vorbereitungstool Windows6.1-KB947821-v33-x86.msu" von Microsoft herunter und führt es auf dem betroffenen Computer aus. Es rödelt eine ganze Weile vor sich hin und ist irgendwann fertig. Microsoft schreibt, dass bestimmte Probleme alleine durch diesen Vorgang automatisch behoben würden. Das mag sein, ich kann mich jedoch nicht erinnern, dass dies jemals so gewesen ist. Der eigentliche Reparaturvorgang beginnt nämlich erst jetzt: In der Datei %SYSTEMROOT%\Logs\CBS\CheckSUR.log findet sich, so war es zumindest bei dem von mir betreuten Netzwerk (ca. 150 Windows 7-PCs) immer der Fall, eine Auflistung defekter Update-Pakete. Diese müssen jetzt von einem anderen Computer mit gleicher Hard- und Software-Ausstattung auf den PC mit den defekten Updates herüberkopiert werden. Das mache ich immer in zwei Schritten. Zunächst kopiere ich die benötigten Dateien mit dem untenstehenden Skript in ein Netzwerklaufwerk; in meinem Fall das Laufwerk s:\

copy /y c:\windows\winsxs\manifests\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.18766_none_0b32a93025b365c1.manifest s:\ 
copy /y c:\windows\servicing\packages\Package_2_for_KB3020369~31bf3856ad364e35~x86~~6.1.1.1.cat s:\ 
copy /y c:\windows\servicing\packages\Package_2_for_KB3020369~31bf3856ad364e35~x86~~6.1.1.1.cat s:\ 
copy /y c:\windows\servicing\packages\Package_for_KB3020369_RTM~31bf3856ad364e35~x86~~6.1.1.1.cat s:\ 
copy /y c:\windows\servicing\packages\Package_for_KB3020369_RTM~31bf3856ad364e35~x86~~6.1.1.1.cat s:\ 
copy /y c:\windows\servicing\packages\Package_for_KB3020369~31bf3856ad364e35~x86~~6.1.1.1.cat s:\ 
copy /y c:\windows\servicing\packages\Package_for_KB3020369~31bf3856ad364e35~x86~~6.1.1.1.cat s:\ 
pause

Dann wechsele ich zu dem defekten PC und führe das folgende Skript aus:

mkdir c:\Windows\Temp\CheckSUR
mkdir c:\Windows\Temp\CheckSUR\servicing
mkdir c:\Windows\Temp\CheckSUR\servicing\packages 
mkdir c:\Windows\Temp\CheckSUR\winsxs 
mkdir c:\Windows\Temp\CheckSUR\winsxs\manifests 
copy /y s:\*.cat c:\Windows\Temp\CheckSUR\servicing\packages
copy /y s:\*.manifest c:\Windows\Temp\CheckSUR\winsxs\manifests 
pause

Nachdem dieser Schritt vollzogen wurde, starte ich erneut das Vorbereitungstool. Wenn dessen Artbeit getan hat, überprüfe ich wieder die log-Datei. Wenn hier keine defekten Update-Pakete mehr angezeigt werden, startet ich über die Systemsteuerung wieder ganz normal die Installation der Updates. Bisher waren in jedem Fall nach dieser Prozedur die Update-Probleme verschwunden. Warum das Vorbereitungstool nicht selbst die defekten Dateien erneut herunterlädt oder wenigstens den Benutzer informiert, worin das Problem besteht und was zu tun ist, wissen nur die Götter oder Microsoft selbst. Bevor ich eine Anleitung für das oben beschriebene Vorgehen gefunden habe, hatte ich schon Stunden erfolglos damit zugebracht, bestimmte Updatefehler zu reparieren. Wenn es bei einem meiner Computer jetzt zu einem solchen Problem kommt, warte ich erst ein paar Tage, ob es sich von selbst repariert. Wenn sich der hässliche rote Strich in der WSUS-Übersicht nicht von selbst verflüchtigt, wende ich ganz gechillt das obige Verfahren an und habe bisher jedes Problem auf diese Art und Weise behoben.

Client-Computer mit Update-Problemen reparieren (ab Windows 8)

Ab Windows 8 wurde das System zur Verwaltung der Update-Dateien umgestellt. Es gibt kein Systemvorbereitungstool mehr. Ich habe hier gerade einen Rechner mit Windows 8.1, bei dem sich das Verzeichnis c:\Windows\WinSxS mehr als normal aufgebläht hatte. Auch in dem Temp-Verzeichnis darunter befanden sich 2 GByte Daten. Ich weiß, dass sich in dem Verzeichnis lauter Dateien befinden, die mit Hardlinks miteinander verbunden sind, so dass die Angaben über den Platzverbrauch nicht stimmen. Trotzdem wird mir jeder kundige Systemverwalter beipflichte, dass es ungewöhnlich ist, wenn eine 150 GByte System-Partition mit Windows 8.1 64 überläuft.

Ich habe also die Datenträgerbereinigung ausgeführt, die Dropbox und die Spotify-Daten ins d:-Laufwerk verschoben, sonstige temporäre Dateien gelöscht, aber trotzdem blieb die Festplatte fast komplett angefüllt. 

Darum habe ich zunächst eine Kontrolle der Systemintegrität mit Hilfe des Programms sfc.exe vorgenommen. Dies bracht das folgende Ergebnis:

C:\WINDOWS\system32>sfc /scannow

Systemsuche wird gestartet. Dieser Vorgang kann einige Zeit dauern.

Überprüfungsphase der Systemsuche wird gestartet.
Überprüfung 100 % abgeschlossen.

Vom Windows-Ressourcenschutz wurden beschädigte Dateien gefunden und erfolgreich

repariert. Weitere Informationen finden Sie in der Datei "CBS.Log" unter "windir\Logs\CBS\CBS.log",
z.B. "C:\Windows\Logs\CBS\CBS.log".
Hinweis: Bei der Offlinewartung wird die Protokollierung derzeit nicht unterstützt.

C:\WINDOWS\system32>

Gut, das sieht ja schon mal nicht so schlecht aus. Weiter geht es mit der Überprüfung der Integrität der Update-Dateien. Mit Hilfe des folgenden Kommandos kann man dies bewerkstelligen:

C:\WINDOWS\system32>Dism /Online /Cleanup-Image /ScanHealth

Tool zur Imageverwaltung für die Bereitstellung
Version: 6.3.9600.17031

Abbildversion: 6.3.9600.17031

[==========================100.0%==========================]
Der Komponentenspeicher kann repariert werden.
Der Vorgang wurde erfolgreich beendet.

C:\WINDOWS\system32>

In der Log-Datei des dism-Tools fand ich dann die folgenden Zeilen, die darauf hindeuten, dass sich einige Update-Dateien nicht in einem korrekten Zustand befinden:

(p)	CSI Payload Corrupt			amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17747_none_90df8130dac08ee0\utc.app.json
(p)	CSI Payload Corrupt			amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17747_none_90df8130dac08ee0\telemetry.ASM-WindowsDefault.json
(p)	CSI Payload Corrupt			amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17807_none_910ac2c6daa01c43\utc.app.json
(p)	CSI Payload Corrupt			amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17807_none_910ac2c6daa01c43\telemetry.ASM-WindowsDefault.json
(p)	CSI Payload Corrupt			amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17842_none_90da81a4dac50d54\utc.app.json
(p)	CSI Payload Corrupt			amd64_microsoft-windows-u..ed-telemetry-client_31bf3856ad364e35_6.3.9600.17842_none_90da81a4dac50d54\telemetry.ASM-WindowsDefault.json

Summary:
Operation: Detect only 
Operation result: 0x0
Last Successful Step: CSI store detection completes.
Total Detected Corruption:	6
	CBS Manifest Corruption:	0
	CBS Metadata Corruption:	0
	CSI Manifest Corruption:	0
	CSI Metadata Corruption:	0
	CSI Payload Corruption:	6
Total Repaired Corruption:	0
	CBS Manifest Repaired:	0
	CSI Manifest Repaired:	0
	CSI Payload Repaired:	0
	CSI Store Metadata refreshed:	True

Gut, laut Microsoft soll man dann nacheinander dism.exe mit zwei unterschiedlichen Parametern aufrufen, um die Update-Bibliothek zu reparieren. Gesagt, getan:

C:\WINDOWS\system32>Dism /Online /Cleanup-Image /CheckHealth

Tool zur Imageverwaltung für die Bereitstellung
Version: 6.3.9600.17031

Abbildversion: 6.3.9600.17031

Der Komponentenspeicher kann repariert werden.
Der Vorgang wurde erfolgreich beendet.

C:\WINDOWS\system32>Dism /Online /Cleanup-Image /RestoreHealth

Tool zur Imageverwaltung für die Bereitstellung
Version: 6.3.9600.17031

Abbildversion: 6.3.9600.17031

[==========================100.0%==========================]

Fehler: 0x800f0906

Die Quelldateien konnten nicht heruntergeladen werden.
Geben Sie mit der Option "Quelle" den Ort der Dateien an, die zum Wiederherstell
en des Features erforderlich sind. Weitere Informationen zum Angeben eines Quell
orts finden Sie unter "http://go.microsoft.com/fwlink/?LinkId=243077".

Die DISM-Protokolldatei befindet sich unter "C:\WINDOWS\Logs\DISM\dism.log".

C:\WINDOWS\system32>

Huch, das ist ja unerfreulich! Warum kann Windows diese 6 Dateien nicht nachladen? Ich habe nun angefangen, im Internet herumzusuchen, wo das Problem liegt. Eine empfohlene Maßnahme besteht darin, dism.exe noch einmal aufzurufen und als Source für das Nachladen das Windows-Verzeichnis eines anderen Windows-Rechner im Netzwerk anzugeben. Das habe ich dann auch noch probiert:

C:\WINDOWS\system32>Dism /Online /Cleanup-Image /RestoreHealth /Source:\\gurlitt
\Windows /LimitAccess

Tool zur Imageverwaltung für die Bereitstellung
Version: 6.3.9600.17031

Abbildversion: 6.3.9600.17031

[==========================100.0%==========================]
Fehler beim Wiederherstellungsvorgang. Entweder wurde die Reparaturquelle nicht
gefunden, oder der Komponentenspeicher konnte nicht repariert werden.

Fehler: 0x800f081f

DISM-Fehler: Es wurde kein Vorgang ausgeführt.
Weitere Informationen finden Sie in der Protokolldatei.

Die DISM-Protokolldatei befindet sich unter "C:\WINDOWS\Logs\DISM\dism.log".

C:\WINDOWS\system32>

Den Parameter /LimitAccess soll man übrigens angeben, wenn der Rechner sich in einer WSUS-Umgebung befindet, was bei mir ja der Fall ist. Um es kurz zu machen: Mehrere Stunden Internet-Recherche brachten mich nicht weiter. Dies ist ein Microsoft-Problem und es scheint keine Lösung innerhalb von Windows 8.1 (außer Neuinstallation) zu geben. Da ich den Rechner sowieso in den nächsten Tagen auf Windows 10 bringen werde, erledigt sich das Problem wahrscheinlich von selbst. Tröstlicher Seiteneffekt der ganzen Angelegenheit ist, dass der Aufruf der diversen Programme doch einen Aufräumprozess in Gang gesetzt hat, denn ich habe auf der C-Partition wieder 40 GByte Platz frei...

Ausnahmen bestätigen die Regel

Kaum hatte ich den obigen Windows 7-Beitrag fertig geschrieben, tauchte ein Fall auf, bei das beschriebene Vorgehen nicht geholfen hat: Auf einem der von mir betreuten Computer liefen gleich 10 Office-2010-Updates nicht durch (Fehler 80070652). Siegesgewiss startete ich wie oben beschrieben das Systemupdate-Vorbereitungstool. Dieses fand jedoch keinen Fehler. Mehrere Versuche mit den obligatorischen Reboots brachten ebenfalls nichts. Ich habe dann im Internet herumgesucht und die folgende Anleitung gefunden, die dann zum Erfolg führte:

  • Windows Installer-Dienst deaktivieren
  • Rechner neu starten
  • Windows Installer-Dienst wieder auf manuell stellen
  • Fehlerhafte Updates einzeln aus der Systemsteuerung installieren

Ich habe vor kurzem erst verstanden, was der Hintergrund dieses Problems war: Auf dem entsprechenden Computer hatte jemand den Adobe Acrobat Reader DC installiert, was zur Folge hatte, das mein Installations-Skript für eine ältere Version des Acrobat-Readers steckenblieb. Dadurch wurde der Windows Installer nicht korrekt beendet und die offiziellen Microsoft-Updates nicht ordnungsgemäß durchgeführt. Nachdem ich mein Skript so modifiziert hatte, dass es die bestehende Reader DC-Installation erkannte, trat das Problem nicht mehr auf.

Für mich ist das mal wieder ein Beispiel dafür, dass diese kryptischen Fehlermeldungen einfach nur dämlich sind. Warum wird die Ursache für den Abbruch nicht in einer vernünftigen Meldung angezeigt? Statt dessen bekommt man eine Fehlernummer vor den Latz geknallt und kann sehen, wie man damit weiterkommt. In dem konkreten Fall konnte ich auch mit den Meldungen im Windows-Update-Log nichts anfangen.