Mal wieder Probleme. Diesmal brachten Clients mit 1703 und auch 1709 beim Suchen nach Updates auf dem WSUS-Server den Fehler 0x8024000d.

Im Windowsupdate-Log waren entscheidend diese 3 Zeilen, die mich der Lösung näherbrachten:

2017.11.23 19:34:10.4010252 3540 5556 Agent Failed to parse extended metadata for 6D629889-8D3F-4F26-929A-E08B8F363F49.100, hr=8024000d
2017.11.23 19:34:10.4012989 3540 5556 Agent *FAILED* [8024000D] Failed to get extended update infos
2017.11.23 19:34:10.4499203 3540 5556 Agent Exit code = 0x8024000D

Auf dem WSUS-Server in einer als Administrator ausgeführten Powershell-Konsole oder ISE dann

Get-WsusUpdate -UpdateId 6D629889-8D3F-4F26-929A-E08B8F363F49

Damit hatte ich die Update-Bezeichnung „Microsoft Office File Validation AddIn“. Dieses war im WSUS nicht zur Installation freigegeben.
Nachdem ich das getan hatte, funktionierten auch die Windows Updates auf den Clients fehlerfrei. Das Update selbst könnte zu Problemen führen, wenn mit 3rdparty-Anwendungen wie Libre Office usw. Dokumente im Office-Format gespeichert werden. Dann greift der Sicherheitscheck. Sehr gut und ausführlich beschrieben in der borncity unter https://borncity.com/win/2017/09/05/windows-10-v1703-update-error-0x8024000d-on-wsus/

Ergänzung: Nach meiner Ansicht tritt das Problem dort auf, wo über den WSUS auch noch eigene Updates verteilt werden – z.B. über den WPP (WSUS Package Publisher).