[English]Am 13. Juli 2021 (zweiter Dienstag im Monat, Patchday bei Microsoft) wurden verschiedene kumulative Updates für die unterstützten Windows 10 Builds (von der RTM-Version bis zur aktuellen Version 21H1) freigegeben. Hier einige Details zu den jeweiligen Sicherheitsupdates zum Patchday.Eine Liste der Updates lässt sich auf dieser Microsoft-Webseite abrufen (die deutschsprachigen Seiten sind aber noch nicht aktuell). Ich habe nachfolgend die Details herausgezogen. Seit März 2021 integriert Microsoft ja die Servicing Stack Updates (SSUs) in das kumulative Update. Das bezieht sich aber nur auf Windows 10 Version 2004 und höher, es gibt also noch separate SSU-Installation für ältere Windows 10-Versionen.
Anzeige
Updates für Windows 10 Version 2004/20H2/21H1
Für die Mai 2020 erschienenen Windows 10 Version 2004 sowie die im Oktober 2020 per Update-Suche angebotene Windows 10 Version 20H2 und die im Mai 2021 freigegebene Windows 10 Version 21H1 stellt Microsoft die gleichen Update-Pakete, die nachfolgend genannt sind, bereit.
Update KB5004237 für Windows 10 Version 2004/20H2/21H1
Das kumulative Update KB5004237 hebt die OS-Build bei Windows 10 Version 2004 auf 19041.1110 und bei Windows 10 Version 20H2 auf 19042.1110. Bei Windows 10 Version 21H1 wird es die OS-Build 19043.1110. Das Update steht für Windows 10 Version 2004, Windows 10 Version 20H2, Windows 10 Version 21H1 sowie für Windows Server Version 2004, Windows Server Version 20H2 und Windows Server Version 21H1 bereit. Es beinhaltet Qualitätsverbesserungen aber keine neuen Betriebssystemfunktionen. Der Legay Edge-Browser wurde im April 2021 aus Windows 10 entfernt. Hier die Liste der Verbesserungen, von Microsoft als Highlights bezeichnet:
- Updates for verifying usernames and passwords.
- Updates to improve security when Windows performs basic operations.
- Updates an issue that might make printing to certain printers difficult. This issue affects various brands and models, but primarily receipt or label printers that connect using a USB port.
Microsoft weist darauf hin, dass dieses Update Qualitätsverbesserungen am Servicing Stack (ist für Microsoft Updates verantwortlich) durchführt. Hinzukommen folgende allgemeine Fixes und Verbesserungen:
- Addresses an issue that might make printing to certain printers difficult. This issue affects various brands and models, but primarily receipt or label printers that connect using a USB port.
- Removes support for the PerformTicketSignature setting and permanently enables Enforcement mode for CVE-2020-17049. For more information and steps to enable full protection on domain controller servers, see Managing deployment of Kerberos S4U changes for CVE-2020-17049.
- Adds Advanced Encryption Standard (AES) encryption protections for CVE-2021-33757. For more information, see KB5004605.
- Addresses a vulnerability in which Primary Refresh Tokens are not strongly encrypted. This issue might allow the tokens to be reused until the token expires or is renewed. For more information about this issue, see CVE-2021-33779.
- Security updates to Windows Apps, Windows Management, Windows Fundamentals, Windows Authentication, Windows User Account Control (UAC), Operating System Security, Windows Virtualization, Windows Linux, the Windows Kernel, the Microsoft Scripting Engine, the Windows HTML Platforms, the Windows MSHTML Platform, and Windows Graphics.
Administratoren von Domain Controllern beachten die Änderung im 2. Punkt zu den Kerberos S4U-Änderungen, auf die mich Microsoft die Nacht per E-Mail separat hingewiesen hat. Ansonsten wird der Fix für die PrintNightmare-Schwachstelle, die bereits durch die Sonderupdates vom 6./7. Juli 2021 geschlossen wurde (vermutlich mit den dort aufgetauchten Problemen) erneut mit ausgerollt.
Wichtig: Voraussetzung zur Installation ist aber ein installiertes Update KB5003173 vom 11. Mai 2021. Das war schon beim Preview Update vom Mai 2021 so – das "kumulativ" kann man sich also bei Windows 10 2004 bis 21H1 auf absehbare Zeit sparen (danke an Martin E. für den Hinweis). Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Für das Update gibt Microsoft verschiedene bekannte Probleme im Supportbeitrag an.
Anzeige
Zudem hat Microsoft ein Update direkt für den Windows Update Client veröffentlicht, um dessen Zuverlässigkeit zu verbessern. Das wird außerhalb von Windows Update ausgerollt, wenn die Maschine kompatibel und keine LTSC-Variante ist und Updates nicht per GPO blockiert wurden.
Updates für Windows 10 Version 1909
Windows 10 Version 1903 ist am 8. Dezember 2020 aus dem Support gefallen. Für das in 2019 erschienene Windows 10 Version 1909 stehen folgende Updates zur Verfügung.
Update KB55004245 für Windows 10 Version 1909
Das kumulative Update KB5004245 hebt die Windows 10 V1909 OS-Build auf 18363.1679. Das Update steht für Windows 10 Enterprise/Education Version 1909 sowie für Windows Server Version 1909 bereit. Der Legacy Edge-Browser wurde bereits im April entfernt. Das Update beinhaltet Qualitätsverbesserungen aber keine neuen Betriebssystemfunktionen. Hier die Liste der Verbesserungen, von Microsoft als Highlights bezeichnet:
- Updates for verifying usernames and passwords.
- Updates to improve security when Windows performs basic operations.
Hinzukommen folgende Fixes und Verbesserungen an der Windows 10 Version 1909:
- Adds Advanced Encryption Standard (AES) encryption protections for CVE-2021-33757. For more information, see KB5004605.
- Security updates to Windows Apps, Windows Management, Windows Fundamentals, Windows Authentication, Windows User Account Control (UAC), Operating System Security, Windows Virtualization, Windows Linux, the Windows Kernel, the Microsoft Scripting Engine, the Windows HTML Platforms, the Windows MSHTML Platform, and Windows Graphics.
Dieses Update wird automatisch von Windows Update heruntergeladen und installiert. Dieses Update ist auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Microsoft empfiehlt dringend, dass Sie das neueste Service Stack Update (SSU) für Ihr Betriebssystem installieren, bevor Sie das neueste kumulative Update (LCU) installieren. Für das Update gibt Microsoft diverse Probleme an, die im Supportbeitrag dokumentiert sind.
Zudem hat Microsoft ein Update direkt für den Windows Update Client veröffentlicht, um dessen Zuverlässigkeit zu verbessern. Das wird außerhalb von Windows Update ausgerollt, wenn die Maschine kompatibel und keine LTSC-Variante ist und Updates nicht per GPO blockiert wurden.
Updates für Windows 10 Version 1809
Windows 10 Oktober 2018 Update (Version 1809) ist zwar aus dem Support gefallen, für Windows 10 Enterprise 2019 LTSC und Windows Server 2019 steht aber folgendes Updates zur Verfügung.
Update KB5004244 für Windows 10 Version 1809
Das kumulative Update KB5004244 hebt die OS-Build (laut MS) auf 17763.2061 und beinhaltet Qualitätsverbesserungen aber keine neuen Betriebssystemfunktionen. Auch für diese Windows 10-Version, die nur noch Updates für Enterprise, Education, IoT Enterprise LTSC erhält (die restlichen Varianten sind am 11. Mai 2021 aus der Versorgung mit Sicherheitsupdates herausgefallen) wurden von Microsoft folgende Verbesserungen, als Highlights bezeichnet bereitgestellt:
- Updates to improve security when Windows performs basic operations.
- Updates for verifying usernames and passwords.
Hinzukommen folgende Fixes und Verbesserungen an der Windows-Version:
- Removes support for the PerformTicketSignature setting and permanently enables Enforcement mode for CVE-2020-17049. For more information and steps to enable full protection on domain controller servers, see Managing deployment of Kerberos S4U changes for CVE-2020-17049.
- Adds Advanced Encryption Standard (AES) encryption protections for CVE-2021-33757. For more information, see KB5004605.
- Addresses a vulnerability in which Primary Refresh Tokens are not strongly encrypted. This issue might allow the tokens to be reused until the token expires or is renewed. For more information about this issue, see CVE-2021-33779.
- Security updates to Windows Apps, Windows Management, Windows Fundamentals, Windows Authentication, Windows User Account Control (UAC), Operating System Security, Windows Fundamentals, Windows Virtualization, Windows Linux, the Windows Kernel, the Microsoft Scripting Engine, the Windows HTML Platforms, the Windows MSHTML Platform, and Windows Graphics.
Beachtet die Hinweise zu Kerberos S4U bei Domain Controllern. Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog, per WSUS und WUfB erhältlich. Microsoft empfiehlt dringend, dass Sie das neueste Service Stack Update (SSU) für Ihr Betriebssystem installieren, bevor Sie das neueste kumulative Update (LCU) installieren. Microsoft führt das bekannte Problem auf, die das Update verursacht. Bei der Update-Installation kann der Fehler 0x800f0982 – PSFX_E_MATCHING_COMPONENT_NOT_FOUND auftreten. Details finden sich im KB-Artikel.
Zudem hat Microsoft ein Update direkt für den Windows Update Client veröffentlicht, um dessen Zuverlässigkeit zu verbessern. Das wird außerhalb von Windows Update ausgerollt, wenn die Maschine kompatibel und keine LTSC-Variante ist und Updates nicht per GPO blockiert wurden.
Updates für Windows 10 Version 1507 bis 1607
Für Windows 10 RTM bis Version 1607 stehen Updates für die Enterprise LTSC-Versionen zur Verfügung. Diese Updates werden automatisch von Windows Update heruntergeladen und installiert, stehen aber im Microsoft Update Catalog als Download zur Verfügung (nach der KB-Nummer suchen lassen). Vor der manuellen Installation muss das aktuellste Servicing Stack Update (SSU) installiert werden. Details sind im jeweiligen KB-Artikel zu finden.
- Windows 10 Version 1607: Update KB5004238 steht nur noch für Enterprise LTSC bereit. Das Update hebt die OS-Build auf 14393.4530.
- Windows 10 Version 1507: Update KB5004249 steht für die RTM-Version (LTSC) bereit. Das Update hebt die OS-Build auf 10240.19003.
Für die restlichen Windows 10 Versionen gab es kein Update, da diese Versionen aus dem Support gefallen ist. Details zu obigen Updates sind im Zweifelsfall den jeweiligen Microsoft KB-Artikeln zu entnehmen.
Ähnliche Artikel:
Microsoft Office Patchday (6. Juli 2021), Fix für Outlook-Abstürze
Notfall-Update schließt PrintNightmare-Schwachstelle in Windows (6. Juli 2021)
PrintNightmare-Notfall-Update auch für Windows Server 2012 und 2016 (7. Juli 2021)
Microsoft Security Update Summary (13. Juli 2021)
Patchday: Windows 10-Updates (13. Juli 2021)
Patchday: Windows 8.1/Server 2012-Updates (13. Juli 2021)
Patchday: Updates für Windows 7/Server 2008 R2 (13. Juli 2021)
Patchday Microsoft Office Updates (13. Juli 2021)
Anzeige
Am WSUS sollte man wirklich höllisch aufpassen, dass man KB5003173 beim "Aufräumen" nicht declined. Führt nämlich zum Ergebnis völlig ungepatchter clients welche ein schönes Einfallsszenario bieten.
Ich hoffe doch, dass Microsoft dieses Problem Zeitnah behebt!
Danke – hab grad geschaut und das Update KB5003173 war schon abgelehnt.
Hab es wieder genehmigt … sollte nun passen.
Echt ein Käse …
Schöne Grüße
Sebastian
Und auch sonst spinnt die detection bei 20H2 immer noch
clients auf Stand .1052 oder .108x melden dem WSUS das .1110 schon installiert wäre
Nach dem Update ist plötzlich wieder der Schnellzugriff aktiviert.
Echt nervig den wieder zu deaktivieren. Macht man ja nicht jeden Tag und muss er5st mal wieder nachlesen wie das ging.
Hallo zusammen,
haben eben das Update mit einem Client mit Kartendrucker (Intermec EasyCoder F4) probiert.
Klappt wieder.
Puh – wir sind erleichtert.
Schönen Mittwoch
Sebastian
Danke für die Rückmeldung
Windows 10 Pro 20H2.
War diesmal ein echt zähes Update.
Man muß diesmal etwas mehr Geduld haben.
Dachte zwischendurch der Rechner ist hängengeblieben und wollte schon einen Zwangsneustart machen.( habe ich dann aber doch nicht)
Lief dann aber doch weiter, und wurde fehlerfrei abgeschlossen.
Und noch eine Frage:
Ist bei euch auch die Kontakte App nur noch auf englisch seit der letzten Aktualisierung ?
Ps.: trotzdem sind die ewigen Updates zum kotzen.
KB5003173 als Voraussetzung?? Da die neuen Updates kumulativ sind ignorieren die neu installierten Clients nun am WSUS KB5003173 und wollen die frischen updates installieren. Klappt natürlich nicht da KB5003173 nicht installiert ist. Macht nicht wirklich Sinn. Nun müssen wir bei jedem neuen Client KB5003173 von Hand installieren. Sehr seltsam
Nicht sehr seltsam – lies meinen Blog-Beitrag Windows 10, der WSUS und das SSU+LCU-Erkennungs-Chaos – und den Beitrag Windows 10 SSU: Klippen, Bugs und neue Version KB5003974 (15.6.2021) – erklärt vermutlich einiges.
Falls da ein CBS_E_NEW_SERVICING_STACK_REQUIRED-Fehler geworfen werden sollte – schau dir die Ausführungen in diesem Kommentar an.
Das neue CU 2021-07 (KB5004237) verhält sich nun wieder so wie das CU 2021-06. Mit anderen Worten wird der Rechner wieder als aktuell eingestuft und es werden keine Updates gefunden, sollte CU 2021-05 fehlen und am WSUS abgelehnt sein. Ist es nicht abgelehnt, wird erstmal nur das Ding vom Mai am WSUS angefordert und erst danach das vom Juli.
Beim ersten CU 2021-07 (KB5004945) war es noch so, dass nur dieses angefordert wurde, auch wenn das CU 2021-05 noch gefehlt hat. Dann wurde CBS_E_NEW_SERVICING_STACK_REQUIRED ausgeworfen, was nun wieder hinfällig ist.
Hallo Zusammen!
Wir stehen aktuell vor folgendem Problem:
Wir patchen unsere Clients Windows 10 20H2 über einen WSUS Server 2012R2.
Durch den Notfallpatch von letzter Woche haben die Clients den Build 10.0.19042.1083.
Nachdem ich die neuen Updates von Heute Nacht nun freigegeben habe, passiert nun folgendes:
– Am WSUS wird angezeigt, dass für den Client das Update KB5004237 erforderlich ist
– KB5004237 wird am Cient auch gefunden und installiert ABER es wird für dieses Update kein Neustart verlangt
– Unter Updateverlauf wird das KB5004237 als erfolgreich installiert angezeigt
– WSUS meldet anschließend dass für den Client der KB5004237 nicht mehr erforderlich ist
ABER!
– Die Buildnumber am Client bleibt auf 10.0.19042.1083 und ERHÖHT SICH NICHT auf die Buildnumber 10.0.19042.1110
Was ist nun hier kaputt? Updatet sich der Client nun nicht obwohl im Verlauf steht installiert?
Anmerkung:
Suche ich Online nach Updates, wird der KB KB5004237 (Juli) erneut gefunden und nochmal installiert. Zusätzlich wird das KB4023057 (Mai) heruntergeladen und installiert.
Danach passt auch die Buildnumber.
Aber ich kann doch nicht an allen Clients nochmal Online suchen…
KB4023057 hatte ich bisher noch nicht auf dem Schirm…
Hat jemand von euch auch das Problem? I
Vielen Dank schon mal im Voraus
Stefan A.
Die Build am WSUS ist zu vergessen! das klappt nicht!
Was zeigt "winver.exe" am client an?
Die Clients zeigen noch immer 10.0.19042.1083 an, obwohl am Client KB5004237 erfolgreich installiert angezeigt wird.
Was mir eben auffällt ist, dass der Client danach keinen Neustart wollte…
Bisher noch nicht. Ich habe aber bei manchen Clients das Phänomen (schon vor diesem Update), dass sie bei Winver einen alten Stand anzeigen, auch wenn alle Updates installiert sind (und sich auch nicht noch mal manuell installieren lassen ->Ist bereits installiert). Hat das schon mal jemand gehabt?
Ich habe auch dieses Problem (und meine nicht die im WSUS angezeigte version)
Lies mal meine Mail an Herrn Born aus dem Artikel https://www.borncity.com/blog/2021/07/04/windows-10-der-wsus-und-das-ssulcu-erkennungs-chaos/ .
Das Verhalten besteht in der Form schon seit Monaten und hat damit zu tun, dass die kumulativen Updates aus dem WSUS große Probleme machen, wenn ihr Servicing Stack (der bei KB5004945 und KB5004237 derselbe ist) bereits vorher installiert war.
Ich hatte heute einen Client, auf dem wohl die LCU-Installation vom Enduser abgebrochen wurde. Das SSU hat es aber bereits installiert geschafft. Nun ist der Rechner nicht mehr patchbar, bis das August-LCU released und freigegeben wird. Herrlich.
Hab mir gerade den Artikel durchgelesen.
Auch wir setzen WSUS 2012R2 ein und die Clients sind 20H2.
Genau das von dir folgend beschriebene Verhalten tritt bei der Installation (über WSUS) von KB5004237 auf, wenn bereits das KB5004945 von letzter Woche installiert ist:
„Ab dem kumulativen Update vom Mai wurde dies sogar noch undurchsichtiger: Das Update wird durchaus von den Clients als benötigt erkannt, „installiert" sich dann allerdings innerhalb von wenigen Sekunden und verlangt keinen Neustart. Führt man diesen durch, erkennt man in den Windows Einstellungen, dass sich die Build-Nummer nicht erhöht hat."
Bei einer online Suche direkt am Client wird das Update KB5004237 nochmals gefunden und richtig installiert.
Ich hatte das Problem letztes Monat schon mal an 2 Test Clients, als ich da das Preview Update Juni installiert hatte. Auch diese beiden Clients hatten dann das Verhalten mit den „normalen" Juni Updates.
Da es nur zwei PCs waren hatte ich dann einfach online gesucht und damit war es für mich erledigt. Da es aber nun fast alle Clients betrifft, stehen wir echt vor einem Problem.
Konntest du das Problem inzwischen lösen?
Viele Grüße
Stefan A.
Leider nein. So lange Microsoft weiter fehlerhafte LCUs im WSUS rausbringt, wird das Problem quasi monatlich reinkarniert.
Aber vielleicht wird Microsoft ja nun, da eine breite Masse das Out-of-Band Update von vor einer Woche ausgerollt hat und nun merkt, dass sich das "reguläre" 2021-07er wegen der identischen SSU-Version nicht installieren lässt, endlich mal auf das Problem aufmerksam.
Denkst Du wirklich – in der Ferienzeit?
Da wertet doch nur eine KI die Telemetriedaten aus. Wenn die sagt "alles schick" dann schaut sich das auch kein Programmierer an.
Betrifft das dann nur Clients, die z.B. von 1909 auf 20H2 aktualisiert wurden und nicht frisch installiert wurden?
Wenn ich dich richtig verstehe, ist das Problem, dass das „PrintNightmare-Juli-Update" und das „reguläre Juli Update" das selbe SSU beinhaltet?
Und deswegen „installieren" die Clients das „reguläre Update" innerhalb von Sekunden ohne Neustart und WSUS denkt dann: „Nicht mehr erforderlich", obwohl die Build am Client noch die alte ist.
Ich sehe nur gerade keine so richtige Lösung :(
An allen Clients direkt online suchen wäre ein riesiger Aufwand. Und bis zum August Patchday warten nicht akzeptabel.
Nur irgendwie habe ich das Gefühl, bei uns ist was falsch konfiguriert oder wir haben wo was falsch gemacht, denn man findet sonst nichts weiter über das Thema.
Das Problem müsste doch noch viele Admins mehr betreffen?!
Das Kernproblem ist: Die kumulativen Updates vom WSUS werden nicht als benötigt erkannt, oder installieren sich nicht richtig, wenn ihr zugehöriges SSU-Paket bereits installiert ist. Dies kann auf unterschiedlichen Wegen passiert sein:
– Es wurde ein Feature Upgrade auf 20H2 mit "/DynamicUpdate NoLCU" durchgeführt. Dann hat der Client am Ende das aktuelle SSU (per DU), aber den LCU-Stand vom Upgrade-Medium (beim WSUS-Paket z.B. 2020-11).
– Das aktuelle kumulative Update enthält dieselbe SSU-Version wie das vorige. Das ist momentan der Fall.
– Die Installation des aktuellen LCU schlug fehl, oder wurde abgebrochen, wobei das SSU bereits installiert wurde.
– Das aktuelle SSU wurde vom experimentierfreudigen Admin manuell installiert
Die Verwirrung um das 2021-05er Update als Voraussetzung für neuere Updates hat die ganze Situation natürlich nicht einfacher zu debuggen gemacht.
Eine lokale Fehlkonfiguration kann ich mir eigentlich nicht vorstellen. Mein Kollege, der eine komplett unabhängige Infrastruktur administriert, kann das Verhalten mit WSUS auf Server 2016 bestätigen.
Zur Frage, warum das Problem nicht viel mehr Leuten auffällt:
– Feature Upgrades mit "/DynamicUpdate (NoLCU|NoDriversNoLCU)" sind vermutlich eine administrative Seltenheit. Die beiden Parameter wurden erst mit 2004 eingeführt.
– Es ist in WSUS nicht zu erkennen. Man muss auf den Clients schauen, welche Build läuft. Die Update-History schwindelt einem ja auch vor, dass das neueste Update erfolgreich installiert wurde.
– In der Regel "verschwindet" das Problem auf bereits betroffenen Rechnern mit dem nächsten veröffentlichten LCU
– Bis jetzt trat das Problem einfach viel zu selten auf, die "regulären" monatlichen LCUs hatten immer ein neues SSU im Gepäck und die Preview Updates werden in der Regel nicht produktiv installiert. Hoffentlich ändert sich das nun, da 2 "kritische" Updates mit demselben SSU innerhalb einer Woche released wurde.
Also in unserer Umgebung scheint erstmal alles so zu funktionieren, wie es soll. Das Update wird am WSUS angefordert, egal ob das Update von letzter Woche schon drauf ist, oder nicht. Die Installation dauert dann mehrere Minuten, so wie es zu erwarten wäre.
Erzähl mal bitte etwas mehr über "/DynamicUpdate NoLCU". Was hat das für einen Hintergrund? Habt ihr das explizit so installiert, oder passiert das bei einer normalen Installation über den WSUS? Wie unterscheiden sich die Clients danach von den anderen?
Früher gab es bei Dynamic Update nur "enable" oder "disable", entweder bekam man das volle DU-Paket mit Setup Updates, SafeOS Updates, Treiber, Servicing Stack und dem aktuellen LCU, oder gar nichts.
Gerade in einer verwalteten Umgebung mit WSUS möchte ich allerdings nicht, dass Clients z.B. das allerneueste LCU beim Feature Upgrade bekommen, während vielleicht im WSUS nur das vom Vormonat freigegeben ist. Seit Version 1809 werden Dynamic Updates nämlich ausschließlich nur noch von MS direkt, am WSUS vorbei geladen.
Daher steuere ich Dynamic Update durch die neuen Optionen granular: Setup- und SafeOS Updates sind durchaus sinnvoll, und auch nur für den Upgrade-Prozess relevant. Auch "Optionale Komponenten" oder Language Packs, die zuvor installiert waren, können bei einem Feature Upgrade nur über DU bezogen werden und wären andernfalls nach dem Upgrade nicht mehr verfügbar (sofern man kein custom Upgrade Media verwendet, in das die Komponenten vorher manuell integriert wurden).
Durch "NoLCU" verhindere ich also lediglich, dass die Clients in einem neueren LCU-Stand landen als sie sollen – nach dem Feature Upgrade forciere ich dann sofort einen Scan gegen WSUS, um das neueste von mir freigegebene LCU zu erhalten.
Ok, danke. Wir verzichten hier komplett auf dynamische Updates.
Gestern habe ich Visual Studio 2019 auf 16.10.3 upgedatet.
Heute im WSUS für mich alle Patches freigegeben. Es wurde "2021-07 .NET 5.0.8 Update for x64 Client (KB5004698)" installiert.
Nun versucht Windows Update "2021-06 .NET 5.0.7 Security Update for x64 Client" einzuspielen und scheitert mit Fehler 0x80070643. Deaktiviere ich das im WSUS verucht er es mit 2021-05…
Über "Online nach Updates von Microsoft Update suchen" werden keine fehlenden Updates angezeigt und es wird auch nichts installiert. Dann wird unter Qualitätsupdates auch die Fehler nicht mehr angezeigt.
Die kommen dort wieder wenn ich die Suche über den internen WSUS laufen lasse.
Unter Systemsteuerung finde ich mehrere Versionen des SDK:
Microsoft .NET SDK 5.0.104
Microsoft .NET SDK 5.0.205
Microsoft .NET SDK 5.0.301 from Visual Studio
Microsoft .NET SDK 5.0.302
Erstmal ratlos.
Wenn ich nachgucke:
2021-05 .NET 5.0.6 Security Update for x64 Client
Erfolgreich installiert am 12.05.2021
2021-06 .NET 5.0.7 Security Update for x64 Client
Erfolgreich installiert am 09.06.2021
2021-07 .NET 5.0.8 Update for x64 Client (KB5004698)
Erfolgreich installiert am 14.07.2021
Und nun wird versucht "2021-06 .NET 5.0.7 Security Update for x64 Client" zu installieren und das scheitert. Ist ja auch ein .NET 5.0.8 Update installiert worden. Woher übrhaupt .NET 5.0.8 stammt keine Ahnung? Gestern durch Visual Studio Installer und das Update von 16.10.2 auf 16.10.3?
ja, kann ich bestätigen und das Problem bzw. der Fehler 0x80070643 beim .NET 5.0.7 Security Update tritt bei uns auch auf.
Nach meinem Verständnis müsste das 2021-07 .NET 5.0.8 Update (KB5004698) das .NET 5.0.7 Security Update ersetzen, da mit den aktuellen .NET 5 Updates immer alle vorherigen Versionen automatisch deinstalliert werden.
So liegt nach dem .NET 5.0.8 Update unter:
C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App
nur noch der Ordner 5.0.8.
Kein Wunder also, dass das .NET 5.0.7 Security Update in einen Fehler läuft, da die Version 5.0.7 ja nicht mehr installiert ist.
Ich habe dieses Update daher heute abgelehnt.
Ansonsten:
Wieder mal ein belegbarer Beweis dafür dass MS die Sache mit den Updates über WSUS definitiv nicht im Griff hat.
Was hast du aus der Verteilung rausgenommen?
Das hier?
2021-07 .NET 5.0.8 Update for x64 Client (KB5004698)
Wobei ich in "C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App" 5.0.1, 5.0.4, 5.0.7 und 5.0.8 finde.
Vielleicht weil ich imit Visual Studio entwickle und man da die Möglichkeit hat Zielframework und Version auszuwählen?
Laut WSUS ist Update 5.0.8 auf zwei meiner Rechner installiert worden. Dort wo ich gestern VS über dessen Installer upgedatet habe will der Rechne "2021-06 .NET 5.0.7 Security Update for x64 Client" installieren.
Auf dem anderen Rechner ist noch VS 16.10.2 installiert, da passiert das nicht.
Mache ich jetzt mal. Eben dort auch auf 16.10.3 upgedatet. Dann Windows Update gestartet. Keine weitere Updates gefunden. Also da kein Problem. Dort habe ich aber heute auch zuerst die Updates per WSUS installieren lassen und dann erst Visual Studio Installer aufgerufen. Visual Studio Installer Version: 2.11.13.53049. Ist auf beiden PCs identisch.
Herausgenommen bzw. im WSUS abgelehnt habe ich das NET 5.0.7 Security Update (nach Genehmigung des .NET 5.0.8 Update).
Wobei ich in Deinem Fall dann davon abraten würde, wenn die Version 5.0.7 parallel installiert ist.
Die Installation von Visual Studio macht die Sache natürlich komplexer (vielleicht installiert auch das Update bzw. der Installer von Visual Studio die einzelnen .NET Versionen).
In unserer Umgebung (Windows 1909 Enterprise) war es aber bisher immer so, das mit den über den WSUS verteilten .NET 5 Updates die Vorgängerversionen immer deinstalliert wurden.
Heute Nacht kam 2021-07 .NET 5.0.8 Update an. Die Installation von 5.0.7 endete hier, sehe im Updateverlauf nicht mehr das diese immer wieder fehlschlägt. Davon kam aber kein neues Release hier an?
Am WSUS habe ich "2021-07 .NET 5.0.8 Update for x64 Client (KB5004698)" auf "Nicht genehmigt".
Warum auch immer, es funktioniert jetzt auf meinem Rechner und dieses Update werde ich vorerst mal nicht für alle freigeben.
Merkwürdig. Ich habe hier mehrere 21H1 Kisten, die KB5004237 nicht aus dem WSUS ziehen wollten, sondern nur aktuelles ,NET, bösartige Software und solche Nebensächlichkeiten. Erst nachdem ich im Updatedialog online bei Microsoft gesucht habe, wurde erst KB4023057 gefunden, was ja ausdrücklich nicht für WSUS-verwaltete Büchsen gedacht ist, und dann teils zusammen oder erst nach Installation von KB4023057 wurde erst/auch KB5004237 gefunden. Einen Reim daraus kann ich mir nicht machen. zuvor wurde auf den Kisten KB5004760 für PrintNightmare Beseitigung installiert, das heißt die Kisten waren bis gestern aktuell. Jetzt würde ich ja gerne die aktuelle KB4023057 für 21h1 aus dem Updatekatalog ziehen und im WSUS importieren, aber das gibts im Update-Catalog nicht (sondern nur für 1507-1803). Hat da jemand eine Erklärung? Morgen werde ich dann im WSUS-Report sehen, ob es noch mehr außer die stichprobenmäßig manuell aktualisierten Büchsen gibt.
Anmerkung: KB5004237 wird vom WSUS bisher auf 0 Computern mit 21h1 als erforderlich angezeigt… Wir haben auch noch ein paar 20h2 und 20h1 auf denen es als erforderlich angezeigt bzw. auch schon als installiert angezeigt wird.
Wenn bei euch im WSUS der KB5004237 für den Client schon als installiert angezeigt wird, was wird bei euch dann unter winver am Client direkt angezeigt?
Wir haben wie oben beschrieben das Problem, dass
-> WSUS das Update anbietet
-> Der Client es findet und der Client es innerhalb einer Minute ohne Neustart "installiert"
-> Der WSUS dann auch meldet, es ist nicht mehr notwendig für den Client
ABER der Build direkt am Client noch der alte ist von letzter Woche
Bei den untersuchten Clients war es so, dass die das Update garnicht finden. Und im WSUS wird es als nicht benötigt angezeigt.
KB5004237 wird dann nach KB4023057 ohne Reboot installiert, es dauert auch so rund 5-10 Minuten.
Ich werde gleich mal den Insider-Feedback-Hub damit füttern.
Diverse Kommentare von Otto und 1ST1 gelöscht, da sie mit dem Thema um dass es im Thread geht, nichts zu tun hatten.
Nach der kompletten Installationsorgie hab ich jetzt Build 19043.1110.
Hallo 1ST1!
Was verstehst du unter kompletter Installationsorgie?
Hab mir jetzt nochmal den WSUS vorgeknöpft, kann mir da nachwievor keinen Reim draus machen:
2021-07 Cumulative Update for Windows 10 Version 21H1 for x64-based Systems (KB5004237) Security Updates Install No Status
Möglicherweise hängt es aber damit zusammen?
Feature Update to Windows 10 Version 21H1 x64-based systems 2021-05 via Enablement Package Upgrades Not approved Not Installed
Feature-Updates wie 21H1 wollen wir nicht per WSUS aus, sondern per unserem Deployment-System, weil wir da den Zeitpunkt genauer bestimmen können und der User das nicht verzögern kann.
Hab mir noch ein paar andere 21h1 Clients im WSUS Status angesehen, die auch schon auf .1110 sind, einige weitere davon verhalten sich auch derartig seltsam, das heißt wsus sieht nicht dass die auf 21h1 sind (Feature Update not installed) und KB5004237 not applicable, und bei anderen ist zwar Feature Update wie gewollt auf not approved, aber (wie gewollt per Deployment) installiert und KB5004237 wurde installiert. Sehr diffus…
Zur Info Update KB5004244 für Windows 10 Version 1809
Das kumulative Update KB5004244 hebt die OS-Build (laut MS) auf 17763.2061 nicht auf 17763.2069.
Das kann ich bei mir aus der Praxis bestätigen!
Also, es wäre verfrüht zu sagen: "Alles schick", dazu ist es zu früh aber die Maschinen, die ihre Updates vom WSUS gezogen haben, haben nach der Installation auch die richtige Nummer (1110). Soweit ich das sehe wird das Update auch von allen Maschinen erkannt. Alle hatten vorher das OOB bekommen. Alle wurden ursprünglich mit 1909 Image versehen und nach 21H1 upgedated. Wenn, dann werden vielleicht einzelne Probleme machen. Das ist aber normales Geschäft, kommt immer mal vor.
Diese Beobachtung habe ich auf mehreren WSUS Servern unter Server 2019 gemacht.
Hallo Thomas,
hast du zufällig auch noch 20H2 Clients?
Die WSUS Server sind alle auf 2019?
Gruß
Stefan A.
20H2 habe ich keine mehr. Da hatten wir aber auch nur vereinzelte Testrechner.
Die WSUS Server sind alle 2019. Per Inplace Upgrade von 2016.
Bei einem WSUS-Server zeigte sich auch bei mir das Problem das KB5004237 auf 20H2 und 21H1 Clients gefunden und dann ohne Neustart installiert wurde. Die Build-Nummer war nach dem Update immernoch xxx.1083.
Bei anderen Clients die über andere WSUS-Server versorgt werden zeigte sich das Problem nicht und es wurde KB5004237 inkl. Neustart installiert. Winver zeigte anschließend auch den korrekten xxx.1110-Build.
Bei dem WSUS-Server wo die Updates nicht richtig funktionieren ist unter der Option "Updatedateien auf diesem Server lokal speichern" das Häckchen für "Schnellinstallationsdateien herunterladen" gesetzt. Bei den denen wo es funktioniert aber nicht! Denke mal das hier die Ursache liegt.
Hallo Udo,
ich habe ja bereits fleißig hier kommentiert.
Bisher haben wir einen WSUS Server 2012R2 der unsere Clients versorgt.
In den letzten Stunden habe ich zum Testen einen neuen WSUS Server auf 2016 aufgesetzt.
Meine ersten drei Test Computer haben vom neuen WSUS nun das Update KB5004237 korrekt erkannt und installiert (reboot war danach auch erforderlich).
Laut winver am Client wird dann auch die .1110 korrekt angezeigt.
Was ich nun noch testen muss ist, wie sich die Handvoll an Computer verhalten, die sich ja das KB5004237 bereits "installiert" haben und "denken" sind Up-To-Date.
Ich hatte nämlich am Mittwoch die Freigabe von dem Update wieder weggenommen, als ich das Problem festgestellt hatte.
Damit ist bei so gut wie allen Clients das KB5004237 noch ausstehend.
Ich dachte bisher, weil es nun funktioniert, dass dies entweder am WSUS 2016 Server liegt oder weil ich generell einen neuen Server aufgesetzt habe.
Aufgrund deines Kommentars habe ich den Punkt mit den "Schnellinstallationsdateien" soeben geprüft. Ich wusste, dass wir an unserem bisherigen 2012R2 WSUS dies aktiviert haben.
Auf dem soeben neu installierten Server 2016 ist dieser Haken aber nicht gesetzt (ist der Default Wert).
Ich werde an dieser Stelle nun weiter testen und mich hier nochmal melden.
@Markus D.
Ist bei dir vielleicht auch "Schnellinstallationsdateien herunterladen" aktiviert?
Gruß
Stefan A.
Bei mir tritt das Problem (Patch wird nicht wirklich installiert etc) aber auch mit einem WSUS (Server 2016) auf, der so eingestellt ist, dass die Clients die Updates direkt von MS laden. Und dadurch ist die Option "Schnellupdates" ausgegraut.
Hier noch eine Ergänzung:
Ich habe zum Testen auf dem neuen 2016er WSUS das KB5004237 einmal abgelehnt und anschließend mit dem Assistenten den WSUS aufgeräumt. Man sieht auch wie die Dateien aus dem WSUS Ordner auf der Festplatte gelöscht wurden.
Anschließend den Haken bei „Schnellinstallationsdateien herunterladen" gesetzt und das Update erneut genehmigt.
Man sieht auch im WSUS während er das Update herunterlädt, dass die Größe mehr als doppelt so viel ist dadurch.
Anschließend von einem Client wieder vom WSUS das KB 5004237 gezogen, welches wiederum erfolgreich installiert wurde und am Client ein Neustart erforderte. Build war danach auch korrekt die .1110
Ich kann noch nicht abschließend sagen ob der 2016er Server nun meine Lösung ist oder das abhaken der „Schnellinstallationsdateien".
@Udo
Welche WSUS Versionen habt ihr im Einsatz?
Hallo Stefan A.,
ich setze hier Server 2019 für den WSUS ein.
Ich habe mir mal genauer angeschaut welche Updates der Client herunterlädt. Sobald die Express-Variante von KB5004237 heruntergeladen wird, tritt das Problem bei mir auf.
Bei zwei verschiedenen WSUS-Konfigurationen ist das der Fall:
a) "Schnellinstallationsdateien herunterladen" im WSUS angehakt
oder b) wie bei @Anonymous, der WSUS ist so konfiguriert das die Clients die Updates direkt von MS laden.
In der Default-Konfiguration des WSUS, also weder a) noch b), wird immer die non-Express-Variante heruntergeladen und die installiert sich ohne Problem.
Das kann ich nicht bestätigen, bei uns ist das Häkchen „Schnellinstallationsdateien herunterladen" nicht gesetzt und die Build-Version im WSUS ist trotzdem falsch. Alle anderen Programme zeigen die Versionsnummer richtig an.
Hallo Andreas,
die Build Version im WSUS direkt wird bei uns schon immer irgendwie falsch angezeigt. Was ich meine ist, dass auch die Build Version am Client direkt mit vinver noch die alte ist…
Hallo Zusammen,
nach langer Suche und Aufgrund eines Kommentars von Udo, konnte ich eine Lösung zu unserem Problem finden.
Nach abschalten des Punktes „Schnellinstallationsdateien herunterladen" haben nun die ersten Clients erfolgreich das aktuelle Juli Sicherheitsupdate installiert.
Dieser Punkt ist im Default nicht gesetzt, was auch die Testweise Installation eines neuen WSUS auf Server 2016 bestätigte.
Aber Achtung!
Nach abhaken des Punktes hat der WSUS Server erst einmal einige Stunden die CPU voll ausgelastet (sqlservr.exe und WsusService.exe) und der Clientwebdienst meldete Fehler 12022, was sich auf den IIS zurückführen lies.
Die nächsten Tage werden zeigen, ob durch das abhaken des Punktes nicht noch irgendwelche unerwarteten Phänomene auftauchen, aber bisher sieht alles gut aus.
Danke @Udo
Danke für die interessante Info! Auch bei mir sind die Schnellinstallationsdaten bewusst aktiviert. Meines Wissens nach ermöglicht diese Funktion, dass die Clients deutlich weniger Daten vom WSUS laden, indem sie nur differenziell die wirklich geänderten Daten anfordern können.
Da ich aber ein bisschen Angst davor habe, unser eh schon volles 150-Standorte-Intranet lahmzulegen, werde ich lieber noch ein bisschen warten, ob MS das in den nächsten Tagen nicht doch noch gefixt bekommt. Andernfalls muss ich hoffen, dass BranchCache und Delivery Optimization die gestiegenen Datenmengen abfedern können.