Patchday 09.01.2024: Warnung vor Problem 0x80070643
Hinweis und Warnung!
Der monatliche Microsoft-Patchday macht Probleme auf Windows 10 und Windows Server 2022!
(vermutlich auch bei anderen Versionen)
Ich muss jeden Monat etliche Systeme updaten und habe dies jetzt abgebrochen!
Auf etwa 70% aller Systeme gibt es bei diesem Patch ständig den Fehler 0x80070643:
Windows 10 bei Patch:
2024-01 Sicherheitsupdate für Windows 10 Version 22H2 für x64-basierte Systeme (KB5034441)
Windows Server 2022 bei Patch:
2024-01 Sicherheitsupdate für Microsoft server operating system version 21H2 für x64-basierte Systeme (KB5034439)
Auch in anderen Foren wird von dem Problem berichtet. Bei einigen soll geholfen haben, die "WinRe Partition" zu vergrößern. Was ohne großen Zeitaufwand und speziellen Tool nicht geht. Hier ein Link:
https://www.deskmodder.de/blog/2024/01/09/windows-10-kb5034441-winre-upd ...
Was wirklich gut und schnell hilft, ohne großen Zeitaufwand, weiß ich nicht.
Was also tun? Abwarten?
Wird Microsoft dies in den nächsten Tagen korrigieren?
Hier noch zwei Microsoft-Link zu dem Problem:
https://support.microsoft.com/de-de/topic/kb5034441-windows-recovery-env ...
https://support.microsoft.com/de-de/topic/kb5028997-anweisungen-zum-manu ...
P.S. Die spinnen doch, wenn man das jetzt bei allen Systemen per Hand machen soll!
Der monatliche Microsoft-Patchday macht Probleme auf Windows 10 und Windows Server 2022!
(vermutlich auch bei anderen Versionen)
Ich muss jeden Monat etliche Systeme updaten und habe dies jetzt abgebrochen!
Auf etwa 70% aller Systeme gibt es bei diesem Patch ständig den Fehler 0x80070643:
Windows 10 bei Patch:
2024-01 Sicherheitsupdate für Windows 10 Version 22H2 für x64-basierte Systeme (KB5034441)
Windows Server 2022 bei Patch:
2024-01 Sicherheitsupdate für Microsoft server operating system version 21H2 für x64-basierte Systeme (KB5034439)
Auch in anderen Foren wird von dem Problem berichtet. Bei einigen soll geholfen haben, die "WinRe Partition" zu vergrößern. Was ohne großen Zeitaufwand und speziellen Tool nicht geht. Hier ein Link:
https://www.deskmodder.de/blog/2024/01/09/windows-10-kb5034441-winre-upd ...
Was wirklich gut und schnell hilft, ohne großen Zeitaufwand, weiß ich nicht.
Was also tun? Abwarten?
Wird Microsoft dies in den nächsten Tagen korrigieren?
Hier noch zwei Microsoft-Link zu dem Problem:
https://support.microsoft.com/de-de/topic/kb5034441-windows-recovery-env ...
https://support.microsoft.com/de-de/topic/kb5028997-anweisungen-zum-manu ...
P.S. Die spinnen doch, wenn man das jetzt bei allen Systemen per Hand machen soll!
Please also mark the comments that contributed to the solution of the article
Content-ID: 92352603385
Url: https://administrator.de/contentid/92352603385
Printed on: November 4, 2024 at 20:11 o'clock
56 Comments
Latest comment
Moin...
Bescheid
Danke im Voraus
Frank
Zitat von @DerWoWusste:
Moin.
Einen WinRE- Patch braucht man nicht zwingend,vda man WinRE nicht zwingend braucht. Ich hab bedenkenlos WinRE per Kommando abgeschaltet, wenn du das brauchst, sag Bescheid.
Moin.
Einen WinRE- Patch braucht man nicht zwingend,vda man WinRE nicht zwingend braucht. Ich hab bedenkenlos WinRE per Kommando abgeschaltet, wenn du das brauchst, sag Bescheid.
Bescheid
Danke im Voraus
Frank
Zitat von @DerWoWusste:
Moin.
Einen WinRE- Patch braucht man nicht zwingend,vda man WinRE nicht zwingend braucht. Ich hab bedenkenlos WinRE per Kommando abgeschaltet, wenn du das brauchst, sag Bescheid.
Moin.
Einen WinRE- Patch braucht man nicht zwingend,vda man WinRE nicht zwingend braucht. Ich hab bedenkenlos WinRE per Kommando abgeschaltet, wenn du das brauchst, sag Bescheid.
Da ich gerade auch suchen musste:
https://technischetipps.com/betriebssysteme/so-aktivieren-oder-deaktivie ...
In unserem WSUS finde ich dazu auch nichts.
Hier unser Skript von Anfang des Jahres 23 (da war das Selbe in grün):
# Disable Windows Recovery Environment wegen Sicherheitslücke in Bitlocker
$BitlockerStatus = (Get-BitLockerVolume -MountPoint "C:").ProtectionStatus
$WinReStatus = reagentc /info | Select-String -Pattern "Status"
$LogPath = "\\server\loggingshare\Win_RE"
if ( $BitlockerStatus -like "ON" ) {
if ( $WinReStatus -match "Enabled" ) {
reagentc /disable
[void] ( New-Item -path $LogPath -name "$env:COMPUTERNAME.txt" )
} else {
if ( -Not ( Test-Path -path "$LogPath\$env:COMPUTERNAME.txt" -PathType leaf ) ) {
[void] ( New-Item -path $LogPath -name "$env:COMPUTERNAME.txt" )
}
}
}
# Befehl in Batch: for /f "delims=" %%a in ('powershell "(Get-BitLockerVolume -MountPoint "C:").ProtectionStatus" ') do if /i ON==%%a ( reagentc /disable )
Moin,
habe das Problem an meinem Arbeitsplatzrechner (hoffentlich nicht auch noch auf anderen).
@dww
Verstehe ich das richtig, dass es reichen sollte, WinRE zu deaktivieren? Ist auf meinem Rechner schon deaktiviert, trotzdem soll der Patch runtergeladen werden (was scheitert). Muss ich zusätzlich im WSUS KB5034441 ablehnen, damit das nicht mehr passiert?
Nur zum Verständnis, weil wir das Problem bei diversen Rechnern nicht haben...
Gruß
EDIT: Ich kann KB5034441 im WSUS nicht ablehnen, weil der dort gar nicht gefunden wird?!?
habe das Problem an meinem Arbeitsplatzrechner (hoffentlich nicht auch noch auf anderen).
@dww
Einen WinRE- Patch braucht man nicht zwingend, da man WinRE nicht zwingend braucht. Ich hab bedenkenlos WinRE per Kommando abgeschaltet, wenn du das brauchst, sag Bescheid.
Verstehe ich das richtig, dass es reichen sollte, WinRE zu deaktivieren? Ist auf meinem Rechner schon deaktiviert, trotzdem soll der Patch runtergeladen werden (was scheitert). Muss ich zusätzlich im WSUS KB5034441 ablehnen, damit das nicht mehr passiert?
Nur zum Verständnis, weil wir das Problem bei diversen Rechnern nicht haben...
Gruß
EDIT: Ich kann KB5034441 im WSUS nicht ablehnen, weil der dort gar nicht gefunden wird?!?
Verstehe ich das richtig, dass es reichen sollte, WinRE zu deaktivieren? Ist auf meinem Rechner schon deaktiviert, trotzdem soll der Patch runtergeladen werden (was scheitert). Muss ich zusätzlich im WSUS KB5034441 ablehnen, damit das nicht mehr passiert?
Seltsam... ich habe WinRE deaktiviert und mir wird der Patch nicht angeboten. Muss der etwa im WSUS noch bejaht werden? Das würde mich wundern. Ich schaue nach.
Auch bei uns auf 3 WSUS Servern ist das Update KB5034441 nicht verfügbar, obwohl wir in WSUS das Product schon ausgewählt haben.
Laut MSFT:
This update will automatically sync with WSUS if you configure Products and Classifications as follows:
Product: Windows 10, version 1903 and later
Classification: Updates
https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-env ...
Laut MSFT:
This update will automatically sync with WSUS if you configure Products and Classifications as follows:
Product: Windows 10, version 1903 and later
Classification: Updates
https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-env ...
Moin,
ich bekomme das:
ich bekomme das:
C:\WINDOWS\system32>reagentc /info
Konfigurationsinformationen zur Windows-Wiederherstellungsumgebung (WinRE) und
zur Systemwiederherstellung:
WinRE-Status: Disabled
WinRE-Ort:
Startkonfigurationsdaten-ID: 61b666d1-ef53-11e9-8e72-fea15293a3d0
Ort des Wiederherstellungsimages:
Index des Wiederherstellungsimages: 0
Ort des benutzerdefinierten Images:
Index des benutzerdefinierten Images: 0
REAGENTC.EXE: Vorgang erfolgreich.
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 (des MSRC) viele offene Fragen (welche schon das letzte Mal kaum jemand interessiert hat) und wieder täuscht der niedrige CVE 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.
Und wieder hinterlässt die FAQ (des MSRC) viele offene Fragen (welche schon das letzte Mal kaum jemand interessiert hat) und wieder täuscht der niedrige CVE 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.
Moin,
ein paar Lösungsansätze findet man noch hier:
https://www.deskmodder.de/blog/2024/01/09/windows-10-kb5034441-winre-upd ...
Da mir das aber alles zu blöd ist und ich die Gefahr für uns (!) recht gering einschätze, habe ich mich an den Vorschlag von @dww gehalten und wushowhide.diagcab eingesetzt:
https://techcommunity.microsoft.com/t5/windows-servicing/why-have-all-mi ...
Update auf dem betreffenden Rechner versteckt und Ruhe ist.
Gruß
ein paar Lösungsansätze findet man noch hier:
https://www.deskmodder.de/blog/2024/01/09/windows-10-kb5034441-winre-upd ...
Da mir das aber alles zu blöd ist und ich die Gefahr für uns (!) recht gering einschätze, habe ich mich an den Vorschlag von @dww gehalten und wushowhide.diagcab eingesetzt:
https://techcommunity.microsoft.com/t5/windows-servicing/why-have-all-mi ...
Update auf dem betreffenden Rechner versteckt und Ruhe ist.
Gruß
Microsoft hat im entsprechenden KB Artikel die Fehlerbehandlung gepostet. Ich denke nicht, dass es dann noch einen Hotfix geben wird. Ich hab es grade ausprobiert und war in 5 Minuten den Fehler los.
KB Artikel: https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-env ...
Fehlerbehandlung: https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manu ...
Bitte lasst den Artikel auf Englisch, sonst stimmen die Befehle in der Anleitung unten nicht. (dumme automatisierte Übersetzung)
KB Artikel: https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-env ...
Fehlerbehandlung: https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manu ...
Bitte lasst den Artikel auf Englisch, sonst stimmen die Befehle in der Anleitung unten nicht. (dumme automatisierte Übersetzung)
Moin,
@tobi983
Steht doch alles schon oben... Fehlerbehandlung nach MS-Anleitung oder Update ausblenden mit wushowhide.diagcab.
Gruß
@tobi983
Wie verhält sich der Lösungsansatz auf Windows Servern bzw. wenn Win-RE von vorne herein deaktiviert ist?
Dann gibt es ja den Pfad nicht (und auch die Partition nicht?!)
Dann gibt es ja den Pfad nicht (und auch die Partition nicht?!)
Steht doch alles schon oben... Fehlerbehandlung nach MS-Anleitung oder Update ausblenden mit wushowhide.diagcab.
Gruß
Sollte sich jemand für das netzwerkweite Ausblenden des Patches interessieren, hier der Weg über wushowhide.diagcab
Ich habe mir das nur notiert und die Funktion damals geprüft. Hier meine Notiz:
wushowhide.diagcab entpacken und dann mit get-troubleshootingpack (Powershell) auf einem betroffenen System ein Answerfile erstellen (siehe https://learn.microsoft.com/en-us/powershell/module/troubleshootingpack/ ... )
Auf allen anderen Systemen kann man es dann unattended mit invoke... laufen lassen: https://learn.microsoft.com/en-us/powershell/module/troubleshootingpack/ ...
Ich habe mir das nur notiert und die Funktion damals geprüft. Hier meine Notiz:
wushowhide.diagcab entpacken und dann mit get-troubleshootingpack (Powershell) auf einem betroffenen System ein Answerfile erstellen (siehe https://learn.microsoft.com/en-us/powershell/module/troubleshootingpack/ ... )
Auf allen anderen Systemen kann man es dann unattended mit invoke... laufen lassen: https://learn.microsoft.com/en-us/powershell/module/troubleshootingpack/ ...
Zitat von @Der-Phil:
...aber es ist einfach absurd, dass Microsoft so ein Update herausbringt, das bei einem dermaßen großen Teil der Systeme fehlschlägt.
...aber es ist einfach absurd, dass Microsoft so ein Update herausbringt, das bei einem dermaßen großen Teil der Systeme fehlschlägt.
Ja das ist wirklich unfassbar. Selbst auf relativ neu installierten Systemen mit 538MB großen RE Partition, schlägt das Update fehl. Ich lege da jedenfalls nicht händisch die Hand an. Sollen die Microsoft-Telemetrie-Server halt unter der Anzahl der Meldungen bezüglich fehlgeschlagener Updates implodieren.
Moin...
Frank
Zitat von @anteNope:
Ja das ist wirklich unfassbar. Selbst auf relativ neu installierten Systemen mit 538MB großen RE Partition, schlägt das Update fehl. Ich lege da jedenfalls nicht händisch die Hand an. Sollen die Microsoft-Telemetrie-Server halt unter der Anzahl der Meldungen bezüglich fehlgeschlagener Updates implodieren.
wenn das jemand da Lesen würdeZitat von @Der-Phil:
...aber es ist einfach absurd, dass Microsoft so ein Update herausbringt, das bei einem dermaßen großen Teil der Systeme fehlschlägt.
...aber es ist einfach absurd, dass Microsoft so ein Update herausbringt, das bei einem dermaßen großen Teil der Systeme fehlschlägt.
Ja das ist wirklich unfassbar. Selbst auf relativ neu installierten Systemen mit 538MB großen RE Partition, schlägt das Update fehl. Ich lege da jedenfalls nicht händisch die Hand an. Sollen die Microsoft-Telemetrie-Server halt unter der Anzahl der Meldungen bezüglich fehlgeschlagener Updates implodieren.
Frank
Zitat von @DerWoWusste:
Hier unser Skript von Anfang des Jahres 23 (da war das Selbe in grün):
Hier unser Skript von Anfang des Jahres 23 (da war das Selbe in grün):
# Disable Windows Recovery Environment wegen Sicherheitslücke in Bitlocker
$BitlockerStatus = (Get-BitLockerVolume -MountPoint "C:").ProtectionStatus
$WinReStatus = reagentc /info | Select-String -Pattern "Status"
$LogPath = "\\server\loggingshare\Win_RE"
if ( $BitlockerStatus -like "ON" ) {
if ( $WinReStatus -match "Enabled" ) {
reagentc /disable
[void] ( New-Item -path $LogPath -name "$env:COMPUTERNAME.txt" )
} else {
if ( -Not ( Test-Path -path "$LogPath\$env:COMPUTERNAME.txt" -PathType leaf ) ) {
[void] ( New-Item -path $LogPath -name "$env:COMPUTERNAME.txt" )
}
}
}
# Befehl in Batch: for /f "delims=" %%a in ('powershell "(Get-BitLockerVolume -MountPoint "C:").ProtectionStatus" ') do if /i ON==%%a ( reagentc /disable )
Danke für das Script zum deaktivieren von WinRe.
Das werden wir jetzt wohl endlich auf allen Clients laufen lassen.
Bei uns haben einige Clients gar keine WinRE partition, trotzdem zeigt Reagentc /info das WinRE aktiv ist. Wie kann das ohne die Partition sein?
Die Anleitung von Microsoft ist ja super, aber ich kann ja nicht auf 200 clients diese Schritte ausführen und das alles in ein Script packen, was viele unterschiedliche Ausgangssituationen berücksichtigen muss, macht man auch nicht einfach mal so schnell nebenbei. Eine manuelle Vergrößerung per gparted usw ist ebenso nicht realistisch.
Von daher bleibt ja nur das deaktivieren.
Die Anleitung von Microsoft ist ja super, aber ich kann ja nicht auf 200 clients diese Schritte ausführen und das alles in ein Script packen, was viele unterschiedliche Ausgangssituationen berücksichtigen muss, macht man auch nicht einfach mal so schnell nebenbei. Eine manuelle Vergrößerung per gparted usw ist ebenso nicht realistisch.
Ich sehe hier MS in der Pflicht. Sollen die halt das Update richtig bauen! Wenn die Partition schon vom Setup zu klein angelegt worden ist (damals mal 100-200 MB oder was?) muss halt die RE-Partition gelöscht, Systemlaufwerk verkleinert, RE-Partition neu angelegt, und neu befüllt werden.
Sehe hier wirklich keine Notwendigkeit, dass dies nicht automatisch passieren kann. Dem Endanwender zu sagen fummel in deiner RE-Partition rum, kann wirklich nicht deren Lösung sein.
MS hat nun auch ein Script veröffentlicht zum Update der WinRE Partition:
https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-p ...
Der Kollege von bleepingcomputers hat es auch schon getestet:
https://www.bleepingcomputer.com/news/microsoft/windows-10-kb5034441-sec ...
Bei mir taucht allerdings das "Problem"-Update (noch) gar nicht auf dem WSUS auf...
https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-p ...
Der Kollege von bleepingcomputers hat es auch schon getestet:
https://www.bleepingcomputer.com/news/microsoft/windows-10-kb5034441-sec ...
Bei mir taucht allerdings das "Problem"-Update (noch) gar nicht auf dem WSUS auf...
Moin,
Mahlzeit, wir haben das Problem jetzt auf diversen Rechnern
@clemens-der-vierte
Hast Du mal getestet, ob das Script funktioniert? Laut Bleeping-Test ja nicht?
Gruß
Mahlzeit, wir haben das Problem jetzt auf diversen Rechnern
@clemens-der-vierte
Hast Du mal getestet, ob das Script funktioniert? Laut Bleeping-Test ja nicht?
Bei mir taucht allerdings das "Problem"-Update (noch) gar nicht auf dem WSUS auf...
Sagte ich bereits, das ist da nicht zu sehen. Und nein, da ist kein Dualscan aktiv.Gruß
Zitat von @Coreknabe:
Moin,
Mahlzeit, wir haben das Problem jetzt auf diversen Rechnern
@clemens-der-vierte
Hast Du mal getestet, ob das Script funktioniert? Laut Bleeping-Test ja nicht?
Gruß
Moin,
Mahlzeit, wir haben das Problem jetzt auf diversen Rechnern
@clemens-der-vierte
Hast Du mal getestet, ob das Script funktioniert? Laut Bleeping-Test ja nicht?
Bei mir taucht allerdings das "Problem"-Update (noch) gar nicht auf dem WSUS auf...
Sagte ich bereits, das ist da nicht zu sehen. Und nein, da ist kein Dualscan aktiv.Gruß
Nein, ich habe es selbst noch nicht getestet.
Hallo,
der Link - das MS bei einem der nächsten Patchdays den Fehler wieder geradebügeln will - wurde ja schon eingestellt.
https://www.heise.de/news/Microsoft-liefert-Abhilfe-zur-Installation-von ...
Den Fehler mit KB5034441 kann ich mangels 2022 Server nur mit W10 bestätigen.
Auf einigen Systemen habe ich ein portables Partition-Tools verwendet
(Beispiel https://macrorit.com/download.html?mde
und damit die Wiederherstellungspartition von 512MB auf ca.800MB aufgeblasen.
Anschließend wird das Update sauber installiert.
Das Vergrößern hat evtl. den Mehrwert das künftige Updates nicht wieder an einer zu kleinen Partition scheitern.
Arbeitsaufwand pro Client ca. 5-8min inkl. Neustart (bei einigen Clients geht das in Ordnung. Wenn jemand eine größere Anzahl hat dann muss er wohl oder übel auf MS warten beim nächsten oder übernächsten Patchday)
Gruß Andreas
der Link - das MS bei einem der nächsten Patchdays den Fehler wieder geradebügeln will - wurde ja schon eingestellt.
https://www.heise.de/news/Microsoft-liefert-Abhilfe-zur-Installation-von ...
Den Fehler mit KB5034441 kann ich mangels 2022 Server nur mit W10 bestätigen.
Auf einigen Systemen habe ich ein portables Partition-Tools verwendet
(Beispiel https://macrorit.com/download.html?mde
und damit die Wiederherstellungspartition von 512MB auf ca.800MB aufgeblasen.
Anschließend wird das Update sauber installiert.
Das Vergrößern hat evtl. den Mehrwert das künftige Updates nicht wieder an einer zu kleinen Partition scheitern.
Arbeitsaufwand pro Client ca. 5-8min inkl. Neustart (bei einigen Clients geht das in Ordnung. Wenn jemand eine größere Anzahl hat dann muss er wohl oder übel auf MS warten beim nächsten oder übernächsten Patchday)
Gruß Andreas
Moin,
habe grade ein Notebook vor mir, wo Samsung Magician v8.0.1 auf einer originalen Samsung SSD KEIN Over-Provisioning und KEIN Performance Optimization mehr unterstützt.
Eventuell Folgen den vermurktem Update KB5034441?
Systeminfo:
Windows 10 Build 22H2 Home Edition
2x SSD: Samsung 850 EVO 500GB. Jeweils 46,58 GB sind noch frei.
Bin schon auf Samsung Magician v8.0.0 zurück gegangen - Gleicher Fehler.
Laut Hilfebschreibung soll es bei der 850 EVO aber unterstützt werden.
Hat jemand weitere Ideen, Hilfen? Oder ähnliches Phänomen?
Gruss Penny.
habe grade ein Notebook vor mir, wo Samsung Magician v8.0.1 auf einer originalen Samsung SSD KEIN Over-Provisioning und KEIN Performance Optimization mehr unterstützt.
Eventuell Folgen den vermurktem Update KB5034441?
Systeminfo:
Windows 10 Build 22H2 Home Edition
2x SSD: Samsung 850 EVO 500GB. Jeweils 46,58 GB sind noch frei.
Bin schon auf Samsung Magician v8.0.0 zurück gegangen - Gleicher Fehler.
Laut Hilfebschreibung soll es bei der 850 EVO aber unterstützt werden.
Hat jemand weitere Ideen, Hilfen? Oder ähnliches Phänomen?
Gruss Penny.
@anteNope
Woher kommt die Info, dass das automatisiert werden soll? Hier im Thread direkt sehe ich nichts dazu.
Gruß
Die Entwickler kündigen an, eine Lösung mit einem kommenden Update zu automatisieren.
Warum nicht gleich so? Bei den damaligen Funktionsuprades wurde eine fehlende RE-Partition auch angelegt oder ggf. vergrößert.
Warum nicht gleich so? Bei den damaligen Funktionsuprades wurde eine fehlende RE-Partition auch angelegt oder ggf. vergrößert.
Woher kommt die Info, dass das automatisiert werden soll? Hier im Thread direkt sehe ich nichts dazu.
Gruß
Zitat von @Coreknabe:
Woher kommt die Info, dass das automatisiert werden soll? Hier im Thread direkt sehe ich nichts dazu.
Woher kommt die Info, dass das automatisiert werden soll? Hier im Thread direkt sehe ich nichts dazu.
Von dort:
Zitat von @andipc:
Hallo, der Link - das MS bei einem der nächsten Patchdays den Fehler wieder geradebügeln will - wurde ja schon eingestellt.
https://www.heise.de/news/Microsoft-liefert-Abhilfe-zur-Installation-von ...
Hallo, der Link - das MS bei einem der nächsten Patchdays den Fehler wieder geradebügeln will - wurde ja schon eingestellt.
https://www.heise.de/news/Microsoft-liefert-Abhilfe-zur-Installation-von ...
Bei dem Link der aller letzte Satz.
https://www.borncity.com/blog/2024/05/02/windows-10-11-kein-fix-fr-den-i ...
Die blöden Wixxer ... unglaublich
sry für die Ausdrucksweise, aber da bleibt mir schlicht die Spucke weg!
Die blöden Wixxer ... unglaublich
sry für die Ausdrucksweise, aber da bleibt mir schlicht die Spucke weg!
Hallo,
das deaktivieren des Updates ist natürlich auch eine Möglichkeit.
Leider weiß man nie ob einem das irgendwann mal auf die Füße fällt.
Bei allen Clients mit diesem Problem habe ich bis jetzt erfolgreich eine Lösung mit
"mde-free-portable" jetzt in der Version 8.16 hinbekommen (auch VMs).
Dauert mit Änderung der Partition und Neustart keine 10 Minuten.
Bis auf ein DELL NB, hier blieb mir nichts anderes übrig als es zu deaktivieren.
Jedenfalls verdient sich MS hier keine Lorbeeren.
Erst den Fehler in Umlauf bringen und die Lösung den Usern zu überlassen ist nicht nett (einen persönlichen Kommentar verkneife ich mir mal)
Update zurückziehen und neuauflegen wäre schön gewesen (ob machbar ist eine andere Frage, aber zurückgezogen hat man schon öfter ein Update)
Gruß Andreas
das deaktivieren des Updates ist natürlich auch eine Möglichkeit.
Leider weiß man nie ob einem das irgendwann mal auf die Füße fällt.
Bei allen Clients mit diesem Problem habe ich bis jetzt erfolgreich eine Lösung mit
"mde-free-portable" jetzt in der Version 8.16 hinbekommen (auch VMs).
Dauert mit Änderung der Partition und Neustart keine 10 Minuten.
Bis auf ein DELL NB, hier blieb mir nichts anderes übrig als es zu deaktivieren.
Jedenfalls verdient sich MS hier keine Lorbeeren.
Erst den Fehler in Umlauf bringen und die Lösung den Usern zu überlassen ist nicht nett (einen persönlichen Kommentar verkneife ich mir mal)
Update zurückziehen und neuauflegen wäre schön gewesen (ob machbar ist eine andere Frage, aber zurückgezogen hat man schon öfter ein Update)
Gruß Andreas
@anteNope
Danke fürs Update!
Dank gestrigen Patchday wieder mal daran erinnert worden.
Aber... "Isch abe gar keine Auto ähhh WinRE, Signorina."
Nicht mal das wollen sie abfragen... es ist ein Trauerspiel.
Dazu passend... Sicherheit "No. 1 priority":
Aber mit Cloud ist eh alles besser. Nachdem MBAM im Extended Support ist und man einem die zukünftige Verwaltung mittels Azure empfiehlt, wird sich (neben Marianne und Herberts) so mancher weiterer Recovery Key auf den sicheren Microsoft Servern einfinden.
Apropos... ist es aktuell immer noch der Fall, dass Besitzer von "Modern devices" (und somit automatisch aktiviertem Bitlocker), teils ohne dass der "Clear Key Modus" verlassen wurde ausgesperrt werden, weil Bitlocker Recovery getriggert wurde?
Selbst schon live gesehen.... richtig pfiffig seitens Microsoft die Anwender so für Backups zu sensibilisieren!
Grüße, Martin
Danke fürs Update!
Dank gestrigen Patchday wieder mal daran erinnert worden.
Aber... "Isch abe gar keine Auto ähhh WinRE, Signorina."
Nicht mal das wollen sie abfragen... es ist ein Trauerspiel.
Resolution: Automatic resolution of this issue won't be available in a future Windows update. Manual steps are necessary to complete the installation of this update on devices which are experiencing this error.
Endbenutzer wie Marianne und Herbert müssen jetzt eben manuell patchen - keine große Sache. Dazu passend... Sicherheit "No. 1 priority":
"Security underpins every layer of the tech stack and it's our No. 1 priority," Nadella said on a conference call with analysts. "We are doubling down on this very important work, putting security above all else, before all other features and investments."
https://www.axios.com/2024/04/26/microsoft-earnings-cybersecurity-hacks
https://www.axios.com/2024/04/26/microsoft-earnings-cybersecurity-hacks
Aber mit Cloud ist eh alles besser. Nachdem MBAM im Extended Support ist und man einem die zukünftige Verwaltung mittels Azure empfiehlt, wird sich (neben Marianne und Herberts) so mancher weiterer Recovery Key auf den sicheren Microsoft Servern einfinden.
Apropos... ist es aktuell immer noch der Fall, dass Besitzer von "Modern devices" (und somit automatisch aktiviertem Bitlocker), teils ohne dass der "Clear Key Modus" verlassen wurde ausgesperrt werden, weil Bitlocker Recovery getriggert wurde?
Selbst schon live gesehen.... richtig pfiffig seitens Microsoft die Anwender so für Backups zu sensibilisieren!
Grüße, Martin
Nicht mal das wollen sie abfragen... es ist ein Trauerspiel.
Ja das Update ist echt dämlich ... Wollte das bei meinen drei eigenen Systemen machen. Aber selbst wenn man die RE auf 2 GB vergrößert, schlägt in 2 von 3 Fällen die Installation fehl.
Ein richtiges Qualitätsupdate was MS da präsentiert hat.
Ich habe es jetzt zumindest bei den Servern und kritischen Clients händisch gemacht ...
im Prinzip ein Skript geschrieben … mit folgendem Inhalt:
Dann die Updates für eine Woche aussetzen, dann fortsetzten. Update wird installiert.
Fall es dann noch immer abspackt reagentc /disable, winre.wim gegen eine "vor Update"-Version austauschen, reagentc /enable, nomma Updates, fertig.
Nervt tierisch!
im Prinzip ein Skript geschrieben … mit folgendem Inhalt:
- reagentc /disable
- diskpart RE-Partition löschen
- diskpart vorherige Partition vergrößern
- diskpart vorherige Partition um 2048 MB verkleinern
- diskpart neue Partition anlegen mit
create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
gpt attributes =0x8000000000000001
format quick fs=ntfs label="Windows RE tools"
- reagentc /enable
Dann die Updates für eine Woche aussetzen, dann fortsetzten. Update wird installiert.
Fall es dann noch immer abspackt reagentc /disable, winre.wim gegen eine "vor Update"-Version austauschen, reagentc /enable, nomma Updates, fertig.
Nervt tierisch!
Und es geht lustig weiter:
Man hat nun KB5034441 und KB5034439 zurückgezogen, den KB Würfel rollen lassen und
verteilt nun das Update unter KB5042320/KB5042322 nicht mehr wenn
In so einem Fall bleibt die WinRE also unbemerkt ungepatcht...
Aber ist ja nicht so wild... es ging ja um die CVE-2024-20666 und da braucht es ja "physical access" und Bitlocker soll ja nur bei ähhh... ok genug für heute!
Grüße, Martin
Man hat nun KB5034441 und KB5034439 zurückgezogen, den KB Würfel rollen lassen und
verteilt nun das Update unter KB5042320/KB5042322 nicht mehr wenn
- die WinRE bereits gepatcht wurde
- die Version gleich oder höher als 10.0.19041.3920 bzw. 10.0.20348.2201 ist
- keine WinRE Partition existiert (hört, hört! )
In so einem Fall bleibt die WinRE also unbemerkt ungepatcht...
Aber ist ja nicht so wild... es ging ja um die CVE-2024-20666 und da braucht es ja "physical access" und Bitlocker soll ja nur bei ähhh... ok genug für heute!
Grüße, Martin