[English]Es ist ein merkwürdiges Fehlerbild, welches mir die Tage unter die Augen gekommen ist. Alle Windows 10 Clients lösen bei der Suche nach Update den Fehlercode 0x8024000d aus, wobei eine spezielle Konstellation vorliegt. Mit beteiligt sind WSUS auf Windows Server 2012 R2 und Office 2007. Ich habe den Fall mal etwas aufbereitet, um auch die Vorgehensweise zu dokumentieren.
Der Update-Fehler 0x8024000d im Detail
Der betroffene Administrator beschreibt das Ganze im Technet-Forum etwas genauer und kann sogar einen Auszug aus der Protokolldatei vorliegen.
nach dem [Upgrade auf das] Creators Update [Version 1703] von Windows 10 (x64) läuft auf allen unseren Rechnern die mit Office 2007 Standard/Prof (32 bit) bestückt sind das Windows Update nicht mehr. Es wird auf allen Rechnern der gleiche Fehler 0x8024000d gemeldet.
In der Windows Update-Protokolldatei Windowsupdate.log, die sich unter
%windir%\Windowsupdate.log
befindet, sind folgende Einträge zu finden:
2017.08.01 14:13:04.1189449 4736 2516 Metadata [0]1280.09D4::08/01/2017-14:13:04.118 [metadataintegrity] failed: hr = 0x8024500C
2017.08.01 14:13:04.1189456 4736 2516 Metadata [0]1280.09D4::08/01/2017-14:13:04.118 [metadataintegrity]GetFragmentSigningConfig failed with 0x8024500C. Using default enforcement mode: Audit.
2017.08.01 14:13:04.1189460 4736 2516 Metadata [0]1280.09D4::08/01/2017-14:13:04.118 [metadataintegrity] failed: hr = 0x8024500C
2017.08.01 14:13:04.1189479 4736 2516 Metadata [0]1280.09D4::08/01/2017-14:13:04.118 [metadataintegrity]Policy-driven service enabled. Using Ignore Policy.
2017.08.01 14:13:04.1190057 4736 2516 ProtocolTalker [0]1280.09D4::08/01/2017-14:13:04.119 [agent]SyncExtendedUpdateInfo – 0 bad out of 0 metadata signatures checked using Audit enforcement mode.
2017.08.01 14:13:04.1310942 4736 2516 Misc [0]1280.09D4::08/01/2017-14:13:04.131 [updparse]Missing required node AdditionalDigest
2017.08.01 14:13:04.1311162 4736 2516 Agent [0]1280.09D4::08/01/2017-14:13:04.131 [agent]Failed to parse extended metadata for 6D629889-8D3F-4F26-929A-E08B8F363F49.100, hr=8024000d
2017.08.01 14:13:04.1320713 4736 2516 Agent [0]1280.09D4::08/01/2017-14:13:04.132 [agent]Failed to get extended update infos, hr=0x8024000d.
2017.08.01 14:13:04.1808464 4736 2516 Agent [0]1280.09D4::08/01/2017-14:13:04.180 [agent]Exit code = 0x8024000D
Es werden also Fehler im Zusammenhang mit der Auswertung der Metadaten gemeldet. Und es kommt noch kurioser, wie der Administrator schreibt.
Wenn ich Office 2007 deinstalliere oder auf eine Version größer 2010 upgrade, gehen die Windows Updates sofort wieder normal. Installiere ich Office 2007 wieder, ist der Fehler sofort wieder da.
Ich habe auch versucht die für 1703 bereits veröffentlichten Updates manuell herunterzuladen und auf den betroffenen Systemen zu installieren, das behebt den Fehler aber nicht.
Im Unternehmen sind ca. 30 Systeme von dem Problem betroffen. Das Fehlerbild ist mehr als dubios, versucht Microsoft Office 2007 unter Windows 10 herauszuschießen? Oder gibt es ein Kompatibilitätsproblem mit Windows as a service?
Ziemlich viel Ärger mit Windows 10 V1703 und WSUS
An dieser Stelle noch ein kleiner Einschub, der zeigt, wie vielschichtig das Thema ist. Geht man auf die Suche nach dem Fehlercode 0x8024000d, stößt man auf weitere Treffer wie im Technet-Forenbeitrag: Windows 10 1703 and WSUS. Dort wird berichtet, dass der Fehler mit dem kumulativen Juni 2017-Update KB4022716 behoben sei. Problem ist aber, dass man diese und folgende Updates nicht bekommt, wenn der Client bei der Update-Suche scheitert. Im Thread werden noch eine Menge andere Lösungen angeboten (z.B. bei Dell-Systemen diese per DELL UPDATE aktualisieren lassen), die aber nicht global funktionieren. Mehrere Posts betonen, dass das Löschen von Metadaten von Drittanbietern (Dell, Adobe etc.) Abhilfe schafft. Zudem wird der Fehlercode 0x80240042 (WU_E_UNKNOWN_SERVICE The update service is no longer registered with AU) beschrieben.
Dort gibt es auch einen Verweis auf diesen Technet-Forenbeitrag der sich in Form eines Artikels mit dem Problem ‘Dual Scan’ unter Windows 10 befasst.
Beim Windows-Partner-Support gibt es noch diesen Thread (gelöscht), wo jemand den Fehlercode 0x8024000d und Windows 10 V1703 mit WSUS moniert. Dort gibt ein Microsoft-Mitarbeiter einen Hinweis auf einen Server Cleanup Wizard, mit dem man Updates auf dem Server bereinigen kann (siehe obigen Screenshot, hilft im aktuellen Fall aber nicht).
Im Dokument How to clean up the WSUS server and clients when reaching the locally published category limit gibt es einige Hinweise, wie man den WSUS Update-Speicher bereinigen könnte.
Ein Microsoft Support-Engineer berichtet am 26. Juni 2017, dass es ein bekanntes Problem gäbe:
Based on our discussion, there is a known issue about Windows 10 1703 and WSUS. If we used to import any third party update or any tools that the publisher is not Microsoft, WSUS would not work well with Windows 10 1703. So please help me double confirm if we have import and third party update or tools to WSUS. We could use WSUS to list all updates and look for the updates that do not have the corresponding KB number. If there is such an update listed, it means that we have used WSUS to install the third party updates. This may be our cause.
Dieses Problem sollte mit der manuellen Download und der Installation des letzten kumulativen Updates (die geben KB4022716 an) unter Windows 10 Version 1703 behoben sein. Dürfte den hier im Blog-Beitrag gegenständlichen Fehler aber nicht beheben. In den meisten Fällen wird man um eine Analyse nicht vorbei kommen.
Was sagen die Fehlercodes?
Gemäß meinem Blog-Beitrag Tipp: Windows Update Error Codes 0x8024xxxx dokumentiert habe ich bei Microsoft als erstes nach dem Fehlercode 0x8024500C gesucht, diesen aber nicht gefunden. Laut obigem Log handelt es sich um einen Fehler in der Integrität der Metadaten. Im verlinkten Dokument gibt es einen Abschnitt Redirector errors der Fehlercodes mit dem Muster 0x8024500x, die sich auf Redirector-Fehler in den Metadaten des Update-Pakets beziehen.
Der Fehlercode 0x8024000d ist dagegen im betreffenden Microsoft-Dokument ausgewiesen und steht für
WU_E_XML_MISSINGDATA – Windows Update Agent could not find required information in the update’s XML data.
Es fehlen also Metadaten in einem oder mehreren Update-Paketen, wodurch Windows Update nicht weiß, wo er die Informationen her bekommt. Ursache dürfte ein beschädigtes oder inkompatibles Update im Update Store der Clients sein.
Die Lösung: Fehlerhaftes Update finden
Der betroffene Administrator, der laut eigener Aussage mehr als 6 Wochen an dem Thema dran war, hat dann noch eine Lösung zur Ermittlung der Ursache gefunden. Die Idee war, das beschädigte Update per PowerShell zu ermitteln. Aus der Protokolldatei war die ID des Update-Pakets ja bekannt:
[agent]Failed to parse extended metadata for 6D629889-8D3F-4F26-929A-E08B8F363F49.100, hr=8024000d
Öffnet man eine administrative PowerShell-Eingabeaufforderung lässt sich der Status eines Update-Pakets mit:
Get-WsusUpdate -UpdateId <ID>
abfragen. Für die obige ID sieht der Befehl und das Ergebnis, welches der Administrator erhielt, so aus:
PS H:\> Get-WsusUpdate -UpdateId 6D629889-8D3F-4F26-929A-E08B8F363F49 Title Classification Installed/Not Applicable Approved Percentage ----- -------------- --------------------------- -------- Microsoft Office File Wichtige Updates Nicht genehmigt Validation Add-in PS H:\>
Das ‘Microsoft Office File Validation Add-in’ war auf den betreffenden Clients nicht zur Installation genehmigt und fehlte demnach in den Verweisen der Metadateien der Folge-Updates.
Was ist das Microsoft Office File Validation Add-in?
Das betreffende Paket Add-In zu Microsoft Office-Dateiüberprüfung (KB2501584) wird auf der Download-Seite von Microsoft mit folgender Funktion beschrieben:
Office-Dateiüberprüfung ist ein Sicherheits-Add-In für Office 2003 und 2007 und dient zur Sicherstellung, dass Dateien im Binärdateiformat mit dem Microsoft Office-Dateiformat übereinstimmen. Benutzer werden über mögliche Sicherheitslücken informiert, falls Dateien nicht mit dem Format übereinstimmen.
Scheint sinnvoll. Geht man aber nach dem Namen des Add-Ins auf die Suche, trifft man möglicherweise auf diesen Technet-Forenbeitrag aus 2011, der vor dem Update warnt. Auch in diesem älteren Blog-Beitrag gibt es eine Warnung, dass man das Update nicht einfach installieren solle: Zitat:
Das Office File Validation Add-In verhindert, dass Dateien in den klassischen Formaten doc und xls, die mit Fremdsoftware, wie z.B. LibreOffice oder OpenOffice erstellt wurden, in Microsoft Office geöffnet werden können. Auch Dateien, die mit bestimmten Office-Addons erzeugt wurden, können davon betroffen sein. Microsoft versucht damit offensichtlich, die alten Office-Dateiformate und auch Office-Pakete von Drittentwicklern aus dem Verkehr zu ziehen. Dateien in den neuen Formaten docx und xlsx sind nicht betroffen.
Das bringt jetzt schon etwas Licht ins Dunkel. Wer ggf. Dateien für Office 2007 aus den genannten Fremdquellen verarbeiten muss, darf das Add-In nicht installieren. Ein fehlendes Add-In führt aber unter Windows 10 Creators Update (Version 1703) zum Metadatei-Fehler 0x8024000d.
Die Lösung für den Fehler 0x8024000d
Die Lösung für den Fehler 0x8024000d ist reichlich obskur. Der Betroffene schreibt bei Technet im Forum, dass er das Update zur Installation in den Clients (in WSUS auf Windows 2012 R2) genehmigt habe. Danach fingen die Windows 10 V1703-Clients an, die anstehenden Windows Updates wieder normal zu verarbeiten.
Ab dieser Stelle wird es bei der Lösung aber reichlich obskur. Der Betroffene gibt an, dass das Update für das Add-in selbst nicht benötigt wird, denn es sei nicht installiert worden. Nach weiteren Feldforschungen schreibt der Betroffene:
Wenn ich den lokalen WSUS überbrücke und direkt von MS downloade, funktionieren die Updates. Ich habe einen PC vollständig Updaten lassen und dann wieder zurück auf meinen WSUS gesetzt und es kommt sofort wieder der Fehler 0x8024000d. Dann habe ich bei dem gleichen Client „Update für andere Microsoft-Produkte“ ausgeschaltet und erneut nach Updates suchen lassen, aber wieder 0x8024000d. Das verwirrt mich nun vollends. Ich werde jetzt noch einmal Office 2007 deinstallieren.
Es ist also mal wieder ein WSUS-Problem in Zusammenhang mit Windows 10 Clients. Scheint ein Bug im WSUS zu sein. Vielleicht helfen die hier im Blog-Beitrag aufbereiteten Informationen mal einem Betroffenen.
Ergänzung: André weist in folgendem Kommentar darauf hin, dass der in obigem log-File gelistete Fehler 0x8024500C für E_REDIRECTOR_CONNECT_POLICY = Connections to the redirector server are disallowed by managed policy steht. Es gibt Probleme mit Richtlinien. Nutzer Damon B berichtet im oben verlinkten Technet-Forenbeitrag, dass die Aktualisierung der admx-Dateien geholfen habe. Danach findet sich ein Hinweis des Nutzers McLion, der Registrierungsanpassungen für die Update-Einstellungen vorgenommen hat. Auch falsche SSL-Einstellungen werden als Ursache vermutet. Im Technet gibt es einen Blog-Beitrag, der sich mit Problemen unter Windows 10 V1511 und V1607 befasst.
Nutzer Matthias Miks hatte Erfolg, nachdem er den Real Time-Schutz des Defenders deaktiviert hatte. Und Chris Michetti musste einen Realtek PCIe GBE Family Driver aktualisieren und dann diverse Fixes in der Registrierung vornehmen. Weiterhin scheint KB4022716 (muss manuell auf den Win 10-Clients installiert werden) einen Bug zu beheben. Voodoo at it’s best …
Ähnliche Artikel:
Windows 10 Wiki/FAQ
Windows 10 V 1607 Wiki/FAQ
Windows 10 V1703 Wiki/FAQ
Windows 10: Update-Fehlercodes 0x8024…. entschlüsselt
Tipp: Windows Update Error Codes 0x8024xxxx dokumentiert
Windows 10: Update-Fehler 0x8024a112
Windows 10: Fehlercode 0x80240437 beim Update
Windows 10 (V1607): WSUS-Fehler 0x8024401c mit KB4034658 und KB4034661
Windows-Upgrade: Fehler 0x8024201c
Windows Update-Fehler 0x8024000E
0x8024500C = WU_E_REDIRECTOR_CONNECT_POLICY = Connections to the redirector server are disallowed by managed policy.
Der code steht in der SDK Datei „C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\um\wuerror.h“
Danke für die Ergänzung. Muss wohl doch mal in den sauren Apfel beißen und mir diese Teile des SDK auf eine Win 10 Maschine herunterladen lassen.
Spontan muss ich daran denken, dass Windows Upate for Business dem WSUS dazwischengrätschen kann.
Hier gibt es Infos dazu und welche GPOs dem im Wege stehen:
https://blogs.technet.microsoft.com/windowsserver/2017/01/09/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online/
https://www.windowspro.de/wolfgang-sommergut/updates-fuer-windows-10-apps-ignorieren-wsus-konflikt-wufb
Ist evtl. ein Funktionsupdate verschoben worden (mehr als 0 Tage)? Das hatte bei mir die Verbindung zum WSUS überbrückt und ist nur online gegangen.
Vielleicht hilft das weiter.
Viele Grüße
Peter
reprise des Windows 10 Bugs mit dem ersten August CU bei 1607? Oder aktive Sterbehilfe für das nicht mehr supportete Office 2007?
Folgendes habe ich zum Fehler 0x8024000d herausgefunden. Dieses Problem hatten wir ebenfalls auf allen Windows 10 V1703 Clients (egal ob Upgrade oder Neuinstallation). Alle älteren Windows Versionen konnten ihre Updates über unseren WSUS laden und installiert.
Im WindowsUpdateLog der Clients wurde der Fehlercode 0x8024500c an mehreren Stellen protokolliert. Office 2007 haben wir nicht installiert.
Zum Testen habe ich einige betroffene Clients so umgestellt, dass Windows Updates direkt über Internet bezogen und installiert werden. Hier kam es zu keinem Fehler, Windows hat anstandslos alle Updates geladen und installiert.
Danach habe ich die Clients wieder mit dem internen WSUS verbunden und siehe da: der Fehler war weg!
Nach einer Analyse des Updateverlaufs meiner nun wieder funktionierenden Clients konnte ich das Update KB4040724, welches die Lösung unseres Problems war, ausfindig machen.
Nach manueller Installation dieses kumulativen Updates auf weiteren betroffenen Rechnern, ist auch dort eine Kommunikation mit dem internen WSUS wieder möglich.