[English]Zum 12. November 2024 hat Microsoft wohl Sicherheitsupdates für Windows Server 2008 R2 herausgegeben. Wer diese Updates installieren ließ, musste anschließend feststellen, dass die älteren Browser, die auf diesen Maschinen bisher genutzt werden konnten, nicht mehr funktionieren. Es gibt inzwischen aber einen Workaround, um wieder einen Browser zum Laufen zu bringen. Ist aber eher ein Exoten-Problem, da wohl nur noch wenige Windows Server 2008 R2 laufen dürften.
Windows 7/Server 2008 R2 sind EOL
Windows 7 ist längst aus dem Support gefallen, und auch Windows Server 2008 R2 bekommt seit Januar 2024 auch keinen Extended Security Update (ESU) Support mehr (siehe auch Windows Server 2008 R2 bekommt ESU-Support bis 9. Januar 2024). Andererseits war Windows Embedded POSReady 7 noch bis zum 24. Oktober 2024 im Support (siehe).
Aber es gibt von Microsoft immer noch Sicherheitsupdates für Windows Server 2008 R2. Einige Nutzer von Windows 7 haben dann die Sicherheitsupdates von Windows Embedded POSReady 7 verwendet, um Sicherheitslücken auf ihren Betriebssystemen zu patchen und diese weiter zu betreiben.
Browser fallen aus dem Support
Google hat auf Grund des Lebensendes den Support für seinen Chromium-Browser für Windows 7 SP1 und Windows 8.1 sowie die Server-Pendants im Januar 2023 mit der Version 109 beendet. Ich hatte im Blog-Beitrag Windows 7/8.1: Google beendet den Support im Februar 2023, Edge auch betroffen auf diesen Sachverhalt hingewiesen.
Damit fallen auch alle auf Chromium basierenden Browser, wie der Microsoft Edge, in höheren Versionen für diese Betriebssysteme aus. Lediglich für Windows Server 2012 R2 haben Microsoft und Google zugesagt, Sicherheitsupdate für den Google Chrome / Edge 109 bereitzustellen. Und es gibt noch den Firefox, dessen Entwickler den Browser unter Windows 7 noch bis zum 3. Quartal 2024 unterstützen wollten (siehe Windows 7/8.1: Firefox gewährt Support bis mind. 3. Q. 2024). So weit zur Vorgeschichte.
Sicherheitsupdates legen Browser lahm
Für mich überraschend scheint es zum Patchday, November 2024, doch noch Updates für Windows Embedded POSReady 7 und Windows Server 2008 / R2 gegeben zu haben. Zum Beitrag Patchday: Windows Server 2012 / R2 und Windows 7 (12. November 2024) hat sich R.S. mit diesem Kommentar gemeldet. Er schrieb, dass es für Windows Server 2008 R2 auch noch ein Update für den Internet Explorer (KB5046630) und ein Update für .NET (KB5046543) gebe – hatte ich hier im Blog nicht mehr thematisiert. Die Updates für Windows Server 2008 R2 lassen sich auch bei Windows 7 installieren.
Dann hat sich Bolko mit diesem Kommentar gemeldet, und fragt, ob die Browser nach Installation der Updates noch funktionieren. Ein weiterer Nutzer kommentiert hier: „Alle Legacy Browser sind mit dem Update, unter Windows 7 und 2008 R2, kaputt.“ Er hat es in einer virtuellen Maschine getestet, Chrome 109, Edge 109, Firefox ESR 115, Opera 95 funktionieren nicht mehr.
Es kristallisiert sich aber heraus, dass das Internet Explorer Update KB5046630 nicht die Ursache ist. Leser Trillian schreibt, dass die Update KB5046705 als auch KB5046687 (im Microsoft Update Catalog für Windows Server 2008 R2 erhältlich) unter Windows Server 2008 R2 (und wohl unter Windows 7) die alten Browser unbenutzbar machen.
Ein schmutziger Workaround
Bolko hat in diesem Kommentar die Datei Win32k.sys als Ursache angegeben. Wer vom Exoten-Problem betroffen ist (es dürften nur noch wenige der Altsysteme laufen), kann den von Bolko in diesem Kommentar skizzierten Workaround verwenden.
Nach dem Abschalten des Integritätscheck und der Treibersignaturprüfung über BCDEdit kann die Datei Win32k.sys aus einem alten Backup vor den November 2024-Updates verwendet werden, um die im November 2024 gepatchte Version zu ersetzen.
Ähnliche Artikel:
Browser-Ärger I: Edge will erneut Google Chrome-Tabs importieren (Nov. 2024)
Browser-Ärger II: Nov. 2024-Updates für Server 2008/R2 legen ältere Browser lahm
Technischer Hinweis: „Weiterlesen“ ist auch hier in die Folgeüberschrift gerutscht.
Danke! Erklärung zum Hintergrund: Es scheint eine Eigenart des klassischen WordPress-Editors zu sein, dass er mir den more-Tag beim Einfügen mit Folgetags verhackstückt. Früher habe ich mit dem Windows Live Writer (WLW) gebloggt – da kam das praktisch nicht vor. Seit dem Blog-Umzug auf all-incl.com habe ich meinen Workflow so umgestellt, dass ich direkt in WordPress im Classic-Editor (mit Erweiterungen) bloggen kann (der WLW funktioniert in der neuen Konstellation nicht mehr – und ich kann auch unter Linux bloggen).
Mir fällt der verunglückte more-H2-Tag meist nicht auf, weil ich mir selten die Startseite des Blogs mit den Kurzfassungen der Beiträge ansehe – ich arbeite im WordPress-Dashboard und schaue mir nur die finalen Beiträge an. Von daher bin ich froh, wenn dieser Fehler gemeldet wird – ich korrigiere und lösche danach den Kommentar.
Workflow im Classic Editor: Cursor direkt nach den letzten Punkt des erstes Absatzes setzen, dann per Button „Weiterlesen“ einfügen.
Du bloggst sehr viel? Theoretisch hast Du Recht – kann man so machen – und ist auch der normale Workflow -> „Artikelbild per Plugin einfügen, Anreißertext möglichst verfassen, more-Tag einfügen und weiterschreiben“. Und wenn ich mir den HTML-Code auf dem Tab „Text“ anschaue, sehe ich auch das Malheur.
Nur entstehen bei mir Blog-Beiträge nicht nach der reinen Lehre der Art „wat is ene Dampfmaschine“. Da wird ein Text vom Scratch geschrieben, ich stelle Absätze um, mir fällt ein „Oh, am Anfang könnte noch ein Titel stehen“, damit es ggf. mit weiteren Überschriften passt, und dann geht der Text raus. Manchmal ändere ich auch noch was nach dem Publizieren, und schon ist das Malheur passiert. Ich müsste nach jeder Änderung am Artikelanfang den HTML-Code kontrollieren – da ich noch auf andere Sachen zu achten habe, ist das eher unrealistisch. Das Problem fällt mir i.d.R. nur auf, wenn ein Nutzer das dann anmerkt. Ich sehe bei 5-10 Blog-Beiträgen / Tag auch keine wirkliche Alternative.
Firefox 115 ESR soll laut Mozilla noch bis mindestens März 2025 Updates bekommen.
Moin Herr Born!
Mozilla hat den Support für den Firefox 115 ESR unter Windows 7/8 bis bis März 2025 verlängert:
„We decided to extend support for ESR 115 only on Windows 7-8.1 and macOS 10.12-10.14 up to March 2025. We will re-evaluate this decision in early 2025 and announce any updates on ESR 115’s end-of-life then.“
Quelle: https://whattrainisitnow.com/release/?version=esr
Noch zwei kleine Ergänzungen:
Die Updates für Windows Server 2008 R2 funktionieren nur bei den 64-bit Windows-7-Versionen.
Via Premium Assurance gibt es für Windows Server 2008 R2 verlängerten Support bis Januar 2026. Theoretisch/praktisch ließen sich darüber ebenso Windows-7-x64-Versionen bis Januar 2026 patchen…
Danke für die Ergänzungen – wusste im Hinterkopf „da war noch was“, habe aber auf die Schnelle nichts bei einer Suche gefunden.
Das mit den 64bit ist logisch, da es Server 2008R2 nicht als 32bit-Version gibt.
Der Workaround ist wirklich schmutzig, da er damit das Sicherheitsupdate aushebelt und damit geschlossene Lücken wieder aufreißt.
Auf Servern ist das Nichtfunktionieren der Browser ein kleineres Problem, denn auf Servern sollte grundsätzlich kein Browser installiert sein.
Das Problem entsteht nur, wenn man die Serverupdates auch für Windows 7 nutzt.
Da das aber von Microsoft so nicht vorgesehen ist, ist es nicht unwahrscheinlich, das es da keinen Fix von Microsoft geben wird.
Moin R.S.!
Windows ‚Server 2008 R2 eingerichtet als Terminalserver für den Internetzugang von Clients benötigt sehr wohl eine funktionierende Browserlösung. Und da auch die unter Windows Server 2008 R2 lauffähige Edge-Version davon betroffen ist, ist es eventuell doch nicht so unwahrscheinlich, dass Microsoft da einen Fix anbieten wird… (Just My Cent! ^^)