[English]Administratoren, die das Feature-Update auf Windows 10 V190x per WSUS verteilen, berichten, dass das nicht funktioniert und Fehlercodes wie 0x80070057 oder 0xc1900298 gemeldet wird.
Anzeige
Es sind jetzt zwei unterschiedliche Fälle, die mir unter die Augen gekommen sind bzw. die von Lesern berichtet wurden.
WSUS wirft Fehler 0xc1900298
In diesem Kommentar meldet sich Blog-Leser Ralf Münz und gibt an, dass er Probleme mit einem Funktionsupdate habe.
Hallo,
ich habe hier auch das Problem, dass ein Update von 1809 auf 1909 mit einem Fehler 0xc1900298 im WSUS auftaucht. Mit manueller Suche wird nach dem Fehler der Download wiederholt und 1909 installiert, aber automatisch im Hintergrund nicht. Hat das jemand auch so beobachtet und ggf. eine Lösung?
Eine Suche hat mir diesem Artikel ausgeworfen. Dort wird auf einen Beitrag in der Norton-Community verwiesen. Meist wird vermutet, dass es mit installierten Drittanbieter-Antivirus-Produkten zu tun habe. Diese führen mitunter zu beschädigten Update-Datenbanken auf dem Client.
WSUS wirft Fehler 0x80070057
Ein anderer Fall wurde mit von Blog-Leser Stefan T. per E-Mail berichtet. Ich stelle den Sachverhalt hier mal im Blog ein.
vielleicht sind Sie bei sich oder in ihren Blog auf das Problem gestossen, dass der WSUS (weiß nicht ob es nur Server 2019 betrifft) das Funktionsupdate auf z.B. 1903 oder 1909 nicht verteilt und stattdessen Fehler 0x80070057 bringt.
Obiger Screenshot zeigt die Fehlermeldung mit dem Fehlercode 0x80070057. Zum Update-Fehler 0x80070057 hatte ich vor längerer Zeit mal was im Blog-Beitrag Windows 10: Update-Fehler 0x80070057 zusammen gestellt, was diesen Fehlercode auslösen kann. Stefan hat zu dem Problem noch folgendes angemerkt:
Hier unten in den Links (gibt noch mehr) sind auch Leidensgenossen, die genau das gleiche Problem haben. "Normale" Updates funktionieren ohne Probleme!
Diese Links zu weiteren Betroffene, die Stefan andeutet, beziehen sich auf diesen Post im ComputerBase-Forum, wo der Update-Fehler 0x80070057 im Zusammenhang mit WSUS thematisiert wird. Und bei administrator.de findet sich hier ein Thread, der sich ebenfalls um den Fehler dreht. Dort heißt es, dass die Installation per ISO-Installationsdatei aber funktioniere.
Bisher keine Lösung
Stefan schreibt Leider scheint noch keiner eine Lösung zu haben… und gibt an, schon vieles ausprobiert zu haben. Dazu gehören:
Anzeige
WSUS ganz neu installiert auf VM mit Server 2019
Anpassung im IIS (Einstellungen Speicher / Protokoll usw.
MIME Typ gewechselt – einer hat auch geschrieben Eintrag ganz löschen???Verschiedene Registry-Einstellungen lt. Foren probiert
So eine .ini mit Eintrag "DynamicUpdate=Disable" erstellt siehe (falls er vor dem Download vom WSUS was Online prüfen will)
Ich zitiere Stefan, der folgendes sagt: Ich habe schon vieles probiert, aber die Clients bekommen das Update angeboten und laden es aber wohl (zumindest die .esd Datei) nicht runter.
Obiger Screenshot zeigt die Dateien im Windows-Unterordner SoftwareDistribution\Download. Er schrieb mir zudem:
Das sah mir erst aus, wie das Problem, dass es schon mal gab, dass im IIS die .esd nicht registriert war – aber ist sie. Weder als MIME Type "application/vnd.ms-cab-compressed" noch als "application/octet-stream" funktioniert es.
Irgendwo liest man dann so zwischen den Zeilen, dass es offline nicht gehen würde, aber wenn man es mit der ISO macht, geht es – nur dass kann ja nicht die Lösung sein an über 100 PCs mit einer ISO zu gehen. Das ganze soll ja im Hintergrund ablaufen, ohne zutun. Soviel Zeit hat man ja gar nicht und die Mitarbeiter sollen ja auch weiterarbeiten können während der Installation. Dafür gibt es ja den WSUS.
Frage: Hat jemand von Euch eine Lösung für die obigen Update-Fehler?
2015
Ich dachte das betrifft nur 2004, aber jetzt scheint es auch noch mit 190x Probleme zu geben. Ist ja wieder super alles.
Update nicht über WSUS, sondern über ein Script ausführen, wer kein Deploymenttool von Drittanbietern (wie z.B. PDQ Deploy oder ABC-Deploy) einsetzt wird es sicher auch über die Gruppenrichtlinie gesteuert bekommen.
CMD Befehlszeile um ein Upgrade ohne Reboot auszuführen (User wird nicht gestört, außer er führt selber ein Neustart aus):
\\pfad_zur_Win_10_1909_x64_ordner\setup.exe /auto upgrade /noreboot /migratedrivers all /ShowOOBE none /Compat IgnoreWarning /Telemetry Disable /DynamicUpdate disable
Durch entfernen von /noreboot kann man das Setup auch inkl. Reboot vollautomatisch bis zum Ende durchlaufen lassen.
Der Pfad zum Setup kann auf ein Netzlaufwerk gehen, er muss nur vom PC aus zugreifbar sein. Es besteht kein Grund das Windows Setup erst auf den lokalen PC zu kopieren.
Hallo zusammen,
ich hatte das Problem vor einigen Monaten. Ich bin letztendlich darauf gekommen, dass in WSUS das Produkt Windows 10 Dynamic Update dafür verantwortlich war. Nachdem ich den Haken entfernt habe sowie die Dynamic Updates manuell gelöscht habe, hat es auch wieder funktioniert. Seit einer bestimmten Win 10 Version (glaube 1803) wird laut einem Microsoft Artikel automatisch ein Dynamic Update durchgeführt, man muss es also nicht mehr anhaken.
Weiß nicht ob das hier der gleiche Fehler ist, aber zumindest funktionieren bei mir Feature Updates über WSUS
Die Probleme haben wir eigentlich schon immer mit allen Upgrade gehabt. Bei manchen Rechnern sind mittlerweile ich glaube 4 Upgrades ausstehend, aber installiert werden die nur mit Fehler. Der WSUS Server war zuvor neu aufgesetzt worden, Server 2016.
2 Wochen hat das Funktionsupdate über den WSUS funktioniert. Seit dieser Woche laden die Clients das esd-File nicht mehr mit dem Fehler 0x80070057.
WSUS auf vorige Woche zurückgesetzt hat auch nicht geholfen.
Lösung gefunden! Es liegt an den dynamische Updates. Bei mir lag es an dem 2020-06 Dynamic Update for Windows 10 Version 2004 for x64-based Systems (KB4557956).
Vor dem Upgrade auf die Version 2004 versucht der Client das dynamische Update zu installieren. Dies schlägt aber leider fehl. Keine Ahnung warum. Nachdem ich das Update im WSUS abgelehnt habe und das Verzeichnis C:\$WINDOWS.~BT lokal am Client gelöscht habe, (dort speichert der Client nämlich alle notwendigen Dateien für das Upgrade, auch die Dateien für das Dynamic Update) lief das Upgrade ohne Probleme durch.
Konnte ich bei unserer Umgebung auch verifizieren, das Upgrade auf 1909 über WSUS schlug auf allen Clients fehl mit dem Fehler 0x80070057 .
Nachdem ich den Lösungsvorschlag hier heute gefunden habe, habe ich die Dynamischen Updatepakete auf unserem WSUS abgelehnt und vorbeugend auch erstmal aus dem Download genommen. Nun funktioniert das Inplace Upgrade auf 1909 über den WSUS wieder. Viele dank für die Lösung, ich bin schon vor Monaten auf den Fehler gestoßen, hatte aber bis heute nichts gefunden und hatte daher zwangsläufig ein Image verwenden müssen :).
Sofern das keine Absicht ist, sollte das seitens Microsoft dringend gefixt werden.
Hallo Tobias,
Vielen Dank für deinen Tipp – an meinem Testrechner scheint es schon mal zu funktionieren, nachdem ich wirklich viel probiert habe mit WSU Bereinigung usw.
Wie macht ihr das mit dem "$WINDOWS.~BT" Verzeichnis löschen?
Kann man das in eine Gruppenrichtlinie machen? Darf das nur einmalig laufen?
Merkwürdig ist auch, dass er zumindest das 2004 vor dem Juni Update bei ein Paar Rechnern installiert hat und dann kamen wieder die Fehler auf den anderen Clients… – Hatte auch, dass die Service-Stacks vom Juni beim Download auf die Rechner bei 0% stehengeblieben sind.
Gruß
Stefan
Perfekt, Vielen Dank, das ist die Lösung, funktioniert sofort für das Windows 10 Funktions-Update 2004 .
Hatte auch Probleme, per WSUS (Server 2016) die Clients von 1809 auf 1909 zu aktualisieren, nur an ein paar vereinzelten Clients mit WSUS hat es funktioniert (warum genau an diesen? Keine Ahnung). Die Fehlermeldung war 0x80070003, wozu es ja auch hier: https://www.borncity.com/blog/2013/11/05/windows-8-1-upgrade-error-0x80070003/ einen Beitrag gibt. Woanders hieß es dazu auch "könnte was mit dem Partitionslayout sein" (welches tatsächlich manuell erstellt ist aber nach Referenz von Microsoft).
Mir hat geholfen, den MIME-Typ auf application/octet-stream zu stellen und anschließend IIS- und WSUS-Dienste neuzustarten. An einem Client testweise SoftwareDistribution zurückgesetzt, in der Einstellungen-App am Client das Update gestartet und erfolgreich installiert – bei einem zweiten Client war das Löschen des SoftwareDistribution-Ordners nicht nötig.
PS: Defekte Benutzerprofile und auch Benutzer, die mit temporären Profilen angemeldet werden, können ebenfalls das Upgrade verhindern – das gibt nach der Installation per WU nicht mal eine Angabe zum Fehler ("Update erfolgreich installiert", aber trotzdem zurückgerollt), die Angabe des Fehlercodes nur bei Installation per Setup.exe.
Bei Windows 10 Clients, die über WSUS (Windows 2012R2), ein Funktionsupdate beziehen tritt die Problematik auf, da Windows 2012 noch keine MIME-Typ "esd" kennen. In diesem Falle wie folgt vorgehen
1. „Internetinformationsdienste (IIS)-Manager" öffnen.
2. Auf „MIME-Typ" klicken.
3. Auf „Hinzufügen" klicken.
4. Bei „Dateinamenerweiterungen" „.esd" und bei „MIME-Type" „application/octet-stream" eintragen und OK klicken.
Ein Neustart des IIS-Dienstes ist nicht nötig.
Super hat bei mir sofort geklappt! War auch die einzige logische Antwort – da ein manueller Testdownload (der ESD-Datei) mit dem Firefox auch schon nicht geklappt hatte.