[English]Am 9. Januar 2024 (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) sowie für die Windows Server-Pendants freigegeben. Hier einige Details zu den jeweiligen Sicherheitsupdates für Windows 10.
Anzeige
Eine Liste der Updates lässt sich auf dieser Microsoft-Webseite abrufen. Ich habe nachfolgend die Details herausgezogen. Seit März 2021 integriert Microsoft die Servicing Stack Updates (SSUs) für neuere Windows 10 Builds in das kumulative Update. Im März 2023 gibt es für ältere Windows 10 Builds letztmalig Preview Updates.
Updates für Windows 10 Version 21H1-22H2
Für die oben erwähnten Windows 10 Versionen stellt Microsoft nur ein Update-Paket, welches nachfolgend genannt wird, bereit.
Update KB5034122 für Windows 10 Version 21H1 – 22H2
Das kumulative Update KB5034122 hebt die OS-Build bei allen Windows 10-Varianten auf 1904x.3930 – bei 21H2 bekommt nur noch die Enterprise-Variante das Update. Das Update enthält nur Sicherheitsfixes, aber keine neuen Betriebssystemfunktionen. Für das kumulative Update heißt es lediglich:
This update addresses security issues for your Windows operating system.
Im Supportbeitrag werden zudem folgende Fixes aufgeführt.
- This update addresses an issue that affects the ActiveX scroll bar. It does not work in IE mode.
- This update addresses an issue that causes your device to shut down after 60 seconds. This occurs when you use a smart card to authenticate on a remote system.
- This update addresses an issue that affects the display of a smart card icon. The icon does not appear when you sign in. This occurs when there are multiple certificates on the smart card.
Microsoft weist auch darauf hin, dass dieses Update Qualitätsverbesserungen am Servicing Stack (ist für Microsoft Updates verantwortlich) durchführt. Dieses Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Beachtet die im Support-Beitrag beschriebene Hinweise zur Installation und zu bekannten Problemen.
Anzeige
Updates für Windows 10/Server 2019
Für Windows 10 Enterprise 2019 LTSC und Windows Server 2019 stehen folgendes Updates zur Verfügung.
Update KB5034127 für Windows 10 Enterprise 2019 LTSC /Windows Server 2019
Das kumulative Update KB5034127 (wird unter Windows 10 v1809 einsortiert, bezieht sich aber auf die 2019er-Versionen und) und beinhaltet Qualitätsverbesserungen aber keine neuen Betriebssystemfunktionen. Dieses Update steht nur für Windows 10 2019 Enterprise LTSC und IoT Enterprise LTSC (die restlichen Varianten sind am 11. Mai 2021 aus der Versorgung mit Sicherheitsupdates herausgefallen) sowie Windows Server 2019 bereit.
Microsoft listet unter KB5034127 eine Reihe an Korrekturen auf. Das Update wird automatisch von Windows Update heruntergeladen und installiert, ist aber auch im Microsoft Update Catalog, per WSUS und WUfB erhältlich. Microsoft hat zudem das Service Stack Update (SSU) aktualisiert. Beachtet die im Support-Beitrag beschriebene Installationsreihenfolge und auch die Hinweise zu weiteren Anforderungen. Für das Update gibt Microsoft bekannte Probleme im Supportbeitrag an.
Ergänzung: Beachtet den Kommentar von ZEN-Master, der auf Probleme mit den GFI MailEssentials durch das Update hinweist.
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 KB5034119 steht nur noch für Enterprise LTSC sowie Windows Server 2016 bereit. Das Update adressiert Sicherheitsprobleme sowie andere Probleme.
- Windows 10 Version 1507: Update KB5034134 steht für die RTM-Version (LTSC) bereit. Das Update fixt Schwachstellen sowie Bugs.
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.
Beachtet die Hinweise aus dem Artikel Windows WinRE-Update gegen CVE-2024-20666 scheitert mit Installationsfehler 0x80070643 (Jan. 2024, KB5034441).
Ergänzung: Nachfolgend finden sich Kommentare mit dem Hinweis, dass Update KB5034129 zu Abstürzen des Edge, Chrome oder anderer Browser führt. Ich habe den Sachverhalt samt Workaround mal separat in einem Beitrag Windows Server 2022: Update KB5034129 killt Browser (Chrome, Edge, Firefox) herausgezogen.
Ähnliche Artikel:
Office Update KB5002500 vom 2. Januar 2023 fixt OneNote 2016 Sync-Problem
Microsoft Security Update Summary (9. Januar 2024)
Patchday: Windows 10-Updates (9. Januar 2024)
Patchday: Windows 11/Server 2022-Updates (9. Januar 2024)
Windows 7/Server 2008 R2; Server 2012 R2: Updates (9. Januar 2024)
Windows WinRE-Update gegen CVE-2024-20666 scheitert mit Installationsfehler 0x80070643 (Jan. 2024, KB5034441)
Windows Server 2022: Update KB5034129 killt Browser (Chrome, Edge, Firefox)
Anzeige
Mit KB5034441 kann es Probleme geben:
https://www.deskmodder.de/blog/2024/01/09/windows-10-kb5034441-winre-update-als-sicherheitsupdate-kann-fehler-0x80070643-ausloesen/
https://www.deskmodder.de/blog/2024/01/09/kb5034122-windows-10-22h2-manueller-download-19045-3930-erster-sicherheitspatch-2024/#comments
Also das ist ja mal wieder ein Patchday vom Feinsten:
Mir wird außerdem noch KB5034441 angeboten, das mit Error-Code 0x80070643 – ERROR_INSTALL_FAILURE (als Text angezeigt wird: „Downloadfehler"!) scheitert, der wiederum laut Known Issue aber in Wirklichkeit „CBS_E_INSUFFICIENT_DISK_SPACE" bedeutet (!), weshalb man sodann laut KB5028997 an der Größe der Systempartition herumfriemeln und etwas abzwacken soll …
Werde ich nicht tun. – Was für ein Unsinn! Ich habe fürs System (C:) eine SSD und außerdem reichlich Platz auf einem HDD (D:). Aber wie man das für dieses ominöse WinRE nutzen kann, darüber steht in der famosen Anleitung nichts. Und die ist zudem unverständliches Kauderwelsch.
WinRE war hier im Blog für Win 11 schon mal Thema, nun geht dies Gewürge bei Win 10 los.
Frage: Kann man KB5034441 einfach ignorieren? Es soll ja angeblich wichtig sein: CVE-2024-20666. Was hat es damit auf sich und wen betrifft das?
KB5034441 wird überall angeboten, bei mir daheim sind 2 von 3 Win 10 PCs betroffen, das heißt, die Installation scheitert mit jener Fehlermeldung! Reboot hilft nicht. Der 3. PC ist gerade aus geschaltet. Auch bei Winfuture.de habe ich gestern Abend schon einen ersten Kommentar zu dem Problem gesehen.
Win 11 Updates gingen problemlos durch.
ab zu BSD oder sowas und du bist frei von der Knechtschaft :-)
Gute Idee, nur, läuft da auch meine wichtige Software drauf? Affinity Photo, DxO Raw-Converter, Calamus, Office 365 usw.?
Wenn nicht, dann nicht!
Office 365 ist wichtige Software? Was kann man damit besser als mit Open Source Office Paketen, also im Privatumfeld?
Das gibt es überall gute Alternativen. Und wer Office 365 privat freiwillig einsetzt, hat eh die Kontrolle über sein Leben verloren…
Krankerweise tritt der gleiche Fehler bei einer frischen Installation mit einem frisch erstelltem Windows 10 Installer Medium (Stand 12/2023) auch auf. Warum zur Hölle erstellt das immer noch zu kleine Partitionen :(
Wenn du so alt bist wie ich solltest du dir das selbst beantworten können:
In Firmen gibt es Abteilungen. In diesen Abteilungen gibt es Menschen die Dienst nach Vorschrift machen. Diese Menschen sagen oft: "Nicht meine Aufgabe." Dann wird Stechuhr gedrückt und nach Hause gegangen.
So ist es fast überall, da es keine echten Konsequenzen für DnV gibt.
Hier bei mir schlägt das Update des Sicherheitsupdate für Windows 10 (KB5034441) fehlt. Laut Internetrecherchen scheint das Problem bei Microsoft zu liegen.
ich habe heute auf zwei Windows 10 Rechner das Januar 2024 Update versucht.
Bei beiden lässt sich ein Update nicht installieren:
2024-01 Sicherheitsupdate für Windows 10 Version 22H2 für x64-basierte Systeme (KB5034441)
Es kommt ein Fehler 0x80070643
Das habe ich dazu gefunden:
https://www.deskmodder.de/blog/2024/01/09/windows-10-kb5034441-winre-update-als-sicherheitsupdate-kann-fehler-0x80070643-ausloesen/
Anscheinend ist die Wiederherstellungspartition zu klein.
Nach dem Vergrößern derselben (siehe "Tutorial" im obigen Link) lief das Update anscheinend durch.
Was für ein Gefrickel.
Habt Ihr ähnliche Probleme mit dem Update?
Eventuell auch eine Lösung wie man das auf allen Rechnern automatisieren kann?
Ich habe noch
2024-01 Sicherheitsupdate für Windows 10 Version 22H2 für x64-basierte Systeme (KB5034441)
Allerdings mit
Downloadfehler – 0x80070643
Habe ich auch. Irgendwie ist das wohl bei fast alle. Wier warten mal ab, was das ist.
Bei Deskmodder steht, dass die Wiederherstellungspartition zu klein sein soll (nach MS). Das kann ja nicht sein.
MS muss auf der Systemfestplatte irgendwas ablegen. Da wird was blockiert. Irgendwie sind bei mir durch die Updates ca. 35 -40 GB verbraucht und nun sind wieder ca. 20 GB freigeworden.
Da haut was nicht hin.
Hier ebenso, KB5034441 lässt sich nicht installieren, mal wieder typischer Microschrott Pfusch, werde das Update einfach ignorieren, kein Bock auf mehreren Computern diese WinRE Partition von Hand zu vergrössern.
Und das soll vorab bei MS keinem aufgefallen sein?
Die Anzahl der Patches bei denen man manuell eingreifen soll nimmt überhand.
Doch, sie wussten es, ist alles dokumentiert:
https://support.microsoft.com/de-de/topic/kb5034441-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8
verweist auf
https://support.microsoft.com/de-de/topic/kb5028997-anweisungen-zum-manuellen-%C3%A4ndern-der-partitionsgr%C3%B6%C3%9Fe-zum-installieren-des-winre-updates-400faa27-9343-461c-ada9-24c8229763bf
Das ist das eigentlich Schlimme daran! Nämlich, dass sie das auch noch ganz offen und frei zugeben, dass sie mal wieder Sch…. gebaut haben. KEIN durchschnittlicher Benutzer wird sich mit dieser "Anleitung" (die eh nur eher versierte Nutzer verstehen) beschäftigen. Die wenigsten werden sie überhaupt erst finden! Und wenn, dann werden 99 % davor sitzen und außer Fragezeichen nichts verstehen … Welcher Endnutzer weiß überhaupt, was die "Eingabeaufforderung" ist und wie man diese dann auch noch korrekt anwendet?! Ist so ähnlich, wie wenn ich mein Auto zur Wartung bringe und dann bei der Abholung aus der Werkstatt auf dem Beifahrersitz ein Zettel liegt mit kryptischen Anweisungen was ich jetzt tun soll, damit mein Auto wieder zuverlässig fährt … Dazu gibt es dann noch ein Satz Spezial-Bordwerkzeug mit dem ich leider nix anfangen kann, da ich es nicht kenne … Wer würde sich dies gefallen lassen? (Ja, wir alle tun dies – LEIDER!)
Eine totale Unverschämtheit und irgendwie auch komplette Bankrotterklärung seitens MS ist das!!
Hallo Leute,
das ist ja mal wieder ein Patchday :-(
Bei mir im WSUS wird der KB 5034441 für Win10 22H2 gar nicht angeboten. Im WSUS gibt es lediglich den KB5034122 für Win1022H2…
An meinen Notwbook will er aber den KB 5034441 installieren das schlägt aber wie bei Euch auch fehl.
Mal abwarten was da wieder versaut wurde.
Gruß Tino
Hallo Timo,
deine Beobachtungen bei KB 5034441 kann ich bestätigen. Auch unser WSUS bietet das Update derzeit nicht an. Bei einem Notebook, welches nicht von unserem WSUS verwaltet wird und die Updates direkt aus dem Internet bezieht, wurde es angeboten.
Ich habe mir das Tutorial von MS durchgelesen. Ist eigentlich nur von fortgeschrittenen Anwendern durchführbar und bei der Ausbringung auf größere Anzahl von Geräten nicht zumutbar.
Da hier wohl eine Bitlocker-Sicherheitslücke gefixt wird und Bitlocker bei mobilen Geräten meist vorkonfiguriert ist, könnte das der Grund sein, dass dieses Update derzeit in unserem WSUS noch nicht auftaucht, da bei normalen Desktops Bitlocker nicht vorkonfiguriert bzw. aktiviert ist.
Ich kann nur hoffen, dass Microsoft hier eine bessere Lösung finden wird, da dieses Update so nicht massentauglich ist.
Gruß
Michael
Soweit ich die MS-Doku unter https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8 verstehe, wird es (derzeit) für WSUS nicht automatisch bereitgestellt. Im Update Catalog ist es demnach auch nicht, d. h. manueller Import zum WSUS momentan auch nicht möglich – angesichts der Gesamtumstände aber vielleicht auch verschmerzbar ;-)
Ich bin mir über die Lesart nicht so ganz klar. KB5034441 ist ja nur der Support-Beitrag (und möglicherweise die KB-Nummer für den internen Fix). Das Update wird in den Sicherheitspatch vom 9. Januar 2024 der jeweiligen Windows-Version integriert (siehe meinen Beitrag hier). Wenn Du das betreffende Update per WSUS oder aus dem Update Catalog installierst, sollte das Problem genau so auftreten. Es sei denn, Microsoft nimmt den Fix aus dem kumulativen Update raus. Oder wird euch KB5034441 bei euch aufgelistet – hier wird mir im Update-Verlauf z.B. KB5034127 für Win10 V2019 IoT LTSC angezeigt – oder habe ich mich total verrannt bzw. verlesen – dann korrigiert mich.
Ich hätte es so verstanden wie bei Deskmodder formuliert:
– "(…)" Neben dem "normalen" Sicherheitsupdate für Windows 10 (KB5034122) hat Microsoft die KB5034441 bereitgestellt (…)" (s. https://www.deskmodder.de/blog/2024/01/09/windows-10-kb5034441-winre-update-als-sicherheitsupdate-kann-fehler-0x80070643-ausloesen/)
– hab das aber noch nicht an einem nicht per WSUS gepatchetem / verwalteten Gerät gegengecheckt
– das additive Update KB5034441 (W10, 22H2) verursacht im Zusammenspiel mit der WinRE Umgebung die Probleme
– das KB5034441 (W10, 22H2) wird zunächst "nur" per Windows Update direkt verteilt
– damit sammelt MS u. a. auch Erkenntnisse, bevor dann eine spätere Version ggf. auch via Update-Catalog zum manuellen Import oder direkt per Sync zum WSUS für Firmen bereitgestellt wird
– an unserem WSUS kam KB5034441 auch nicht an, d. h. ich gehe hier nicht davon aus, dass das von MS bisher mal angeboten und wieder zurückgezogen war (so Späße gab es in anderen Monaten ja auch schon)
wurde hier bereits drueben im win11 update blogpost geschrieben, und deskmodder hats rauskristallisiert.
es ist wieder mal n mess-up von microsoft. seitens windows recovery partition update patch etc….. microsoft typische leistung der verhunzten monatsupdates
im westen nichts neues
Hat schon mal jemand Server 2019 aktualisiert? Wie schauts da aus? DC, SQL, Exchange?
Das eigentlich geilste ist doch das die Microsoft Anleitung sogar falsch ist!
Wenn man nach der Microsoft Anleitung macht hat man eine ganz normale primäre Partition und die bekommt dann natürlich auch automatisch einen Laufwerksbuchstaben :)
Nach dem man also die Systempartition verkleinert hat wäre meiner Meinung nach folgende Reihenfolge sinnvoller:
create partition primary
format quick fs=ntfs
(für Systeme mit MBR) set id=27
(für UEFI Systeme) set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
(für UEFI Systeme) gpt attributes=0x8000000000000001
exit (Diskpart Beenden)
reagentc /enable
Das ist noch aus meiner Anleitung die ich für den Wechsel von MBR zu UEFI gemacht habe.
Die Anleitung zum Vergrößern der WinRE-Partition ist unvollständig und funktioniert so nicht unbedingt.
support[.]microsoft[.]com/de-de/topic/kb5028997-anweisungen-zum-manuellen-%C3%A4ndern-der-partitionsgr%C3%B6%C3%9Fe-zum-installieren-des-winre-updates-400faa27-9343-461c-ada9-24c8229763bf
Dabei muss man auch beachten, dass diese Anleitung für Version 1607 gilt.
Manche Windows-Versionen haben aber eine unterschiedlich große Recovery-Partition (500 oder 768 oder 1 GB) und dann braucht man auch jeweils die passende Menge an freiem Speicherplatz auf dieser WinRE-Partiiton.
Bei vorhandener 1 GB WinRE-Partition und Windows-Version früher als 2004, braucht man auch 1 GB freien Platz auf dieser Partition.
learn[.]microsoft[.]com/en-us/troubleshoot/windows-client/windows-security/disk-partition-requirement-use-windows-re-tool
Das Problem:
1. Diese vergrößerte Partition ist unter Umständen anschließend leer, weil das WinRE-Image eventuell gar nicht erneut dort rein geschrieben wurde, weil die WinRE.wim fehlte.
Deswegen wäre es vermutlich besser, nicht diese Microsoft-Anleitung zu benutzen, sondern Tools zu benutzen wie "MiniTool Partition Wizard 10.2.2 Technician" oder Paragon Partition Manager" etc., weil die den Inhalt der WinRE-Partition nicht löschen.
2. Damit das WinRE-Image überhaupt dort neu reingeschrieben werden kann, muss die \\Windows\System32\\Recovery\\WinRE.wim auch vorhanden sein, aber auf manchen Computern fehlt diese.
Der Trick mit dem Befehl reagentc /enable funktioniert dann auch nicht, wenn es diese WinRE.wim dort gar nicht gibt.
Der Tipp mit dem manchmal fehlenden WinRE.wim stammt aus dem HP-Suppoert.-Forum:
h30434[.]www3[.]hp[.]com/t5/Notebook-Operating-System-and-Recovery/WinRE-wim-not-found/td-p/8961770
3. Damit das Update KB5034441 durchläuft, müssen 1 und 2 erfüllt sein, denn sonst kann das Update die WinRE.WIM weder patchen, noch in die WinRE-Partition reinschreiben.
Ich werde da sicherlich nicht dran rumbasteln. Da macht man am Ende u.U. mehr kaputt. Es ist nicht meine Aufgabe, ein Update durch Umwege zum Laufen zu bringen.
Abwarten und Kaffee oder Tee trinken.
Also mit der WinRE.wim in \\Windows\System32\\Recovery\\ geht
reagentc /enable auf meinen Windows 10 Systemen auch nicht!
Ich bin ratlos:
reagentc /info zeigte mir die Partion 4 an und die musste ich von 814 auf jetzt 1055 MB vergrößern. Danach lief das Update durch.
Wegen deines Posts habe ich gerade mal als Admin nach der WinRE.wim suchen lassen und es wurde nichts gefunden (geschütze und versteckte Dateien ausblenden war natürlich deaktiviert). Löscht das Update die WinRE.wim nach der Installation?
Was mich stutzig macht: Ich habe mit Partition 5 eine zweite, die ebenfalls mit Wiederherstellung bezeichnet ist und 619 MB umfasst. Im Datenträgermanager werden beide übrigens mit 100 % frei angezeigt. Wo kommt diese zweite Partition, mit wahrscheinlich ebenfalls WinRE, her?
Auf dem System war laut Dells Service-Tag ursprünglich Windows 10. Ich habe ihn aber von privat gebraucht gekauft und da war schon Windos 11 drauf, was ich nach etwa 2 Wochen entnervt mittels MediaCreationTool und USB-Stick wieder durch Windows 10 ersetzt habe.
Kommt diese zweite WinRE Wiederherstellungspartition von Windows 11, oder hat meine Inplace-Reparatur vom Dezember die ursprüngliche als Backup behalten und dafür die 5 angelegt? Oder ist die von Dell?
Laut Dell: "Systeme, auf denen Windows 10 bereits werkseitig installiert ist, verwenden die nativen Backup- und Wiederherstellungsfunktionen von Windows 10."
Wenn meine Windows 10 Inplace-Reparatur vom letzten Monat die als Backup der alten WinRE angelegt hat, hätte ich die ja löschen und zum Vergrößern der 4 nutzen können, statt 250 MB von der 3 (Betriebssytem) abzugeben. Kann man beiden bedenkenlos einen Laufwerksbuchstaben zuordnen und mal schauen, was drauf ist, und den dann wieder entziehen, ohne dass was kaputtgeht?
Eine Suche nach Recovery fand mehrere Ordner davon:
c: recovery
Inhalt: ReAgentOld.xml, (inhaltlich und zeitlich identisch zur ReAgent.xml aus system32);
einen Ordner OEM, mit einer ResetConfig.xml (in der z.B. *Run Phase="FactoryReset_AfterImageApply"* steht) und einer "AfterImageApply_BDB… .cmd".
c: system32 recovery
Inhalt: nur ReAgent.xml (von gestern) und ReAgent_Merged.xml1 vom November 2023; letztere unterscheidet sich bei der "WinreBCD id", beim Offset des "WinreLocation path" und beim "ScheduledOperation state" (5 statt 4)
C: Windows System32 Microsoft Protect\Recovery
Inhalt: 6 recovery.dat/.LOG1/.LOG2/.blf/.regtrans-ms
… AppData Local Microsoft EDP Recovery
Inhalt: 2 leere Ordner namens input & output
C: Windows SysWOW64 Recovery
Inhalt: ReAgent.xml vom Dezember 2019 (die aber keine spezifischen Daten enthält: *WinreBCD id=""* und alles andere hat Wert "0", außer ScheduledOperation state="4"
Dann gibt es noch:
C: Windows System32 Tasks_Migrated Microsoft Windows RecoveryEnvironment die eine XML namens VerifyWinRE enthält (4KB, vom September 2022 und ohne Dateierweiterung)
C: ProgramData Dell OS Recovery Tool
Inhalt; nur einen Ordner "data", der wiederum einen leeren Ordner "session" enhält.
@ Günter Born
Huch, ich hatte das doch kurz vor Ablauf der Bearbeitungszeit gelöscht. Das war nicht der Spamfilter. :)
Bei den Pfaden fehlen ohnehin die Backslashes.
Es war allerdings so knapp vor dem Timeout, dass ich keine Zeit mehr hatte, um den Inhalt gegen "gelöscht" zu ersetzen, damit klar ist, dass ich es selbst gelöscht habe.
Während der Zeit bis zum Bearbeitungs-Timeout hatte ich im Netz recherchiert und damit hat sich mein Post praktisch erübrigt.
Also löschen. :) Eine Antwort würde ohnehin nicht mehr kommen.
Warum wird KB5034441 ausdrücklich nicht im Microsoft Update Catalog angeboten?
Welchen technischen Grund sollte es dafür geben?
"Microsoft Update Catalog
Abailable: No
See the other release channels."
"Windows Update and Microsoft Update
Available: Yes"
support[.]microsoft[.]com/de-de/topic/kb5034441-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8
Dann könnte man es manuell runterladen, auspacken, analysieren, per Script automatisch reparieren und installieren.
Aber nein, Microsoft meint ja alles besser zu wissen und es funktioniert dann trotzdem nicht.
Wenn das Problem mit der zu kleinen Wiederherstellungspartition (WHP) besteht ist diese vermutlich nur ungefähr 500MB groß. Da gab es in der Vergangenheit schon öfters mal Probleme und die dadurch entstehenden Fehlermeldungen sind absolut irreführend.
Diese Partition sollte man auf mindestens 1-2GB erweitern. Das ist ja keine Größe, die einem in Schwierigkeiten mit dem Platz bringt.
Microsoft hat dafür eine Anleitung wie man es mit Bord-Mitteln macht aber das ist echt aufwändig. Wenn hier die Erwähnung von Produkten erlaubt ist verwende ich für diesen Fall den AOMEI Partition Assistent in der Free Version. Backup machen (!) und dann von einer Partition wo es passt (bei mir C:) einfach 1GB abknapsen. Das dauert dann im PE Modus je nach Laufwerkstyp 30-60 Minuten. Wenn dann der Rechner wieder startet (hoffentlich :D ) noch mal in den Manager rein, die WHP anklicken und mit dem freien Bereich vergrößern. Das dauert dann nur Sekunden.
Der Vorgang ist mit dem Tool relativ simpel. Es gibt da auf der Herstellerseite eine Anleitung. Die Vorgehensweise hängt natürlich auch von der auf dem PC vorhandenen Partitionierung ab, das kann abweichen. Bei mir ist das Boot Medium eine SSD mit Laufwerk C und den üblichen Systempartitionen ohne weitere Laufwerke. Natürlich könnt ihr das auch nach der MS Anleitung machen oder einen anderen Partitions Manager eurer Wahl verwenden.
Ich habe jetzt knapp 2GB für die WHP und das Update läuft durch.
im Prinzip schon richtig. Aber ist es das wirklich?
Wenn es vorher ging, so sollte es auch jetzt gehen. Es betrifft doch nicht nur einen PC sondern wohl viele. Menge nach oben offen. Ein Sicherheitsupdate ist doch nicht dazu da, dass man selbst rumbasteln muss.
Vielleicht hat MS den Begriff "sicherheitsupdate" eine eigene neue Definition: Jetzt meinen die damit vielleicht den PC unbrauchbar zu machen. Da kann ich auch gleich den Stecker rausziehen.
Ich muss bei mir auch mal gucken, wie das mit den anderen PC bei mir ist.
Da hast Du natürlich recht. Ich hoffe auch, das MS das fixt denn sonst bricht hier das Chaos aus und die Kunden meckern über die Rechnung für die zusätzlichen Wartungsarbeiten.
Ich hatte das Problem in der Vergangenheit schon öfters und habe mir anfangs nen Wolf gesucht um das dann zu finden. Die Meldungen bei MS sind da überhaupt nicht hilfreich. Als das Problem mehr und mehr PC betrifft findet man dazu jetzt bessere Treffer. Ich musste bislang auch nur wenige PC manuell umstellen. Oftmals waren das Win7 PCs die dann auf Win10 umgestellt wurden. Hier war dann die Partition noch viel kleiner (250GB) und es knallte früher ohne das MS einen Fix bereit stellte.
Dieses manuelle Erweitern ist für all die Leute gedacht, die es mit dem Fix eilig haben. Der Rest wartet einfach mal ab.
Bei Windows 11 gab es doch das gleiche Problem!
Haben die das da gefixt?
Oder haben es alle entweder selber repariert oder es einfach sein lassen?
Also die Windows Server 2022 Azure Images von Microsoft haben auch zu kleine WinRE Partionen, da fliegt das Update reihenweise auf die Bretter.
Schon beim letzten Problem mit Bitlocker/WinRE haben wir die Recovery deaktiviert.
Finde ich im Businessumfeld sowieso nicht nützlich. Damit sollte ich das Problem hoffentlich aussitzen können.
Ohne WinRe funktioniert hier das Wipen/Neuinstallieren der Systeme mit Intune nicht, ich finde die WinRE daher sehr wichtig. Ohne WinRE verweigert Intune die Bitlocker verschlüsselung, diese ist im Unternehmensumfeld notwendig sofern man nichts anders als Bitlocker nutzt.
Bin wohl eine der wenigen die hier mehr Glück hatte.
KB5034441 lief bei mir gerade Problemlos durch.
Bei uns ist das Update im WSUS nicht sichtbar und wird auch nicht gefordert, dass ich es freigebe. Auf unseren VMs wird erst bei dem direkten Windows Update über MS das KB5034441 sichtbar und auch installiert. Das aber nur auf VMs, die keine Recovery Part haben.
Alle DELL Devices haben den Fehler, obwohl mein Gerät hier sogar ne WinRE von 800 MB hat? Trotzdem geht der KB auf Fehler… es ist zum Brechen…
Wie soll man hier automatisiert eine Korrektur hinbekommen? Wir haben generell überall auch Bitlocker installiert. Wie denkt sich MS das?
Für manche User sind Backups ein Fremdwort.. die halten "alles" auf den Clients… Wenn man mit so etwas die Kiste zerschießt, dann hat man als Admin aber "Geburtstag"… WTF… wir überlegen sogar schon, das Ding zu blockieren… wer soll denn das alles manuell mit den Usern zusammen machen? Bei 250+ an Devices ist das ja ein Unding…
Bei mir reichen 640MB für die Recovery Partition aus aber die Microsoft Anleitung (mit Abwandlung) hat nur auf einem System funktioniert bei allen anderen klappt dann reagentc /enable nicht mehr. Das muss ich dann mit dem Windows 10 Boot Stick machen. Man hat ja sonst nichts zu tun :(
Auf meiner Kiste nutze ich WinRE gar nicht, also der Status ist Disabled ( via Reagentc /info )
Das MS sowas simples nicht in ihrer Update Routine drin haben (Ist Disable? Dann ignore update) wundert mich jetzt auch wieder nicht.
Ich habe Win10 zweimal auf der Platte installiert, jeweils ohne Recoverypartition.
Irgendwann wurde bei einem Win10 diese Partition angelegt 579MB.
Hier funktioniert das Update nicht.
Beim zweiten Win10 wurde die Partition nicht angelegt, dort liegt die Recoverypartition laut Reagentc /info in der Systempartion.
Hier funktioniert das Update.
Also ich habe jetzt drei Fälle:
Fall 1: Recovery Partition ist zu klein, WinRE.wim schwirrt wohl irgendwo in der Installation rum. Dann klappt die Anleitung von Microsoft, das aber besser mit Anpassungen in der Reihenfolge. 640MB als Recovery Partition reichen dann, ich habe die Partition beim Neuerstellen zuerst formatiert und dann die entsprechenden Flags gesetzt. Nach einem Neustart lässt sich das Update installieren.
Fall 2: Die Recovery Partition ist zu klein die WinRE.wim ist aber nicht im System vorhanden. mit Parted Magic kann man die Partition, nach Verkleinern der Systempartition (C:), gut vergrößern. Das Update lässt sich dann installieren.
Fall 3: Die Recovery Partition ist zu klein die WinRE.wim ist aber nicht im System vorhanden.Die Recovery Partition wurde wohl auch nie richtig angelegt, die WinRE.wim ist daher auch nicht auf der Recovery Partition, da ist dann Basteln angesagt :)
Fall 2 funktioniert bei mir so doch auch nicht. Wenn ich die Partition mit Parted Magic vergrößere muss ich danach die Recovery Partition wieder aktivieren was wegen der fehlenden WinRE.wim fehlschlägt. Man kann aber den Pfad für die WinRE.wim mittels Parameter /setreimage für reagentc angeben. Die WinRE.Wim wird nach dem reagentc /enable versteckt bzw. wenn sie unter \Windows\System32\Recovery\ liegt irgendwo anders hinverschoben.
Bei mir werden die Updates auf dem Client nicht angeboten ( Online Check ) Windows 10 22H2, im WSUS Sync sind alle angekommen ;)
CVE-2024-20666… ich hab grad arge Déjà-vus (CVE-2022-41099, CVE-2022-21894/CVE-2023-24932). :-(
Und wieder hinterlässt die FAQ viele offene Fragen (welche schon das letzte Mal kaum jemand interessiert hat) und wieder täuscht der niedrige CVV da physischer Kontakt gegeben sein muss, was ja in den meisten Szenarien wo Bitlocker vor fremden Datenzugriff schützen soll naturgemäß der Fall ist.
Das Ganze automatisch zu patchen ist ja durchaus der richtige Weg, denn wenn sie schon jedem Bitlocker aufs Auge drücken (Stichwort Modern Devices) dürfen sie nicht wie das letzte Mal erwarten, dass Enduser wie Marianne und Herbert die Update History Seiten verfolgen, KBs lesen usw. um dann mittels dism oder Powershell Scipt manuell zu patchen.
Aber ist es denn zuviel verlangt ein paar Prüfungen mit einzubauen?
Nach der letzten Bitlocker Geschichte und dann BlackLotus habe ich auf allen Geräten WinRE verbannt.
Und trotzdem läuft das Update auf und schlägt dann bei der Installation fehl.
Grüße, Martin
Microsoft wird auf jeden Fall reagieren müssen, da führt kein Weg dran vorbei.
Dafür gibt es schon zu viele Meldungen. Ein erster Schritt wäre m.E. schonmal, das Update wieder zurückzuziehen. Damit man nicht in Dauerschleife eine Download oder Installationsfehlermeldung erhält.
Das mit der Liste abarbeiten als Sofort Hilfe ist eher ein kleiner Scherz. Wenn man da wirklich keine Ahnung von hat, verhaut man sich nachher u.U. noch völlig das System.
Ich hatte heute Morgen zweimal eine Installation angeworfen. Direkt nach dem Systemstart und dann nochmal, als alle anderen Updates durchgelaufen waren. In beiden Fällen natürlich mit Fehlermeldung. Jetzt heißt es erstmal abwarten. Ich bastel da wie schon im anderen Post geschrieben, nicht selber über die Eingabeforderung oder sonstiges rum. Ist nicht meine Aufgabe.
//edit:
CVV = CVE
FAQ = FAQ (des MSRC)
Win 10 22H2 Pro hier – habe es mit viel Aufwand hinbekommen.
Habe komplett neue Recovery Partition angelegt (2GB) nach der Anleitung hier https://www.deskmodder.de/blog/2023/09/10/windows-11-winre-update-mit-fehlermeldung-wegen-zu-kleiner-partition-anleitung-von-microsoft/
Dazu musste ich aber noch das WinRE.wim aus dem InstallationsISO extrahieren, weil es auf dem System nicht vorhanden war – also ISO runterladen, ESD in WIM konvertieren usw.
Das war Spaß :)
Wie groß ist denn bei Neuinstallation standardmäßig die Win Re Partition? Darauf achtet man ja nun mal nicht, denn man frisch installiert , sondern wählt die automatische Größe aus.
Kurz gefragt? Dass ein Update fehlschlägt, ist natürlich ärgerlich, aber dann schlägt es halt fehl und man eine Lücke … was auch Mist ist, aber besser als vor 2 Jahren, als es einen Kolluralschaden gab . Wird MS bestimmt nochmal nachpatchen, ansonsten erstmal nicht installieren. Schlimmer wäre es, wenn danach alle Clients nicht mehr funktionieren würden
Hi…
"Und täglich grüßt das Murmeltier"…
Sorry, sicherlich etwas OT, aber wenn ich immer solche Stories vom "qualitativen Wirken" M$s bezüglich der modernen Win-Versionen sowie entsprechender Updates lese, kann ich nicht anders als mich (diebisch 😉) darüber zu freuen, dass ich immer noch mit meinem (ach so unsicheren) W7 unterwegs bin, bei dem – komischerweise – einfach alles im gewünschten Use-Case funktioniert und meine Produktivität nicht mindert.
Und so "fühle" ich mich leider auch nur immer wieder bestätigt. 🤷♂️
So ist es, meine Win 7 Kisten laufen jetzt seit 10 Jahren und länger, damals gebraucht gekauft, Neuinstallation von Windows war nie notwendig.
Stimmt absolut!
Hieß ja immer so pauschal, dass man alle 3 – 5 Jahre eine Neuinstallation durchführen muss, da zu viele Fehler, Probleme usw. Win 7 lief bei mir fast 12 Jahre mit der Erstinstallation und so gut wie fehlerfrei! (Es würde wohl auch noch immer laufen, aber ich nutze den PC seit rund 1,5 Jahren nicht mehr …)
Hier auch.
Mit MiniTool Partition Wizard Pro eine Partition verkleinert, dann die Recovery Partition vergrößert => das Update lässt sich installieren.
Jo. Und dann gibt es tatsächlich Leute, die Linux als "Frickel-System" bezeichnen…
SCNR
Wird seinen Grund haben, warum trotzdem keiner Wechselt und sich Linux antut, vielleicht ist es auch die charmante Community ¯\_(ツ)_/¯
Was ist denn bei Microsoft los?
Können die nicht klar – das heißt in deutscher Sprache – aussprechen, dass die Wiederherstellungspartition bei Vielen zu klein ist.
Wie ich meine Wiederherstellungspartition – wenn es einen Bedarf gibt – vergrößere das schaffe ich selbst noch.
Mein Partitionmanager – Bezahlsoftware – kann das bzw. hat mir angezeigt:
Wiederherstellungspartition: Kapazität 869 MB Belegt 506,73 MB Frei 362,27 MB
Weil ich noch "freie Kapazitäten" habe, hat mein Patchday anscheinend keine Probleme gemacht. Noch!
Wer braucht wozu eine Wiederherstellungspartition?
Das hat Microsoft noch nicht erklärt.
Es handelt sich sicher nicht um ein "Abbild" des Betriebssystems. Das würde sich mit 900 MB gar nicht ausgehen.
Die Wiederherstellungspartition wurde beim Setup von MS automatisch erstellt. Ich habe auf die Größe keinen Einfluss.
Ist es seitens MS so schwer die Wiederherstellungspartition mit mindestens 5 GByte einzurichten und zu erklären wozu man diese Partition überhaupt benötigt?
Hallo, auch ich möchte euch meine Erfahrungen mitteilen.
beim ersten Aufrufen der Update-Funktion wurde u.a. das erforderliche Update KB5034441 angezeigt. Der erste Download war nicht erfolgreich – der bekannte Fehler "0x80070643". Also Hinweis bzgl. dieser Fehlermeldung ausgeführt "reagentc /info" (in CMD als admin ausgeführt) zeigte "Enabled". Also Überprüfung der Partitionsgröße mittels Computerverwaltung – Datenträgerverwaltung (als admin) – Größe der Wiederherstellungspartition (Datenträger 0 Partition 4) Kapazität 974 MB davon freier Speicher 997 MB. Kurz überlegt, ob die Hinweise/Anleitung von M$ bzw. von deskmodder.de zu befolgen oder einfach auf "Wiederholen" beim Update KB5034441 zu klicken. Da ich (manchmal) faul bin, also einfach auf Widerholen geklickt – und siehe da, dass Update wurde heruntergeladen und erfolgreich installiert. Evtl. nur Glück gehabt ….
Fehlerteufel …es muss natürlich heißen: 'Größe der Wiederherstellungspartition (Datenträger 0 Partition 4) Kapazität 974 MB davon freier Speicher 974 MB …'
Schönen Abend noch.
Was die Problematik KB 5034441 angeht habe ich folgende Erkenntnisse:
Auf 5 von meinen Rechnern/Notebooks war die Wiederherstellungspartition von Win10-22H2 am ENDE der SSD, war also das letzte Volume.
C:\ mittels AOMEI Partition Assist oder Minitool Partition Manager Free am Ende etwas verkleinern, anschließend die Recovery-Partition auf ca. 1,5 GB vergrößern.
Danach wurde KB 5034441 erfolgreich installiert, wie gesagt auf 5 PCs/Notebooks erfolgreich.
Bei einem weiteren PC ist die Recovery-Partition als ERSTE Partition angelegt (alle Geräte jeweils mit Win10-Setup-Prg automatisch angelegt).
Hier hat das vergrößern der Partition nichts geholfen, KB 5034441 bringt immer wieder den Fehler – angeblich zu wenig Platz.
Theoretisch braucht man die Recovery Partition ja nicht, wenn man entsprechende Bootmedien (wie W10-USB-Stick o.ä.) hat.
Somit werde ich diese vermutlich löschen und ggf. am Ende der SSD wieder anlegen …
So habe ich das bei mir gemacht – die Recovery Partition war bei mir die erste und nur 500 MB gross, wohl zu klein. Hab also eine neue 2 GB erstellt, als letzte, nachdem ich die Hautppartition verkleinert habe.
Damit es aber alles funktioniert, musste ich das machen
https://www.deskmodder.de/blog/2023/09/10/windows-11-winre-update-mit-fehlermeldung-wegen-zu-kleiner-partition-anleitung-von-microsoft/
Dazu musste ich noch das Winrm.wim aus den ISO extrahieren, weil ich es auf dem System nicht gefunden habe und ohne hat "reagentc.exe /enable" nicht funktioniert.
Kann es sein, dass MS KB5034441 inzwischen zurück gezogen hat? Konnte es vorhin zu Feierabend auf unserem WSUS nicht mehr finden.
Das Update wird nur mittels Windows Update und Microsoft Update ausgeliefert.
https://support.microsoft.com/de-de/topic/kb5034441-windows-wiederherstellungsumgebungsupdate-f%C3%BCr-windows-10-version-21h2-und-22h2-9-januar-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8
Gestern nachmittag stand auf der Seite bei WSUS noch Ja. Ist trotzdem nicht im WSUS aufgetaucht.
Aus diesem Grund allein bin ich sehr vorsichtig mit der "sofortigen" Installation von Aktualisierungen für Microsoft Betriebssystem – die einzige Anwendung aus diesem Haus auf meinem Rechner. Auch mit anderen Anwendungen bin ich mit Aktualisierungen sehr vorsichtig. Meistens warte ich eine Woche post Freigabe. In der Zeit hat entweder Microsoft seinen Fehler behoben, und eine neue Distro freigeschaltet, oder, wie es auch manchmal der Fall ist, die Aktualisierung vollständig zurückgezogen. Diese wird dann meistens überprüft und beim nächsten monatlichen Katastrophendienstag freigeschaltet. Im Gewebebereich testet man zuerst auf einer bis drei Maschinen, und danach mittels beispielsweise Matrix42 umverteilt. Ja, mit Zeit kommt immer Rat.
Wenn Microsoft das nicht fixt in den nächsten Tagen programmiere ich mir ein eigenes Windows!
…sagte Linus Torvalds….
Alle großen Organisationen, ob Konzerne oder pol. Systeme / Staaten, sind irgendwann an ihrer eigenen Arroganz und Ignoranz zugrunde gegangen … das war immer so, ist so und wird immer so sein … und ist natürlich auch für MS gültig! Also entspannt euch, nicht aufregen, das Leben ist zu kurz um sich ständig … zu ärgern.
Mit dem Windows Update Manager (WuMgr) 1.1 von DavidXanatos kann man das Update KB5034441 auch manuell runterladen.
github[.]com/DavidXanatos/wumgr/releases/tag/v1.1
Inhalt des Updates:
www[.]computerbase[.]de/forum/attachments/kb5034441-2024-01-10-png.1441980/
Dieses Update kann man manuell mit Dism in die WinRE.wim integrieren.
Allgemeine Anleitung von Microsoft zu diesem Verfahren:
learn[.]microsoft[.]com/de-de/windows-hardware/manufacture/desktop/add-update-to-winre?view=windows-11
Anschließend mit dem reagentc /enable Befehl das gepatchte WinRE.wim manuell in die Wiederherstellungspartition schreiben und aktivieren.
Falls die WinRE.wim unter \\Windows\\System32\\Recovery fehlen sollte, dann kann man sie aus dem Windows-Unterordner \\Windows\\Sources\\SafeOS rauskopieren oder man muss sie sich von der Windows-ISO holen.
Hallo Gemeinde,
wie bereits im Oktober 2023 für KB5031356 geschildert, brachen alle folgenden Updates bei 99% mit Fehler "0x800F0922" ab und das System wurde zurückgesetzt.
Letztes funktionierende Update war KB5030300 Version 22H2 Build 19045.3516.
Seitdem habe ich Update-Sperre, bis Microsoft gnädigst Lösung bringt.
Gruß Wolf
Ich würde mir da keine Hoffnungen machen, wenn das seit Oktober so geht. Erfahrungsgemäß kommt da nichts mehr, da solltest du wohl mal selbst nach einer Lösung suchen.
Probleme mit Update: 2024-01 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5034127)
Wir haben Probleme festgestellt das nach einspielen des Updates die Verbindung zu SQL Clustern mit div. Fehler auftreten:
SQLClient.SqlException (0x80131904) Execution Timeout Expired.
SystemComponentModel.Win32Exeception (0x80004005)
In unserem Fall Windows Server 2019 zu Window Server 2016 SQL Cluster.
Jemand ähnliche Probleme Festgestellt?
per hand mit dism und checkdisk befehlen die Re Partition vergrößern funktioniert nicht da sie aus Datenträger in Windows verschoben wird auf C:\ und einen unendlich langen Namen erhält der Patch kann dann zwar installiert werden aber mit welchem nutzen wenn das System komplett durch einander gebracht wird und System Teile nicht an ihrer Position mehr sind mit AOMEI Partitions Assistent funktionieret es auch nicht und nebenbei fehlt dann die Datei WinRe.wim in Recovery.Ich habe es mit einem Backup Programm auf letzten Freitag zurück gesetzt und alles wieder wie es sein sollte auch mit RE Partition unter Datenträger Verwaltung,Computerverwaltung,Datenträgerverwaltung, und genau so bleibt es sonst programmierte ich mir ein eigenes Windows nur die WinRe.wim Datei fehlt in Recovery und ich habe keine Lust meine Original Windows DVD auf C:\ zu entpacken um an die Datei zu kommen da man den Temp Ordner nicht löschen kann hinterher.Ich kann nur hoffen das Microsoft einsieht das die Windows Nutzer auf der Erde nicht alle Administrator studiert haben.Ich kann es niemanden emfehlen das selbst zu machen das ist ein verschlüsseltes System in Windows weder über die Registrierung noch anders da es verschlüsselt nur als Admin mit Microsoft Pass machbar ist wenn überhaupt.
MS hat wohl ein Skript zum KB5034441 bereitgestellt:
https://www.heise.de/news/Microsoft-liefert-Abhilfe-zur-Installation-von-Updates-in-WinRE-Partition-9595312.html
Ich habe das über diesen Link gemacht, für Win10, 11, Server2022, wenn man sich die passende CAB-Datei herunterlädt, tut es das. das kum. Update 2024-01 wird dann in einem installiert, zumindest sagt das der Updateverlauf, wobei mir das zu schnell ging, die ca. 800MB müssten ja eigentlich erst einmal herunter geladen werden.
https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10
Oft bekommt man hier ja mit, ob eins der besprochenen Updates Probleme macht.
Heute bin ich mal der Erste der eine problematische Konstellation meldet:
KB5034127 (2024-01 Cumulative Update for Windows Server 2019 for x64-based Systems) legt GFI MailEssentials teilweise lahm.
Tückisch ist, daß man es nicht sofort merkt. Die AntiSpam- und EmailSecurity-Engines laufen zwar noch und Mails werden durchgeleitet (also nicht komplett blockiert, was man ja sofort merken würde). Allerdings sieht man in der Bedienkonsole (in einem Untermenü versteckt) nun häufig den Satz "Einige E-Mails konnten nicht von GFI MailEssentials verarbeitet werden. Als Vorsichtsmaßnahme wurden diese E-Mails in \Program Files (x86)\GFI\MailEssentials\EmailSecurity\FailedMails gespeichert." Dh. einige Mails bleiben dann dort einfach im "Nirvana" stecken.
Ticket bei GFI geöffnet: "Wir untersuchen das, es haben auch schon andere Kunden dasselbe Problem gemeldet… bis dahin deinstallieren sie KB5034127!"
Traurig aber wahr …
Bei mir gibt es ein ähnliches Problem
Server 2022 (aktueller Patchstand)
Exchange 2019 (aktueller Patchstand)
GFI Mailessentials (aktueller Patchstand)
Bei mir ist es aber so, dass alle Mails einfach ohne Scan durchgeleitet werden.
Man sieht es also nur im GFI Webinterface, dass keine Mails verarbeitet.
Nach dem löschen des Updates KB5034129 läuft es erstmal wieder…
Identisches Problem
GFI läuft, filtert aber nichts mehr.
Update temp. deinstalliert und GFI filtert wieder
Nachlese für Interessierte:
Zwischenzeitlich hat GFI einen neuen Patch rausgebracht.
Details:
==========================
Patch 5
Datum: 2024-01-23 Schweregrad: Wichtig
Fix: GFI Mailessentials not processing emails correctly after applying Microsoft KB5034129/KB5034127 updates
==========================
Installiert und funktioniert!
Ich sehe hier nach der Installation der Januar-Updates gerade ein übles Problem bei der Lesegeschwindigkeit einer REFS-Partition beim Lesen auf Windows Server 2016 (Hyper-V-Host), interessanterweise nicht bei kleinen Blöcken, da blieb alles soweit "normal":
[Read]
SEQ 1MiB (Q= 8, T= 1): 297.594 MB/s [ 283.8 IOPS]
SEQ 1MiB (Q= 1, T= 1): 77.592 MB/s [ 74.0 IOPS]
RND 4KiB (Q= 32, T= 1): 186.163 MB/s [ 45450.0 IOPS]
RND 4KiB (Q= 1, T= 1): 74.653 MB/s [ 18225.8 IOPS]
[Write]
SEQ 1MiB (Q= 8, T= 1): 1393.991 MB/s [ 1329.4 IOPS]
SEQ 1MiB (Q= 1, T= 1): 1234.297 MB/s [ 1177.1 IOPS]
RND 4KiB (Q= 32, T= 1): 125.362 MB/s [ 30606.0 IOPS]
RND 4KiB (Q= 1, T= 1): 77.014 MB/s [ 18802.2 IOPS]
NTFS auf dem gleichen System:
[Read]
SEQ 1MiB (Q= 8, T= 1): 6922.937 MB/s [ 6602.2 IOPS]
SEQ 1MiB (Q= 1, T= 1): 3888.334 MB/s [ 3708.2 IOPS]
RND 4KiB (Q= 32, T= 1): 167.219 MB/s [ 40825.0 IOPS]
RND 4KiB (Q= 1, T= 1): 110.889 MB/s [ 27072.5 IOPS]
[Write]
SEQ 1MiB (Q= 8, T= 1): 5326.412 MB/s [ 5079.7 IOPS]
SEQ 1MiB (Q= 1, T= 1): 2963.131 MB/s [ 2825.9 IOPS]
RND 4KiB (Q= 32, T= 1): 119.452 MB/s [ 29163.1 IOPS]
RND 4KiB (Q= 1, T= 1): 81.189 MB/s [ 19821.5 IOPS]
So ungefähr sahen die Werte vor dem Update auch auf ReFS aus. Mir ist das bloß aufgefallen, weil die virtuellen Server mit VHDX-Dateien auf dem ReFS-Volume ewig bis zur Verfügbarkeit brauchten.
Ein Neustart hatte nichts geändert, sah danach immer so aus. Hardware:
2x HPE Proliant ML350 mit Festplatten-RAID 10.
In einem der Server werkelt ein HPE Smart Array P816i-a SR Gen 10-Controller, im anderen ein P824i-p.
Bei letzterem schlug das augenscheinlich nicht unmittelbar auf die VM-Performance durch, zumindest nicht in der einen VM, die ich testweise"gebenchmarkt" habe. Beim anderen Host mit virtuellem Dateiserver hingegen sehr.
Während der Deinstallation von KB5034119 noch vor dem Neustart normalisierte sich die Lesegeschwindigkeit auch auf dem ReFS-Laufwerk (allerdings waren da die VMs bereits heruntergefahren).
[Read]
SEQ 1MiB (Q= 8, T= 1): 6237.602 MB/s [ 5948.6 IOPS]
SEQ 1MiB (Q= 1, T= 1): 2873.855 MB/s [ 2740.7 IOPS]
RND 4KiB (Q= 32, T= 1): 198.955 MB/s [ 48573.0 IOPS]
RND 4KiB (Q= 1, T= 1): 46.756 MB/s [ 11415.0 IOPS]
[Write]
SEQ 1MiB (Q= 8, T= 1): 6692.317 MB/s [ 6382.3 IOPS]
SEQ 1MiB (Q= 1, T= 1): 3856.654 MB/s [ 3678.0 IOPS]
RND 4KiB (Q= 32, T= 1): 128.120 MB/s [ 31279.3 IOPS]
RND 4KiB (Q= 1, T= 1): 85.748 MB/s [ 20934.6 IOPS]
Nach dem Neustart aber wieder miserabel, auch mit nicht gestarteten VMs, sodass ich nicht sicher sein kann, ob das Update wirklich schuld war. Zudem musste ich feststellen, dass die Deinstallation von kumulativen Updates nicht etwa den Zustand von vor deren Installation, also das CU aus dem Dezember, wiederherstellt, sondern den Server weit zurückkatapultiert. (CredSPP Authentifizierungsfehler etc.) War mir so noch nicht bewusst.
Bei zwei Windows Server 2019-Hyper-V-Hosts liegen nach dem Update die Lesegeschwindigkeiten des Hosts ebenfalls deutlich unter den Schreibgeschwindigkeiten, allerdings nicht so extrem.
Hallo, wir hatten hier ein paar "tolle" Phänomene.
Dürfte die meisten recht wenig interessieren, außer sie haben noch wirklich alte Schätzchen am Laufen.
Innerhalb weniger Tage kamen zwei ältliche Workstations rein, die sich alle paar Stunden aufgehängt haben. Da dies an unterschiedlichen Standorten geschah und nicht die gleichen Mitarbeiter betraut waren, hat es ein bisschen gedauert einen Zusammenhang herzustellen.
Diagnose ergab nichts, weder Malware noch Hardwarefehler.
Schließlich haben wir die Januar-Updates ins Visier genommen, nachdem weitere Tickets reingekommen waren. Nach der Deinstallation von KB5033918 sind die Probleme auch scheinbar tatsächlich behoben (heute keine Meldung).
Allerdings konnte ich nicht nachvollziehen, wie dieses Update auf die Maschinen kam, denn am WSUS konnte ich es nicht finden!
Kumulatives Update (KB5033918) vom 9. Januar 2024 für .NET Framework 3.5 und 4.8.1 für Windows 10 Version 21H2 und Windows 10 Version 22H2
Wir haben bislang 3 ältere DELL Workstations und zwei HP Notebooks (Elitebook, Probook 6560) ermittelt. Und ja, die Prozessoren sind in allen Fällen Ivy Bridge oder noch älter…
Das Fehlerbild: Bild friert komplett ein, keine Reaktion mehr auf Maus und Tastatur (auch nicht NUM). Eine der Workstations hat sich einmal nach 10 Minuten wieder selbst berappelt, eine andere zeigte mal einen matschigen BSOD ohne nützliche Information.
Das passierte so alle paar Stunden, scheinbar in Abhängigkeit von der ausgeführten Software.
Wir haben eine (aktuelle) Software im Verdacht, das Problem zu triggern. Bei den Notebooks allerdings lief eine Citrix-Sitzung.
Wir können diese Kisten natürlich alle sofort ersetzen wenn es sein muss, aber irgendwie wurmt das dennoch. Insbesondere, dass ich das Update nicht am WSUS nachvollziehen kann, macht mich stutzig.
bzgl. Sichtbarkeit im WSUS.
Mir ist auch so, daß insbesondere diese beiden Updates kurz nach dem Patchday noch nicht im WSUS waren:
5034119 (2024-01 Cumulative Update for Windows Server 2016 for x64-based Systems)
5033910 (2024-01 Kumulatives Update für .NET Framework 4.8 für Windows Server 2016 für x64)
Da ich aufgrund eines historisch gewachsenen (mein Vorgänger *facepalm*) und noch nicht komplett aufgeräumten Rechner-Zoos eine Liste führe, was ich für welche WSUS-Gruppe genehmigt habe, bin ich mir da sicher.
Es sind zwar nicht genau deine erwähnten Updates aber das Verhalten "war noch gar nicht im WSUS" ist identisch.
Ich habe beide Updates erst heute zum ersten Mal erblickt, während andere Updates von dem Januar-Patchday längst von mir freigegeben wurden.
Wie sie in deinem Fall allerdings ohne WSUS-Genehmigung auf deine Maschinen kamen, ist schon nachforschungswürdig.
Sind die betroffenen Maschinen im Nutzerzugriff und können/dürfen Nutzer (ggf. mit den nötigen Privilegien) Updates direkt aus dem Internet laden? Das hab ich bei mir per Richtlinien weitgehend (aber auch nicht zu 100%) eingeschränkt.
"Rechner-Zoo" gefällt mir.
Ich lege Update-Zoo nach.
Ich forsche also im Eventlog einer Workstation:
Zuerst wird KB5034122 installiert und ein Neustart angefordert (09:54 – reboot necessary).
Dieser wurde erst 16:40:17 Uhr durchgeführt und dann taucht KB5033918 erstmals auf um 16:41:12 (reboot necessary).
16:42:17 wird der Eventlogdienst beendet,
16:43:10 Uhr sind beide Pakete "installed state".
Download von Online schließe ich aus.
Ich schaue also in den Updateverlauf an der Maschine.
Laut dem Updateverlauf wurde KB5034275 installiert, das sehe ich aber nicht im Eventlog – bei MS nachgehakt: hier wurde wohl das gesuchte KB5033918 eingekapselt!
Bitte, was soll denn dieses Hütchenspiel?
Heute weiterhin kein Fehler bei den Rechnern…
KB5034275 für diese Gruppe Clients abgelehnt.