[English]Das zum 9. Januar 2024 per automatischem Update (z.B. KB5034441) gegen eine BitLocker Security Feature Bypass-Schwachstelle CVE-2024-20666 in der WinRE-Partition ausgerollte Sicherheitsupdate scheitert auf vielen Systemen mit dem Installationsfehler 0x80070643. Ist irgendwie ein Desaster mit Ansage – und viele Nutzer bzw. Nutzerinnen sind nicht in der Lage, diesen Installationsfehler zu beheben. Letzte Woche hat Microsoft dann noch PowerShell-Scripte veröffentlicht, die Ursache für den Installationsfehler 0x800706431 beheben sollen. In einem Nachtrag fasse ich diesbezüglich einige Informationen zusammen.
Anzeige
Worum geht es bei CVE-2024-20666
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 2016, 2019, 2022.
Zum Beseitigen der Schwachstelle soll ein Update dafür sorgen, dass die Windows Recovery Environment (WinRE) aktualisiert wird. Microsoft hat dazu unter KB5034441 einige Hinweise veröffentlicht und rollt einen entsprechenden Patch per Windows Update auf alle Geräte aus. Im Beitrag zu CVE-2024-20666 heißt es von Microsoft, dass die Aktualisierung der WinRE-Umgebung für Windows 11 22H2 und 23H2 automatisch erfolgen soll.
Für Windows 10 21H2 – 22H2, Windows 11 21H2 und Windows Server 2022 (samt der 23H2-Edition) sind Updates für die Windows-Wiederherstellungsumgebung verfügbar, die automatisch das neueste dynamische Safe OS-Update vom laufenden Windows-Betriebssystem auf WinRE anwenden sollen. Details sind im Beitrag zu CVE-2024-20666 zu finden.
Update wirft Installationsfehler 0x80070643
Seit dem 9. Januar 2024 scheitert die automatische Installation der betreffenden Sicherheitsupdates unter Windows bei vielen Anwender mit dem Installationsfehler 0x80070643. Hier im Blog finden sich entsprechende Kommentare (siehe z.B. hier), verteilt auf die am Beitragsende verlinkten Blog-Beiträge. Als Ursache kristallisieren sich folgende Ursachen heraus:
Anzeige
- Das System verfügt nicht über eine Wiederherstellungspartition, die groß genug ist, um um dieses Update abzuschließen.
- Es ist keine WinRE-Partition auf dem System verfügbar oder diese Partition ist nicht mit den richtigen Flags aktiviert.
Ich hatte im Blog-Beitrag Windows WinRE-Update gegen CVE-2024-20666 scheitert mit Installationsfehler 0x80070643 (Jan. 2024, KB5034441) einige Hinweise gegeben, wie erfahrene Nutzer die Ursache für die Fehlermeldung
0x80070643 – ERROR_INSTALL_FAILURE
Windows Recovery Environment servicing failed.
(CBS_E_INSUFFICIENT_DISK_SPACE)
beheben könnten (Größe der WinRE-Partition anpassen und ggf. aktivieren). Auch die Kollegen von deskmodder.de arbeiten sich in diesem Beitrag am Thema ab und haben die Anleitung von Microsoft in diesem Artikel verbessert. Inzwischen hat auch Microsoft die Beschreibung im Beitrag zu CVE-2024-20666 sowie unter KB5034441 überarbeitet.
Manche Nutzer berichten auch, dass ihnen das fehlerhafte Update nicht mehr angeboten werden. Ob das Update zurückgezogen wurde, ist mir nach wie vor unklar. 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.
Microsofts PowerShell-Scripte sollen es richten
Im Laufe der Woche hat Microsoft dann PowerShell-Scripte veröffentlicht, die die Ursachen für den Installationsfehler 0x80070643 beseitigen sollen. Ein Blog-Leser hatte in diesem Kommentar auf diesen heise-Beitrag zum Thema hingewiesen. Ich hatte das Thema zum 11. Januar 2023 bei Bleeping Computer in diesem Beitrag gesehen.
Microsoft bietet nun im Supportbeitrag KB5034957: Updating the WinRE partition on deployed devices to address security vulnerabilities in CVE-2024-20666 gleich zwei PowerShell-Scripte an, um die Aktualisierung der Windows-Wiederherstellungsumgebung (WinRE) im Hinblick auf CVE-2024-20666 zu automatisieren. Es gibt dabei zwei PowerShell-Scripte:
- PatchWinREScript_2004plus.ps1 für Windows 10 Version 2004 und spätere Versionen, einschließlich Windows 11. Diese Variante wird empfohlen.
- PatchWinREScript_General.ps1 für Windows 10, Version 1909 und frühere Versionen, kann aber auf allen Versionen von Windows 10 und Windows 11 ausgeführt werden.
Laut der Beschreibung Microsofts führt das PowerShell-Script dann folgende Operationen durch:
- Mounted das vorhandene WinRE-Abbild (WINRE.WIM)
- Aktualisiert das WinRE-Image mit dem angegebenen Paket für das dynamische Betriebssystem-Update (Kompatibilitätsupdate), das im Windows Update-Katalog verfügbar ist.
- Deaktiviert das WinRE-Image
- Ist BitLocker-TPM aktiv, wird WinRE für den BitLocker-Dienst neu konfiguriert
Im kaum dokumentierten Script-Code lässt sich erkennen, dass die WinRE-Partition mit folgendem Befehl:
Dism /image:$mountDir /cleanup-image /StartComponentCleanup /ResetBase
zudem bereinigt wird. Der Support-Beitrag KB5034957 listet noch Parameter auf, die ein Administrator zur Ausführung des PowerShell-Scripts in der PS-Konsole angeben soll. Ein Aufruf könnte so aussehen:
.\PatchWinREScript_2004plus.ps1 -packagePath "\\server\share\windows10.0-kb5021043-x64_efa19d2d431c5e782a59daaf2d.cab
Rafael weist in diesem Kommentar darauf hin, dass sich das Safe OS-Paket im Windows Update Catalog für die betreffende Windows-Version herunterladen lässt.
Die Kollegen von Bleeping Computer verweisen in ihrem Artikel zudem auf einen zweiten Ansatz Fixing WinRE Update Issues for CVE-2024-20666 and KB5034441 auf der Seite action1.com, wo ebenfalls PowerShell-Scripte zur Behebung des Problems angeboten werden.
Meine 2 Cents
Dieser Ansatz wird sich für normale Nutzer nicht verwenden lassen, da er schlicht zu kompliziert ist. Speziell Nutzer im Umfeld der Consumer, bei denen die Systeme eh nicht mit Bitlocker verschlüsselt sind, werden mit den obigen Ansätzen nichts anfangen können. Hier ist es für mich absolut unverständlich, dass Microsoft ein solches Update am ersten Patchday nach Weihnachten und dem Jahreswechsel breit per Windows Update ausrollt und einer große Zahl Nutzern Installationsfehler beschert.
In meinen Augen wird Microsoft da kräftig nachbessern müssen. Der Ansatz, Nutzer in eine administrative Eingabeaufforderung zu jagen, um dort mit Partitionen oder PowerShell-Scripten zu operieren, ist schlicht ein Offenbarungseid von Redmond. Die blasen zwar die Backen mit den Möglichkeiten von Copilot auf, schaffen es aber nicht einmal, ein Update-Programm, welches die Schwachstelle zuverlässig beseitigt, bereitzustellen.
Wie ist bei euch der Status, habt ihr das Update fehlerfrei installieren können und falls ja, auf welchem Weg? Auf meinem Windows 10 2019 IoT LTSC wird das Update übrigens nach wie vor nicht angeboten.
Ä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)
Anzeige
Auf meinem Win 10 PC hat es zuerst die Fehlermeldung gegeben, dann habe ich auf wiederholen o.ä. geklickt, und dann hat es geklappt.
Mit der Veröffentlichung des Power-Shell-Scripts zeigt Microsoft die Arroganz der IT-Cracks: "Du musst dich halt damit befassen, Auto fahren muss man auch lernen."
Geht der arrogante IT-Crack dann zum Chirurgen, weil er zusammengeflickt werden muss, und erhält die Antwort "Flick dich selbst, Auto fahren muss man auch lernen", geht der IT-Crack dann aber sehr zügigen Schrittes zu Papi Rechtsstaat jammern.
So bin ich auch vorgegangen, einfach nach der Fehlermeldung auf Wiederholen bei dem entsprechenden Update (unter Windows Updates) geklickt und es wurde anstandslos heruntergeladen und fehlerfrei installiert.
Auf meinem PC habe ich mich explizit dafür entschieden auf eine
Wiederherstellungspartition gänzlich zu verzichten. Also habe ich auch keine Sicherheitslücke die zu schließen ist. Hilfreich sind also all die Infos im Netz, die es jetzt gibt, für mich überhaupt nicht.
Nein, und gleich mehrere Hindernisse!
1. Die WinRE-Partition ist zu klein.
2. Die WinRE-Partition ist nicht die letzte Partition.
3. Bitlocker ist deaktiv.
Probiert habe ich, die Windows (C:\)-Partition, dies ist die letzte Partition, etwas zu verkleinern.
Bekomme ich einfach nicht hin. Das Programm wirft einen Fehler aus, dass auf dem Laufwerk nicht,
oder nicht genug Platz wäre, was ich nicht verstehe.
Auch das Verschieben der WinRE-Partition klappt nicht. Ich verstehe es einfach nicht, wie das funktionieren soll.
Aber selbst wenn dies alles doch noch so wäre, wie MS sich das wünscht, ist da wohl immer noch die Sache mit dem deaktivierten Bitlocker.
Die ersten Windows 10 Installationen hatten die Recovery-Partition am Anfang der Platte mit einer Größe von etwas über 500mb angelegt. Da hilft m.E. nur das Deaktivieren der Recover-Umgebung (reagentc /disable), das Löschen der Recoverypartition am Anfang, dann dort eine neue leere „Dummy"-Partition erzeugen (nicht Recovery!), dann die „Hauptpartition" (meistens das was als Laufwerk c: ist) um mindestens 750mb schrumpfen, da dann eine neue Recoverypartition anlegen, Recovery wieder aktivieren (reagentc /enable) und fertig.
Auf der zu verkleinernden Partition muss natürlich genug freier Platz sein! ;-)
Und zumindest Minitool Partition Wizard behauptete das mit dem fehlenden Platz früher auch schonmal einfach so, wenn Bitlocker aktiviert war, während diskpart das trotzdem schaffte.
Die nutzlose Partition am Anfang kriegt man leider nicht einfach mit Bordmitteln mit der Hauptpartition verschmolzen, da dazwischen die nicht verschiebbare und besser nicht zu löschende MSR-Partition liegt.
Die MSR-Partition kann problemlos gelöscht und neu erstellt werden.
In vielen Fällen kann sogar komplett darauf verzichtet werden, das ist lediglich freier Speicher, der unformatiert belassen und aus dem Grund nicht vom Betriebssystem zugängig ist.
Wenn man diese Partition neu erstellen möchte, kann man das mittels diskpart (Konsole, "create partition msr size=16") machen, man muss nur darauf achten, dass die MSR zwischen die EFI- und erste primäre Partition platziert wird.
Nicht provokativ, sondern ernst gemeint: sicher?
Die MSR-Partition soll doch auf GPT-Datenträgern der Ersatz für die ungenutzten/versteckten Sektoren der MBR-Datenträger sein, wenn ich es richtig verstehe. Und da könnten dann doch Kopierschutzinfos, … drin stecken?!
Eher unwahrscheinlich, meines Wissens nutzt die Windows-Datenträgerverwaltung diesen Bereich und keine Drittsoftware. Angeblich soll sie für BitLocker nötig sein, aber hier findet man widersprüchliche Aussagen.
Man hat die MSR aus Gründen der Abwärtskompatibilität eingeführt, weil versteckte Sektoren nicht UEFI-konform sind.
Jedenfalls haben wir oft darauf verzichtet und keine Schwierigkeiten. Bei der Konvertierung eines startfähigen MBR-Laufwerks zu GUID wird sie m.W. auch nicht angelegt.
Wie gesagt: Im Zweifelsfall würde ich diese Partition nachträglich neu anlegen, die 16MB sind ja fast nix.
Mit dem deaktivierten Bitlocker kann ich so nicht bestätigen.
Zumindest bei einer recht frisch aufgesetzten Win 10 2021 IOT LTSC.
Update hat sich bei dieser Version ohne Zucken und Mucken installiert.
Die fragliche Partition auf Datenträger C (GPT) ist übrigens nur 582MB+die 100MB Partition groß.
—Grüße—
Nach einigen Fehlversuchen und dem Zurückspielen einiger Backups, habe ich es doch noch hinbekommen.
Ausgangssituation war, WinRE-Partition war am Anfang, direkt vor der EFI und die Windows-Partition war am Ende des Datenträgers.
Hier die Vorgehensweise.
https://www.camp-firefox.de/forum/thema/113551-windows-10/?postID=1243093#post1243093
Was "Nutzer im Umfeld der Consumer" betrifft:
Soweit ich gelesen habe, aktiviert MS bei neueren Home-Installationen die "device encryption", die auch auf der Technik von Bitlocker basiert.
Weiß jemand, ob die Sicherheitslücke und der "Fix" auch diese Geräte betreffen?
So weit wie ich es bisher mitbekommen habe, haben auch Homenutzer mit aktivem Bitlocker und zu kleiner Wiederherstellungspartition oder wenn diese eben nicht die letzte Partition auf dem Datenträger ist, selbige Probleme.
Ich hab privat 2 Win 10 Pro und auch da schlägt es fehl. Ich könnte jetzt diese Scripte laufen lassen, hab ich aber keine Lust drauf, die Systeme sind aus gutem Grund eh nicht verschlüsselt, das Update bringt also nichts. Wenn MS will, dass das Update erfolgreich eingespielt wird, dann sollen sie es automatisiert fixen, wie sie das auch bei der Mehrzahl der Nutzer machen müssen, die mit so Scripten nicht umgehen können.
Das werde sie nicht hinbekommen.
Da bin ich mir absolut sicher!
Wenn Du oben den Link verfolgst, wirst Du sehen, welche Klimmzüge ich machen musste.
Mit einem gefixten Update? Nie und nimmer!
Das Script lässt sich bestimmt in das Updatepaket integrieren.
So weit ich weiß gibt es bei Homeversionen genauso "Bitlocker" wie bei Pro Versionen.
Der einzige Unterschied ist das bei Homeversionen dies nur funktioniert wenn man sich mit einem MS Konto bei Windows anmeldet, da der Recovery -Schlüssel bei MS im Konto gespeichert wird.
Bei Pro Versionen kann man den auch selbst exportieren (USB oder ausdrucken).
Bei Domainsystemen wird der im Activedirectory gespeichert.
btw: Rafael weist in diesem Kommentar darauf hin, dass sich das Safe OS-Paket im Windows Update Catalog für die betreffende Windows-Version herunterladen lässt.
Wenn für eine x86 dann dieses:
Also ich blicke da auch nicht durch. Bei mir wurde das Update installiert, nachdem ich die Partition um 250 MB vergrößert hatte (zuvor war sie 800 MB groß).
Jetzt habe interessehalber mal prüfen wollen, ob die Version auch tatsächlich aktuell ist, und bin verwirrt.
reagentc /info zeigt mir als Index 0 an:
WinRE-Status: Enabled
WinRE-Ort: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Startkonfigurationsdaten-ID: 828012de-9962-11ee-a0fb-fd6c731baa33
Ort des Wiederherstellungsimages:
Index des Wiederherstellungsimages: 0
Ort des benutzerdefinierten Images:
Index des benutzerdefinierten Images: 0
Gebe ich das so auch ein, bekomme ich eine Fehlermeldung:
Dism /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim /index:0
Dabei weist MS daraufhin, dass man auf den korrekten Namen des Images und seinem Index achten soll. Aber woher soll man den wissen, wenn der angezeigte gar nicht stimmt? Sie schreiben ja nicht, dass man 1 hinzuaddieren muss:
"Use DISM to get version information about the winre.wim image located in the path returned by ReagentC in the previous step. Make sure to add the WinRE image name and image index number to the path when you run the command."
Gebe ich hingegen als Index 1 ein, also exakt der Pfad, den MS als Beispiel zeigt, bekomme ich Versionsinformationen – und die sind noch verwirrender. Denn demnach ist das WinRE eben nicht aktuell, obwohl das Update duch Windows-Update installiert wurde: Windows 10 hat hier die Build-Nummer 19045.3930 und WinRE 10.0.19041-3920! Dabei zeigt es aber an, dass es am 09.01. 2024 geändert wurde.
Name: "Microsoft Windows Recovery Environment (x64)"
Beschreibung: "Microsoft Windows Recovery Environment (x64)"
Größe: 3.399.483.372 Bytes
WIM startbar: Nein
Architektur: x64
Hal:
Version: 10.0.19041
Service Pack-Build: 3920
Service Pack-Nummer: 0
Edition: WindowsPE
Installation: WindowsPE
Produkttyp: WinNT
Produktsuite:
Systemstamm: WINDOWS
Verzeichnisse: 3905
Dateien: 18122
Erstellt: xx.xx.2019 – xx:xx:xx
Geändert: 09.01.2024 – xx:xx:xx
Sprachen:
de-DE (Standard)
Der Vorgang wurde erfolgreich beendet.
Ok, ich las gerade bei Deskmodder, dass Windows 10 22H2 intern nach wie vor 19041 ist, nach außen hin aber 19045 angezeigt wird. Aber dennoch ist ja die 3920 des WinPE kleiner als die 3930 des Systems.
Edit: In diesen Thread bei computerbase wird bei jemandem ebenfalls 3920 angezeigt:
h..ps://www.computerbase.de/forum/threads/kb5034441-windows-10-update-bricht-mit-fehlercode-0x80070643-ab.2178882/page-7
Entweder ist dann die folgende Aussage von MS falsch, oder sie haben beim Update selbst auch Mist gebaut:
"Make sure that the ServicePackBuild is greater than or equal to the UBR for the update that you added. For example, for Windows 11, version 22H2, the November security update would show 819 as the SerivcePack Build, since full version number for that update is 22621.819."
Edit 2: Der Artikel von MS ist ja vom März 2023. Möglicherweise gilt das so gar nicht mehr.
Wie kommst du auf Index 0?
Meiner Meinung nach ist bei WinRE immer der Index 1 der richtige.
Auch bei allen Windows-ISOs hat das erste Image in den WIMs immer den Index 1.
In allen Anleitungen von Microsoft steht auch immer Index 1:
learn[.]microsoft[.]com/de-de/windows-hardware/manufacture/desktop/customize-windows-re?view=windows-11
Siehe den dritten Absatz meines Posts.
reagentc /info zeigte mir Index 0 an:
Ort des Wiederherstellungsimages:
Index des Wiederherstellungsimages: 0
Ort des benutzerdefinierten Images:
Index des benutzerdefinierten Images: 0
Mir schwant aber gerade , dass damit etwas ganz anderes gemeint ist. Das bezieht sich wohl auf vorhandene Windows 10 Images, die WinRE nutzen könnte, sofern vorhanden, was sie aber eben nicht sind, weshalb es auch keine Pfade gibt.
Build 19041 ist Version 2004 (dein WinRE).
Build 19045 ist Version 22H2 (dein Windows-OS, C:).
Wäre vermutlich besser, die alte WinRE zu löschen und die aktuelle WinRE zu patchen und neu auf die Recovery-Partiiton zu schreiben.
Danke für die Aufklärung!
Ich mache da nichts, das soll MS irgendwann mit einem Update machen. Die Partition löschen bekomme ich ja hin, aber das erneute Einspielen wahrscheinlich nicht. So wie ich das heute Mittag überflogen habe, sind die Skripte von MS offenbar auch nicht einfach anzuwenden wie sie sind.
Nach dieser 4. Partition (vor dem Update mit 800 MB zu klein) gibt es aber noch eine 5., die 619 MB umfasst und vermutlich ebenfalls eine WinRE enthält. Leider weiß ich nicht, woher die kommt und ob sie schon vor meiner Inplace-Reparatur im Dezember vorhanden war.
Da das aktive WinRE auf der 4. Partition (System ist die 3.) so alt ist, müsste das die originale Wiederherstellungspartition von Dell sein.
Wenn aber das Inplace vom letzten Monat diese 5. angelegt hätte, hätte es doch die auf aktiv gesetzt, sonst würde die Anlage ja keinen Sinn ergeben. Oder hat es die 5. Partition angelegt und erst später gemerkt, dass sie ja zu klein ist und es dann sein lassen? Laut Datenträgerverwaltung hat sie ebenfalls das Attribut einer Wiederherstellungspartition.
Ist da vielleicht zusätzlich eine spezielle Version von Dell drauf? Dann wäre sie auch schon immer da gewesen.
Wenn ich wüsste, dass diese 5. unötig ist und vielleicht gar nichts Funktionierendes enthält, würde ich sie natürlich gerne löschen und die 4. mit dem aktiven WinRE dahin verschieben. Damit ich die 3. mit dem System wieder vergrößern kann. Der Laptop hat ja nur eine SSD mit 256 GB.
Natürlich hatte ich die Tage versucht herauszubekommen, ob Laptops von Dell, welche mit Windows 10 ausgeliefert wurden, zwei Wiederherstellungspartionen haben. Aber selbst die Dell-Supportforen liefern keine Antwort darauf. Manche Ratsuchenden haben sogar 3 oder gar 4 Wiederherstellungspartionen, was natürlich nicht dem Auslieferungszustand entsprechen kann. Aber ob 2 bei Dell normal sind, wird leider auch nicht beantwortet.
Ich traue mich nicht, der Partition einen Laufwerksbuchstaben zu verpassen, um mich darauf mal umzuschauen. Jemand der das gemacht hat, hat sich damit das System zerschossen, weil c: danach d: war.
Tja das ist halt die BuildNr. vom WinRE unter Windows 10 irgendwas Patchlevel Januar 2024. Microsoft hat halt nichts im Griff.
Vor allem wäre es Hilfreich irgendwo die BuildNr. dafür auch bei Microsoft in einem KB zu hinterlegen. Aber das wäre wieder zu einfach
Microsoft hätte das Pferd besser von Anfang an, von der anderen Seite aufzäumen sollen. Allein das Update über Windows Update automatisch freizugeben, war Fehler Nummer 1.
Bei vielen wird die Wiederherstellungsumgebung deaktiviert sein und selbst bei aktivierter Umgebung ist ein Ausnutzen der Lücke eher schwierig, wenn man so liest.
Da hätte es m.E. völlig ausgereicht, das Update erst einmal manuell im Update Katalog bereitzustellen. Mit dem Hinweis, welche Probleme u.U. auftreten können. Zudem mit dem Hinweis, dass User mit deaktivierter Umgebung das Update generell ignorieren können. Und schon wäre die Dimension der Rückmeldung über eine fehlerhafte Installation vermutlich deutlich geringer ausgefallen.
So wurde die Sache hingegen "durchgeprügelt" und nun steht man seit rund 5 Tagen mit irgendwelchen Maßnahmen da, die den Großteil der User eher überfordern dürften.
Natürlich gibt es bei keinem Update eine Garantie, dass es völlig problemlos durchläuft, aber sowas wie in dieser Woche, geht einfach gar nicht.
Ich hoffe, Microsoft lernt daraus. Das OS wird schließlich noch bis 10/2025 unterstützt. Bis dahin darf man schon erwarten, dass Updates auch ohne eigenes Zutun funktionieren.
Die "2 Cents" kann ich nur 100% unterschreiben.
Ich bin aktuell zufrieden, dass das Update nicht mehr automatisch gesucht, bzw. installiert wird.
"Natürlich gibt es bei keinem Update eine Garantie, dass es völlig problemlos durchläuft (…)"
Schlimm genug, dass dem so ist! Besser: Dass man sich darauf immer schon per se mal einstellen sollte/muss. Deshalb verzögere/ignoriere ich inzwischen ALLE Updates (nicht nur bei MS) um mind. 10 Tage. Außer beim Defender natürlich nicht und selbst dort fällt man ja daher immer mal wieder auf die Schnauze. So wie vor einigen Wochen mit der "Falsch-Positiv-Geschichte" beim Tor-Browser …
"Ich hoffe, Microsoft lernt daraus."
(😂 – Danke für die nette Belustigung in diesen Zeiten … ;-))
Mit dem "Hoffen" verhält es sich ähnlich wie mit dem "Glauben": Kann man in der Kirche tun. Die reale Wirklichkeit hat uns doch – wie schon mehrfach auch in der Vergangenheit bewiesen – gelehrt, dass MS i. d. R. so gut wie NICHT lernfähig ist. Besser: Vor lauter monopolistischer Großkotz-Arroganz und Überheblichkeit überhaupt kein Interesse daran hat, irgend etwas auch nur ansatzweise im Sinne seiner Kunden zu verändern, oder zu tun. So lange "die Kasse" stimmt (und die stimmt halt …) interessiert die rein gar nix! Wichtig ist, dass die (Groß-)Aktionäre die Füße und die Klappe still halten, der Börsenkurs steigt und ordentlich Dividende ausgeschüttet wird …
Ist ne "olle Kamelle", die aber halt stimmt: Persönlich MS und Windows den Rücken kehren – das würde wirklich helfen. Bin aber ehrlicherweise auch viel zu träge, um mich mit den diversen Alternativen mal wirklich auseinander zu setzen. Der Mensch ist halt Gewohnheitstier und wenn man seit der Schulzeit immer nur mit Microsoft zu tun hatte dann … Tja, dann wird man (und auch Frau) sich wohl weiterhin regelmäßig ärgern müssen. "Selbst schuld" kann ich da nur zu mir selbst sagen …
OT
Das Beste ist wohl die Ruhe zu bewahren und schauen, was sich Microsoft einfallen lässt. Man arbeitet anscheinend an einer Lösung:
https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-22h2#january-2024
dann ist bei Win11 der aktuelle Bulid (23h2) garnicht betroffen und auch der 22er nicht ?
"Affected platforms:
Client: Windows 11, version 21H2; Windows 10, version 22H2; Windows 10, version 21H2
Server: Windows Server 2022"
Kann man wohl durchaus (inzwischen?!) so lesen …
Ich hab Win 11 – 22H2 und die Updates generell über GPO 10 Tage verzögert. Bei mir schlägt das Update also erst am 19. auf. Mal sehen, was bis dahin passiert ist.
"dann ist bei Win11 der aktuelle Bulid (23h2) garnicht betroffen und auch der 22er nicht ?"
Nicht ganz richtig. Auf einer 22H2 die auf 23H2 aktualisiert wurde kann es auch zu Problemen kommen.
Laut Updateverlauf wird alles erfolgreich gemeldet.
Im Ereignisprotokoll steht die Kritische Fehlermeldung:
"Wartung der Windows RE ist fehlgeschlagen".
Wurde so ohne weiteres Zutun automatisch installiert.
https://share-your-photo.com/img/9029acb62f.jpg
Bei mir ging es, nachdem ich die Partition vergrößert habe.
Und ich bin da genau nach Mirosoft-Anleitung vorgegangen, ging völlig problemlos und fehlerfrei.
Merkwürdig finde ich dagegen die Politik von Microsoft, das das Update NICHT per WSUS ausgerollt wird.
D.H., bei Firmenkunden wird die Sicherheitslücke nicht geschlossen!
Laien sollten den Vorschlag von Microsoft nicht befolgen. Denn wenn man einen Fehler macht, kommt es unweigerlich zum Datenverlust. Laien sollten daher lieber warten bis Microsoft das selber löst. Zum glück habe ich eine Updateverzögerung von 16 Tagen eingestellt (Über die Win 10 Pro Gruppenrichtlinie), und bin davon erstmal nicht betroffen. Die Arbeit das Manuell zu beheben, werde ich als nutzer Microsoft bestimmt nicht abnehmen. Ist aber schon Traurig zu sehen, das Microsoft fehlerhafte Updates einfach so veröffentlicht und die Nutzer dann den Ärger haben damit. Fällt einem nichts mehr zu ein.
Mir fällt dazu ein: Nutzt Windows eben nicht mehr, besser wird es bei Microsoft nicht mehr.
Wenn die es nicht mal auf die Reihe bekommen ihr Betriebssystem mit fehlerfreien Updates zu versorgen und dann die Benutzer nachbessern sollen hört es bei mir auf. Von dem Verschlüsseln der Festplatten ohne Zutun und Willen des Nutzers ganz zu schweigen.
Ist dir langweilig? Was sollen wir denn benutzen?
Windows 7.
mmh und was empfiehlst du dann? Linux? Da muss man doch ständig frickeln hat man ein System abseits 08/15! Dann kann ich auch bei MS bleiben ;-P (mal ganz abegsehen davon das 80% der Software die ich nutze unter Linux gar nicht gibt und bei den restlichen 20% nicht alles wirklich ne brauchbare Alternative ist)
selbst mit FreeDos wäre man mittlerweile wahrscheinlich besser bedient
Demnächst wird bestimmt ein remote gehostetes Windows Cloud mit allen "Apps" und auch allen Daten in der Cloud und die lokalen PCs/Tablets/usw. nur noch als vernagelte Terminal Clients gefordert und gefeiert werden, dann kann irgendwas mit Partitionen lokal usw. ja gar nicht mehr passieren. Leider werden viele darauf abfahren.
So wird es definitiv sein!
Und alle haben schon längst vergessen, dass der MS-Cloud nicht zu trauen ist!
Nur zur Erinnerung, sie wurde gehackt und niemand weis, welche Backdoors MS da
untergejubelt wurde!
untergejubelt? Du meinst welche Backdoor Keys entwendet wurden ;-p Da braucht man nix unterzujubeln!
Sind halt schon schön blöd sich den NSA Masterkey klauen zu lassen!
KB5034441 wird bei mir einfach nicht mehr angeboten.
In Firmen wird verschlüsselt und wie soll die NSA dann in den Firmen Daten spionieren? So ohne Sicherheits Lücke und Sicherheits Kopie der privaten Schlüssel im online Account?
sorry Pau11, du hast das mit dem privaten Schlüssel nicht verstanden. Es ist eine Sicherung deines Recovery Key, der bei offline Zugriff auf die platte zum Einsatz kommt.
Wie oft steht die NSA bei dir im Wohnzimmer?
online, im laufenden Betrieb ist dein Bitlocker schon entsperrt. da braucht es keinen Schlüssel.
solange Recovery Key und platte getrennt aufbewahrt werden, ist dieser Teil von Bitlocker sicher vor jedem und im Vergleich besser aufgehoben, als auf dem Zettel am Schreibtisch
und wenn z.B. das TPM defekt ist wären die Daten ohne Recoverykey verloren.
So wie es sein sollte! Ist ja wertlos wenn man die verschlüsselte Daten wieder rekonstruieren kann. Für das "ohne Datenverlust" ist das Backup da nicht die Verschlüsselung!
Das Skript ist nicht neu und wurde bereits letzten Sommer empfohlen um z.B. kb5027389 bei Windows 10 22H2 zu installieren.
Nun hat das Skript mindestens drei Probleme:
1. Es setzt in der Registrierung unter HKLM\SOFTWARE\Microsoft\PushButtonReset den Wert WinREPathScriptSuccee auf 1.
Ist dieser Wert bereits vorhanden, wird mit dem Skript kein weiteres Update mehr installiert.
–> Wurde das Skript bereits für kb5027389 verwendet, kann ohne Anpassung an Registrierung oder Skript kein neueres SafeOS Update installiert werden.
2. Im Skript wird z.B. überprüft ob bei Windows 10 22H2 im SafeOS die Datei bootmenuux.dll die Version 1904X.2247 oder höher besitzt. Falls Ja wird das Update nicht installiert.
–> Wurde das Skript bereits für kb5027389 verwendet, kann ohne Anpassung am Skript kein neueres SafeOS Update installiert werden.
3. Das Skript ist nicht digital signiert.
–> Dies ist ein Armutszeugnis für Microsoft.
ich habe "zum Glück" nur noch knappe 25 Windows 10 Kisten unter meiner Fuchtel, der Rest sind schon W11 Clients (auch nicht viel besser aber in dem Zusammenhang von Vorteil)
Werde die restlichen 10er nun jetzt schon auf 11 migrieren. Hätte ich nächstes Jahr eh schon machen müssen dann wirds halt jetzt gemacht.
Hab schon zuviel Zeit mit dem Thema vergeudet da isses zeitsparender einfach neue Kisten hinzustellen und die per Autopilot betanken zu lassen
Hallo zusammen,
nachdem ich so ziemlich alle Beiträge und Tips im Netz abgearbeitet habe bin ich nun auf folgende Sache in einem englischem Forum gestossen.
Alle Tips brachten bei mir keinen Erfolg bis ich nun den folgenden ausgeführt habe.
Werde das mal bereits übersetzt mit DeepL einfügen.
@Kyhi @Brink Ich habe endlich die Lösung gefunden. Wenn Sie den Reagent-Befehl verwenden, um den Speicherort der Wiederherstellungsumgebung festzulegen, muss die Datei ReAgent.xml im Ordner "C:\Windows\System32\Recovery" entweder gelöscht oder in etwas wie ReAgentOLD.xml umbenannt werden. Offensichtlich ist reagent.exe nicht in der Lage, die vorhandene Datei "ReAgent.xml" selektiv zu bearbeiten. Wenn die Datei bereits vorhanden ist, meldet der Befehl zurück, dass der Befehl /setreimage /path erfolgreich war, obwohl dies nicht der Fall war, da der Pfad nie aktualisiert wird. Damit der Befehl erfolgreich ausgeführt werden kann, muss die gesamte Datei neu erstellt werden.
Übersetzt mit DeepL.com (kostenlose Version)
Diese XML Datei löschen brachte den Erfolg, Update lief in ein paar Sekunden durch.
Hoffe das es so manchem auch zum Erfolg der gelungenen Installation des Updates hilft.
Schönen Sonntag wünsche ich euch noch.
Habe zwei PC`s mit Windows 10 und der hier besagten Fehlermeldung.
Leider hat der von dir vorgeschlagene Lösungweg, mit Löschung der XML Datei im Recovery Ordner nicht geholfen.
Bei ca. 90 PCs tritt der Fehler bei uns auf. Etwa 20 haben es fehlerfrei installiert. Mir ist aufgefallen, dass bei allen PCs, die von den Weihnachtsurlaubern erst nach dem 10.1. wieder eingeschaltet wurden das Update nicht angeboten wird. Scheinbar wurde es zurückgezogen.
Bei meinem Gaming Laptop und dem PC meiner Eltern (beide Win10) gab es mit dem Update (zum Glück) keinerlei Fehler.
Sie hätten dann noch weniger als ich gewusst, was dann zu tun wäre.
Vielleicht lieber gleich Linux Mint 21.3: installieren. Das ist gerade veröffentlicht worden.
Scheinbar wurde es wirklich zurückgezogen, zumindest bei meinen VMs wird es auch anch manuellem Triggern nicht mehr zum Download angeboten (gestern haben die Kisten noch versucht es zu installieren)
Immerhin eine gute Nachricht heute morgen :)
Bei mir bei allen Geräten ohne Probleme.
Allerdings ist auf Allen Macrium installiert und die Re Partition bei Allen 1gb groß, die Vergrößerung ist vermutlich bei der Installation von Macrium passiert.
Für mich ist Microsoft hier in einer Bringschuld.
Die Updates müssen einfach von sich aus funktionieren.
Selbst als IT-Administrator würde ich hier so etwas nicht ausführen.
Systeme die Ordnungsgemäß nach den Empfehlungen und Anleitungen von Microsoft installiert worden, da steht Microsoft auch in der Verantwortung das ihre Patches funktionieren.
Aus meiner Sicht ist die Zuverlässigkeit Microsoft für KMU und Privat in den letzten Jahren massiv in den Keller gerauscht.
Ich bin daher echt schon einmal aus das Supportende von Windows 10 gespannt, wenn hier riesige Menge an Systemen nicht mehr geupdatet werden. Die größeren Virenausbrüche sind hier zu befürchten.
Bei mir hat das Skript "PatchWinREScript_2004plus.ps1" die Partition von 499 MB auf 570 MB erweitert, aber es funktioniert trotzdem nicht. Danach habe ich es manuell auf 1 GB erweitert und das Update wurde installiert. Weiß jemand, was man in dem Microsoft-Skript ändern muss, damit es die Partition auf 1 GB erweitert?
Lenovo 16" Laptop, neu, Win 11 Pro, 22H2, wird nebenher in Betrieb genommen…
11.01.24 Nach dem Einschalten sehe ich, dass Updates laufen. KB5034123 läuft erfolgreich durch. ABER, im Laptop steckt ein intel i7, also x64, oder? Weil dism imageinfo…
"Tool zur Imageverwaltung fr die Bereitstellung
Version: 10.0.22621.2792
Details fr Image: "\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim"
Index: "1"
Name: "Microsoft Windows Recovery Environment (amd64)"
Beschreibung: "Microsoft Windows Recover Environment (amd64)"
Gr"áe: 3.553.435.113 Bytes
WIM startbar: Nein
Architektur: x64
Hal:
Version: 10.0.22621
Service Pack-Build: 3000
Service Pack-Nummer: 0
Edition: WindowsPE
Installation: WindowsPE
Produkttyp: WinNT
Produktsuite:
Systemstamm: WINDOWS
Verzeichnisse: 9722
Dateien: 49055
Erstellt: 07.05.2022 – 06:53:32
Ge„ndert: 11.01.2024 – 22:12:20
Sprachen:
ar-SA
de-DE
en-US (Standard)
es-ES
es-MX
fr-CA
fr-FR
it-IT
nl-NL
pt-PT
Der Vorgang wurde erfolgreich beendet."
amd64 – ist das nicht die falsche Version?
Die WD SSD hat 512 GB. Ganz hinten liegt die Wiederherstellungspartition mit 1,95 GB (4). Davor das OS.
Frage an die Profis, Stichwort Over Provisioning = "hinten etwas freien Platz lassen"
https://www.samsung.com/de/support/memory-storage/welche-funktionen-hat-magician/
https://blog.westerndigital.com/why-overprovision-an-ssd/
Soweit mir bekannt, gilt dies nur für die letzte Partition vor dem freien Platz. Der kann man so Beine machen. Ist das korrekt? Weil hinter dem OS sollte nur noch freier Platz sein und nicht die Wiederherstellungspartition liegen.
Muss die Wiederherstellungspartition hinter dem OS liegen oder kann ich die auch davor anlegen?
Vorab danke für Antworten und Grüße!
Habe meine Wiederherstellungspartition mit dem MiniTool Partition Wizard 12 auf 1GB mit gerade mal 3 Klicks erhöht. Danach lieft das KB5034441 problemlos durch.
Kannst du einem Nichtprofi erklären, wie das genau geht mit diesem Tool?
Gerne…
Natürlich auf eigene Gefahr. Auf jeden Fall vorher ein Backup/systemabbild etc. erstellen.
Ich finde das Vorgehen deutlich einfacher, als der von Microsoft vorgeschlagene Weg. Andererseits ist es halt ein "fremdes" Tool, dass ins System eingreift.
Wenn du unsicher bist, schlage ich auf jeden Fall vor, die update-Korrektur von Microsoft abzuwarten.
Vorbereitung:
Wenn du nicht sicher bist, welches dein Wiederherstellungsdatenträger ist: Mit der „Windowstaste" und der Taste „R" das Feld "Ausführen" öffnen und diskmgmt.msc eingeben. Dann werden oben alle Datenträger angezeigt. Weiter unten (vermutlich unter "0" sollte der Wiederherstellungsdatenträger angezeigt werden. Auch anhand der Grösse kannst du den im MiniTool angezeigten vergleichen.
Programm laden:
Im Internet nach dem Festplattentool "MiniTool Partition Wizard Free Edition" herunterladen und installieren. Ich habs von hier: https://www.chip.de/downloads/Partition-Wizard-Free-Edition_37391095.html
Programm MiniTool starten und "möchten Sie zulassen, dass…" mit "Ja" bestätigen.
Datenträger anpassen:
Nach dem Öffnen werden automatisch alle vorhandenen Datenträger angezeigt. Zum Beispiel…
*system-reserviert (bitte hier nichts ändern!)
C: Lokaler Datenträger
*. Der Wiederherstellungsdatenträger, den wir vergrössern möchten.
Es werden noch andere angezeigt, sofern vorhanden…
Grösse anpassen/umteilen:
1. Den entsprechenden Wiederherstellungsdatenträger mit der rechten Maustaste anklicken und "erweitern" wählen.
2. Das Tool fragt nun resp. schlägt vor, von welcher Partition du den Speicherplatz übernehmen willst. Meistens und in meinem Fall vom Datenträger „C".
3. Mit dem Schieber unterhalb wählst du die Grösse, die du übertragen möchtest und mit OK bestätigen. Bei mir haben übrigens die 250MB wie von Microsoft vorgeschlagen nicht gereicht. Ich hab dann 1GB übertragen. (so wenig wie nötig übertragen, da auf C ja genügend Reserve vorhanden sein soll.)
4. Unten links "übernehmen" wählen um den Vorgang abzuschliessen oder "Rückgängig machen", wenn du doch nichts übertragen willst.
Neustart:
Danach sollte ein Neustart vorgeschlagen werden. Während dem Neustart wird angezeigt, wie der Speicherplatz verschoben wird. Das kann eine Weile dauern.
Kontrolle:
Zur Kontrolle, ob der Speicher korrekt übertragen wurde, einfach das Programm MiniTool neu starten.
Programm behalten oder wieder löschen:
Das Programm habe ich danach wieder gelöscht. Wenn du es behalten willst, würde ich via Task-Manager unter Autostart den Befehl "updatechecker.exe" vom Mi iTool deaktivieren.
Danke. Hat bestens geklappt.
Hallo, hier noch einmal eine genaue Anleitung die ich von "Deskmodder.de" entnommen und durchgeführt habe.
Mit der Anleitung ließen sich Pc und Laptop ohne Probleme updaten.
Von Microsoft gab es mittlerweile aber auch eine Info das in naher Zukunft ein Update dazu erscheint.
Liegt nun an jedem selbst ob er auf das Update wartet oder den genannten Versuch durchführt.
ANLEITUNG
Für alle die hier noch kämpfen hätte ich einen anderen/zusätzlichen Lösungsansatz – Ich stand mal vor der gleichen Herausforderung, dass die winre.win nicht aktualisiert wurde aufgrund von "zu groß geworden" bzw "zu kleine Partition"..
1) Frische winre.wim besorgen – Aktuelle und passende ISO hier von DM nehmen
https://www.winhelponline.com/blog/extract-files-windows-10-iso-dvd-install-wim/
Method 1: Using 7-Zip to extract files from Install.wim (empfehle ich mal, weil einfach)
Die Frische winre.wim ist mit ca 420 MB bedeutend kleiner als die über die Jahr upgedatete winre.wim (700-800MB sind da schon drin). Ich habe mal gelesen, dass die winre.wim nicht effektiv bereinigt wird und oft gern einfach wächst… (Halbwissen :-))
2) Checken mit reagentc /info – Da sollte dann "Enabled" die genaue Partition zu sehen sein
z.B. \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
3) Reagentc /disable
4) CMD (Admin) und DEL C:\Windows\System32\Recovery\ReAgent.xml
Oder eben über Explorer löschen
5) die frische winre.wim in Ordner C:\Windows\System32\Recovery\ kopieren
6) Reagentc /enable
-> REAGENTC.EXE: Vorgang erfolgreich.
winre.wim ist dann im Ordner verschwunden bzw nicht mehr sichtbar
ReAgent.xml wurde neu erstellt.
7) Checken wieder mit reagentc /info
8) Update starten und freuen
Ich hoffe das es bei allen klappt und ich helfen konnte.
Sehr eigenartig, denn mein 10 Jahre alter Notebook Lenovo ThinkPad Edge 531 hat keinen Installationsfehler (KB5034441) von sich gegeben, obwohl keine Wiederherstellungspartition auf dem Rechner vorhanden ist. Auf der Einleitung (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-20666) von Microsoft steht, dass die Fehlermeldung sowohl bei Rechner mit als auch ohne Wiederherstellungspartition auftauchen kann.
habe gerade mal ein altes Windows 10 installiert, danach auf Version 22H2 geupdatet und wollte probehalber mal das Script ausführen :D
Danach habe ich aber gesehen, dass das Sicherheitsupdate aber durchgelaufen ist, obwohl die Partition nur 500 MB war (genauso angelegt) eben bei der Neuinstallation.
muss man alles nicht verstehen
unter: 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
steht, dass man nur 250MB braucht ?! Ich dachte mindestens 1 GB ?!
Es ist wohl auch einfach viel Glücksache dabei, ob es durchläuft oder nicht. ^^
"muss man alles nicht verstehen" bringt die Sache gut auf den Punkt.
Ich warte weiter auf einen Patch von Microsoft. Das Update ist seit Ende letzter Woche still und würde nur bei manueller Suche "aufgeweckt".
auf meinem Lenovo Ideapad5 mit Windows 10 habe ich den Fehler von Tag 1 an, ändert sich nix kann manuell suchen so oft ich mag
Meine Frage:
https://www.paules-pc-forum.de/forum/thread/210228-update-kb5034441-l%C3%A4sst-sich-nicht-installieren-fehlermeldung-0x80070643/?pageNo=1
Meine Lösung:
https://www.paules-pc-forum.de/forum/thread/210325-windows-10-wiederherstellungspartition-neu-erstellen/
Also ich habe per MediaCreation Tool einfach die aktuelle Version drüber installiert. Dann war das gut…
Stand 11.02.2024, Win10 x64 Pro 22H2, VM unter Virtualbox:
KB 5034441 wird über WU noch immer angeboten (nach schon mehreren Fehlversuchen), liefert 0x80070643.
Der Tipp reagentc /disable | /enable mit Neustart hat es leider nicht gebracht. reagentc /info liefert Enabled.
In dieser VM (weitgehend unmanipulierte Spielwiese) hatte ich bewusst darauf verzichtet, die Wiederherstellungspartition manuell anzupassen oder das Script zu verwenden, um zu sehen, ob es eine bereinigte Updateversion gäbe. Scheint nicht so zu sein, auch nicht zurückgezogen…
Ich habe auch absichtlich nicht den Update-Ordner geleert, also alles unterlassen, was Normalanwender*innen wohl kaum tun würden.
Mal abwarten, was sich mit den Februar-Updates tut.
Stand 19.03.2024.
Zwei Patchdays (Monate) weiter und der Fehler besteht immer noch.
Man ließt aber auch gar nicht mehr zu dem Thema, bzw. Microsoft hüllt sich in schweigen.
Wird da überhaupt noch was passieren?
ALLE bisherigen Lösungen hier und anderswo bringen mich bei einem Notebook nicht weiter – es verweigert das Update KB5034441 mit der Fehlermeldung 0x80070643.
Wie hier geschrieben wird…
https://www.pcgameshardware.de/Windows-Software-277633/News/10-Update-KB5034441-Monate-nach-Release-fehlerhaft-1444817/
…verweigert MS sich regelrecht:
Dabei sind die EU und die deutschen Datenschützer doch bei jeder Gelegenheit immer am herumtröten mit Ihrer unsäglichen DSGVO.
Wo bitte bleiben hier denn diese "Verbraucherschützer"?
Ein Trauerspiel und Armutszeugnis für alle Seiten.
Die Endverbraucher sind wieder mal die Geschädigten, ohne jegliche Möglichkeit sich zu wehren.
Hallo, ich war jetzt erfolgreich:
Rezept erfolgreich 2024-05-14
1. Befehlsfenster mit Admin-Rechten öffnen
2. In CMD ausführen: C:\WINDOWS\system32>reagentc /info
Konfigurationsinformationen zur Windows-Wiederherstellungsumgebung (WinRE) und zur Systemwiederherstellung:
WinRE-Status: Enabled
WinRE-Ort: \\?\GLOBALROOT\device\harddisk2\partition3\Recovery\WindowsRE
Startkonfigurationsdaten-ID: e584dfd7-c0f2-11e9-ae40-aa6c21cadb8f
Ort des Wiederherstellungsimages:
Index des Wiederherstellungsimages: 0
Ort des benutzerdefinierten Images:
Index des benutzerdefinierten Images: 0
Status muss sein „Enabled"
3. In CMD ausführen: C:\WINDOWS\system32>reagentc /disable
4. In CMD ausführen: C:\WINDOWS\system32>reagentc /info
C:\WINDOWS\system32>reagentc /info
Konfigurationsinformationen zur Windows-Wiederherstellungsumgebung (WinRE) und zur Systemwiederherstellung:
WinRE-Status: Disabled
WinRE-Ort:
Startkonfigurationsdaten-ID: 00000000-0000-0000-0000-000000000000
Ort des Wiederherstellungsimages:
Index des Wiederherstellungsimages: 0
Ort des benutzerdefinierten Images:
Index des benutzerdefinierten Images: 0
REAGENTC.EXE: Vorgang erfolgreich.
Status ist jetzt „Disabled"
5. Erweitern der Windows RE-Partition
https://learn.microsoft.com/de-de/windows-hardware/manufacture/desktop/add-update-to-winre?view=windows-11#extend-the-windows-re-partition
Backup-Folder erstellen, z.B. C:\winre_backup
Powershell-Skript Resize_script.ps1 erstellen
6. In CMD Rechte für Powershellscripts anpassen (als Admin):
set-executionpolicy remotesigned
7. Powershell-Skript Resize_script.ps1 ausführen
8. Evtl. Rechte für Powershellscripts zurücksetzen (als Admin)
set-executionpolicy restricted
9. In CMD ausführen: C:\WINDOWS\system32>reagentc /enable
10. Windows Update starten