Bents Blog

Manche Probleme sind einfach nicht schlüssig erklärbar, zumindest für die Lösung des hier dokumentierten Falls habe ich eine ziemlich lange Zeit benötigt. Es geht um den Microsoft Windows Server Update Service kurz WSUS.

Auf Grund der zentralen Verteilung von Updates innerhalb einer Organisation ist der WSUS durchgängig bei unseren Kunden im Einsatz, allerdings bereitete mir ein System einige Kopfschmerzen. Obwohl die betroffene Umgebung zu den aktuellsten gehört, tauchte das Problem nun bereits zum zweiten Mal auf. Der WSUS ist in der aktuellen Version 3.0 Service Pack 2 auf einem mit Hyper-V virtualisierten Windows Server 2008 R2 Standard installiert. Dieser Server ist Mitglied einer Domäne und versorgte ca. 70 Clients bereits eine geraume Zeit mit den neuesten Windows Updates.

Beim ersten Auftreten des Problems konnte ich den WSUS durch eine De- und anschließende Neu-Installation zur Wiederaufnahme der Arbeit bewegen – nun – beim wiederholten Male – wollte ich das Problem an der Wurzel packen und beseitigen.

Problem

Der Endkunde informierte mich darüber, dass der WSUS sich bereits seit mehreren Tagen nicht mehr mit den Servern von Microsoft synchronisierte. Und tatsächlich ein Blick in die Update Services Konsole lieferte folgendes Bild:

Die anschließende Untersuchung der Fehlerdetails enthielt bei allen Ereignissen die folgende Meldung:

Auch die wiederholten Versuche einer manuellen Synchronisierung scheiterten mit dem selben Fehler.

Lösung

Auf Grund der obigen Meldung schaut man selbstverständlich zu Beginn in den Zertifikatsspeicher des lokalen Computers nach den Vertrauenswürdigen Stammzertifizierungsstellen (MMC, Snap-in hinzufügen, Zertifikate, lokaler Computer):

Auf den ersten Blick fand ich hier keine Fehler, die Root-Zertifikate von Microsoft waren enthalten und gültig. Das Zertifikat der Stammzertifizierungsstelle stammt von der eigenen, internen Zertifizierungsstelle der Organisation, welches über eine Gruppenrichtlinie zentral an Domänenmitglieder verteilt wird. Alle anderen Zertifikate waren in der Installation des Betriebssystems Windows Server 2008 R2 Standard Edition inkl. SP1 enthalten, welches – wie alle anderen neuen Server in der Umgebung – über die Bereitstellungsdienste installiert wurde.

Da ich im Ereignisprotokoll keine weiteren Hinweise fand, untersuchte ich zunächst die Protokoll-Datei des WSUS, welche unter dem Pfad

%ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log

abgespeichert wird. Dieses Log ist extrem umfangreich, allerdings entdeckte ich folgende Fehlermeldung, die meiner Meinung als Ursache in Frage kam:

Error wsusservice.138 CabUtilities.CheckCertificateSignature File cert verification failed for C:\Program Files\Update Services\autest.cab with 2148081667

Die aufgeführte Datei existiert allerdings nicht auf dem System (auf keinem WSUS!), doch die Suche nach dem Ausdruck brachte mich wiederum ein weiteres Stück voran.

Lösungsansatz 1

Bei meiner Suche im Internet fand ich einen ersten Lösungsansatz: Einige Benutzer berichteten, dass eine Änderung in der Datenbank des WSUS das geschilderte Problem beseitigt. Wer die Windows Internal Database (Microsoft SSEE) für den WSUS nutzt und das Microsoft SQL Server Management Studio Express installiert hat, kann sich mit dem Ausdruck

\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

an der Datenbank anmelden. In der Tabelle dbo.tbConfigurationC der Datenbank SUSDB ist nun in der Spalte BitsDownloadPriorityForeground der Wert von $false (0) in $true (1) zu ändern:

Nach einem Neustart des Dienstes Update Services

net stop wsusservice
net start wsusservice

wird diese Änderung dann angewendet.

Leider führte in meinem Fall diese Änderung zu keinem Erfolg, das Synchronisationsproblem des WSUS bestand nach wie vor.

Lösungsansatz 2

Bei meiner weiteren Suche stieß ich auf den Hinweis, die aktuellsten Stammzertifikate via Windows Update direkt online herunterzuladen. Das schien mir sinnvoll, da mir die Liste der installierten Zertifikate ohnehin etwas kurz erschien. Beim Versuch aktuelle Windows Updates online zu aktualisieren, erhielt ich allerdings die folgende Fehlermeldung:

Der Fehler 80072F8F hat dabei unterschiedliche Ursachen: Uhrzeit-Differenzen oder Zertifikatsprobleme. Da die Uhrzeit via NTP synchronisiert wird und aktuell war, kam nur Punkt 2 in Betracht. Notgedrungen suchte ich nun über den Internet Explorer das aktuelle Update für Stammzertifikate (November 2011) und startete den Download. Für diese Datei ist schlägt allerdings die Orginal-Windows-Gültigkeitsprüfung zu, beim Ausführen des Windows Genuine Advantage Tools erhielt ich die folgende Nachricht:

Ein hübsches Henne-Ei-Problem, scheitert die Ausführung des Tools doch lediglich an den fehlenden Stammzertifikaten! Schließlich lud ich die Datei rootsupd.exe auf einem anderen System herunter und führte selbige auf dem betroffenen Server aus. Und hier verstehe ich Microsoft nicht mehr: Weder die normale, noch die Ausführung als Administrator erstellten die für Windows Update (und den WSUS) benötigten Stammzertifikate im Container Vertrauenswürdige Stammzertifizierungsstellen!

Und nun kommt die eigentliche Arbeit: Um den Dingen auf den Grund zu kommen aktivierte ich zunächst das Ereignisprotokoll CAPI2 unter Anwendungs- und Dienstprotokolle, Microsoft, CAPI2. Bei der Ausführung von Windows Update erhält man nun die folgenden Fehler:

Quelle CAPI2, Ereignis-ID: 30, Kategorie: Kette erstellen, Kettenrichtlinie überprüfen

Die eigentlichen Information verbergen sich dabei im Reiter Details:

Startet man zur Kontrolle nun den Internet Explorer und öffnet die Seite https://www.update.microsoft.com, so wird das hinterlegte Zertifikat des Webservers für ungültig erklärt:

Bei der Anzeige des Zertifikats erhält man nun die Meldung, dass selbige nicht bis zur ursprünglichen Zertifizierungsstelle verifiziert werden kann:

Das Problem liegt aber bei dem ersten Zertifikat der Kette, der Microsoft Internet Authority. Obwohl das Zertifikat selber ohne Fehler – und damit gültig – erschien, fiel mir doch folgende Merkwürdigkeit ins Auge:

Der Aussteller GTE CyberTrust Global Root existierte aber nicht in der Liste der Vertrauenswürdigen Stammzertifizierungsstellen (siehe zweites Bild von oben). Also suchte ich mir das (gültige) Zertifikat auf einem anderen Computer, exportierte und importierte es auf dem betreffenden Server:

Und siehe da, beim erneuten Aufruf von https://www.update.microsoft.com erschien die Leiste im Internet Explorer so:

In Folge dessen tauchten keinerlei Fehlermeldungen mehr im Ereignisprotokoll CAPI2 auf, Windows Update präsentierte nach dem Klick auf „Vorgang wiederholen“ einige zu installierende Updates und nach einem Neustart des Dienstes Update Services verlief die neue Synchronisierung ohne Probleme.

Fazit

Wie so oft, gilt auch hier: kleine Ursache, große Wirkung. Und obwohl ich das Problem erfolgreich lösen konnte, bleiben für mich einige Fragen offen:

• Warum fehlt das nötige Stammzertifikat nach der Installation des Betriebssystems? (Es wurden keine Zertifikate gelöscht, das Problem existiert auf allen Windows Server 2008 R2 SP1.)
• Warum funktioniert der WSUS zunächst einmal für etwa 30 Tage?
• Warum werden hier nicht bevorzugt (ohne Möglichkeit der Ablehnung) und automatisch die Stammzertifikate aktualisiert?
• Warum funktioniert das manuelle Update der Stammzertifikate via rootsupd.exe nicht?

Ich werde bei zukünftigen Installationen dieses Verhalten genau prüfen, möglicherweise finde ich einen anderen ursächlichen Fehler. Vielleicht hat aber auch ein Leser dieses Artikels ähnliche Erfahrungen gemacht und kennt die Ursache – wie bei allen meinen Beiträgen gilt: Bei Hinweisen, Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.