Zum 12. März 2019 hat Microsoft den SHA-2 Support für Windows 7 SP1 und Windows Server 2008/R2 sowie WSUS 3.0 SP2 nachgerüstet. Hier einige Informationen zu diesem Thema sowie Hinweise auf erste Probleme.
Anzeige
Der Blog-Beitrag ist ein Versuch, einige lose Enden aufzugreifen und zu einer geschlossenen Darstellung zusammen zu führen. Ihr könnt fehlende Informationen ja ggf. in den Kommentaren nachtragen.
Worum geht es beim SHA-2-Support?
Microsoft hatte 2018 angekündigt, ab Mitte 2019 seine Windows-Updates nur noch mit SHA-2-Signaturen zu versehen – die Signierung mit SHA-1 entfällt dann aus Sicherheitsgründen. Ich hatte im Artikel Windows 7: Ab April 2019 wird ein 'SHA-2-Update' benötigt darüber berichtet.
Benutzer von Windows 7 SP1 (sowie der Server Pendants) und WSUS benötigen daher ab April 2019 ein spezielles Update, welches die Maschine für SHA2-Codesignaturen ertüchtigt. Ohne dieses Update können diese Maschinen zukünftig keine neuen Updates mehr verarbeiten. Im Blog-Beitrag SHA-2-Patch für Windows 7 kommt wohl im März 2019 hatte ich ein Update für diesen Monat angekündigt, musste aber Details schuldig bleiben. Mit dem 12. März 2019 hat Microsoft im Rahmen des Patchdays nun die erforderlichen Updates bereitgestellt.
Updates KB4474419 und KB4490628
Microsoft hat zum 12. März 2019 den Support-Beitrag 4472027 (2019 SHA-2 Code Signing Support requirement for Windows and WSUS) dahingehend erweitert, als das die für Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1 und Windows Server 2008 Service Pack 2 erforderlichen SHA-2-Updates genannt werden.
Anzeige
Sicherheits-Update KB4474419
Update KB4474419 (SHA-2 code signing support update for Windows Server 2008 R2 and Windows 7: March 12, 2019) rüstet die Unterstützung für die SHA-2-Signaturauswertung für die genannten Betriebssysteme nach. Das Update wird automatisch über Windows Update heruntergeladen und installiert. Weiterhin steht das Update über Windows Server Update Services (WSUS) oder für den manuellen Download per Microsoft Update Catalog bereit. Zudem wird das Update auf der Advisory-Seite ADV90009 auf den Microsoft Update Catalog verlinkt.
Servicing Stack Update KB4490628
Zudem wurde für Windows 7 SP1 und Windows Server 2008 R2 SP1 das Servicing Stack Update (SSUs) KB4490628 veröffentlicht. Dieses Update korrigiert ein Problem beim Servicing Stack, wenn dort Updates installiert werden sollen, die nur mit dem SHA-2-Hash-Algorithmus signiert wurden. Ich hatte bereits im Blog-Beitrag Patchday: Updates für Windows 7/8.1/Server (12. März 2019) auf diesen Sachverhalt hingewiesen.
Microsoft gibt an, dass dieses SSU vor der Installation der März 2019-Updates installiert werden muss, um Folgefehler und Installationsprobleme zu vermeiden.
Probleme bei diesen Updates
Bei der Nachrüstung der oben genannten Updates zur SHA-2-Ertüchtigung kann es zu diversen Fehlern und Problemen kommen.
Update KB4490628 hängt beim Neustart
Der Pferdefuß beim Update KB4490628 besteht darin, dass es bei dessen Installation zu einem bekannten Problem kommen kann, welches Microsoft hier aufführt. Nachdem Sie das SSU zusammen mit anderen Updates installiert haben, kann ein Neustart zum Abschließen der Installation erforderlich sein.
(Update hängt, Quelle: Microsoft)
Während dieses Neustarts kann es sein, dass das System bei der Meldung "Stufe 2 von 2" oder "Stufe 3 von 3" hängen bleibt. Falls dieses Problem auftritt, drücken Sie die Tastenkombination Strg+Alt+Entf, um sich an Windows anzumelden. Dieses Problem sollte nur einmal auftreten.
Update KB4490628 wird nicht angeboten
In KB-Artikel 4490628 gibt Microsoft an, dass dieses Update automatisch per Windows Update angeboten wird. In diesem Kommentar weist Blog-Leser Joe_Gerhard darauf hin, dass ihm das Update nicht angeboten werde (danke für den Hinweis). Ich habe es auf meiner Maschine kontrolliert – auch dort fehlt dieses Update bisher, während Update KB4474419 angeboten wird. Mögliche Spekulation meinerseits: Das SSU-Update wird nur auf Maschinen angeboten, wo das erforderlich ist. Bei Bedarf steht aber auch im Microsoft Update Catalog zum Download bereit.
Blog-Leser Markus B. schrieb mir gerade per E-Mail folgende Beobachtung, die ich einfach mal einstelle:
Es ging bei mir, dass ich den Win7 kumulativen zuerst installieren lies über den WSUS. Dann im Anschluss erst den Stackupdate. Bei MS steht ja, dass es dann teils Probleme gäbe. Stack braucht dann keinen Restart.
Umgekehrt würde es viel länger dauern, zuerst den Stack zu verteilen, dann den Kumulativen mit dem SHA2. Hier müsste ich ein Wartungsfenster dazwischen abwarten. Nur falls Fragen kommen.
Auch hier mein Dank an Blog-Leser Markus, dessen Ausführung sich auf die Verteilung der Updates per WSUS in Unternehmensumgebungen beziehen.
Neustart-Schleife unter 32-Bit-Windows 7 bei Update KB4474419
In diesem Kommentar zum Blog-Beitrag schreibt Blog-Leser Gregor (danke dafür), dass das Update zur SHA-2-Unterstützung zu einer Neustart-Schleife auf drei 32-Bit-Windows 7-Rechnern führte. Gregor gibt nicht an, welches Update gemeint ist. Es müsste aber Update KB4474419 sein. Hat noch je jemand ähnliche Erfahrungen gemacht?
Update KB4484071 für WSUS 3.0 SP2
Zudem hat Microsoft in diesem Support-Beitrag (siehe auch diesen Leserkommentar) das Standalone Update KB4484071 für WSUS 3.0 SP2 (SHA-2 Support for Windows Server Update Services 3.0 SP2) bereitgestellt. Dieses rüstet den SHA-2-Support für WSUS 3.0 SP2 nach.
Administratoren, die WSUS 3.0 SP2 verwenden, müssen dieses Update bis zum 18. Juni 2019 (manuell) installieren. Nun dann ist sichergestellt, dass Updates für Windows 7 und Windows Server 2008/R2 ab diesem Zeitpunkt per WSUS 3.0 SP2 weiter verteilt werden können. Voraussetzung zur manuellen Installation von Update KB4484071 ist aber, dass die folgenden Updates:
- Windows Monthly Rollup KB4489880 (oder neuer) für Windows Server 2008 SP2
- KB4489878 (oder neuer) für Windows Server 2008 R2 SP1
- und .NET 3.5 vorher installiert wurden.
Wird dies übersehen, kann es zu Fehlern bei der Installation kommen. Zudem empfiehlt Microsoft ein Backup der WSUS-Datenbank, bevor diese Updates installiert werden.
Ähnliche Artikel
Windows 7: Ab April 2019 wird ein 'SHA-2-Update' benötigt
SHA-2-Patch für Windows 7 kommt wohl im März 2019
Patchday: Updates für Windows 7/8.1/Server (12. März 2019)
Patchday Windows 10-Updates (12. März 2019)
Bekommen Windows 7-Nutzer ein SHA-2-Update Problem?
Anzeige
Mir wurden für Windows 7 Professionel heute Vormittag nur angeboten (KB4489878) KB890830 (KB4474419) und in dieser Reihenfolge installiert. Neustart erforderlich, keinerlei Probleme dabei.
Kurz danach wurde mir dann auch Update KB4490628 angeboten. Ich habe es installiert, und es war kein Neustart erforderlich. Aber warum wurde es mir nach und nicht vor den anderen Updates angeboten? – Herunterfahren und ausschalten, jetzt gerade hochfahren wiederum ohne Probleme.
Eins ist trotzdem komisch: Während die vier Updates im Windows Updateverlauf als "erfolgreich" angezeigt werden, gibt es keinerlei Informationseinträge im Wartungscenter unter Zuverlässigkeitsüberwachung. Dort sind alle Updates bislang immer angezeigt worden!
Bei mir war die Reihenfolge auch so. Es wurden auch alle im Wartungscenter unter Zuverlässigkeitsverlauf angezeigt.
Bzgl. Reihenfolge der Installation. – Meine These: SSU KB4490628 „korrigiert ein Problem beim Servicing Stack, wenn dort Updates installiert werden sollen, die nur mit dem SHA-2-Hash-Algorithmus signiert wurden." – Da der SHA-2-Support erst mit KB4474419 für Windows 7 bereitgestellt wird, macht es wenig Sinn, KB4490628 auf Win 7-Geräte ohne SHA-2-Support (= ohne KB4474419) zu installieren. – Folglich: Erst wenn die SHA-2-Unterstützung für Windows 7 mit der erfolgreichen Installation von KB4474419 bereitsteht, wird KB4490628 von Windows Update angeboten.
Ich habe gerade meinen 2008 R2 Testserver gepatcht. Mein Skript regelt automatisch, dass Servicing Stack Updates immer zuerst installiert werden. Daraus folgt diese Installationsreihenfolge über WSUS:
KB4490628
KB4489885
KB4489873
KB4474419
Lief alles problemlos, insofern ist die Reihenfolge also vermutlich egal. SHA2 wird ja momentan nur vorbereitet, erst ab Juli sind alle Updates nur noch mit SHA2 signiert.
Danke für die Ergänzung.
Erstaunlich, Windows 7 findet das SSU auch übern WSUS erst nach Installation von KB4474419. Der 2008 R2 installiert das sofort. Nun ja, wer weiß. Wird schon seinen Grund haben.
Bei meinem Win 7 ist der Patchday durch. Probleme oder Fehler während oder nach der Installation konnte ich nicht feststellen. Reihenfolge:
KB4489885
KB4489873
KB4474419 (via Windows Update)
KB4490628 (via Windows Update)
KB4490628 wurde (gestern) unmittelbar nach Installation von KB4474419 angezeigt – ohne erneute Updatesuche. Die Information war offensichtlich schon in Windows Update hinterlegt.
…bei mir sind diese beiden installiert worden:
KB4474419 und KB4490628
"bisher" keine probleme – aber mal abwarten ;-)
Ich kopiere mal meinen Kommentar zum Blog-Beitrag "Patchday: Updates für Windows 7/8.1/Server (12. März 2019)" hierher und füge noch eine Ergänzung hinzu:
Ganz toll :-|
Die Installation von KB4474419 schlägt bei mir unter Win 7 Prof x64 wiederholt mit Fehler 0x80004005 fehl … Installation läuft zunächst fehlerfrei durch, dann ist ein Neustart erforderlich, der laut MS eigentlich nicht erforderlich sein sollte … bei 83% beim Konfigurieren der Updates kommt dann die Fehlermeldung und die Änderungen werden wieder rückgängig gemacht …
Die anderen Updates + Servicing Stack Update liefen problemlos durch … was soll der Quatsch? :-|
… "Einmal mit Profis arbeiten!" …
Ergänzung:
Der Download via MS Update Catalog mit anschließender manueller Installation des Updates führt ebenfalls zu dem vorgenannten Fehler. Ohne Worte! :-|
Hier ist genau das Gleiche passiert(Win7 Pro 64bit). :-(
Versuche morgen(jetzt heute ;-) ) auf den Wiederherstellungspunkt vorm Märzupdate zu wechseln und KB4490628 vor allem anderen zu installieren. Irgendwo im Netz stand, allein installieren und mind. 30min warten, dann Neustart und dann die Märzupdates einspielen. KB4490628 wurde, obwohl wichtig, erst nach dem Fehlschlag von KB4474419 angeboten und erfolgreich installiert, leider war es da wohl schon zu spät! Danke Microsoft! 6, setzten!
Hat denn evtl. jemand GESICHERTE Infos darüber, ob das KB4490628 nun eigentlich hätte ZUVOR manuell installiert werden müssen, oder ob man auf der sicheren Seite ist, wenn die Updates nun so installiert wurden, wie von Windows Update vorgegeben (also zuerst KB4474419 und KB4489878 und erst danach das KB4490628)?
Es gibt keine gesicherten Infos, mach nur KB4498787 drauf, der Rest kann warten, und immer schön ein Backup erstellen bevor man Updates installiert.
Du meintest sicher KB4489878.
was, ohne wochte, kann denn ms für dein verkorkstes "System"?
erst zunächst mal eigene Nase, immer, gelle?"
=> Hier null komma null probs mit den updates. comisch…
:P
Danke für die hilfreiche Antwort und krieche bitte wieder unter deinen Stein zurück!
bidde – oh wurst.
"selig" die arg humorbefreiten kleingeister ist uebrigens woanders.
warst gar nicht gemeint (Bezug u.a. im ersten Satz). hatter nich bemerkt. (richtig) lesen soll schomma geholfen haben…
:P
Sollte jetzt aber gut sein – dein initialer Beitrag hatte zur Sachlage an sich wenig beizutragen. Wäre nett, wenn Du künftig auf solche Beiträge verzichtest – danke.
Per Kristallkugeldiagnose eine Windows-Installation und die Fachkenntnisse unbekannter Personen beurteilen zu wollen, zeugt wirklich von wahrhaftem Expertenwissen das die Welt nicht braucht!
… und nein, für solche Art von Humor habe ich kein Verständnis … dafür kosten solche Fehler einfach zuviel Zeit!
In dieser Phase werden wohl Dateien ersetzt, die im normalen Windows Betrieb verwendet werden und daher nicht direkt aktualisiert werden können.
Diese Probleme werden meist durch Drittanbieterprogramme verursacht. Wir hatten das Problem vor einiger Zeit mit ArcServer Backup (oder besser dessen Agent for open Files) unter Server 2008R2. Der startete schon vorher und blockierte den Zugriff.
Die Fehlersuche ist aber recht mühselig. Windows-Update-Logs wälzen – googlen – probieren. Am besten mit Backup.
Als ersten Anhaltspunkt könntest du über msconfig alle Nicht-Microsoft Dienste deaktivieren, neu starten, Updates installieren, neu starten, Dienste wieder aktivieren, neu starten.
Der Fehlercode 0x80004005 ist natürlich doof – steht für E_FAIL = Unbekannter Fehler.
Lässt sich an den log-Dateien noch erkennen, wo der Absturz erfolgt? Das System ist unmodifiziert (keine angepasste Installation) und die diversen Tools und Drittanbieter AV-Lösungen lassen sich als Störer ausschließen?
Habe das System mittels eines aktuellen Sicherungsabbildes wieder auf den Zustand vor den März-Updates zurückgesetzt und das KB4474419 ausgeblendet … nach Installation des Rollup-Patches wurde mir dann das SSU angeboten und problemlos installiert.
Im WU Log kann ich jetzt natürlich nicht mehr nach der Fehlerursache suchen, aber es spricht Bände, dass MS es offensichtlich nicht geregelt bekommt beim Systemstart zuverlässig alle wichtigen Komponenten zu aktualisieren. Es ist tatsächlich das erste Mal, dass ich eine Fehlermeldung im Nachgang einer erfolgreichen Updateinstallation angezeigt bekommen habe … im Gegenteil, meistens sind auf meinem System selbst Updates fehlerfrei durchgelaufen die bei anderen zu massiven Problemen geführt haben.
Virenscanner ist MSE und Optimierungstools benutze ich nicht. Es handelt sich um ein AMD System mit FX6300. Als Nicht-MS-Dienste beim Systemstart kommen maximal Sandboxie und O&O DiskImage in Frage, was aber aufgrund der Tatsache, dass alle anderen Updates bislang problemlos durchliefen m.E. als Fehlerursache eher unwahrscheinlich erscheint.
Konnest du inzwischen eine Lösung finden? Laut MS Forum hängt es wohl mit dem Bootloader zusammen, vor allem bei mehreren betriebssystemen. Bei uns auf dem Rechner ist dies aber nicht der Fall, dennoch spuckt Windows ebenso diesen Fehler aus.
https://answers.microsoft.com/en-us/windows/forum/all/kb4474419-will-not-install/658900bc-3103-4a0e-a9ed-08c5c2d31e76
Bei mir stehen beide updates unter den ausgeblendeten.KB4474419 und KB4490628.
Win 7 64 bit.
Da ich unter W7 x64 nur Security-Only-Updates installiere und keine Rollups, anbei mein Vorgehen:
kb4489885 (reboot) kb4489873 cum.ie (reboot) kb890830+kb4474419 (reboot) kb4490628 (keine reboot-aufforderung)
Hatte mit diesem Vorgehen keinerlei, der im Artikel genannten Probleme.
Vielen Dank für diesen guten und wertvollen Beitrag.
Ich hatte mich sehr gewundert, dass nach Installation der Updates und Hochfahren des Rechners noch ein weiteres als wichtig gekennzeichnes Update angeboten wurde.
Auffällig war auch, dass das Herunterladen und Einspielen der Patches diesmal extrem lange gedauert hat.
Habe gestern die 4 Windows 7 x64 Updates Installiert. Probleme gab es keine. KB4490628 wurde erst nach dem Installieren von KB4474419, KB4489873 und KB4489885 angeboten. (Nach Neustart)
KB4490628 Servicing Stack Update for Windows 7 for x64
KB4474419 Security Update for Windows 7 for x64-based (SHA2 Support)
KB4489873 Cumulative Security Update for Internet Explorer 11
KB4489885 Security Only Quality Update for Windows 7 for x64
Win 7 Home Premium 64 Bit SP1
Sehr seltsam:
Angeboten per Windows Update wurden:
KB4489878
KB4474419
KB890830
Nachdem ich alle zur Installation angewählt hatte, dauerte es außergewöhnlich lange (Sandy beschrieb oben Ähnliches), bis sie heruntergeladen und "installiert" wurden.
Die Installation 1 von 3 schien nicht weiterzugehen, bis ich plötzlich diese Meldung erhielt:
"Die Updates wurden installiert
Erfolgreich: 1 Update
NICHT BENÖTIGT: 2 Updates
2 wichtige Updates ausgewählt"
Der Updateverlauf zeigte mir, dass lediglich das KB890830 installiert worden war.
Warum?
Ich werde nun neu starten und es nochmals mit den beiden anderen Updates probieren.
Weshalb aber werden diese als "nicht benötigt" klassifiziert?
Hallo, ich hatte keine Probleme mit der installation der Updates auf meinem AMD System mit Windows 7 Ultimate 64-Bit SP-1. Das daß Stack Update erst nach installation von Update KB4474419 angeboten wird scheint so gewollt zu sein. Erst nach installation des Updates KB4474419, wurde mir das Stack Update KB4490628 angeboten über Windows Update. Probleme bei der Installation dieser Updates hatte ich allerdings wie gesagt nicht.
Wichtig beim Update KB4484071 für WSUS 3.0 SP2:
Hier sollten unbedingt die Voraussetzungen berücksichtigt werden:
KB4489878 und .NET 3.5 !
Ich habe vor der Installation von KB4484071 .NET 3.5 nicht installiert. Es kam eine erfolgreich Installationsbestätigung jedoch funktionierte der WSUS 3.2 nicht mehr ordnungsgemäß. Es traten folgende Fehler in der Ereignisanzeige auf:
Event ID 10032: "The server is failing to download some updates." und
Event ID 364: "Content file download failed. Reason: File cert verification failure. ……"
Eine nachträgliche Installation von .NET 3.5 brachte vorerst keinen Erfolg, erst eine erneute Installation von KB4484071 brachte den WSUS wieder auf Spur.
Der Tip mit dem .NET 3.5 und die erneute Installation war mir nach Stunden der Fehlersuche eine große Hilfe!
Mir wurden unter Windows 7 Pro 64 Bit zuerst diese 3 angeboten:
KB4489878
KB4474419
KB890830
Download wie hier mehrfach beschrieben etwas länger als sonst, hält sich längere Zeit bei einem bestimmten Prozentsatz auf, lief dann aber weiter. Nach Neustart und den üblichen Wartereien alle 3 Updates als erfolgreich angezeigt und direkt danach das KB4490628 angeboten bekommen. Das installierte sich schnell und ohne Neustart. Aus diesem Zustand heraus schreibe ich das hier gerade.
Ja Sackgasse….. das letzte KB4474419 wurde nicht installiert und immer wieder rückgängig gemacht. kein Wiederherstellungspunkt da als Familienvater keine Zeit für so ein Scheiss. Man sollte für so ein teures betriebssystem schon erwarten können das die Updates in richtiger reihenfolge und fehlerfrei installiert werden. Ich hasse MS, die sollten wenigstens einen patch rausbringen für dieses verbockte Update. Ist mir scheissegal dann halt ohne den kack KB4474419 ….boa hasse ich MS. Teuer und scheisse.
Kann ich absolut nachvollziehen … sowas nervt ohne Ende.
Handelt es sich um ein AMD oder Intel System? Windows 7 32-Bit oder 64-Bit? Virenscanner MSE oder eine Drittanbietersoftware?
Versuche Gemeinsamkeiten bzw. Unterschiede zu finden, um die Fehlerursache eingrenzen zu können.
"kein Wiederherstellungspunkt da als Familienvater keine Zeit für so ein Scheiss."
Selten so einen Blödsinn gelesen – und damit meine ich nicht nur Ihr schlechtes Deutsch!
Einen Wiederherstellungspunkt manuell anzulegen, dauert ca. ZEHN SEKUNDEN! Das mache ich manuell vor JEDER Installation! Außerdem legt Windows normalerweise auch von selbst (im Hintergrund) regelmäßig einen neuen Wiederherstellungspunkt an; das nennt sich dann "geplanter Prüfpunkt".
Das wäre also auch für einen schwer beschäftigten "Familienvater" Nullkommanull Arbeit…
Ein Wiederherstellungspunkt ist nach ZEHN SEKUNDEN angelegt – und falls Sie das mit einem Systemabbild (=Backup) verwechseln, haben Sie sogar noch weniger Ahnung…
Mündiger Anwender zu sein kostet tatsächlich Zeit! Das setzt nämlich tiefere Kenntnisse des Betriebssystems voraus, die man bei einem normalen Anwender keineswegs voraussetzen darf: Heim-PCs werden gekauft, um damit ohne viel Hintergrundwissen bestimmte Anwendungen auszuführen – und nicht, um das Betriebssystem hätscheln zu müssen wie ein Tamagotchi.
Man sollte also erwarten dürfen, dass auf „automatisch" belassene Vorgänge auch reibungslos ablaufen. Aber das klappt ja nicht mal beim total eigenmächtig agierenden Windows 10.
Kein Wunder, dass der private PC-Markt weggebrochen ist und sich die Familienväter lieber mit einem Smartphone abmühen. Sobald das Zicken macht, ersetzen sie es einfach durch das Nachfolgemodell…
Die Ausdrucksweise kann man natürlich bemängeln, muss man aber nicht … und ich kann den Frust, wie gesagt, absolut nachvollziehen, da auch auf meinem System genau dieses Problem auftritt.
So wie ich das sehe, ist das Rücksetzen des Systems nach der fehlgeschlagenen Updateinstallation in diesem Fall nicht notwendig, da die Änderungen automatisch wieder rückgängig gemacht wurden. Bis es eine Lösung gibt muss nur das Update ausgeblendet werden.
… und MS ist hier ganz klar in der Verantwortung einen fehlerfreien Updateprozess zu gewährleisten … man kann nicht einfach davon ausgehen, dass normale Anwender das Fachwissen und die Zeit haben sich mit solchen Detailfragen zu beschäftigen. Zum Glück lässt sich bei Windows 7 ein Problemupdate einfach ausblenden … unter Windows 10 wäre mein System unter gleichen Voraussetzungen jetzt nicht mehr nutzbar.
Was jetzt aber einfach wichtig ist, ist Gemeinsamkeiten und Unterschiede der betroffenen Systeme zu analysieren, um überhaupt erst einmal die Fehlerursache eingrenzen zu können.
Volko …Du scheinst der normalste hier zu sein und mich und meinen Frust zu verstehen. Also habe Systemwiederherstwellungspunkte gefunden die vom System selbst angelegt wurden. Brachte aber auch nichts das System zurückzusetzen. Der will einfach die KB4474419 nicht installieren. Grob: Mein System Win7 pro 64, i5 3200 Mhz 4570, MSI board 16GB. Arbeitsspeicher. Sollte ich eine Lösung finden melde ich mich nochmal. Wenn ich gar nicht weiterkomme bleibt mir nichts anderes übrig als auf W10 Pro 64 umzusteigen. Und an die Kluglaberer: Ich hab einfach keine Zeit ganze Vormittage oder Nachmittage zu verbringen um MicroSoft seine Updatefehler zu beseitigen! Sollte nicht Aufgabe des Kunden sein. Eure Argumente könnt ihr 100% alle in den Kübel klopfen, für das Geld sollte ein teures Betriebssystem + Updates fehlerfrei funktionieren und fertig. AMEN. Es gibt genug die wollen einfach nur klug labern und andere runtermachen. Manche suchen förmlich danach andere zu runterzumachen… Rechtschreibfehler zu finden usw. … wie krank. Aber sich darüber aufzuregen bringt nichts die Foren sind voll mit diesen Leuten. Wer Rechtschreibfehler findet kann diese gerne behalten oder bei eBay weiterverkaufen c[_] Prost
Bitte an Alle den Ball flach zu halten. Die Kommentarfunktion hier im Blog soll eigentlich dazu dienen, Hilfestellung zu geben – oder über ein Thema zu diskutieren, wenn nach Meinungen gefragt wird. Klappt i.d.R. auch ganz gut. Sich gegenseitig auf Nebenkriegsschauplätzen nieder zu machen, bringt niemandem etwas – auch wenn der Frust hoch kocht. Danke für euer Verständnis.
Hans … Blende das Update mittels Systemsteuerung -> Windows Update -> Wichtige Updates -> Rechtsklick auf das Update einfach aus … dann hast Du Ruhe und kannst wieder normal arbeiten … eine Wiederherstellung ist nicht erforderlich.
Gut, die Plattform (bei Dir Intel, bei mir AMD) scheidet als Fehlerursache schon einmal aus …
Danke für die Info
Danke Volko, zurücksetzen
auf Wiederherstellungspunkte und das deinstallieren von Avast Antivirus hat auch nichts gebracht. Ja mir bleibt nichts anderes mehr übrig als rechtsklick auf KB4474419 und ausschalten damit ich weiterarbeiten kann ohne den Endlos Update Horror.
Frage an die Leute mit Installationsproblemen bei KB4474419, habt ihr eine manuelle Installation probiert, also nicht über Windows-Update?
Bei mir kommt es öfters vor dass ich für das kumulative Update zwei Anläufe brauche, beim ersten Anlauf bricht die Installation bei plus 90% ab und wird rückgängig gemacht, dann kommt der zweite Anlauf und es funktioniert.
Manuelle Installation habe ich auch versucht, ohne Erfolg.
Interessanterweise kommt die Fehlermeldung mal bei 67%, dann wieder erst bei 83%. Davon ausgehend, dass die Aktualisierung immer gleich verläuft scheint wohl irgendein währenddessen vom System gestarteter Prozess dazwischen zu funken … wenn man nur wüsste welcher?!
Zustandsmeldung bei mir:
Bei 3 Win 7 prof 64 bit Pc das gemacht und bisher keine Probleme. 2 PC kommen noch, das aber erst am Wochenende, davon einer 32bit Home.
Die Meldung hilft zwar keinen der Probleme hat. Aber bisher funtioniert es. Bei einem PC hat das SHA-Update ganz schön gedauert (mind. ca. 40 Minuten). Danach war es aber in Ordnung.
Danke für die Zusammenfassung Herr Born!
So ganz versteh ich das immer noch nicht. Habe gestern eine Abteilung in der Reihenfolge erst servicing stack dann der Rest upgedated, ohne Probleme.
Heute stelle ich auf einer weiteren (identischen zu der von vorgestern) Testmaschine fest, dass so wie hier berichtet, das SSU nun nach den normalen Updates angeboten wird.
Also die nächste Abteilung in der anderen Reihenfolge upgedated auch wieder ohne Probleme, kein Neustart nach dem SSU.
Dabei meine ich, mich zu erinnern, dass SSUs immer zuerst gemacht werden müssen…
Egal, wenigstens läuft alles ohne Probleme.
Ich denke, die These von Ralf Lindemann trifft es in diesem Fall. Mir wurde das Servicing Stack Update KB4490628 erst heute angeboten, mehrere Tage nachdem ich das SHA-2-Update installieren ließ.
Es gibt einen MS Forenthread mit etwas ähnlichem. Keine Ahnung, ob das in die gleiche Richtung geht.
Auf allen Servern mit 2008/R2 funktioniert NETDOM.EXE nach der Installation der SHA-2 Updates nicht mehr.
Beliebige übergebene Parameter liefern "Der Befehl wurde nicht ordnungsgemäß ausgeführt."
Mit dem KB4493448 (2019-04 Sicherheitsqualitätsrollup) wurde eine wieder funktionierende NEDOM.EXE ausgeliefert.
Danke, ich habe das Thema mal im Artikel Windows Server 2008/R2: Update KB4493448 fixt Netdom aufbereitet.
So wie ich das aus den bisherigen Kommentaren lese ist es scheinbar relativ egal in welcher Reihenfolge die Updates installiert werden.
Von daher sollte mit KB4489878 -> KB4474419 -> KB4490628 ja nix schiefgehen, wenn das SSU sowieso erst zum Schluss angeboten wird. Oder sollte man bei manueller Installation direkt das SSU als erstes installieren?
SSU als erstes ist nicht verkehrt, sehr wahrscheinlich sogar richtig.
Wurde zwar schon mehrfach angedeutet, aber bisher nicht so explizit.
Wir haben einen WSUS und u.a. mehrere Server 2008R2 im Einsatz. Wir installieren nur Security Only Updates.
Auf dem WSUS wurden gestern die entsprechenden Updates freigegeben, auch das SSU usw. lag am WSUS an zur Freigabe.
Heute standen dann im ersten Schritt an den entsprechenden Servern 4 Updates bereit zu Installation: KB4489885 (Sicherheitsqualitäts…), KB4474419 (Sicherheitsupdate), KB4489873 (IE) und KB4486459. (Das letzte ist eins ausm Februar, da hatte ich eigentlich schon alle installiert, das tauchte dann Ende Februar auf einmal auf, aber egal)
Kein Servicing Stack Update KB4490628.
Nach der Installation und anschließendem Neustart taucht, bei erneuter Anmeldung, das SSU auf. Und lässt sich dann einfach installieren, nach wenigen Minuten ist er auch damit fertig, ohne nochmaliges neustarten.
Bisher läuft alles wie gewohnt. Da das SSU ja alleine installiert werden soll, macht diese automatische Vorgehensweise durchaus Sinn. Das gute ist man muss nichts weiter beachten, wenn man nicht eingreift läuft das so durch.
Hier könnte man durchaus ein Lob an Microsoft aussprechen. ;)
Hallo, bin jetzt etwas verwirrt…?
Unser WSUS hat V 6.3.9600.18694 und läuft unter Windows Server 2012R2. Über Windows Updates wird mir für diesen WSUS das mtl. Rollup KB 4489881 angeboten. Beinhaltet das u.a. SHA-2 Update für den WSUS oder muss das manuell im Windows Update Catalog geladen werden?
Das mtl. Rollup KB4489881 ist für Windows Server 2012R2, nicht für WSUS.
V 6.3.9600.18694 ist WSUS 4.0, das braucht kein SHA-2 Update!
Hmm, dann habe ich da wohl gewaltig was verwechselt. Danke schön… ;)
kb2952664 taucht seit dieser woche auch nicht mehr bei der updatesuche auf, nachdem es entfernt wurde.
ich glaube das wird entsetzlich, wenn das eines tages rauskommt, was für funktionen da inzwischen eingebaut wurden, egal welche windows version.
Oh. Dann war es hoffentlich nicht mit in den anderen updates versteckt!? Also bei mir ist es noch da vorhanden kb2952664 .
Win 7 64 bit updatestand: 20.12. 2017.
Die beiden anderen KB4474419 -> KB4490628 werden bei mir auch angeboten. ohne das ich erst das eine oder das andere zuerst installieren muß.
Hallo zusammen und erst mal ganz allgemein vielen Dank für die ausführlichen Artikel auf dieser wertvollen Seite.
Hat denn inzwischen jemand einen Ansatz für diese Problematik? Ich versuche seit dem 12.03. vergeblich, dieses Update zu installieren und habe auch schon diverse verschiedene Varianten durch – alles ohne Erfolg.
Auf welchem System?
Win 7 Pro x64.
Habe es aber inzwischen mehr durch Zufall hinbekommen.
Dummerweise wird mein "Weg" wohl den wenigsten helfen, aber vielleicht kommt der eine oder andere zumindest auf ein, zwei Ideen, was man noch ausprobieren könnte.
Ich wollte nach einigen nervigen Versuchen, das Update zu installieren, auf Win 10 wechseln, hatte aber früher schon Probleme mit Freezes. Meine Hardware ist halt auch nicht mehr die neueste.
Also habe ich mir vorher mit Acronis einen Klon gezogen.
Also Win 10 installiert, gleiche Probleme wie früher. Aber bei der Installation ist mir wieder aufgefallen, dass noch eine HDD bei mir drin hängt, auf der ich eine Weile Ubuntu nebenher laufen hatte.
Stimmt … der GRUB kam auch beim Booten immer kurz, ich hatte da aber die Zeit ziemlich runtergestellt und das kaum noch bemerkt.
Die Windows-10-Installation hat GRUB eh zerschossen, also dachte ich mir, ich pfeife drauf (hab das eh kaum mehr benutzt) und schmeiße die Platte raus.
Dann also den Klon wieder auf meine System-SSD geschmissen, eher aus Spaß das KB4474419 nochmal über die .msu gestartet … und siehe da – es lief diesmal flott und völlig problemlos drauf.
Die Geschichte gibt es in länger übrigens auch hier:
https://answers.microsoft.com/en-us/windows/forum/all/kb4474419-will-not-install/658900bc-3103-4a0e-a9ed-08c5c2d31e76
Update: Das mit der Linux-HDD scheint wohl doch auch Anderen zu helfen. :)
Ja, hat mir auch geholfen. Problem gelöst.
Vielen Dank für die Info!
Ich habe gestern den ersten Rechner mit Windows 7 x64 Home Premium aktualisiert. Update wurde ohne Probleme durchgeführt. KB4490628 wurde erst nach dem Neustart angeboten und installiert. Für dieses Update wurde keine weiterer Neustart verlangt.
Bisher läuft der Rechner ohne Probleme. Werde jetzt am Wochenende zwei VMs mit Windows 7 Pro (x32 und x64) aktualisieren.
Muss gerade feststellen. Seitdem Märzupdate funktioniert die Tastenkombination WIN+L nicht mehr zum sperren.
Bei mir bootete der Rechner nach Installation von kb4490628 nicht mehr, weil die UEFI Partition unautorisiert verändert worden sei.
Hatte nach leidvollen Erfahrungen eine Stunde zuvor ein Image meiner Systemfestplatte gemacht und konnte deshalb die UEFI Partition einfach wieder herstellen.
Hat noch jemand ähnliche Erfahrungen gemacht? Kann man die Partition nicht im BIOS sperren?
Danke
Hajü
lies mal ein wenig in der uefi spezifikation!
im bios kannst du die schon garnicht sperren weil du keines mehr hast, auf der betreffenden maschine, sondern nur noch eine "uefi firmware".
wenn die legacy only noch unterstützt, ist das die zu bevorzugende art zu booten, weil dort ms (ein mitglied des uefi commitees) nicht in der boot-order rumpfuschen kann.
ist mir leider auch erst nach vielen bluescreens klar geworden! lg!
Habe auch das Problem mit KB4474419 gehabt.
Es handelt sich um ein Dual-Boot-System, bei dem Windows 7 über Grub gestartet wird. Habe testweise die Linux-Platte im BIOS deaktiviert, so dass direkt Windows gebootet wird. Der Patch lief nun ordentlich durch.
So ein Problem mit Dual-Boot-Systemen gab es bei irgendeinem Patch vor einigen Jahren schonmal…
Ich kann bestätigen, dass auf meinem Dual-Boot-System nach der temporären Einstellung der Windows 7 SSD als erstes Boot-Device im BIOS das Update KB4474419 erfolgreich ohne Fehler installiert werden konnte.
Irgendwie merkwürdig, denn der Grub2 liegt auf der separaten Linux SSD die normalerweise – und jetzt auch wieder – das erste Boot-Device ist … Windows dürfte sich daran also eigentlich überhaupt nicht stören …
Danke, dass ist für mich ein weiterer Hinweis, dass auch dieses Update wieder einen MS Bootloader erwartet. Leider ist das Austauschen und zurücksetzen für mich wegen der bestehenden Bootkette ein riesengroßer Aufwand, so dass ich das Update erstmal verschieben muss. Ja, deartige Probleme verursachten früher sogar einmal eine Bootkette, die man nicht einfach unterbrechen konnte. Diesmal scheitert das Update KB4474419 und es gibt ein Rollback.
Win7x64 Dual Boot mit Grub.
kb4490628 manuell installiert – wurde nicht angeboten – lief fehlerfrei.
Windows Update bietet außer KB4474419 keine weiteren Updates mehr an.
KB4474419 scheitert jedes Mal.
Vielen Dank, das war's auch hier! Wann kapiert MS endlich, dass es andere Betriebssysteme gibt und dass man sich auch kooperativ benehmen kann?
Grub2 aus der Bootchain raus(*) und das KB4474419 läuft durch! Einmal mit Profies arbeiten!
(*)Ist auf meinem System kein Problem(1. SATA-SSD ist Linux samt grub2, auf einer NVME ist Windows, also nur im BIOS das Bootlaufwerk ändern, hat sich so ergeben, ist aber hilfreich, da Windows eh mal quer schießt).
regel nummer 1:
max. 1 os je pc
bei legacy boot easy zu handlen, bei uefi capable kann das bloße anstecken einer sata hdd aus nem nb mit efi system partition für bluescreen sorgen, oder wie ich in deinem fall vermute, nutzt du den mischmode uefi & legacy, was über kurz oder lang zum problem führt.
das ist ne harte materie, die die meisten nicht durchschauen. ihr habt nicht mehr viel zeit! einen teufel wird ms tun wenn ihr nicht lernen wollt..
//www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
mfg!
Das heisst?
Weg von Microsoft; und zwar schnell!
Habe gerade die März-Updates ausgeführt – nicht ohne Bauchschmerzen, nachdem ich diesen Thread (und auch andere) bzgl. auftretender Probleme durchgelesen hatte… Bei mir liefen zum Glück alle Updates einwandfrei durch und auch das System funktioniert nach dem nun 2. manuellen Neustart ohne Probleme:
Win 7/64 Bit – über automatische Updatefunktion wurde folgende Reihenfolge ausgeführt:
1.: KB4489878 installiert
2.: KB890830 installiert
3.: KB4474419 installiert – danach geforderter Neustart ausgeführt
4.: Manuelle Suche nach Updates ausgeführt. Ergebnis: kein neues Update verfügbar!
5.: Noch (bei mir) ausstehendes Office 2010-Update KB4462226 ausgeführt. Kein Neustart verlangt. Kurz danach wurde aber komischerweise dann OHNE nochmalige erneute Updatesuche doch das SSU KB4490628 angezeigt…
6.: KB4490628 installiert – kein Neustart verlangt!
Hallo :-)
Bei den Vorraussetzungen für den WSUS-Patch sticht mir das .Net 3.5 ins Auge.
Auf den meisten Servern ist es ja eh schon drauf – aber sicher ist sicher, daher folgende Frage:
Tut es .NET 4.7.2 auch oder muss explizit .NET 3.5.x vorhanden sein?
Danke schonmal
biber
Ich reihe mich auch mal ein.
4.7.2 ist am Server installiert
3.5 nicht
Sollte aber imho abwärtskompatibel sein?!
Ergänzung:
https://docs.microsoft.com/de-de/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed#net_a
Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\ sollte alle installierten Versionen anzeigen wenn ich das richtig sehe.
UNd 3.5 sollte "Ab Werk" schon dabei sein
https://de.wikipedia.org/wiki/.NET_Framework#%C3%9Cberblick
4.7.2 ist abwärtskompatibel … bis zur 4.0. ;-)
Also ja, wenn 3.5 verlangt wird, muss diese explizit installiert werden.
In der Verwaltung beim Server-Manager unter "Features" sollte es aufgelistet sein.
Bei uns ist es das zumindest.
Ansonsten halt dementsprechend nachinstallieren
https://blogs.msdn.microsoft.com/sqlblog/2010/01/08/how-to-installenable-net-3-5-sp1-on-windows-server-2008-r2-for-sql-server-2008-and-sql-server-2008-r2/
Nutze Windows 7 x64 Home.
Mir wurde nur KB4474419 und KB4489878 angeboten, beides habe ich installiert.
KB4490628 wird mir nicht angeboten.
Bin ich da der einzige?
Was mich auch etwas stutzig macht: diesen Monat gab es auch kein .NET-Rollup, nur die Vorschaub 2019-02 wird mir als KB4487256 angeboten. Ist das normal?
Siehe hier:
https://www.borncity.com/blog/2019/03/20/windows-7-8-1-preview-rollup-updates-19-mrz-2019/#comment-69565
.NET Updates sind bei uns (Windows 7 Pro, versorgt über WSUS) angekommen.
KB4487256 bei mir ist aber etwas anders als KB4489486 bei Dir in dem Posting.
Ich scheine, wie gesagt, beim Februar-Preview-Stand zu hängen.
Ist bei mir auch so mit Win7 Pro x64, es wird KB4487256 bei den optionalen Updates angeboten.
Und Dir wird ebenfalls kein KB4490628 angeboten?
Ich habe vielleicht die Lösung für das Problem mit dem KB4474419.
Schaut euch mal die System-reservierte Partition an, wieviel Speicherplatz dort zur Verfügung steht. Ich habe diese Partition auf 1GB erweitert. Danach ist die Installation einwandfrei durchgelaufen.
"System-reservierte Partition", was soll das sein? Meinst Du die Boot-Partition? Die wird von Windows 7 selber angelegt und ist etwa 100MB gross, sollte das ein Problem sein bei der Installatin von KB4474419 hat MS mal wieder gepfuscht. Diese Partition brauchts eigentlich nur wenn BitLocker benutzt wird, meine Win7 Installationen laufen ohne dieses Ding.
Das weiß ich, meine Installationen laufen auch ohne diese Partition. Ich war gestern bei einem Kunden, der das Update auch nicht einspielen konnte und da war es genau das Problem. Als ich diese Partition vergrößert hatte, lief das Update einwandfrei und schnell durch. Es reichten 300MB. Einen Versuch ist es wert.
Hatte vergessen meinen Namen einzutragen.
Jörg
"Microsoft gibt an, dass dieses SSU vor der Installation der März 2019-Updates installiert werden muss, um Folgefehler und Installationsprobleme zu vermeiden."
Windows hat bei mir das März-Update eigenständig VOR dem SSU installiert. Und nun schlägt das SSU immer wieder fehl.
Was kann ich denn jetzt tun? Kann man das Sicherheitsqualitätsrollup für März irgendwie deinstallieren??
PS: Danke übrigens für diesen tollen Blog!
Deine Beobachtung deckt sich mit den Aussagen weiterer Benutzer, das SSU kommt zuletzt. Versuche eine Systemwiederherstellung auf den Punkt vor der Update-Installation oder schau nach, warum das SSU bei der Installation fehl schlägt.
Puh, danke! Habe es geschafft das letzte Update zu deinstallieren. Das wurde mir vorher komischerweise gar nicht angezeigt, bei Programme/installierte Updates (oder es hat trotz SSD ewig gedauert, bis windows es gefunden hat). Als es mir dann angezeigt wurde konnte ich das März Sicherheitsupdate deinstallieren. Dabei hat er automatisch das SSU installiert – es wurde nach dem Neustart als installiertes Update angezeigt.
Computerschutz war deinstalliert, das hätte mir nicht geholfen. (Entweder weil Allwaysync mir den Namen verstellt hatte oder weil ich mit dem Samsung-Migration-Tool C auf SSD umgezogen habe).
Mmmh,
bei uns ist eine Windows Server 2012 Essentials mit WSUS 3.0 SP2 (ja, das ist die 6.2.9200.22297) im Einssatz. Für den Server 2008 wird ja ein WSUS 3.0 SP2 Update (KB4489880) angeboten.
Jetzt stellt sich für mich die Frage:
Braucht auch der Windows Server 2012 Essentials ein Update, um SHA-2 Updates aus zu liefern, oder reicht da schon die im Betriebssystem integrierte SHA-2 Engine?
Fragen über Fragen..
hallo
habe das Problem mit KB4474419 gestern bei mir lösen können!
Das update läuft nicht durch wenn ein "alternativer bootloader" benutzt wird!
Ich habe Multiboot mit Windows 10 und Windows 7, im Bootloader von Windows 10 ist Windows 7 eingetragen,
es kommt also der schwarze Auswahlbildschirm wenn ich starte.
Jetzt habe ich im UEFI die Bootreihenfolge so eingestellt das er direkt von der Windows 7 Platte bootet,
der schwarze Auswahlbildschirm vom Windows 10 Bootloader kommt also nicht,
und so konnte ich nun das update erfolgreich installieren!
Gefunden habe ich die Lösung hier:
"In verschiedenen Foren berichteten Nutzer zudem, dass dass Update KB4474419 bei ca. 83 Prozent mit dem Fehler 0x80004005 (E_FAIL, unbekannter Fehler) fehl schlägt. Inzwischen hat sich in einem englischen Microsoft-Forenthread eine mögliche Ursache herauskristallisiert. Die Update-Installation scheitert, wenn ein fremder Bootlader (etwa Linux GRUB2, der auf eine Linux-Partition zeigt) vorhanden ist. Nach Entfernen des Bootladers oder 'abklemmen' des Linux-Laufwerks lässt sich das Update dann erfolgreich installieren."
link:
[url]https://www.heise.de/newsticker/meldung/SHA-2-Support-fuer-Windows-7-und-Server-2008-R2-aktualisieren-4341198.html[/url]
Danke für die Rückmeldung. So schließt sich der Kreis – ist ja mein Artikel, wo ich die Informationen hier im Blog und aus diversen Foren zusammen gefasst habe ;-)
achso dann vielen Dank für deine Hilfe!
und natürlich auch an die anderen hier!
MfG Michael
Guten Tag,
ich habe mir ein neues Win7 Image erstellt, dabei fiel mir auf, dass das Servicing Update KB4490628 doch nicht 100% den alten SSU KB3177467 ersetzt.
Wenn ich bei meiner Update Zusammenstellung mit dem SSU KB4490628 ein Image erstelle, bekomme ich spätestens bei der Installation Fehlermeldung und die Installation bricht ab. Keine Probleme beim Erstellen der ISO-Datei.
Mit dem alten SSU klappt es einwandfrei.
Zur Info
Guten Tag, haben hier mehrere fehlerhafte Update Installation beim KB4474419 auf Win7 x64 Pro.
Code: 0x80246001 (Download failed)
Das SSU KB4490628 wurde auf allen bereits erfolgreich installiert.
Hat wer ein Tipp für mich?
Der Fehlercode 0x80246001 steht für WU_E_DM_URLNOTAVAILABLE – A download manager operation could not be completed because the requested file does not have a URL.
Frage 1: Kann eine Internet Security Suite stören?
Frage 2: Wurde Windows Update schon zurückgesetzt (per Assistent oder manuell)?
Was passiert, wenn Du das Update manuell herunter lädst und dann installieren lässt?
Frage 1: Kann ich ausschließen
Frage 2: Habe ich noch nicht durchgeführt.
Habe eben einen noch nicht gepatchten Client hochgefahren, SSU wurde installiert, Updatesuche KB4474419 gefunden und fehlerfrei installiert.
Gesamtstatus: 43 Fehler | 12 Erforderlich | 14 Installiert
Ich schnappe mir jetzt einen im Fehlerstatus und mache den WSUS Client Agent Reset.
Lasse mich wissen, was dabei herum gekommen ist. Ich habe nämlich auf Grund des Kommentars einen Artikel als Konserve aufgesetzt, der Ostermontag online gehen soll. Vielleicht kann ich da noch was nachtragen.
Vom Bauchgefühl her könnte etwas in den Komponentenspeichern (qmgr*.dat, Downloads, DataStore, catroot2) kaputt sein. Schau dir folgende zwei Links an:
MS-Answers-Forum (Reset von qmgr*.dat)
Microsoft Support-Beitrag
sowie meinen Blog-Beitrag Windows Update Error 0x8007042B (Abschnitt zum Reset des Update-Cache) an
Beide Wege haben funktioniert.
Update aus dem WinUpdateCatalog herunterladen und als .msu installieren
WSUS Client Agent Reset mit anschließender WSUS Installation
Heißt für mich ein Script zu basteln damit der WSUS Client Reset auto. auf allen betroffenen einmal ausgeführt wird.
Vielen Dank für die Hinweise.
@Anonymous: Ich habe zu danken – ist die Bestätigung, dass mein erstellter Artikel das in erweiterter Form aufbereitet, was ich dir in Brocken vor die Füße geworfen habe.
KB4474419 V2 (SHA-2 Code Signing Support) wird im Update Katalog bei den 2019-08 Updates aufgeführt.
Das KB4474419 V2 wurde installiert, obwohl das KB4474419 schon im März installiert worden ist.
KB4474419 lässt sich bei mir nicht installieren. Dann ist das eben so, werde keinen Stress machen und auf Fehlersuche gehen. Entweder es geht auf Anhieb oder eben nicht.
Was nicht geht wird ausgeblendet, wie eine Flasche leer.
Tschöö mit ö
Ich hatte gestern beim Booten eines W7 64 Bit einen Signaturfehler, der Start war nicht mehr möglich, alle Reparaturversuche schlugen fehl, nichts zu machen. Grund war wohl das Update. Ich muss dazu sagen, dass mein Windows 7 auf einer NVME-M.2-SSD läuft.
Ich konnte alles über einen Restore wieder herstellen, habe gestern dann normal gearbeitet, im Hintergrund wurde das Update wohl wieder gezogen, und heute Morgen das Selbe Problem. Sigh… Ja, ich bin blöd, hätte ich mir doch denken können.
Ganz tolle Leistung von M$ solche Dinge zu veröffentlichen. Arm dran wer sich nicht auskennt und den Computer erstmal zum Dienstleister tragen darf. Ob M$ den Schaden bezahlt?
Ich werde heute mal schauen was er sich da alles herunter lädt und ob …4419 noch fehlt, das könnte dann wohl der Grund sein.
Updates werden erstmal ausgeschaltet, von Würmern und Viren geht eine geringere Gefahr aus als von System-Updates.
Dieses Update wurde am Dienstag neu veröffentlicht.
Quelle – tatsächlich mit Angabe der Änderung: https://support.microsoft.com/de-de/help/4474419
"Dieses Sicherheitsupdate wurde am 13. August 2019 aktualisiert, um die Datei bootmgfw.efi einzuschließen und dadurch Startfehler unter IA64-Versionen von Windows 7 SP1 und Windows Server 2008 R2 SP1 zu vermeiden."
Warum das nun auf x86 und x64 Systemen zu Problemen führt – und vor allem bei diesen ausgetauscht werden muss, weiß hoffentlich Microsoft selbst.
Kein Neustart nach Update 4484419 mit 4512506.
Dual Boot Konfiguration (Beide Win7 64 bit, C und F (Backup)) mit EFI-Boot -> könnte ein möglicher Grund sein.
Meldung winload.efi.mui kann nicht verifiziert werden (toll und kein Zufall).
Behoben (nach Stundenlanger Sicherung):
Boot von Backup-Windows von F.
Administrator-Console:
dism /image:C\ /cleanup-image /revertpendigactions
Bemerkung: 4484419 und 4512506 waren beide pending.
Reboot von C. Automatischer Rollback, Automatischer Reboot.
Scheint OK. Auto-Update notgedrungen komplett deaktiviert – da weitere Updates nicht mehr einlaufen werden.
Schau dir mal den Blog-Beitrag Bekommen Windows 7-Nutzer ein SHA-2-Update Problem? an – da hatte ich das Dual_Boot-Problem angerissen.
Habe WIN7, x64
Sept-Patchday:
KB4474419 (SHA-2 Code Signing Support) wird ERNEUT als WICHTIGES UPDATE angeboten.
Habe speziell DIESES Update aber noch nicht eingespielt, sondern stelle hier erst mal meine Fragen dazu.
Warum wird es erneut angeboten?
Gibts weiter Probleme auf WIN7?
Was sagen die Experten?
Nach dem sukzessiven Einspielen aller Sept-Patches auf 2 WIN7 PCs: keine Probleme.
Habe Update kb4490628-x64 win7 manuell eingespielt. War bei mir die Lösung.
Hab einen 2008 R2 SP1 als VM und bekomm KB4484071 einfach nicht installiert.
Hab es mit und ohne Framework 3.5 probiert. Bei KB4489878 kommt "Das Update ist nicht für Ihren Computer geeignet." KB4474419 ist installiert, ebenso KB4490628.
Der Server dient nur als WSUS und WDS. Bin am verzweifeln…