Ich habe mal wieder eine merkwürdige Beobachtung eines Blog-Lesers in Bezug auf Windows 10 20H2 und die Update-Installation. Betroffen ist wohl eine verwaltete Umgebung im Unternehmensumfeld. Dort können sich die Windows 10-Clients plötzlich nicht mehr aktualisieren, weil der Download scheitert. Problem ist aber auch, dass sich der Update Component Store nicht mehr einfach leeren lässt. Hier die Beobachtungen des Blog-Lesers, der sich dafür interessiert, ob noch jemand tangiert ist.
Anzeige
Blog-Leser Markus K. ist Administrator im Umfeld einer Firma/Organisation, in der viele Windows-Clients zentral verwaltet werden. Das als Vorabbemerkung, um den Sachverhalt einordnen zu können. Es betrifft auch nicht einen einzelnen Rechner mit Windows 10, sondern mehrere Clients, die auf Version 20H2 aktualisiert sind.
Updates werden nicht mehr heruntergeladen
Markus schrieb mir eben per E-Mail, dass er Probleme mit seinem Clients hat, die sich nicht "aktualisieren" lassen, weil die Updates nicht von der Update-Quelle heruntergeladen und im Windows Update Store gespeichert werden können.
Guten Morgen,
ich beobachte folgendes Verhalten: Rechner können nicht aktualisieren. Soweit so gut, kommt schon mal vor.
Updates können nicht mehr heruntergeladen werden => altbekannten Download Ordner kübeln.
Das Fehlerbild ist klar: Der Download der Updates scheitert auf den Windows 10 20H2 Clients. Die Standard-Kur für so etwas wäre, den Windows-Ordner für die Update-Downloads (Windows Update Speicher / Component Store) unter SoftwareDistribution\Download zu leeren. Dann sollten dort keine kaputten Dateien/Berechtigungen mehr stören. Hier erlebte Markus K. aber sein besonderes Wunder und schreibt:
Spannend wird es für mich, weil "C:\Windows\SoftwareDistribution\Download" nicht mehr einfach gelöscht werden kann.
Besitzer/Owner ist System und loakale Administratoren haben Vollzugriff.
Markus hat per Powershell z.B. den folgenden Befehl zum Rekursiven Löschen dieses Download-Odners versucht:
Anzeige
Remove-Item .\Download -Recurse -Force
Klappte aber nicht, da der PowerShell-Befehl folgenden Fehler wirft:
Remove-Item : Cannot remove item C:\WINDOWS\SoftwareDistribution\_Download\c07e146628f3b3967bcef8590cf20ee5\_Windows10.0-KB5003173-x64.cab_\amd64_microsoft-windows-n..quickstart.appxmain_31bf3856ad364e35_10.0.19041.423_none_72535ca9b59a95 15\f\narratoruwpsquare44x44logo.targetsize-30_altform-unplated_contrast-black.png: Could not find a part of the path 'narratoruwpsquare44x44logo.targetsize-30_altform-unplated_contrast-black.png'. + CategoryInfo : WriteError: (narratoruwpsqua...trast-black.png:FileInfo) [Remove-Item], DirectoryNotFoun dException + FullyQualifiedErrorId : RemoveFileSystemItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand
Zu diesem Fehler schreibt Markus:
Den Fehler verstehe ich nicht, da Pfad und File ja sehr wohl da sind.
und fragt, ob es jemanden unter den Blog-Leser/innen gibt, die das Verhalten beobachtet haben. Er meint, dass es jedenfalls seltsam sei, dass es nur einzelne Rechner trifft. Markus hat mir noch einen Verweis auf den Microsoft Support-Artikel KB5005322 – Some devices cannot install new updates after installing KB5003214 (May 25, 2021) and KB5003690 (June 21, 2021) hinterlassen. Dort wird eine Reparaturinstallation per Inplace-Upgrade vorgeschlagen. Dazu meint der Blog-Leser:
Allein die Aussage, man möge doch das Inplace Upgrade anwerfen um das Problem zu beheben ist in großen Umgebungen nicht umsetzbar und völlig realitätsfern.
Markus K. hat aber in seiner Mail auch nichts vom Fehler PSFX_E_MATCHING_BINARY_MISSING geschrieben, der laut Microsoft Support-Artikel KB5005322 ja ausgeworfen werden sollte. Abschließende Frage: Irgend jemand, dem etwas ähnliches widerfahren ist oder sich einen Reim darauf machen kann?
Anzeige
Ist schon länger her, dass ich Probleme mit Updates hatte. Dann hatte ich den Windows Update Dienst beendet (der Dienst blockiert sonst die Löschung) und den kompletten Ordner SoftwareDistribution gelöscht (nicht nur die Dateien).
Ich meine aber kürzlich ähnliche Probleme im Feedback-Hub oder irgendwo im Forum gelesen zu haben. Wenn ich es noch finden sollte, melde ich mich wieder.
ich würde den kompletten Ordner Download löschen nicht nur den Inhalt. Vorher aber sicherstellen, dass der Windows Update Dienst und der BITS Service nicht läuft.
ggf. noch C:\ProgramData\Microsoft\Network\Downloader\qmgr*.dat löschen. braucht aber auch admin berechtigungen
Was genau ist mit „Updates werden nicht mehr heruntergeladen" gemeint?
Ich hatte zu diesem Patchday das Problem, dass einige Rechner beim herunterladen des KB5004237 bei 0% Download stehen geblieben sind, egal wie lange man wartet.
Wir setzen bei uns WSUS ein.
Wenn ich dann an den Betroffenen Clients online bei MS gesucht hatte, ging es ohne Probleme.
Auch ein manuelles installieren funktionierte.
Ein löschen des SoftwareDistribution-Ordners half auch an den entsprechenden Clients.
Komischerweise trat das Problem nur bei KB5004237 auf, andere Updates wurden problemlos vom WSUS geladen.
Und eben nur bei einem kleinen Teil der Clients.
Da bin ich auch noch am rätseln
Interessant, scheint genau das von mir beschriebene Verhalten zu zeigen.
Wir verwenden auch WSUS und es betrifft exakt 20H2 die das 2021-07 CU wollen.
Wird der "Download" (es ist gar nicht nötig den ganzen "Softwaredistribution" Ordner zu löschen) Ordner gelöscht klappt alles ganz wunderbar.
Was ich nicht verstehe, warum sich der "Download" Ordner via PowerShell mit -Recurse -Force einfach nicht löschen lässt! Jede Menge *.png Files wo die PS mault, dass der Pfad nicht gefunden wird.
Hat man den Explorer mit den selben Berechtigungen mit denen man in der PS löscht offen und löscht dan im "Download" Ordner den Rest, klappt das prompt!
Stellt sich mir die Frage wieso löschen via Explorer besser/anders als löschen via PS funktionieren soll.
Aus meiner Sicht nicht das Erste Mal, dass Dinge plötzlich komisch werden.
Hattest du evtl. auch am WSUS vorher die „Schnellinstallationsdateien" an und hast dieses nun deaktiviert?
Denn das habe ich gemacht und seitdem ist das erste mal dieses Verhalten mit den 0% aufgetreten.
Kann auch Zufall sein
Siehe hier:
https://www.borncity.com/blog/2021/07/14/patchday-windows-10-updates-13-juli-2021/
"express install files" sind bei mir an.
Sollte diese Option nicht eh inzwischen obsolet sein? Kann man aber als "Bösewicht" ausschließen.
Irgendwas passiert auf den clients, das nicht passieren sollte.
"Remove-Item .\Download -Recurse -Force
Klappte aber nicht, da der PowerShell-Befehl folgenden Fehler wirft:"
Das mag der Befehl vielleicht nicht löschen, weil mehr als 255 Zeichen im Pfad/Namen sind.
Kenne das Problem auch.
Mein Windows 10 20H2 ließ sich per du nicht mehr aktualisieren. Den Fehlercode weiß ich nicht mehr, war aber irgentwas mit einem fehlerhaften Update-Paket.
Die Nutzung von sfc und dism brachte keine Besserung,
Das einzigste was half war der Windows-10-Update-Assistent. Und dieses Programm ging etwas brachial vor. Nach 30-60 Minuten war das Update installiert, ich hatte einen weiteren Ordner namens C:\Windows10Upgrade und cirka 53 Programme wurden neu installiert. Angefangen von Treiberpakten für Spezialhardware bis hin zu Programmen wie Python, LLVM, Bildbetrachter, PDF Viewer,…
Moin
Das "riecht" für mich nach Berechtigungsproblemen.
Also Dienste Stoppen.
Ich würde zuerst die Rechte am Ordner übernehmen und Ihn dann löschen.
Samt Struktur.
Elevierte CMD starten:
net session >nul 2>&1 || (powershell -EP Bypass -NoP -C start '"cmd.exe'" -verb runas &exit /b)
net stop bits
net stop wuauserv
takeown /f C:\Windows\SoftwareDistribution\Download /r
cacls C:\Windows\SoftwareDistribution\Download /E /T /G Jeder:F
rd /s C:\Windows\SoftwareDistribution\Download
Mehr als lokaler Administrator mit Vollzugriff geht nicht. Ich könnte maximal versuchen, was passiert, wenn man als SYSTEM daher kommt.
Ich habe mir ein kleines Script auf Basis von diesem hier erstellt:
https://gist.github.com/chw2054/9a5ff06d61c32c1e8cdc364b08df4156
Das weise ich dann im Fehlerfall per Intune dem entsprechenden Client zu. Hat bisher jedes Update-Problem behoben.
Danke für das sehr ausführliche Script. Damit sollten wirklich alle eventuellen Probleme abgedeckt sein 👍
Selbiges in Verwendung, bei manueller ausführung Blut in der Powershell!
Doofes löschen via Explorer mit exakt den selben Rechten und alles ist gut!
Ist der Befehl "wuauclt /resetauthorization /detectnow" wirklich noch aktuell?
einfach neue Zeile und um
"C:\Windows\System32\usoclient.exe RefreshSettings"
ergänzen und gut ist es.
Keine Ahnung warum bei MS hier mit "Geheimwissen" gearbeitet wird, weil offiziell gibt es dazu nichts.
Der Befehl wuauclt /reportnow zb. funktioniert ebenfalls noch obwohl laut MS bei Windows 10 nur noch die usoclient.exe für WSUS Geschichten zuständig ist.
Verwende ich immer noch wenn ein Client seinen Status am WSUS aktualisieren soll.
Von daher würde ich den Befehl drinnen lassen und mit dem Eintrag von Markus K. erweitern.
Die machen echt ein großes Geheimnis darum, eine offizielle Dokumentation habe ich nie gefunden.
Ja das kann ich bestätigen.
Beim vorletzten Patchday waren mehrere Server/Clients defekt bzw. die Update Agents. SFC und DISM haben nichts gebracht.
Bei allen Installationen waren massive Schreib- und Lesezugriffe auf das Verzeichnis SoftwareDistribution\Download vorhanden. Die Systeme liefen dadurch permanent auf 100% Festplattenauslastung.
Das stoppen der Dienste war nicht möglich. Die dahinterliegenden Prozesse von den Diensten "wuauserv", "CryptSvc", "bits" und "msiserver" mussten beendet werden. Danach habe ich den kompletten SoftwareDistribution-Ordner gelöscht und neugestartet.
Dann war alles wieder in Ordnung und die Updates konnten wieder gesucht und installiert werden.
Hatte ich auch schon mal. Nach dem stoppen der Dienste ließ sich der Ordner, in der administrativen Kommandozeile, wegen fehlender Rechte nicht umbenennen.
Ich habe dann beim dritten Versuch einfach mal den Datei-Explorer bemüht und konnte wundersamer Weise den Ordner dort umbenennen …
Danach ging alles wieder, da er den Ordner dann ja neu erstellt.
Löschen verhindert ein aktiver BITS, der gerade eine Datei offenhält. Download-Fehler habe ich manchmal auf Clients mit kruder Netzwerkkonfiguration (z.B. gleichzeitig in LAN und WLAN, mehrere VPNs offen oder eine Virtualisierungssoftware mit virtuellem Netzwerk.
würde in meinem Fall heißen, dass BITS beim 2021-07 CU für 20H2 immer dann rennt wenn man mit Powershell löscht und nie rennt wenn man manuell via Explorer löscht.
Ich lass das jetzt mal so stehen, den bei MS kann man ja inzwischen alles haben…
Nie das Kind mit der Badewanne ausschütten, bringt nix. Erstmal mit Powershell nachgucken, was los ist
Get-WindowsUpdateLog
In der erzeugten Logdatei nach Fehlern suchen. Bei mir kam z.B. raus, dass manche Clients irrtümlich versuchen, den WSUS per Proxy zu erreichen, obwohl interne Adressen eigentlich als Ausnahme in der Proxy-Config hinterlegt sind.
Es half, in der Registry alle Proxy-Settings zu löschen und anschließend per Internet-Optionen wieder zu setzen und dann die Kiste neu zu starten.
Dort scheint alles gut.
Erst im CBS Log sieht man "Access violation".
Berechtigungen passen jedoch.
Einmal weggelöscht, klappt das Update dann ganz wunderbar.
Für mich nicht nachvollziehbar.
Mich stört das – Force….
Es gibt zahlreiche Beiträge dass mit -force das löschen
Nicht wirklich funktioniert..
Hit me if i'm wrong..
@Thomas: Wollte eigentlich antworten…
Leider nein, wird samt stoppen von allem nicht gelöscht, keine chance!
Aus dem Explorer mit exakt den selben Rechten wird der Ordner gekillt.
Ich versteh nur mehr Bahnhof :)
remove-item \\?\C:\WINDOWS\SoftwareDistribution\Download\ -Recurse -Force
Schon bei Win7 war das von 5 Diensten abhängig, die man zuerst wegen der Abhängigkeiten in der richtigen Reihenfolge beenden musste, bevor man die Ordner sicher löschen oder umbenennen konnte.
Es liegt auch nicht nur am Ordner \windows\SoftwareDistribution, sondern auch an \Windows\system\catroot2 (da werden die Signaturen der Updates gespeichert).
net stop TrustedInstaller
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren %windir%\System32\catroot2 catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver
net start TrustedInstaller
Aktuell habe ich ein Problem mit 21H1 in VirtualBox 6.1.26, denn da funktioniert das Startmenü nicht mehr, weil "Herunterfahren" sich nicht mehr mit der linken Maustaste anklicken lässt und mehrere Menüeinträge übereinander und durcheinander dargestellt werden.
Per Rechtsklick funktioniert es.
Ob das am letzten Win-Update liegt oder am Grafiktreiber der neuen VirtualBox GuestAdditions 6.1.26?
bzgl. der pfad überlänge beim löschen mit powershell
https://adamtheautomator.com/powershell-delete-file/
Auszug aus dieser Seite:
In Windows PowerShell 5.1, there is a workaround to the long path name problem. The workaround is to use the Unicode version of the path. Instead of specifying the path like this – C:\temp, use the Unicode version like this – '\\?\C:\temp' for folders located locally, or '\\?\UNC\\\Temp' if the folder is located in a UNC path.
wenn wieder ein kaputter client aufschlägt probier ich das gerne aus und gebe feedback.
Das klappt. Wieder was dazu gelernt :).
Bleibt also nur noch die Frage warum das Update bei manchen Rechnern dermaßen schief geht.
Hallo,
ich habe das Problem, dass das KB5004237 sowie KB5004296 sich nicht installieren lassen. Due Updates werden heruntergeladen und auch installiert, aber bei 100% kommt schließlich der Fehler "0x8007000d". Download Ordner löschen, SFC, Problembehandlung, oder alles in Kombination – nichts hilft. Betroffen sind Domain-Notebooks mit Win 10 21H1, die anscheinend seit April kein KU hatten. Muss ich etwas nachinstallieren, damit das wieder geht?
bloß ja nicht das 2021-05 CU am WSUS declinen, denn dann geht nix mehr!
Soweit wollte ich nicht gehen. Ich habe testhalber das Cu 2021-07 declined und gehofft, es würde das Juni CU 2021-06 installiert, aber das ging auch nicht. Ich habe mehrere Notebooks auch vom WSUS gelöscht um sie komplett unabhängig zu machen, woraufhin die aktuelle .NET einwandfrei installiert wurde, das CU aber weiterhin nicht… also versuche ich es nun weiter über den WSUS und decline noch 2021-06 oder ziehe ich mir 2021-05 über den Update Katalog und versuche mich an der händischen Installation – bei über 20 Notebooks? :-(
Ich habe mir nochmal unseren WSUS vorgenommen. Das declinen des CU2021-07 hatte wohl deshalb nicht den gewünschten Erfolg gebracht, da ich das CU 2021-06 nicht allowed hatte – zumindest nicht das richtige. Jetzt scheint es, als könnten die Notebooks das CU 2021-06 erfolgreich vom WSUS installieren und anschließend 2021-07 via online. Gut, dann mal hoffen dass meine Anwender mitspielen und das zügig über die Bühne geht!
Vielen Dank an den Blog und Markus K. …
Konnte kürzlich auch auf 20H2 Clients keine Updates mehr installieren.
Hatte aber versehentlich das CU 2021-05 KB5003173 im WSUS declined, das hatten diese Clients noch nicht installiert.
Also habe ich die folgenden CUs temporär declined und das KB5003173 wieder approved. Als das dann installiert war, konnten auch die neueren CUs und weitere Updates wieder sauber installiert werden.
Vielleicht ist dieses Update auf dem betroffenen Client auch noch nicht installiert?
Hallo,
ja nun ja – das KU 2021-06 ist jetzt auf manchen der betroffenen Clients (nach decline 2021-07) erfolgreich durch. Aber wieder gibt es – wen wundert es eigentlich! – Kisten, die auch das CU 2021-06 nicht annehmen wollen (fast jedes 2te). Als nächstes werde ich also auch 2021-06 declinen und hoffen, dass die übrigen sich dann wenigstens zu CU 2021-05 überreden lassen.
Das macht mich langsam wahnsinnig. Als hätte ich in den letzten 4 Wochen nicht schon genug gelitten!