[English]Aktuell gibt es mit dem WSUS Synchronisationsprobleme. Weiterhin laufen Administratoren bei der Update-Installation für Office und Windows in Probleme, z.B. wird der Fehler 0x8000ffff ausgeworfen. Hier nochmal ein Überblick bzw. einige Erfahrungen eines Blog-Leser.
Anzeige
Updates für Office und Windows (Fehler 08000FFFF)
Blog-Leser JohnRipper hat mir vor einigen Stunden seinen Erfahrungsbericht mit den September 2016-Updates für Windows 10 und Office 2016 zukommen lassen. Er hat in seiner Firma am vergangenen Wochenende die Updates für Windows 10 und Office 2016 für den September 2018 ausgerollt. Das betrifft sowohl Office Feature-Updates aus dem ersten Dienstag im Monat, als auch auch Windows 10-Updates vom zweiten Dienstag im Moment, einschließlich die kumulativen Updates vom 17. September. Hier seine Erfahrungen:
- Dabei fiel auf, dass alle Clients nach der Installation des kumulativen Updates nach dem Neustart keine Updatesuche zulassen. Es wird der Fehler 0x8000FFFF ausgeworfen.
- Alle Clients prüfen Updates gegen einen WSUS auf Windows 2012R2 mit letztem Patch Stand.
- Nach ca. zwölf Stunden funktioniert die Updatesuche wieder wie gewohnt, ohne dass man etwas tun muss.
Ein Bugfix (z.B. Virenscanner deaktivieren) bzw. Cleanup der Windows Update Services (z.B. löschen des Ordners Software Distributionen sowie der Reg-Schlüssel) auf den Client-Computern, bringt keine Besserung. Nur das Warten. JohnRipper schreibt weiter:
- Die Clients auf denen ich das zuerst bemerkte waren auf Windows 10 V1709. Also tippte ich zuerst auf KB4457142 oder KB4464217.
- Da der Windows 10 1803 Rollout jetzt ebenfalls ansteht, habe ich das Verhalten auf Clients mit 1803 ebenfalls getestet und hatte auf beiden Test-Clients (x64 und x86) genau das identische Problem und zwar unmittelbar nach der Installation von Version 1803.
Da das Upgrade vom WSUS kam, wird bei Feature-Upgrades oft nicht der letzte verfügbare Build installiert, sondern die Build, die WSUS zur Verfügung steht. Hier ist das z.B. bei Windows 10 V1803 der letzte Build im WSUS (per heute) nicht 17134.319 sondern 17134.165.
Fazit ist für mich, dass der neueste Servicing Stack Schrott ist bzw. im Zusammenhang mit einem WSUS nicht richtig funktioniert.
Anzeige
Wahrscheinlich muss der Client warten, bis der letzte Token zur Kommunikation mit dem WSUS abläuft. Dann beantragt er einen neuen. Was dann wieder zum Erfolg in der Updatesuche führt.
Insgesamt nicht weiter tragisch, wenn man weiß, dass man einfach nur warten muss. Ich wusste es nicht, und mich hat es mal einen halben Samstag gekostet das zu "bugfixen". Denn ich bin natürlich von Problemen im Zusammenhang mit dem Updates ausgegangen.
Was die Pfuscher von MS übrigens aber endlich mal behoben haben, ist der Bug im Zusammenhang mit dem Zugriff auf die Updatesuche unter Windows 10, d.h. die Richtlinie "Disable access to Windows Update" funktioniert jetzt endlich richtig! Der Fehler zog sich seit Windows 10 V1607 [GB: hier war V1603 angegeben] durch alle Versionen (Zugriff nicht möglich, egal wie die GPO gesetzt war).
An dieser Stelle mein Dank an JohnRipper für die geschilderten Erfahrungen. Vielleicht hilft es jemand.
Neues zum WSUS-Sync-Problem
Über Synchronisationsprobleme beim WSUS hatte ich im Blog ja mehrfach in den letzten Wochen berichtet (siehe Link-Liste am Artikelende). Generell scheint sich bezüglich dieser Probleme wenig getan zu haben. Das Einzige, was bleibt: Warten, bis sich der Fehler am WSUS von selbst behebt.
- Bei askwoody.com werden sporadische Sync-Fehler im WSUS seit dem 17. September 2018 gemeldet.
- Bei administrator.de gibt es ebenfalls einen Thread, in dem einige Nutzer sporadische Probleme berichten.
Eine Fehlerursache lässt sich nicht festmachen. Es ist davon auszugehen, dass die Probleme bei Microsoft liegen.
Ähnliche Artikel
Office 2016 September-Updates killen WSUS-Synchronisierung
Windows 10: Flash-Update für Insider – und neue WSUS-Probleme
Microsoft fixt WSUS-Problem mit Office 2016-Updates
Patchday-Probleme Updates, WSUS (11. September 2018)
Windows 10 Microcode-Updates (13.9.2018) und WSUS-Chaos
Anzeige
Mir fallen Update Probleme immer nu temporär auf, da auch unseren 5000+ clients ein Skript läuft, welches WindowsUpdate-Fehler erkennt und anhand dieser WindowsUpdate lokal am Rechner zurücksetzt. Danach ist sogut wie immer alles gut und selbst Fehlgeschlagene Updates werden installiert.
Aber im großen und ganzen, ja, WSUS und Windows 10 = Patchärger!
Wenn dann auch noch die Erkennungsregeln für Updates zerbrochen sind, gab es auch schon öfters, wird es spannend.
Hallo Markus,
ich schließe mich, ebenfalls Interesse habend, Stefan an.
—
VG, Steffen
Als Basis dient: https://gallery.technet.microsoft.com/scriptcenter/Reset-WindowsUpdateps1-e0c5eb78
Die hier angeführten Punkte 7) und 10) brauche ich nicht!
Punkt 12) muss unter Windows 10 "C:\Windows\System32\usoclient.exe StartScan" heißen.
Ich untersuche das Eventlog nach möglichen WindowsUpdate Fehlern:
a)
$UpdateError=get-winevent -FilterHashTable @{LogName="Microsoft-Windows-WindowsUpdateClient/Operational"; Level=2; StartTime=$EventStartDate; EndTime=$EventEndTime;} -ErrorAction SilentlyContinue
b)
$OtherError = get-winevent -FilterHashTable @{LogName="System"; Level=2; Providername = "Microsoft-Windows-WindowsUpdateClient"; StartTime=$EventStartDateOtherError; EndTime=$EventEndTime;} -ErrorAction SilentlyContinue
Wobei:
$EventStartDate = (Get-Date).AddDays(-1)
$EventStartDateOtherError = (Get-Date).AddDays(-14)
$EventEndTime = Get-Date
Den Rest erspare ich euch, da ich hier noch einen eigenen LogProvider erstelle und ein weiteres eigenes Event generiere, um zu sehen wann das Skript angeschlagen hat und einfach damit es nicht bei jedem Systemstart läuft, wenn dies nicht nötig ist.
Achtung: lässt man den WindowsUpdateReset Teil als System laufen, dann schlagen nachher RPCs fehl!
Kann das gerne etwas aufbereiten, aber ich bin so frech und setze jetzt einfach PowerSehll Grundkenntnisse voraus.
LG,
Markus
Punkt 12 muss unter 1709: "startscan" heißen. Unter Windows 10 1803 heißt es jetzt "startinteractivescan"
So einfach ist es nicht :-)
Wir verwenden hier keine beta software :)
Klingt interessant. Darf man das Script evtl. sehen?
Zum Problem mit dem WSUS-Sync:
Dieses hatte ich ebenfalls bis zum 12.09.2018. An diesem Tag habe ich mal testweise in den WSUS-Settings die gesetzte Auswahl in Produkte und Klassifizierungen geändert. Sprich den Hacken bei Upgrades gesetzt, quittiert und danach wieder herausgenommen und quittiert. Anscheinend wird die Konfig oder was auch immer in den WSUS-Settings dadurch so angepaßt/gesetzt, dass der Sync danach wieder paßte – seit dem 12.09.2018 macht der WSUS wieder tägl. einen fehlerfreien Sync.
Ähm ja, hatte ich vergessen: WSUS 2012R2
Seit 04.12.2018 habe ich wieder Probleme mit der Synchonisation des WSUS.
2018-12-06 06:54:28.563 UTC Error WsusService.39 SoapUtilities.LogException USS ThrowException: Actor = , Method = "http://www.microsoft.com/SoftwareDistribution/GetUpdateData", ID=b9e721ae-f62d-4521-a536-484525342a90, ErrorCode=InternalServerError, Message=
bei Microsoft.UpdateServices.Internal.SoapUtilities.LogException(SoapException e)
bei Microsoft.UpdateServices.Internal.WebServiceCommunicationHelper.ProcessWebServiceProxyException(SoapHttpClientProtocol& webServiceObject, Exception exceptionInfo)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetUpdateData(UpdateIdentity[] updateIds, List`1 allMetadata, List`1 allFileUrls, List`1& updatesWithSecureFileData, Boolean isForConfig)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.GetUpdateDataInChunksAndImport(List`1 neededUpdates, List`1 allMetadata, List`1 allFileUrls, Boolean isConfigData)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.GetAndSaveUpdateMetadata(List`1 updates)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.CatalogSyncThreadProcess()
bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
bei System.Threading.ThreadHelper.ThreadStart()
2018-12-06 06:54:28.563 UTC Error WsusService.39 SoapUtilities.LogException USS ThrowException: Actor = , Method = "http://www.microsoft.com/SoftwareDistribution/GetUpdateData", ID=b9e721ae-f62d-4521-a536-484525342a90, ErrorCode=InternalServerError, Message=
bei Microsoft.UpdateServices.Internal.SoapUtilities.LogException(SoapException e)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.CatalogSyncThreadProcess()
bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
bei System.Threading.ThreadHelper.ThreadStart()
2018-12-06 06:54:28.563 UTC Info WsusService.39 CatalogSyncAgentCore.UpdateSyncResultAndGenerateReportingEvent CatalogSyncThreadProcess: report subscription USS internal error
2018-12-06 06:54:28.563 UTC Info WsusService.39 EventLogEventReporter.ReportEvent EventId=386,Type=Error,Category=Synchronization,Message=Fehler bei der Synchronisierung. Ursache: Fault occurred
Ein 2. WSUS verwendet die MUURL – dort läuft der Sync ohne Probleme
In meinem englischsprachigen Blog gibt es eine ähnliche Meldung zu Windows Server 2019.