Bents Blog

 

Ein IT Blog mit Themen aus dem Windows Server Umfeld.

Fehler 80070643 und 800b010b bei Microsoft .NET 4 Windows Updates KB2656351, KB2656368 und KB2600217

Der eine oder andere Administrator ist sehr wahrscheinlich auch über das folgende Problem gestolpert, als er bei dem Versuch die Windows Updates für Microsoft .NET 4.0 einzuspielen

  • Sicherheitsupdate für Microsoft .NET Framework 4 (KB2656351)
  • Sicherheitsupdate für Microsoft .NET Framework 4 (KB2656368)
  • Update für Microsoft .NET Framework (KB2600217)

diese Fehlermeldung im Systemereignisprotokoll (Quelle: Windows Update Agent, Event-ID 20) erhielt:

Installationsfehler: Die Installation des folgenden Updates ist mit Fehler 0x80070643 fehlgeschlagen: Sicherheitsupdate für Microsoft .NET Framework 4 unter Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008 x86 (KB2656351)

Problem

In meinem Fall trat der obige Fehler auf einigen (kurioserweise nicht auf allen!) Maschinen unter Windows Server 2003 (32 Bit) inkl. Service Pack 2, aber auch unter Windows Server 2008 (64 Bit Version) inkl. Service Pack 2 auf. Bei letzterem Betriebssystem lieferte Windows Update einen weiteren Fehlercode 800b010b, welcher mich letztendlich bei meiner Fehleranalyse auf die richtige Fährte führte:

Bei meiner Suche nach dem ersten Fehlercode 80070643 stieß ich auf den folgenden Microsoft Support KB Eintrag. Wie beschrieben lud ich das .NET Framework Cleanup Tool für die Reparatur der .NET Framework Umgebung herunter und führte selbiges mit der Option Cleanup Now aus:

Das Tool entfernt dabei alle .NET Framework Einstellungen (per Auswahl auch auf einzelne Versionen beschränkbar) von dem betroffenen System. In Folge dessen musste ich nun alle .NET Framework Versionen (unter Windows Server 2003 sind das immerhin Version 1.1, 2.0, 3.0, 3.5 und 4.0 inkl. aller Service Packs) neu installieren. Dank internem Windows Update Server (WSUS) kein Problem – doch nach der Installation der oben aufgeführten Updates und mehreren Neustarts erhielt ich die selben Fehlermeldungen erneut – eine Bereinigung und anschließende Neuinstallation behebt das Problem demnach nicht.

Analyse und Ursache

Jedes Windows Update legt bei der Installation ein Protokoll im temporären Verzeichnis des Systems an (%TEMP%\KB<Nummer>.html). In diesem Protokoll wird für die betroffenen Updates immer die gleiche Ursache genannt (hier das Beispiel für KB2656368):

Action: Downloading and/or Verifying Items...
[4/24/2012, 8:54:49] Verifying Digital Signatures: d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp
[4/24/2012, 8:54:49] d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp: Verifying signature for NDP40-KB2656368.msp...
[4/24/2012, 8:54:49] d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp - Signature verification for file NDP40-KB2656368.msp (d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp) failed with error 0x800b010e (Der Sperrvorgang konnte nicht fortgesetzt werden. Die Zertifikate konnten nicht überprüft werden.)
[4/24/2012, 8:54:49] d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp Signature could not be verified for NDP40-KB2656368.msp
[4/24/2012, 8:54:49] No FileHash provided. Cannot perform FileHash verification for NDP40-KB2656368.msp
[4/24/2012, 8:54:49] File NDP40-KB2656368.msp (d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp), failed authentication. (Error = -2146762482). It is recommended that you delete this file and retry setup again.
[4/24/2012, 8:54:49] Failed to verify and authenticate the file -d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp
[4/24/2012, 8:54:49] Please delete the file, d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp and run the package again
[4/24/2012, 8:54:49] Action complete
[4/24/2012, 8:54:49] calling PerformAction on an installing performer
[4/24/2012, 8:54:49] Action: Performing actions on all Items...
[4/24/2012, 8:54:49] Wait for Item (NDP40-KB2656368.msp) to be available
[4/24/2012, 8:54:50] Action complete
[4/24/2012, 8:54:50] Sending Manifest Report
[4/24/2012, 8:54:51] Final Result: Installation failed with error code: (0x800B010B), "Allgemeiner Vertrauensfehler." (Elapsed time: 0 00:00:03).

Es ist erkennbar, dass das im Update enthaltene Paket (NDP40-KB2656368.msp) eine digitale Signatur enthält, deren Überprüfung fehlschlägt. Über die Eigenschaften der MSP-Datei lässt sich diese Signatur anzeigen:

Bei dem Klick auf Details erhielt ich daraufhin den folgenden Fehler:

Lässt man sich nun das Zertifikat des Signaturgebers (Microsoft) anzeigen, so kann Windows die Gültigkeit des Zertifikats nicht bestätigen, da das Programm keine gültige Zertifikatsperrliste von der Zertifizierungsstelle ermitteln kann, die dieses Zertifikat ausgestellt hat.

Die Zertifikatsperrliste (Certificate Revocation List = *.crl) ist eine Datei, über die ein Aussteller abgelaufene und kompromittierte Zertifikate für ungültig erklären kann. Die URL für die CRL ist dabei immer in den Eigenschaften eines Zertifikates verankert. Kann die Sperrliste einmal nicht geladen werden, so geht ein Client im Standard immer von der Ungültigkeit eines Zertifikates aus.

Für die beschriebene Datei gibt es nun 3 in Frage kommende (weil hinterlegte) Sperrlisten:

Normalerweise lässt sich die Erreichbarkeit/Verfügbarkeit der jeweiligen CRL durch das Herunterladen prüfen – alle CRLs waren aber erreichbar und konnten erfolgreich heruntergeladen werden. Trotzdem konnte das Zertifikat nicht überprüft werden.

Lösung

Bei der Fortsetzung meiner Suche fand ich schließlich den folgenden, wertvollen Hinweis im Technet-Forum von Microsoft. Eigentliche Ursache für das beschriebene Verhalten sind die System-Einstellungen für die Zertifikat-Überprüfung (Software Publishing State Key Values).

Mit Hilfe des Tools SetReg.exe von Microsoft – welches im Microsoft .NET Framework SDK enthalten ist – lassen sich diese aktuellen Einstellung anzeigen und ändern. Auf den Systemen, auf denen die Updates nicht installiert wurden, zeigte SetReg folgende Werte:

Software Publishing State Key Values (0xc9):
 1) Trust the Test Root........................... TRUE
 2) Use expiration date on certificates........... TRUE
 3) Check the revocation list..................... TRUE
 4) Offline revocation server OK (Individual)..... FALSE
 5) Offline revocation server OK (Commercial)..... FALSE
 6) Java offline revocation server OK (Individual) FALSE
 7) Java offline revocation server OK (Commercial) FALSE
 8) Invalidate version 1 signed objects........... FALSE
 9) Check the revocation list on Time Stamp Signer TRUE
 10) Only trust items found in the Trust DB....... FALSE

Im erwähnten Technet-Eintrag wurde der Punkt 5 Offline revocation server OK (Commercial) als kritisches Element beschrieben. Setzt man diesen über den Befehl

setreg 5 TRUE

auf wahr (allows offline approval for commercial certificates), so lassen sich die Windows Updates ohne Probleme installieren. Außerdem funktioniert danach die Anzeige des Zertifikates des Signaturgebers der MSP-Paketdatei ebenfalls ohne Probleme:

Das Herunterladen des ca. 115 MByte (!) großen .NET Framework SDK für die Ausführung von SetReg kann man sich allerdings sparen, da selbiges Tool lediglich einen Wert in der Registry verändert. In meinem Fall hatte der betroffene Benutzer auf dem System den folgenden Eintrag:

[HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
„State“=DWORD:000000c9

Setzt man nun diesen Wert auf

„State“=dword:00022849

so entspricht diese Einstellung den auf der Webseite für SetReg beschriebenen DEFAULT Werten:

Updated Software Publishing State Key Values (0x22849):
 1) Trust the Test Root........................... FALSE
 2) Use expiration date on certificates........... TRUE
 3) Check the revocation list..................... TRUE
 4) Offline revocation server OK (Individual)..... FALSE
 5) Offline revocation server OK (Commercial)..... TRUE
 6) Java offline revocation server OK (Individual) FALSE
 7) Java offline revocation server OK (Commercial) TRUE
 8) Invalidate version 1 signed objects........... FALSE
 9) Check the revocation list on Time Stamp Signer FALSE
 10) Only trust items found in the Trust DB....... FALSE

Nach dieser simplen und kleinen Änderung funktioniert die Installation der Windows Updates KB2656351, KB2656368 und KB2600217 ohne Probleme.

Fazit

Obwohl ich bereits das eine oder andere Problem mit Windows Updates für das Microsoft .NET Framework lösen musste, verlangte der hier beschriebene Fehler einen extremen Zeit- und Arbeitsaufwand (erkennbar am Umfang des Artikels). So habe ich allein für die Suche und Analyse mehrere Stunden investieren müssen. Warum und vor allen Dingen welches Programm den Standardwert für die Software Publishing Key Values von 23c00 (siehe .DEFAULT Benutzerprofil) auf c9 abgeändert hat, bleibt mir ein Rätsel. Umso überraschender ist doch die recht schnelle und einfache Behebung des Problems, mit dessen Lösung ich hoffentlich anderen Leidensgenossen helfen kann.

Wie bei allen meinen Beiträgen gilt: Bei 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.

28 Kommentare für “Fehler 80070643 und 800b010b bei Microsoft .NET 4 Windows Updates KB2656351, KB2656368 und KB2600217”

  • Martin

    Danke für den Artikel, und Hut ab vor der Arbeit!
    lg

  • Winfried Sonntag

    Wow, das liest sich schon nach sehr viel Arbeit. Vielen Dank für diesen und natürlich auch für die restlichen Artikel. ;)

  • Skaggert

    (sorry for the bad German) – Veilen Dank von mir auch. Bei mir scheint es etwas mit dem User Settings GPO zu tun:
    Preferences > Control Panel Settings > Internet Settings > Internet Explorer 8
    Ohne den hat ein neu anwänder profile den richtige default setting.
    Muss mehr mitt den herum speilen.

  • Tommy's Blog für IT-Wissen

    Hallo!

    Ganz großes Dankeschön für deine Anleitung! Bei mir ist auch gerade eben der Fehler aufgetreten! Da hast du Dir aber echt viel Arbeit gemacht mit dem ausführlichen Artikel.

    Übrigens schöner Blog, mach weiter so.

    Grüße, Tommy

  • Matthias Stolte

    Bei einem Dutzend PCs mit WinXP dasselbe Problem; auf die Ursache der nicht prüfbaren Signatur war ich auch bereits gestoßen und darüber hab ich dann diesen blog mit dem weiten Lösungsweg gefunden. Besten Dank für die Beschreibung – funktioniert nun tadellos. :D

  • Marcel

    Respekt vor der Arbeit. Super Anleitung. Ich habe diesen Fehler schon seit monaten auf einem meiner Server gehabt und bin nicht drauf gekommen. Nach dieser Anleitung habe ich die registry geändert und schon ließen sich alle Updates mit WSUS installeiren auf dem server.

    Endich…. Vielen Vielen Dank.

  • Philippe

    Danke für Deine Anleitung, hat uns sehr geholfen. Ziehe den Hut vor Deiner Arbeit.
    lg

  • Admin ZPD

    Vielen Dank für die detaillierte Beschreibung.
    Bin vor Jahren schon in Unkenntnis der genauen Mechanismen an den NDPxxx Updates verzweifelt.
    Respekt, ist mir eine riesige Hilfe.

  • jan

    Schade, auf Windows7 funktioniert das nicht mehr -.-“

  • Jörg Leuger

    Vielen Dank für diesen Artikel!
    Hatte schon schlimmeres befürchtet!

  • Bernd Wältz

    Danke! Auch für mich, der eher weniger mit Systemfragen zu tun hat, war das eine hervorragende und hilfreiche Problembeschreibung und -lösung.

  • Klaus

    Hallo Bent!
    Vielen Dank für den äußerst hilfreichen Artikel.Bei mir tat folgendes Problem auf:Alggemeiner Vertrauensfehler bei der Installation von Netframework 4 unter XP32-bit.Habe dann dem Arikel folgend festgestellt,dass die digitale Signatur abgelaufen war.Über einen sich auftuenden Assisten habe ich das Zertifikat an den vomm Assistenten bestimmten Ort importiert-und alles war ok.
    Gruß

  • imho

    hallo zusammen,
    habe mich zwangsweise auch mit dem Thema auseinandersetzen müssen, allerdings hatte ich bei meinem XP keinen Erfolg mit der hier beschriebenen Lösung, bis mir letztendlich bei der Überprüfung des ominösen Zertifikats aufgefallen ist, das der Gültigkeitszeitraum bereits 2011 abgelaufen ist, also habe ich das Systemdatum auf 01/2011 gesetzt und wie von Zauberhand gerführt funktioniert die Installation plötzlich ;-o !!

  • madtomtec

    Vielen dank …nach zig anderen Versuchen hat es mit dieser Anleitung bei einem XP System funktioniert…

    Habe die Regkey ändern Variante gemacht, ging sofort.

    Alle andern cleaner tools etc brachten nix.. Ich betreue ca. 1500 PCs als Admin und nur einer hatte das Problem … warum ?!? Ich habe es nicht herrausgefunden.

    Danke Danke Danke

  • Rebecca

    DANKESCHÖN!!!

    ich wollte auf dem Rechner meiner Schwiegereltern „Nur“ das neue Kaspersky installieren und bin nun schon fast Programmiervollprofi :-) geworden.

    Habe dank deinem Artikel überhaupt die Chance bekommen den Fehler zu beheben. Brauchte zwar immernoch 2 Tage, weil ich nicht wusste wie man auf Registry und Zertifikate zugreift, aber dank dir wusste ich nach was ich überhaupt suchen muss.

    Vielen Dank, hätte nie gedacht das ich das Ohne vorkenntnisse hinbekomme, aber dein Artikel ist so toll aufgebaut das kann sogar ein Laie nachvollziehen.

    Vielen Vielen Dank nochmal

  • Josef

    Danke, hatte eben das gleiche Problem. Auf den Registryeintrag wär ich so schnell nicht gekommen.

  • roman

    … ich versteh nicht ganz, was muss man jetzt unter state eingeben, damit es funktioniert? 23c00 oder 00022849 – danke lG Roman

  • Bent Schrader

    Hi Roman,

    es sollten beide Werte funktionieren (wie beschrieben), der 23c00 ist ein Standardwert eines blanken Profils, ohne Änderung. Der andere Wert entspricht den Vorgaben von Setreg (siehe Link).

    Gruß,
    Bent

  • Roman

    Bitte in einzelnen Schritten – ich kapiere es nicht

  • Roman

    Ich gebe unter Hexdezimal einfach 23c00 ein und das war’s?

  • Bent Schrader

    Du setzt einfach in der Registry (via regedit) im obigen Pfad (HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionWinTrustTrust ProvidersSoftware Publishing) den DWORD-Eintrag „State“ mit dem Hex-Wert 22849.

    Das war’s dann auch schon.

  • Roman

    Muss man da neu starten?

  • Bent Schrader

    Nein

  • roman

    … es kommt immer noch „fehler bei der installation“ – „allgemeiner vertrauensfehler“ – wo sollte eigentlich das 23c00 stehen?

  • roman

    wo findet man eigentlich diese setreg exe? ich hab ja auch schon dieses sdk installiert

  • roman

    OS Version = 5.1.2600, Platform 2, Service Pack 3
    OS Description = WinXP – x86 Professional Service Pack 3
    CommandLine = J:963d1f4b3c54b966f1164d00678d1c\Setup.exe /x86 /x64
    TimeZone = Westeuropäische Normalzeit
    Initial LCID = 3079
    Using Simultaneous Download and Install mechanism
    Operation: Installing
    Package Name = Microsoft .NET Framework 4 Setup
    Package Version = 4.0.30319
    User Experience Data Collection Policy: UserControlled
    Number of applicable items: 7
    Possible transient lock. WinVerifyTrust failed with error: 2148204800
    Possible transient lock. WinVerifyTrust failed with error: 2148204800
    J:963d1f4b3c54b966f1164d00678d1cnetfx_Core_x86.msi – Signature verification for file netfx_Core_x86.msi (J:963d1f4b3c54b966f1164d00678d1cnetfx_Core_x86.msi) failed with error 0x800b0100 (Es war keine Signatur im Antragsteller vorhanden.)
    No FileHash provided. Cannot perform FileHash verification for netfx_Core_x86.msi
    File netfx_Core_x86.msi (J:963d1f4b3c54b966f1164d00678d1cnetfx_Core_x86.msi), failed authentication. (Error = -2146762496). It is recommended that you delete this file and retry setup again.
    Final Result: Installation failed with error code: (0x800B010B), „Allgemeiner Vertrauensfehler. “ (Elapsed time: 0 00:00:31).

  • roman

    … und bei mir steht auch true bei punkt 5

  • roman

    Hallo, ich stehe völlig an, brauche NETFRAMEWORK sehr dringend, weil ein anderes Programm brauche, welches nicht ohne 4.0 läuft – bitte, bitte! LG

Einen Kommentar hinterlassen:

Antispam Bee hat Bent's Blog vor 371.116 Spam-Kommentaren bewahrt.