[English]Nachtrag zum Januar 2024-Patchday, wo zahlreiche Nutzer mit dem Update KB5034441 in den Installationsfehler 0x80070643 liefen. Dieses Update soll eine Schwachstelle bezüglich der Bitlocker-Verschlüsselung in der WinRE-Umgebung beseitigen. Es gibt zwar Lösungsansätze, die aber für die meisten Nutzer zu kompliziert sind. Und Administratoren vieler Tausend Windows 10/11-Clients können die auch nicht einzeln in die Finger nehmen. Microsoft hat zum 18. Januar 2024 bestätigt, dass man an einem Fix für diese Probleme arbeitet und diesen irgendwann ausliefern will. Ergänzungen: Gleichzeitig wurde bekannt, dass Microsoft ab April 2024 den Secure Boot härten und unsichere Boot-Umgebungen blockieren will. Nachfolgend fasse ich mal den Status zusammen.
WinRE-Update KB5034441
In Windows gibt es eine BitLocker Security Feature Bypass-Schwachstelle CVE-2024-20666, die es einem Angreifer mit physischem Zugriff auf das System ermöglicht, über die BitLocker Device Encryption-Funktion Zugriff auf mit BitLocker verschlüsselte Daten zu erhalten. Potentiell betroffen sind Windows 10, Windows 11 und Windows Server 2022.
Zum Beseitigen der Schwachstelle hat Microsoft zum 9. Januar 2024 ein Update bereitgestellt, zu dem sich unter dem Supportbeitrag KB5034441 einige Informationen finden. Das Update soll dafür sorgen, dass die Windows Recovery Environment (WinRE) aktualisiert wird. Dieses Update wendet das dynamische Safe Os Update (z.B. KB5034232, KB5034236 etc.) automatisch auf die Windows-Wiederherstellungsumgebung (Windows Recovery Environment, WinRE) auf einem laufenden PC an.
Update Installationsfehler 0x80070643
Das Update wurde dabei automatisch über Windows Update ausgerollt, wobei es egal war, ob auf einer Maschine Bitlocker aktiviert war oder nicht. In Folge des Januar 2024-Patchday meldeten sich dann zahlreiche Nutzer, bei denen das KB5034441 mit einem Installationsfehler 0x80070643 scheiterte. Ich hatte das Thema hier im Blog im Beitrag Windows WinRE-Update gegen CVE-2024-20666 scheitert mit Installationsfehler 0x80070643 (Jan. 2024, KB5034441) aufgegriffen.
Von Microsoft gab es zwar im Vorfeld bereits den Hinweis, dass die Installation des Update 250 MB freien Speicherplatz in der Wiederherstellungspartition erfordert, um erfolgreich installiert werden zu können. Weist die Wiederherstellungspartition nicht über genügend freien Speicherplatz auf, scheitert das Update bei der Installation mit dem Fehler 0x80070643 – ERROR_INSTALL_FAILURE.
Untaugliche Hilfestellung von Microsoft
Es gibt von Microsoft zwar eine Anleitung Anweisungen, um die Größe Ihrer Partition manuell zu ändern, um das WinRE-Update zu installieren, die einerseits in verschiedenen Fälle nicht ausreichend oder schlicht untauglich war (wenn die WinRE-Umgebung nicht aktiv oder nicht vorhanden ist). Und andererseits ist diese Anleitung in vielen Fällen schlicht nicht durchführbar.
- Ein Administrator in einer Firmenumgebung kann nicht manuell die Partitionsgröße bei Tausenden an Clients verändern.
- Gut 99% der betroffenen Windows-Nutzer dürften zudem mit der Behebung des Fehlers (anpassen der Partitionsgrößen, aktivieren der WinRE-Partition) schlicht heillos überfordert sein.
Speziell der letztgenannte Punkt ist als heikel anzusehen, da die Anpassung der Partitionsgröße nicht nur Fachwissen sondern häufig auch Tools von Drittanbietern erfordert (die Windows Bordmittel haben viele Einschränkungen, so dass die Vergrößerung teilweise unmöglich ist). Für Administratoren hat Microsoft zwar ein PowerShell-Script zur Reparatur veröffentlicht (siehe Microsoft PowerShell-Script gegen Installationsfehler 0x80070643 bei KB5034441 (Jan. 2024)), was aber auch Fachwissen und manchmal „etwas Glück“ erfordert, um das Update installieren zu können.
Es gibt auf Github auch ein Dritt-Anbieter PowerShell-Script WinRE-Customization, welches die Partitionsanpassung und mehr unterstützen soll.
Microsoft bessert nach
In den Nutzerkommentaren war häufig zu lesen „ich warte, bis Microsoft einen Fix herausbringt“. Persönlich war ich diesbezüglich zwar skeptisch – und Betroffene hatten das Problem, dass das Update wiederholt zur Installation angeboten wird und dann scheitert.
Nutzer, bei denen sich das Update immer wieder installieren will, können versuchen, dieses in nicht verwalteten Umgebungen unter Windows 10 / 11-Version mittels des Microsoft Tools Show or Hide Updates zu blockieren. In verwalteten Unternehmensumgebungen können Administratoren die Verteilung des Updates aussetzen. Ob Microsoft das Update zurückgezogen hat, ist mir aktuell unklar bzw. unbekannt.
Inzwischen hat Microsoft aber wohl eingesehen, dass man es wieder einmal verpatzt hat. Es war im Grunde ein Desaster mit Ansage, denn im Januar 2023 gab es ein ähnliches Desaster (siehe z.B. Windows 10: „Schlagloch“ Win RE-Patch zum Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099 und die nachfolgenden Links am Beitragsende). Es ist nicht sonderlich schlau, ein solches Update im Dezember oder im Januar auszurollen, wo viele Leute in Urlaub sind oder die Feiertage begehen.
Inzwischen berichten aber einige Medien wie Windows Latest oder Bleeping Computer, dass Microsoft sich der Probleme bewusst sei und daran arbeitet, diese Probleme zu beheben. Redmond will „in Kürze“ weitere Informationen zur Verfügung stellen. Für die Masse der Betroffenen heißt es in meinen Augen daher abwarten, was Redmond da ausbrütet.
Die Bitlocker-Bypassing-Schwachstelle halte ich übrigens nicht für so sonderlich kritisch, weil der Angreifer einen physischen Zugriff auf das System benötigt. In Firmenumgebungen wären Szenarien denkbar, wo Notebooks mit sensiblen Informationen geklaut werden oder verloren gehen und durch Bitlocker vor fremden Augen geschützt werden müssen. Wenn ein Angreifer gezielt Informationen von einem Gerät benötigt, wird es sicher Wege geben, das auch auf anderem Weg zu bewerkstelligen.
Eintrag auf Release Health
Abschließend noch ein ergänzender Hinweis. Microsoft hat zum 18. Januar 2024 den Eintrag The January 2024 Windows RE update might fail to install in den Known Issue im Release-Healt-Bereich von Windows 10 22H2 veröffentlicht. Gleiches gibt es für Windows Server 2022 (siehe) und Windows 11 21H2 (siehe). Für Windows 11 22H2 und 23H2 wird es keinen Eintrag geben, weil dessen WinRE-Umgebung bereits gepatcht ist. Im Eintrag werden die obigen Hinweise zur Korrektur des Installationsfehlers gegeben.
Dort findet sich auch eine Liste der betroffenen Windows-Versionen (Windows 10 21H2-22H2, Windows 11 21H2, Windows Server 2022) samt dem Hinweis, dass bei Systemen ohne WinRE-Umgebung das betreffende Update KB5034441 nicht gebraucht werde. Man könne dann den Installationsfehler ignorieren – tolle Lösung – das Update bei fehlender WinRE einfach nicht zu installieren, wurde nicht implementiert. Im Support-Beitrag in den Known Issues findet sich zudem der Hinweis „Next steps: We are working on a resolution and will provide an update in an upcoming release.“
Secure Boot-Verschärfung ab April 2024!
Das wird auch bitter notwendig werden, denn bei heise habe ich den Hinweis gelesen, dass Microsoft plant, Systeme mit unsicherem WinRE ab April 2024 am Booten zu hindern. Die Information findet man Windows Message Center unter dem Eintrag Reminder: Changes to Windows Boot Manager revocations for Secure Boot effective April 9, 2024. Dort heißt es:
Windows updates released July 11, 2023 and later include security measures which protect against a Secure Boot bypass vulnerability disclosed in CVE-2023-24932. Secure Boot is a Windows security feature designed to protect devices from bootkit malware.
Administrators should observe mitigations and security enforcement requirements coming into effect with Windows updates released on and after April 9, 2024. These updates will provide new mitigations to block additional vulnerable boot managers. Windows updates released on and after October 8, 2024 will enforce the Code Integrity Boot policy and Secure Boot disallow list revocations related to this hardening. There will be no option to disable this enforcement after this update.
To enable protections manually, it’s necessary to ensure all devices and bootable media are updated and ready for this security hardening change. Users should determine whether it’s important to enable protections now, or wait for a future update from Microsoft. To better assess this, in addition to understanding the options available for configuring these security requirements, see KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932.
In Kurzform: Administratoren müssen die geänderten Sicherheitsanforderungen beachten, die mit Windows-Updates, die am und nach dem 9. April 2024 veröffentlicht werden, in Kraft treten. Diese Updates aktivieren neue Schutzmaßnahmen, um zusätzliche anfällige Bootmanager zu blockieren. Windows-Updates, die am und nach dem 8. Oktober 2024 veröffentlicht werden, setzen die Code Integrity Boot-Richtlinie und die Sperrlistenwiderrufe von Secure Boot im Zusammenhang mit dieser Härtung durch. Nach diesem Update gibt es keine Möglichkeit mehr, diese Durchsetzung zu deaktivieren. Das riecht nach weiterem Ärger.
Ähnliche Artikel:
Patchday: Windows 10-Updates (9. Januar 2024)
Patchday: Windows 11/Server 2022-Updates (9. Januar 2024)
Windows WinRE-Update gegen CVE-2024-20666 scheitert mit Installationsfehler 0x80070643 (Jan. 2024, KB5034441)
Microsoft PowerShell-Script gegen Installationsfehler 0x80070643 bei KB5034441 (Jan. 2024)
Windows 10: „Schlagloch“ Win RE-Patch zum Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099
Windows 10: Neues zum WinRE-Patch (Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099)
Windows 10/11: Microsoft veröffentlicht Script für den WinRE BitLocker Bypass-Fix
Ich hatte letzten So das Vergnügen den Patchday bei meinen Kunden auf die Server auszurollen und da war KB5034441 im WSUS nicht mehr(?) vorhanden.
Ich habe auch schon Kommentare gelesen, das es im WSUS gar nicht aufscheint.
Eine Nachschau unter MS KB… zeigt folgendes:
Dieses Update ist über die folgenden Releasekanäle verfügbar:
Windows Update Ja
Microsoft Update-Katalog Nein
Windows Server Update Services (WSUS) und Microsoft Endpoint Konfigurations-Manager Nein
KB5034441 ist und war nie im WSUS
Doch, ganz am Anfang schon! Habs selbst gesehen. Aber als ich später nochmal suchte, war es in der Tat weg. Da muss MS schon früh Schelte dafür bekommen haben.
Hier im WSUS war es laut Logs nie vorhanden – das mag aber auch daran liegen, daß ich die eher exotische Kategorie „Windows Safe OS Dynamic Updates“ nicht abonniert habe.
selbst mit dieser Kategorie nicht.
Ich verstehe den Zusammenhang zwischen WSUS und dem KB5034441 nicht so ganz. Im WSUS wird mir das Update auch nicht angeboten.
Jedoch das normale Januar Update „2024-01 Cumulative Update for Windows 10 Version 22H2 for x64-based Systems (KB5034122)“. Kann ich das nun gefahrlos freigeben ohne in den besagten Fehler zu laufen?
Ja, da passiert nix. Nur bei Windows 11 muss man aufpassen, weil es da kein separates Update ist, sondern im CU enthalten.
WU direkt, ohne WSUS: Bei mir wird es in W10 der WU-GUI nicht mehr angezeigt. Wenn ich die Powershell bemühe, dann aber schon …
Diese Secure-Boot Verschärfung klingt doch schon wieder nach großem Ärger. Es würde mich nicht wundern wenn da einige Linux Bootloader auf dem Index landen, natürlich „nur weil sie gefährlich sind“. Secure-Boot hat doch nix mit Sicherheit zu tun, das ist die Möglichkeit alternative Betriebssystem zu behindern. Warum sonst soll es keine Möglichkeit mehr geben diese Durchsetzung zu deaktivieren.
Auf dem eigenen PC ist der Besitzer der Entscheidung was gebootet wird und nicht Microsoft. Wann verstehen die das endlich mal in Redmond.
HKLM\SYSTEM\CurrentControlSet\Services\WdBoot\Start = 4 „Ruhe im Karton“..
Den Zusammenhang verstehe ich nicht, bitte erklären:
Wieso wirkt sich diese Windows-Einstellung auf Nicht-Windows-Bootloader aus?
https://n4r1b.com/posts/2019/11/understanding-wdboot-windows-defender-elam/
Danke. Ich gebe zu, das dort Beschriebene geht weit über mein Wissen hinaus — ich bin kein Windows-Experte.
Aber beim Überfliegen scheint es, als betreffe das ausschliesslich den Windows-Bootvorgang, und nicht Bootloader, die mit Windows überhaupt nichts zu tun haben?
Secure Boot ist alles andere als „Secure“ es ist besser nicht immer alles zu sagen.. :)
Mit Dual-Boot-System Linux/Windows (wobei Windows nur noch alle 2 Monate oder so drankommt) hat mich das natürlich sehr beschäftigt. Was ich glaube verstanden zu haben:
– Diese „Härtungen“ wirken sich nur auf Bootloader aus, die auf den fehlerhaften Microsoft-Komponenten beruhen bzw. diese verwenden. Bei Grub scheint das nicht der Fall zu sein.
– Sollte es Probleme geben, können die durch Ausschalten von Secure Boot im BIOS umgangen werden.
Falls jemand andere/aktuellere Informationen hat, bitte posten. Ich möchte nicht, dass mein System im April nicht mehr startet, weil ein Betriebssystem, das ich kaum noch verwende, darin ungefragt herumpfuscht.
Ergänzung, etwas OT: Ich verstehe den Sinn von Secure Boot ohnehin nicht, wenn es offensichtlich möglich ist, das von Betriebssystem-Ebene aus zu manipulieren. Ja, ich weiss, die Updates sind signiert usw. usw. Und es ist ja auch noch nie vorgekommen, schon gar nicht bei Microsoft, dass Keys geklaut worden sind…
Unser Sophos Endpoint Protection hat heute eine PC eines Anwenders gesperrt. Grund war „WinREUpdateInstaller.exe“, dieser wurde als Ransomware erkannt.
Jetzt lese ich diese News und kann es mir halbwegs erklären.
Heute den letzten Win10 Client ausgetauscht auf ne Windows 11 Kiste (waren nur 13 bei mir zum Glück) und kann mich in dem Fall zurücklehnen da alle schon auf 11 23h2 laufen. (konnte und wollte mich einfach nicht auf MS verlassen in dem Fall)
Bin allerdings gespannt was da im Aprill noch kommt, vermutlich wirds da auch krachen an allen Ecken und Enden
Ketzerisch kann man und frau schreiben daß dies auch eine Möglichkeit ist, die Leute auf WINDOWS 11 (23H2) zu zwingen…
„Man könne dann den Installationsfehler ignorieren – tolle Lösung – das Update bei fehlender WinRE einfach nicht zu installieren, wurde nicht implementiert. “
Das mit dem „einfach nicht installieren“ ist nicht so einfach, weil MS die Philosophie fährt, das alles was auf dem Rechner ist einen aktuellen Patchstand haben muss.
Das ist auch sinnvoll, denn man kann ja, offline, jederzeit irgendwelche Kompetenten nachinstallieren. Und die paar GB Ballast spielen keine Rolle. Wäre schön blöd wenn man dabei etwas ungepatschtes Installiert installiert und sich ein Loch ins System reist.
MS hat den Fehler gemacht, due Testabteilung zu feuern. Die haben ja nur immer gemeckert und due die zu knappen Termine platzen lassen.
Da müsste MS ansetzen.
Das was MS in letzter Zeit abliefert wird sie, trotz Quasi Monopol vom Markt feuern.
Übrigens scheint Boeing/Spirit das gleiche Problem zu haben. Angeblich werden Mitarbeiter versetzt, die Probleme melden. Unschön ist, dass auch Airbus bei Spirit bauen lässt. Sind wohl die Billigsten…
Es wäre schön, wenn die Edith wiederkäme.
Komponenten m… dieses sch Keyboard…
Zum Feierabend etwas Statistik, hab im Lansweeper gerade einen Report zusammengefrickelt… (Ja auch ich kann frickeln!) Von knapp 700 Workstations mit Win 10 22H2 oder Server 2022, das sind ja die, welche diese beiden KBs (KB5034441 und KB5034439) erfolgreich installieren sollen, haben es gerade mal drei Stück geschafft bevor diese beiden Updates auf dem WSUS scheinbar zurück gezogen wurden. Die WinRE Partitionen der meisten dieser Systeme haben mindestens 450 MB, manche sogar 1.1GB, nur eine Hand voll hat kleinere oder garkeine WinRE Partition. Auf allen WinRE Partitionen größer 500 MB sind mindestens 66 MB frei, darunter wirds deutlich knapper. Ansonsten sind in unserer Umgebung inzwischen alle Windows-Systeme (also auch ältere Serverversionen usw.) uptodate was den Januar Patchday betrifft. Bin mal gespannt, wann und wie MS dieses Problem mit der WinRE Aktualisierung löst. Scripten und rumpartitionieren werden wir da garantiert nüx, bei der Anzahl völlig illusorisch, besonders natürlich bei den Servern.
„… dass man an einem Fix für diese Probleme arbeitet und diesen irgendwann ausliefern will.“ und
„Redmond will „in Kürze“ weitere Informationen zur Verfügung stellen.“
So so, wie einfach man sich das Leben doch machen kann. Werde meinem Chef, wenn er mal wieder fragt, wann der Auftrag, der vor 10 Tagen reingekommen ist nun endlich bearbeitet ist, dann demnächst auch als Antwort liefern: „in Kürze“, oder „irgendwann“ halt. Bin mal auf das Gesicht und die Reaktion gespannt … Werde mich dann auf MS berufen.
Erste „einsichtige“ Lösungsreaktionen 10 Tage nach dem Patchday … Schön, dass sie nun aufgewacht und mit dem Kaffee trinken fertig sind und sich nun so langsam mal auf die Eier hocken, um diese auszubrüten. Solch ein Verhalten kann sich wirklich nur ein großer Monopolist leisten. Einfach nur noch gnadenlos arrogant!
wenn ihr defakto Monopolist seit dürft ihr euch solche Mätzchen leisten.
Ein Unternehmen wie Boeing oder MS wären in einem fairen Wettbewerb doch schon längst tot.
Last famous words:
„Aber es gibt doch nichts anderes“
Hatte heute einen älteren Laptop einer Kollegin auf dem Tisch, der wohl längere Zeit im Schrank lag. War noch auf Windows 10 21H2. Hat dann die Updates gezogen und ist bei KB5034441 gescheitert. Scheinbar wird es doch noch ausgeliefert.
Auch heute gegen 16:20 wird KB504441 angeboten mit bekannter Fehlermeldung.
Win10 22H2, ASUS Vivobook Pro 15 OLED M3500QA – AMD R5600H
Ich hatte bei 2 privaten älteren Laptops genau das Problem mit KB5034441, jedoch hatten beide RE-Partitionen jeweils noch genug freien Speicherplatz (angeblich nach Info der Windows-eigenen Datenträgerverwaltungs-GUI)
Ich habe dann das „Korrektur-Rezept“ von Microsoft manuell umgesetzt:
Auf beiden Laptops war das sofort problemlos hilfreich, und alle Windows-Updates wurden sofort fehlerfrei installiert.
Noch schöner:
Einer der beiden Laptops wurde im Laufe der Jahre immer lahmer, hätte ihn fast entsorgt. Aber nach Ausführung der Reparaturbefehle (zur Vergrößerung der RE-Partition um 250 GB) läuft er plötzlich flott wie am Schnürchen. :-)
„Vergrößerung der RE-Partition um 250 GB“
Da ist das ein ganz schön dickes Ding geworden.
:-))) Meinte natürlich 250 MB…
„Secure Boot-Verschärfung ab April 2024!“
Hat die eine Auswirkung auf PCs bei den Secure Boot deaktiviert wurde?
Auf meinem Haut PC ist Secure Boot deaktiviert. Grund ist meine Technisat USB TV Karte. Diese funktioniert mit dem BDA Treiber von Technisat nicht richtig. Nutzt man allerdings einen neueren Treiber für eine DTV-DVB AzureWave DVB USB Box funktioniert die TV Karte von Technisat einwandfrei unter Windows 11 in Verbindung mit Prog DVB.
Sofern Secure Boot aktiviert wurde, kann der alternative Treiber nicht mehr gestartet werden. Wahrscheinlich liegt das daran das die digitale Signatur für den Treiber nicht zum verwendeten Gerät passt.
In einem Frisch Installierten Windows
Im Dism Log ist folgendes zu sehen
[6784] ImageUnmarshallHandle: Reconstituting wim at C:\$WinREAgent\Scratch\update.wim.
[5084] Received unmount request for image with guid 4bd28b2c-3eef-41a1-aa60-b6660f47e723.
[5084] Unmount for image at C:\$WinREAgent\Scratch\Mount complete.
[6784] [0x8007000e] StateStoreGetMountedImageWimbootEntries:(1285): Für diesen Vorgang sind nicht genügend Speicherressourcen verfügbar.
Zumindest kann man sich mal ansehen ob die Partition Vorhanden ist
reagentc /info
———————————-
C:\Windows\system32>reagentc /info
Konfigurationsinformationen zur Windows-Wiederherstellungsumgebung (WinRE) und
zur Systemwiederherstellung:
WinRE-Status: Enabled
WinRE-Ort: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Startkonfigurationsdaten-ID: 788f7ebf-b91a-11ee-aaa1-cc081de30dc1
Ort des Wiederherstellungsimages:
Index des Wiederherstellungsimages: 0
Ort des benutzerdefinierten Images:
Index des benutzerdefinierten Images: 0
REAGENTC.EXE: Vorgang erfolgreich.
——————————————————————————–
C:\Windows\system32>Dism /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim /index:1
Tool zur Imageverwaltung für die Bereitstellung
Version: 10.0.19041.3636
Details für Image: „\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim“
Index: „1“
Name: „Microsoft Windows Recovery Environment (x64)“
Beschreibung: „Microsoft Windows Recovery Environment (x64)“
Größe: 2.260.193.293 Bytes
WIM startbar: Nein
Architektur: x64
Hal:
Version: 10.0.19041
Service Pack-Build: 1
Service Pack-Nummer: 0
Edition: WindowsPE
Installation: WindowsPE
Produkttyp: WinNT
Produktsuite:
Systemstamm: WINDOWS
Verzeichnisse: 3632
Dateien: 16478
Erstellt: 07.12.2019 – 14:42:41
Geändert: 05.05.2023 – 12:58:05
Sprachen:
de-DE (Standard)
Der Vorgang wurde erfolgreich beendet.
Eventuell hilft es das wiederherstellungsimage zu prüfen oder Zurückzusetzen
https://learn.microsoft.com/de-de/windows-hardware/manufacture/desktop/add-update-to-winre?view=windows-11#check-the-winre-image-version
Es Gibt aber auch Mittlerweile ein Powershell Script von MS was den Fehler angeblich behebt
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
Kann mir bitte jemand genauer erklären was es mit diesen Secure Boot Verschärfung auf sich hat? Ich bin nur ein normaler Nutzer ohne große IT Kenntnisse…. Ich hab aber noch 2 ältere Windows Laptops bei mir rumstehen die ich seit einigen Monaten bis Jahr nicht mehr upgedatet habe.
Würde das heißen wenn ich diese nicht vor 9 April 2024 update, dass meine PCs gar nicht mehr hochfahren würden oder wie ist das gemeint?
Auf meinem Uraltrechner (2017) hat das Update gerade nach 2 Wochen funktioniert, während mein neuer (2021) noch immer den Fehlercode 0x80070643 anzeigt.
Nachtrag aus einer Facebook-Gruppe, wo ein Leser den Fehler nach vielen Versuchen doch noch beheben konnte. Hier seine Erkenntnise:
Wie überall heutzutage, sind auch bei Microsoft jede Menge Dilettanten im Einsatz. Und zwar in allen Bereichen. Das fängt bei den Programmierern an, die zu blöd sind ihre Arbeit vernünftig zu testen. Dann natürlich die Luschen bei Support und Kundenservice, die nicht zeitnah und vernünftig kommunizieren können und stattdessen völlig unpraktische Lösungen veröffentlichen. Und aus Fehlern der Vergangenheit lernt man auch nicht…
Inzwischen ist ein Monat vergangen und Microsoft hat noch immer nichts getan.
Bei Systemen ohne RE läuft das Update immer noch auf und schlägt dann fehl.
Und alle anderen, darunter auch Endbenutzer wie Gisela und Herbert sollen schnell mal die Partitionsgröße manuell ändern… ein Witz!
„We are working on a resolution and will provide an update in an upcoming release.“
https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-22h2#3231msgdesc
Zuammen dann mit Windows 12? ;-)
Grüße,
Martin
Neuer Hinweis von Microsoft:
Wenn Ihr ausgeführter PC nicht über eine WinRE-Wiederherstellungspartition verfügt, benötigen Sie dieses Update nicht.
Hallo zusammen,
Rückfrage zu dem Zusammenhang mit den Secure Boot Verschärfungen im April und Oktober…
Im Beitrag oben schreibt Herr Born „dass Microsoft plant, Systeme mit unsicherem WinRE ab April 2024 am Booten zu hindern“ und bezieht sich dabei auf einen Heise Artikel. Wenn das so wäre, würde das doch tausendfach zu „kaputten“ Windows Installationen führen. Gibt es dazu belastbare Aussagen?
Ich habe das weder im verlinkten Heise Artikel noch im Microsoft Message Center so gelesen. Dort war lediglich nochmal der Hinweis auf diesen Artikel: https://support.microsoft.com/de-de/topic/kb5025885-verwalten-der-windows-start-manager-sperrungen-f%C3%BCr-secure-boot-%C3%A4nderungen-im-zusammenhang-mit-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
Diesen lese ich so, dass künftig unsichere Boot Loader am Starten gehindert werden sollen. Windows Installationen mit den Sicherheitsupdates vom 09 Mai 2023 und 11 Juli 2023 sollten hiervon aber nicht mehr betroffen sein.
In der Folgerung würde ich die These aufstellen, dass maximal eine nicht gepatchte Win RE Umgebung ab April nicht mehr gestartet werden kann, das eigentliche Windows Betriebssystem aber startfähig bleibt.
Wir wären sehr dankbar, wenn es dazu vielleicht ein paar belastbare Daten und Aussagen gäbe.
Hallo, haben Sie hierzu eine belastbare Aussage erhalten? Das würde mich nämlich auch stark interessieren.
Gibt es jetzt denn schon ein Update/fix?
Ich finde nur Artikel die darauf hinweisen das microsoft wohl daran arbeitet, aber funktionieren tut immer noch nichts…
Hallo,
immer wieder „nett“ wie Microsoft für Arbeit sorgt.
Vorab ich bin kein zertifizierter Windows Admin, bin Elektromeister.
Mein Tätigkeitsbereich ist recht breit in meinem Arbeitsumfeld. Ich frage mich wie man dieses Software Bananenprodukt als Profi / Firma gegenüber Kunden mit ruhigem Gewissen verkaufen / betreuen kann.
Aber klar „was lange hält bringt kein Geld“.
Ich könnte das mit Ü60 nicht. Ich kenne noch den Slogan
„Meine Hand für mein Produkt“ und so versuche ich ehrlich jeden Tag mein Geld zu verdienen.
Gott sei Dank haben wir nicht zu viele PCs in jeder Firma da kann ich das händisch wuppen. Nur schade um die Arbeitszeit bzw. den Arbeitsaufwand.
Den Server in der Zentrale betreut eine IT Fachfirma. Was man da teils als Begründung, für was auch immer zu hören bekommt ……
Egal auf einer Maschine (W10 22H2) habe ich jetzt das Problem gelöst.
-> vorab Acronis Backup des Systems gezogen
-> danach versucht mit der MS Anleitung die C Partition zu shrinken bekam dabei eine Fehlerausgabe
-> als alternative Lösung Acronis Disk Direktor angeworfen und die Partitionen angepasst
-> PC Neustart war ok, dann fiel mir ein, dass ich vorhin das „enable“ der WiNRE vergessen habe (ich bin doch schon alt, man könnte es auch lernen durch Schmerz nennen :-))
-> WinRE enabled
-> Neustart Bluescreen mit Meldung winload.efi fehlt
-> Acronis Backup eingespielt und Glück gehabt die Größe von WinRE ist mit 1,5GB bei dem Recovern übernommen worden
-> Neustart war ok und das kb5034441 wurde klaglos eingespielt
Mein Fazit Dank an Acronis und dem Herrn Born für seine informative Seite.
Sie hat mir vor Jahren schon sehr geholfen.
Den Rest was ich Betreff des „Arbeitbeschaffers“ sagen möchte schenk ich mir besser …..
OT zu deinem Outing: Tja, hätte ich vor über 40 Jahren bloß deinen Weg eingeschlagen und den Elektromeister gemacht, ich wäre jetzt in Rente und müsste nicht an einen Rechner gekettet über Software-Scheiß bloggen ;-). Aber der Lehrling hatte dummerweise „einen Ingenieur mit Lackschuhen und Porsche“ in einer Ziegelei vorfahren sehen. Während der Elektrolehrling schwitzend Kabel verlegte, erklärte der Ingenieur dem Meister, was Sache war. Und so ist der Jung auf die „schiefe Bahn geraten„, denn im Ingenieurstudium gab es FORTRAN als Pflichtfach und dann waren wir jung und brauchten das Geld …
Spoiler: Hab als Stift halt auch mitgekriegt, dass einige der jungen Meister den vom Vatter übernommenen Betrieb binnen weniger Jahre in den Abgrund gesteuert haben. War ein Haifischbecken, in den 70er Jahren und auch die Meister mussten wirtschaften können. So gesehen ist das mit dem Rechner gar nicht so schlecht – und wenn die Lust mal weg bleibt, kann ich ausschalten und spazieren gehen. Zudem: In der Software-Branche kannst Du mit jedem Scheiß hausieren gehen.
Man könnte natürlich jetzt etwas zu MacOS und dortigen Updates sagen wo solche Eskapaden schlicht unbekannt sind. Thema „Meine Hand für mein Produkt“. Aber auch das schenk ich mir lieber mit einem milden Lächeln…
Es gibt in der aktuellen ct (07/24) einen sehr ausführlichen Artikel zu dem SecureBoot-Desaster, dass da auf uns zurollt. Wenn das so kommt, dann werden durch das Update viele PC/Server einfach stillgelegt.
Die Admins möchte ich sehen, die bei ein paar hundert oder tausend Clients durch die Büros wetzen und jeden PC einzeln anfassen müssen, da via Fernwartung nix zu machen ist. Ich hoffe, dass zumindest grosse Firmen sich dann endlich mal trauen, Microsoft für diesen Unfug zu verklagen.
Und am Ende werden die allermeisten User einfach SecureBoot komplett abschalten – da kann sich Microsoft dann deren Pseudo-Sicherheit komplett in die Haare geelen…
Auf was muss man sich hier gefasst machen ab morgen? Wir haben hier in der Firma einige Windows Server 2022 VMs, die das Update noch nicht erhalten haben. Starten diese ab morgen nicht mehr?
Nicht mehr starten hatte ich im Hinterkopf für Sept. 2024 im Hinterkopf – bin aber nicht sicher, was im April 2024 passiert.
„no fix!“
https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-22h2#3231msgdesc
Hallo an Günter und alle KB5034441-Update-Leidgeplagten,
hier ein hoffentlich hilfreicher Lösungsnachtrag:
Da Microsoft sich ja offiziell weigert, das Update-Problem selbst zu korrgieren,
habe ich es weiter selbst analysiert…Vor allem weil meine Privat-PCs bereits die von MS beschriebene Vergrößerung der Recovery-Partition als Lösung angenommen haben, aber leider nicht mein dienstlicher PC. Wobei mir auch unser dienstlicher IT-Support nicht weiterhelfen konnte….
Mir fiel auf dem Dienst-PC auf (im Gegensatz zu meinen privaten PCs), dass dort „reagentc /enable“ fehlschlug, weil auf dem gesamten Rechner keine winre.wim (mehr) zu finden war, weder unter c:\Windows\System32\Recovery\ noch versteckt auf der (schon vergößerten) Recovery-Partition.
(Ich vermute, die gesamte Recovery-Environment bzw. winre-wim wurde bei uns dienstlich absichtlich gelöscht, nachdem bekannt wurde, dass sie ein Sicherheitsrisiko für den Windows-Rechner darstellt – aber Microsoft dazu noch keine Lösung hatte bis Anfang Januar 2024…
(Damit hatte wiederum Microsoft anscheinend nicht gerechnet, weil sich eine winre.wim standardmäßig auf jedem Windows-PC befindet… Und schon nahm das weltweite Unglück seinen Lauf…)
MEINE LÖSUNG: (sorry, nur in Englisch)
1.) I copied a fitting Winre.wim (e.g. for Windows 10 Pro/Enterprise)
into (hidden) c:\Windows\System32\Recovery\
(guideline for getting a winre.wim out of a Windows-installation-image install.wim or install.esd: https://www.winhelponline.com/blog/extract-files-windows-10-iso-dvd-install-wim/#seven_zip)
2.) Executed „reagentc /enable“, which moves that Winre.wim in the (already > 1 GB resized) recovery partition into: \Recovery\WindowsRE .
3.) Manually started Search for Windows Updates again. Then update KB5034441 dowloads and starts… (after 6 months for the first time!)
-> Installation takes a very long time (staying at 0%), but then finally succeeds.
=> Final manually „Search for Windows Updates“ brings no more outstanding updates or errors. :-)
(And under Windows update history, the successful installation is logged !)
p.s.
I wonder why this simple solution cannot just be done centrally & automatically by Microsoft for all users with a missing RE and an update-error of KB5034441, running as a (silent) update in background…
(Because no reboot is needed at the end of that solution procedure.)