Desaster Exchange August 2023-Sicherheitsupdate – nicht installieren!

Stop - Pixabay[English]Die von Microsoft zum 8. August 2023 für Exchange Server 2016/2019 veröffentlichten Sicherheitsupdates entwickeln sich auf nicht englischsprachigen Systemen zum Desaster. Einerseits sollen die Sicherheitsupdates kritische Schwachstellen in Exchange schließen, so dass die betreffenden Server abgesichert sind. Andererseits sorgen diese Sicherheitsupdates dafür, dass die Exchange-Instanz anschließend kaputt ist oder die Installation scheitert schlicht, so dass ein Rollback durchgeführt wird. Inzwischen rät Microsoft von der Installation der August 2023-Sicherheitsupdates für Exchange Server 2016/2019 auf nicht englischsprachigen Systemen ab.


Anzeige

Updates für Exchange Server 2016/2019

Ich hatte vor einigen Stunden über die zum 8. August 2023 freigegebenen Sicherheitsupdates für Exchange Server 2016/2019 berichtet (siehe Exchange Server Sicherheitsupdates (8. August 2023)). Es stehen die Sicherheitsupdates:

  • Exchange Server 2016 CU23 entfernt
  • Exchange Server 2019 CU12 entfernt und CU13 entfernt

zur Verfügung, die folgende Schwachstellen schließen sollen (eine Liste aller CVEs, die im August 2023 geschlossen wurden, findet sich unter Microsoft Security Update Summary (8. August 2023)).

  • CVE-2023-21709: EoP Schwachstelle in Microsoft Exchange Server; CVEv3 Score 9.8, important; Ein nicht authentifizierter Angreifer könnte diese Schwachstelle ausnutzen, indem er versucht, das Passwort für gültige Benutzerkonten zu erzwingen. Bei erfolgreicher Ausnutzung (als wenig wahrscheinlich eingestuft) könnte sich der Angreifer "als ein anderer Benutzer anmelden".
  • CVE-2023-38181, CVE-2023-38185, CVE-2023-35368, CVE-2023-38182, CVE-2023-35388, Microsoft Exchange Server Schwachstellen; CVEv3 Score 8.0 – 8.8, important; Ein authentifizierter Angreifer kann durch Ausnutzung dieser Schwachstellen (als wenig wahrscheinlich eingestuft) Code über eine PowerShell-Remoting-Sitzung ausführen. Um diese Schwachstelle erfolgreich auszunutzen, müsste der Angreifer zunächst über LAN-Zugang und gültige Anmeldeinformationen für einen Exchange-Benutzer verfügen.

Microsoft empfahl, diese Sicherheitsupdates zeitnah zu installieren, auch wenn noch keine Ausnutzung in freier Wildbahn beobachtet werden konnte. Allerdings scheint Microsoft diese Sicherheitsupdates nur unzureichend auf Systemen mit nicht englischsprachiger Oberfläche getestet zu haben.

Das Installationsdesaster

Ich hatte die Nacht den Blog-Beitrag Exchange Server Sicherheitsupdates (8. August 2023) gerade veröffentlicht, als ein Administrator mir per Facebook bereits die Information zukommen ließ, dass die Installation nicht durchlaufe. Dazu hieß es:

Installationsfehler: Die Installation des folgenden Updates ist mit Fehler 0x80070643 fehlgeschlagen: Security Update For Exchange Server 2016 CU23 (KB5029388)

Im Techcommunity-Beitrag Released: August 2023 Exchange Server Security Updates gab es bereits gegen 1:00 Uhr deutscher Zeit erste Einträger von deutschen Administratoren, die ebenfalls von Installationsabbrüchen berichteten. Lothar Lindinger schrieb:

This Exchange SU cannot be installed in our environments (OS and Exchange in de-de). Installer throws Error 1603.

Tested on Exchange Server 2016 CU23 SU8 on Windows Server 2016 as well as Exchange Server 2019 CU13 SU1 on Windows Server 2022.

Weitere Administratoren bestätigten die Probleme und eine Person, die  aus dem deutschsprachigen Raum kommt, schrieb in einem Kommentar:

We have a similar problem […]. The Exchange SU cannot complete in our environments (Exchange 2019 and 2016), also on an very clean test environment. The OS and the Exchange are in de-de.

Gleichzeitig hat er obigen Screenshot der Fehlermeldung gepostet. Auch hier lässt sich das CU 23 für Exchange 2016 nicht installieren. Weitere Administratoren haben dann ähnliche Installationsprobleme für Exchange Server 2019 berichtet. In den Kommentaren zu meinem Blog-Beitrag Exchange Server Sicherheitsupdates (8. August 2023), zum Beitrag Patchday: Windows 11/Server 2022-Updates (8. August 2023) sowie zum Beitrag Microsoft Security Update Summary (8. August 2023) meldeten sich ebenfalls Betroffene. Bei Frank Zöchling ging die Diskussion unter diesem Beitrag ebenfalls los.

Microsoft zieht das Update zurück

Nico Billic von Microsoft hatte zeitnah (ca. 1:00 Uhr deutscher Zeit) bereits erste .log-Files von betroffenen, konnte bei einer ersten schnellen Analyse keine Ursache finden. Derweil häuften sich im Blog-Betrag der Techcommunity die Forderungen deutscher Administratoren an Microsoft, dieses fehlerhafte Update zurückzuziehen. Inzwischen findet sich Techcommunity-Beitrag Released: August 2023 Exchange Server Security Updates ein entsprechender Hinweis:


Anzeige

We are aware of Setup issues on non-English servers and have temporarily removed August SU from Windows / Microsoft update last night. If you are using a non-English language server, we recommend you wait with deployment of August SU until we provide more information. Update: Please see Known Issues below for more information.

Man ist über Probleme auf nicht englischen Exchange-Servern informiert und hat das Sicherheitsupdate (SU) für August 2023 temporär zurückgezogen. Wer auf nicht englischsprachigen Installationen unterwegs ist, sollte das SU vorerst nicht installieren (gilt für alle Versionen). In den Known Issues hat Microsoft dann folgenden Eintrag ergänzt:

Due to reports that Exchange setup fails on servers running on several languages other than English, we have temporarily removed August SU from Microsoft / Windows update until we find the root cause of the problem. We recommend our customers running non-English servers to pause installation until we provide more information. If your server has been already impacted by failed setup, please do not try uninstalling anything. Re-enable Exchange Services by running the following from the \Exchange Server\V15\Bin folder. Reboot the server after this and services should start:
.\ServiceControl.ps1 AfterPatch

Zudem gibt es einen weiteren Fehler, der Kunden, die von der bevorstehenden Änderung der AES256-CBC-Verschlüsselung von Microsoft 365 betroffen sind, tangiert – der aber wohl angesichts der Installationsprobleme zweitrangig ist. Nun bleibt abzuwarten, wann Microsoft mit einer Lösung um die Ecke kommt.

Ergänzung: Microsoft hat einen Workaround gepostet – siehe Workaround für Exchange August 2023 Sicherheits-Update Installationsprobleme.

Ähnliche Artikel:
Microsoft Security Update Summary (8. August 2023)
Patchday: Windows 10-Updates (8. August 2023)
Patchday: Windows 11/Server 2022-Updates (8. August 2023)
Windows 7/Server 2008 R2; Server 2012 R2: Updates (August 8, 2023)
Exchange Server Sicherheitsupdates (8. August 2023)

Exchange Server Sicherheitsupdates (8. August 2023)
Desaster Exchange August 2023-Sicherheitsupdate – nicht installieren!
Workaround für Exchange August 2023 Sicherheits-Update Installationsprobleme


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Software, Update abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

83 Antworten zu Desaster Exchange August 2023-Sicherheitsupdate – nicht installieren!

  1. M.D. sagt:

    V I E L E N D A N K !

    *puuuhhhhh*

  2. Robert sagt:

    "nur unzureichend auf Systemen mit nicht englischsprachiger Oberfläche getestet zu haben" – nur unzureichend? Wohl eher gar nicht? Sonst hätte dies ja sofort auffallen müssen…

    • Pau1 sagt:

      Ich frage mich, wie man ein funktionierendes System so kaputt programmieren kann.
      Vor allem wieso die verwendeten Systemsprache das crashen kann.Ja, OK. Vor 40 Jahren war es schwierig und die gesamte Internet-Struktur ist nicht 8-bit fest.
      Aber seit zig Jahren gibt UTF, und es ist ja nicht die erste Version damit.

      Achso, natürlich gibt es für die Kunden in der Cloud das Problem nicht. Ein Schelm der…

      • 12gang sagt:

        Ich frage mich – als langjähriger Exchange-Admin – eher und abseits aller Fehlleistungen der Exchange-Entwickler und der nicht besseren Alternative Exchange Online (angesichts der Schlüsselentwendung): Wie viele ach so kritische Sicherheitslücken hat dieses System denn eigentlich noch, wenn es nicht ausreichend ist, alle zwei Monate zum Teil unter tagelanger Verfolgung der leidvollen und immer hilfreichen Erfahrungen dieses geschätzten Blogs immer und immer wieder Gravierendes nachzupatchen.
        In Anbetracht dieser Zuverlässigkeitsprobleme wäre es sinnvoll, den Hersteller für immer weiterwursteln zu lassen und mit den Füßen abzustimmen. Wenn nur die ganzen Abhängigkeiten zu anderen Unternehmensanwendungen (Outlook-Anbindung ist m.E. kein Alleinstellungsmerkmal mehr von Exchange, auch die Konkurrenz kann inzwischen angeblich Outlook) nicht wäre, die die Position der Frickelbude Microsoft auch noch manifestieren.
        Wie gesagt als langjähriger Exchange-Admin tendiere ich mehr und mehr dazu, doch auch mal anderswo zu schauen, ggf. gibt es sinnvolle Alternativen.

        • Singlethreaded sagt:

          Kann ich gut nachvollziehen und sehe ich genauso. Der Wechselwille steigt auf jeden Fall und ich hoffe dass andere Anbieter die aktuelle Lage auch als Chance sehen. Ich halte es für wahrscheinlich, dass irgendwann für Exchange der Cloud-Zwang kommen wird.

          Im Prinzp wärtet Microsoft doch nur noch darauf, dass der Anteil der On-Prem Kunden so klein geworden ist, dass ein Friss-oder-Strib auch im Worst Case wirtschaftlich zu vertreten ist. Hier hätte ein Anbieter mit einem vergleichbaren On-Prem Produkt glaube ich keine schlechten Karten. Böse Zungen behaupten ja, die Fehler hätten System, um Kunden in die Cloud zu drängen, aber ich glaube sie können es derzeit einfach nicht besser.

          Mein Vertauen in die Fähigkeiten von Microsoft hat in der letzten Zeit deutlich gelitten. Für eine Verlagerung kritscher Prozesse in die MS-Cloud hat es noch nie gereicht.

          Gruß Singlethreaded

        • JohnRipper sagt:

          Das mir den besseren Alternativen glaube ich erst wenn ich es sehe. Outlook hat auch den unschlaglichen Vorteil selbst wackligen GSM Verbindung im letzten Busch noch eine Synchronisation durchzuführen ohne dass es 20 Einträge zu wenig oder 300 zu viel gibt.

          Aber klar Konkurrenz belebt den Markt.

  3. Joerg sagt:

    yeah! Danke :D, wollte gerad in den Feierabend um den Patch später zu installieren, blieb mir eine "lange Nacht" erspart :>

    • Anonymous sagt:

      Ging mir genauso – so kann / konnte ich den Abend anderweitig sinnvoll nutzen :)

      • ITAdmin sagt:

        Ihr Glücklichen, bei mir hat das Update nicht nur den Exchange, sondern auch noch den DC geschrottet (in meiner Mini-Domäne reicht ein physikalischer PC für DC und Exchange).
        Zum Glück mache ich jede Nacht ein Desaster-Image, so konnte ich am nächten Tag das Image zurückspielen und habe nur wenige Stunden verloren.
        Bei meinem Arbeitgeber konnte ich das Update noch rechtzeitig über VPN am WSUS stoppen.
        Man-o-Man, was für ein Desaster :-(

  4. Tobi sagt:

    Jetzt mal ganz ganz ehrlich, wenn es sich nicht gerade um einen Terminalserver handelt auf dem User arbeiten….. Wie zur Hölle kommt man bitte auf die Idee einen Server auf Deutsch / non-English zu installieren? Geht es noch unprofessioneller?

    Am besten gleich das AD auf nem deutschen Server installieren, ich verstehe schon……… Ich bekomme immer das K… wenn ich einen Kunden übernehme dessen AD in Deutsch installiert wurde.

    Es gibt absolut keinen Grund warum man einen Server in Deutsch installieren sollte, aber ungefähr Tausend dagegen. Allein Troubleshooting mit Fehlermeldungen, Script-Kompatibilität, und und und.

    • Michael sagt:

      geht mir zu 100% genauso, leider betreue ich ua. so eine Umgebung wo das AD auf Deutsch installiert wurde…immer wieder schwierig. Immerhin bin ich bald alle deutschen Server los bis auf TS natürlich.

    • Gordon sagt:

      Ich würde nur gern ansatzweise verstehen, was einen zu so einem Kommentar hinreißt.
      Deine Professionalität in Ehren, aber in der Realität arbeiten auch Menschen, die nicht so des Englischen mächtig sind, in der IT. Ich für mich habe kein Problem mit englischem OS, aber habe mehrere Kollegen bei denen ich große Sorgen hätte wenn ich die Anzeigesprache umstelle.

      Ich halte Script-Kompatibilität für ein ziemlich lächerliches Argument, wer sein Script so schreibt dass es in einer anderen Sprache nicht läuft sollte die Finger vom Editor lassen.
      Im aktuellen Fall ist ebenfalls kein Admin schuldig, sondern Microsoft die ja offenbar ebenfalls nicht in der Lage sind, von Anzeigesprachen unabhängige Software zu schreiben.

      • 1ST1 sagt:

        "Ich halte Script-Kompatibilität für ein ziemlich lächerliches Argument, wer sein Script so schreibt dass es in einer anderen Sprache nicht läuft sollte die Finger vom Editor lassen."

        Hmmm… Wem ist wohl genau sowas passiert?

        "Im aktuellen Fall ist ebenfalls kein Admin schuldig, sondern Microsoft die ja offenbar ebenfalls nicht in der Lage sind, von Anzeigesprachen unabhängige Software zu schreiben."

        Sei sicher, das ist genau sowas.

        • Pau1 sagt:

          Den logfiles nach fehlt da wohl ein Programm…

          Ich bin vielleicht paranoid, aber irgendwie habe ich bei kritischen Programmen erst mal zu gucken ob alles Benötigte da ist.
          Wäre ich richtig paranoid würde ich mir auch durch einen Aufruf die Version ausgeben und und so feststellen, dass ich das Programm starten darf.
          Das kostet natürlich viel Zeit und der neue Kollege macht das alles nicht sondern einfach ein Try Catch, und ist Tage eher fertig. Und wenn es crasht hat er weiterhin Arbeit…. die Firma hat real nichts gespart.

          Und wenn der Ruf der Firma in Einer ist oder ein Monopol besteht dann kommt man damit durch.
          .

          Ist der Ruf erstmal ruiniert
          lebt's sich völlig ungeniert.

      • Andreas sagt:

        Du hast hier doch gerade ein 100% Praxisbeispiel, warum lokalisierte Software auf Serven problematisch ist. Das trifft praktisch alle Bereiche.

        Sich damit rauszureden, dass manche in der IT nicht so gut Englisch können, ist schon seltsam. Denn dann können die auch alles mögliche andere nicht, dass man zur Server(!)administration beherrschen sollte. Und >90% der Software für einen Admin ist NICHT lokalisiert. Lokalisierungen sind für Clients.

        Ich stelle meine Maßeinheiten auch nicht auf Fuß und Grad-Fahrenheit wenn ich als Ingenieur arbeite, weil ein Amerikaner mit im Team ist. Es wäre nicht sinnvoll. Genauso verhält es sich mit Servern auf Deutsch.

        Um so idiotischer war es auch schon immer bei Microsoft z.B. die RTC/Hardware-Uhr zu lokalisieren per Default (bis heute). Da gehört UTC als Zeitzone, sonst nichts. Ansonsten ist es nicht möglich für jeden User seine Lokalisierung abzuleiten.

        So sinnvoll wie SI-Einheiten sind, so sinnvoll ist es nunmal, geteilte Systeme auf Admin-Ebene auf Englisch zu betreiben. Vor dem zweiten Weltkrieg war es auch unsinnig, in Chemie und Physik eine Arbeit, die wahrgenommen werden sollte, nicht auf Deutsch zu veröffentlichen. Bei Sprachen sind die Leute irgendwie eingefahren. Esperanto bleibt aber nunmal Gedankenspiel.

        Und ganz ehrlich: Das Admin-Englisch kann sehr sehr schlecht sein. Mit all den Hilfsmitteln die einem noch zur Verfügung stehen muss man sich wirklich nur noch Basiskenntnisse aneignen um ne Fehlermeldung zu verstehen oder zu erkennen, ob eine automatische Übersetzung sinnvoll sein kann oder nicht. Wer das nicht hinbekommt ist schlicht unqualifiziert einen Server professionell zu betreiben.

        • Jens sagt:

          Das alles ist aber trotzdem keine Entschuldigung dafür, dass es der Hersteller seiner eigenen Software nicht gebacken kriegt, seine Updates unabhängig von der verwendeten Sprachversion zum Funktionieren zu bringen. Und es offenbar noch nicht einmal für nötig erachtet, diese zu testen …

          Und wenn er die Software in der Sprache anbietet dann kann ich diese auch installieren, das hat mit Professionalität überhaupt nichts zu tun.

          Das geschilderte Desaster deutet eher auf mangelnde Professionalität auf Seiten des Softwareherstellers Micro$oft schließen.

        • 1ST1 sagt:

          Mit allem einverstanden, bis auf UTC Zeit auf Servern. Wenn du mal über mehrere Server hinweg Logs auswerten musst, in einem SIEM zusammenfasst, usw. dann bist du über eine einheitliche Zeitzohne über ALLE Geräte froh.

          • Ralph D. Kärner sagt:

            Und diese gemeinsame Zeit"zone" ist nunmal weltweit UTC. Wenn mich mein israelischer Kumpel anruft und mir irgendwas erzählt, was um 3:15 bei ihm passiert ist und er sich dabei auf seine lokale Zeit beruft, dann fange ich meine Arbeit an, indem ich erst einmal schaue, welche Uhrzeit das nach meiner Zeitzone dann bei mir wäre? Ganz sicher nicht.

        • Ralph D. Kärner sagt:

          Ich unterschreibe das mal, allerdings mit dem Hinweis, dass man durchaus auch die RTC einer Windowsmaschine auf UTC laufen lassen kann und das Betrübssystem dennoch die lokale Zeit in der Taskleiste anzeigt. Früher immer wieder gern bei Dual-Boot-Clients mit Windows und Linux manuell in die Registry getackert, damit man nicht immer nach jedem Systemwechsel durch Reboot erst einmal die Uhrzeit anpassen musste.

        • Pinguin sagt:

          Hej, das hier schreibt jetzt jemand der glücklicherweise seit Jahrzehnten nichts mehr mit Windows-Administration zu tun hat. Du hast Recht, aus der Erfahrungs-Ebene. Aber nicht auf der logischen Ebene. Wenn die Installation einer lokalisierten Serverumgebung das Gesamtsystem brechen kann, sollte man sie gar nicht installieren können. Es ist beleidigend, anderen mangelnde Professionalität vorzuwerfen, insbesondere wenn es um Windows geht. Denn da sitzt die Unprofessionalität im System. Wenn Du die Erfahrung hast, gib sie weiter, aber beleidige nicht weniger Erfahrene Wenn man es sich genau ansieht, ist der Begriff "Unprofessionell" ohnehin nur geschaffen worden, um andere herabzusetzen. Sieh Dir die Fehler an, die Menschen machen, in den Konzernen, in Unternehmen und Politik. Streng genommen arbeitet niemand durchgängig "professionell".. Und ich würde mich wundern, wenn Du nicht auch schonmal verheerende Fehler gemacht hättest. Also bitte immer schön positiv kommunizieren.

    • Pau1 sagt:

      Deutsche Versionen sind teilweise Firmenpolicy.
      Man würde dann ja die Fehlermeldung besser verstehen.
      Aber in Frankreich z.B. gibt's wohl sogar gesetzliche Vorgaben.
      Und was ist mit Korea oder so ?

      • Anonymous sagt:

        "Besser verstehen", wenn die durch einen billigen Babelfischübersetzer gejagt wurde, wohl kaum und auch viel Spaß beim suchen nach Lösungen im Netz mit der nicht-englischen Fehlermeldung. Selbst zurückübersetzen ins englische nützt da nichts.
        Wenn du Glück hast findest du beim suchen die englische original Meldung und kannst dann damit weitersuchen.
        Sowas wir nur von Managern entschieden die keine Ahnung haben/nicht selbst damit arbeiten.

      • Andreas sagt:

        Ich habe gehört, dass so manche Bürokratie in der Menschheitsgeschichte teils unsinnige Regelungen hervorgebracht hat. Dies könnte auch so ein Fall sein.

        Den Sinn einer Amtssprache verstehe ich. Auch warum man Endanwender und Sachbearbeiter zwangsweise nur mit der Amtssprache arbeiten und konfrontieren will, auch gesetzlich. Da ist das sinnvoll.

        Aber auf IT-Server-Ebene ist es kontraproduktiv und realitätsfremd. Es ist nunmal Grundqualifikation. Kommt doch auch keiner auf die Idee dass jeder an die Elektrik darf oder ein Schaltplan in deutscher Prosa geschrieben sein muss, nur weil es nicht jeder ohne zu lernen, versteht.

        Man lässt also Leute an Server(!), die nicht in der Lage sind die Fehlermeldung zu verstehen weil sie nichtmal Basis-Englisch oder ein Übersetzungstool beherrschen und traut eben diesen Leuten genug geistige Fähigkeiten zu, DEN FEHLER AN SICH zu verstehen, für dessen Verständnis oder Behebung ebenso gelernt werden muss(te)? Und schneidet sich zudem von der globalen (Suchmaschinen)gesellschaft gleich noch mit ab? Und vertraut auf schlechte Lokalisierungen? Ja lol. Sieht nur am Whiteboard gut aus.

        Das hat nichts mit Überheblichkeit, sondern mit Realität zu tun. Es ist vielmehr absolut überheblich, als deutscher Techniker immer alles in Deutsch zu verlangen, obwohl es global erstellt wurde, aber Hauptsache seine Sicht über alles gestülpt, willkommen im Jahr 2023. Andere Länder die nicht so zentrale Stellungen haben, haben diesen Luxus erst gar nicht.

        • Bernd Bachmann sagt:

          Eine ziemlich engstirnige Sichtweise, wenn ich mir die Bemerkung erlauben darf. Ich gehe davon aus, dass die grosse Mehrheit beispielsweise der chinesischen Admins ihre Arbeit selbstverständlich auf Chinesisch tun. Zumindest bei den wenigen mir persönlich bekannten ist das der Fall.

          Aus den fehlenden Sprachkenntnissen dieser Gruppe auf ihre fachliche Qualifikation zu schliessen… nun ja. Und die "globale Suchmaschinengesellschaft" ist für die (a) uninteressant und (b) ohnehin auf legalen Wegen nicht zu erreichen.

        • Nur mal so sagt:

          Guter Einwand, ich hoffe in anderen Ländern gelten trotzdem die Gesetze der Physik. Und die Menschen die dort leben drücken es in ihrer Sprache aus. Und ich hoffe auch das Dank der Schwerkraft die Dinge dort auch von oben nach unten fallen.

      • Ralph D. Kärner sagt:

        Ich erwähne an solcher Stelle immer gern meine Umschulung, bei der es für alle eine Aufgabe gab, einen Windows Server unattended zu installieren. Was tatsächlich so lange scheiterte, bis ich auf die Idee kam, mir eine englische Version der Saftware aushändigen zu lassen und dann in der Hilfe zum unattended setup die Ursache für das Versagen aller mit der deutschen Variante zu finden: ein Übersetzungsfehler, der aus einer Subnetzmaske im Original eine IP-Adresse in der deutschen Übersetzung machte. Was keinem auffiel, weil wir alle ja in der Ausbildung waren und die Vorkenntnisse – vor allem mit Servern – eher rudimentär bis gar nicht vorhanden waren.
        Es ist übrigens eine Tatsache: Server mit deutscher Lokalisierung sind ausschließlich eine Sache der Bequemlichkeit.

    • M.D. sagt:

      Englische Server hatten wir hier auch in Betracht gezogen, waren uns aber nicht sicher, ob es nicht doch hier und da unschöne kleine Wechselwirkungen mit der Umgebung gibt, die vollständig Deutsch ist. Daher haben wir es gelassen.

      Auf der anderen Seite frage ich mich, wie Microsoft das i18n so kaputt hinbekommt, dass eine fehlende Datei oder eine Datei in falscher Version so ein Desaster auslöst.

      Die scheinen die Installation von Updates in vielen Sprachen abseits von Englisch nicht einmal getestet zu haben. :-(

    • Andy sagt:

      "Wie zur Hölle kommt man bitte auf die Idee einen Server auf Deutsch / non-English zu installieren?"

      Bei Exchange 2007 war das noch so, dass man explizit alles auf Englisch haben sollte.
      Später wurde uns von Microsoft klar kommuniziert, dass wir die deutsche Variante nutzen sollten.
      So original bei einem Workshop mit einem Vertreter von Microsoft Deutschland für Behörden zu hören bekommen.
      Ab dem Moment wäre die Frage eigentlich eher gewesen:
      Wie zur Hölle kommt man bitte auf die Idee einen Server nicht auf Deutsch zu installieren?

      Im Übrigen ist das wirklich oft Policy, das genau so zu tun. Und es liegt nicht in der Entscheidung des einzelnen Admin, das so zu machen, wie er es aus der Historie für professioneller hält.

      • Ralph D. Kärner sagt:

        "Und es liegt nicht in der Entscheidung des einzelnen Admin, das so zu machen, wie er es aus der Historie für professioneller hält."
        Wenn nicht einmal das in seiner Entscheidungsgewalt liegt, dann ist er kein Admin, sondern maximal Verwalter.

  5. A.R. sagt:

    Zurückgezogen. Der Mist wurde heute auf all unseren Exchange Servern 2016 und 2019 zwangsinstalliert. Alle Dienste natürlich deaktiviert. Kein Zugang über Teamviewer mehr. Wurde auch gleich mit zerschossen. Zugang nur noch über RDP. Update im WSUS nicht sichtbar, nur über Suche mit der Patchnummer. Microsoft sollte sich schämen. Einmal im Jahr der gleiche Mist.

    • Michael sagt:

      wieso bei allen zwangsinstalliert? habt ihr Auto Patching oder wieso zeitgleich und enforced?

    • M.D. sagt:

      Die automatische Installation von Updates ist keine gute Idee, nicht bei Clients aber schon gar nicht bei Servern. Das haben wir hier aus gutem Grunde unterbunden. Denn wenn so ein Desaster wie jetzt automatisiert über Nacht passiert, geht der maximale Stress unter hohem Zeitdruck am Morgen danach aber mal so richtig los. Keine angenehme Situation.

    • Toby sagt:

      Kapier ich auch nicht, auf meinen Servern wird nichts zwangsinstalliert, sondern das was ich freigebe. Konnte es jetzt wieder auf "nicht genehmigt" setzen und damit erstmal alles gut, auch wenn es mich natürlich nervt, wenn solche Sachen passieren, aber dieses Mal hats mich nicht erwischt :-)

    • Joachim sagt:

      Imho wurde noch nie ein Exchange Security Update "zwangsinstalliert". Auf keinen Fall das aktuelle. Wenn man den eigenen WSUS bzw die passenden GPOs nicht nutzt oder unter Kontrolle hat, sollte man echt nicht die Schuld auf andere schieben. Es ist tw. erschreckend, dass es nicht nur ziemlich viele Admins mit zu wenig Fachwissen gibt, sondern dass diese oft derart wenig von der Materie verstehen, dass sie sich mit Nonsense wie "Zwangsinstallation" glauben profilieren zu müssen.

    • Ralph D. Kärner sagt:

      Wieso läuft auf Deinem Server ein Dienst eines Drittanbieters, der von innen nach außen über einen nicht unter Deiner Kontrolle stehenden Server kommuniziert und damit Deinen Server direkt und ohne Umweg aus dem öffentlichen Netz dauerhaft und unbeaufsichtigt erreichbar macht?

  6. Pau1 sagt:

    Von einen Admin muss man rudimentäre english Kenntnisse erwarten können. Wenn ihr da viele Admis habt, die von einer englischen Fehlermeldung irretiert werden, habt ihr das falsche Management. Wieso werden solche Leute überhaupt eingestellt und warum fördert man keine Weiterbildung?
    Es sind ja auch viele Informations Quellen nur auf englisch.

    Aber als Clicki bunti auf den Scriptern rumhacken?
    Geht gar nicht.
    Natürlich achtet man darauf. Es gibt sogar das eine oder andere Programm das man zu englischen Ausgaben zwingen kann.
    Oder man schaltet das Environment kurzmal.
    Aber dann haut irgendein Programm Strings mit UTF-8 raus, z B. weil Intel unbedingt das "(r)" im Gerätenamen haben will.
    Mit Powershell ist das besser geworden, aber…

    Es gibt da auch Visual C. Nach einem Update konnte einige Kollegen ihre Projekte nicht mehr übersetzen, andere schon.
    Ursache war, das irgendein Penner bei MS auf die dumme Idee gekommen war, doch die Spracheinstellungen in den Compiler zu übernehmen. D.h. der C Source Code war plötzlich landesspezifisch…wieso kann so etwas freigegeben werden?
    Aus der Arroganz der Amerikaner.
    Beim VSC war diese gepaart mit Inkompetenz.

    • GüntherW sagt:

      "Wieso werden solche Leute überhaupt eingestellt und warum fördert man keine Weiterbildung?"

      Wie stellst du dir diese "Weiterbildung" vor? -_- Schüler haben über ein halbes Jahrzehnt Englisch in der Schule, mehrere Stunden am Tag. Was dabei rumkommt oder nicht rumkommt… Du lernst halt auch nicht einfach mal so eine Sprache. Gerade Kollegen die "alt" > 40 Sind.

      Irgendwelche Basisbegriffe hat man sicher sehr schnell gelernt, aber damit ist es ja auch nicht getan. Man muss halt auf der Oberfläche generell klarkommen und dazu sollte man schon die Sprache relativ gut beherrschen, auch weil es durchaus auf die genaue Bedeutung ankommt. Dann geht es ja auch nicht nur um die Oberfläche, sondern auch um die Fehlermeldung. In dem Moment wo du auf English stellst muss man in vielen Fällen den Fehler auch auf English suchen und spätestens da sollte man dann englisch gut lesen könnten.

      Das Ganze dann um mehr schlecht als recht auf einer englischen Oberfläche klarzukommen, OBWOHL es das Produkt auf auf Deutsch gibt.

      Wir brauchen jetzt nicht drüber diskutieren, dass es schon allein deshalb besser wäre auf English zu stellen, weil es da potentiell mehr Problemlösungen im Netz gibt. Nur wenn die Leute das halt nicht beherrschen….

  7. Pau1 sagt:

    Was steht denn in dem Patch Script?

    Exchange Server\V15\Bin
    .\ServiceControl.ps1

    Vielleicht ist es erbaulich zu wissen, warum die Services nicht mehr gestattet werden konnten und wird mit dem Script klar.
    Das MS schreibt was da warum falsch gelaufen ist ist ja ungewöhnlich.

  8. Orth sagt:

    Ich hab grad mal in den Download Ordner von SoftwareDistribution geschaut. Da liegt eine Exchange2016-KB5029388-x64-en.cab. Kommen die Probleme vielleicht von der Stelle? Hat auch eine andere Dateigröße als mein Download der Exchange2016-KB5029388-x64-de.exe. Hat die manuelle Installation bei jemandem geklappt mit de-DE Windows/Exchange? War der zurückgezogene Downloadlink cab oder exe in der englischen Fassung?

    Windows / Exchange ist de-DE

  9. flo sagt:

    Über die Frage ob die Serversprache Englisch die reine Lehre ist oder nicht kann man gerne streiten. Aber Leute runterzumachen weil sie ein Produkt das sie in Sprache Y gekauft haben bzw das in dieser Sprache angeboten wird verwenden halte ich für fragwürdig.

    Der small indie Developer aus Redmond hat zum über 9000. Mal seine Entwicklung und Software Tests (oder das was sie dafür halten) nicht im Griff. Das ist das Problem, nicht die Wahl des Sprachpakets.

    • R.S. sagt:

      Stimmt.
      Und es betrifft ja nicht nur deutsche Systeme.
      Drüben im Blog von Frank Zöchling hat auch ein Franzose diese Probleme bei seinem französischen System.

      Anscheinend haben die Mirosoft-Jungs das nur auf Englisch getestet.
      Wenn man ein Produkt schon in mehreren Sprachen anbietet, dann sollte man auch bei den Patches diese Sprachen bei den Tests berücksichtigen.

      Bei mir wird auch nichts automatisch im WSUS freigegeben.
      Und beim Exchange werden die Updates immer manuell installiert. Aber vorher warte ich noch 1-2 Tage, ob da im Netz Probleme mit den Updates bekannt werden.
      Die Strategie hat sich in diesem Fall wieder einmal bewährt.

      • Olli sagt:

        Mittlerweile sind die Probleme auch aus Italien und Polen gemeldet und das Statement von MS sagt ja non-EN – also alles außer Englisch wobei es auch mittlerweile einzelne Meldungen aus den USA selbst gibt, die scheinen aber andere Ursachen zu haben.

        Und zu dieser Englisch Überheblichkeit: Warum überhaupt andere Sprachen? Wenn alle nur noch Englisch sprechen, was dass für Probleme lösen würde! Moment English Natives sind gar nicht die Mehrheit. Alle müssen Chinesisch sprechen – Stop – auch nicht – seit ein paar Tagen sind die Inder die Meisten. Und Software-Entwicklung und Support findet ohnehin häufig in Indien statt. Alle Welt spricht also künftig Indisch. Wenn diese Englisch Propheten dann vom Chef gesagt bekommen Kein Indisch Kein Job, da will ich aber mal paar Gesichter sehen.

        Wenn eine Software in Sprache X angeboten wird, dann hat der Hersteller selbstverständlich bei Updates für das korrekte Funktionieren auch mit Sprache X zu sorgen – nichts anderes. Falls hier überhaupt etwas zum Thema Kompetenz zu sagen ist, dann einzig über die Inkompetenz der Entwickler und Manager die so was überhaupt zulassen.

      • Pau1 sagt:

        Angeblich kann MS das Problem der nicht-englischen Version nicht reproduzieren und bat im Log Files!
        Die haben auch nicht geholfen.
        So gesehen werden sie wohl schon multilingual getestet haben, was ja bei einem Patch nicht so schwer ist.
        Aber irgendwas ist bei den betroffenen Kunden anders…. Angeblich funktioniert der Patch auch auf einem frischen System nicht. Also bricht ab und startet die gestoppten Dienste nicht wieder.

    • Joachim Emde sagt:

      Die Arroganz, mit der Leute in den Kommentaren niedergemacht werden, weil sie eine nicht-englische Server-Version installiert haben, ist für mich wirklich unfassbar und eine Form von Victim Blaming. Ich bin immer davon ausgegangen und tue das eigentlich immer noch, dass eine andere Sprache einfach durch die Verwendung entsprechender Sprachpakete realisiert wird, und dass es eigentlich völlig egal ist, in welcher Sprache man einen Server betreibt. Die Binaries der ausführbaren Programme sollten auf jeden Fall für jede Sprache identisch sein.

      In diesem Fall wird es wohl so sein, dass ein Programmierer, statt in der Sprachdatenbank nachzuschauen, direkt einen englischen Begriff z.B. für einen Dienstnamen verwendet hat, weil ihm nicht bewusst war, dass das entsprechende Item lokalisiert ist. Das ist dann einfach ein Fehler in der Update-Funktion. Ich vermute die Ursache deshalb eher darin, dass altgediente Programmierer bei Microsoft in Rente gehen und die jungen Kollegen eben manche Dinge nicht wissen und Fehler machen.

      Dieses scheint mir aber ein generelles Problem zu sein, dass wir (ich schließe mich jetzt mal mit ein) Boomer unseren Nachfolgern eine hochkomplexe Welt hinterlassen, mit der wir die nach uns kommenden Generationen teilweise überfordern. Hier sind Dinge wie die Steuergesetzgebung, die unzähligen Vorschriften und komplizierten Verfahren, aber eben auch Computersysteme zu nennen.

      Ich kann die jungen Leute auch verstehen, wenn die gar keine Lust haben, sich diese komplizierte Welt anzutun. Wir, die Boomer, haben es in vielerlei Hinsicht übertrieben: Die Welt ist teilweise überkomplex und nicht mehr beherrschbar.

      • yumper sagt:

        Gut geschrieben – Ich sehe das Ganze genauso
        Einige nicht wenige wollen durch herumblaffen Ihre Schwachstellen überdecken, Hinzu kommt dann noch Arroganz.

        Allen muss jedoch klar sein die Systeme egal ob deutsch, englisch oder mandarin werden immer unbeherrschbarer.

        Und noch ein Spass am Rande der mir dazu einfällt.
        Versucht einmal in Deutschland ein HP Elite Notebook mit englischen Windows UK Keyboard und englischen Office zu kaufen, damit Excel Macros sprachkompatibel sind :-)

        Verstehe das ganze Geschrei eh nicht – Update lässt sich nicht installieren – Das Updatescript wurde also abgebrochen – Ergo die entsprechenden Dienste manuell aktivieren und starten,

        Fertig

        Weiter geht es.

      • 1ST1 sagt:

        Naja, jeder soll seine Server in der Sprache betreiben, wie er mag. Die Erfahrung zeigt aber, dass es durchaus klug ist, englische Server zu betreiben, nämlich aus dem Grund weil die meisten Anleitungen zu Software, die aus dem englischsprachigen Raum kommt, und das schließt auch Windows und sogar Linux mit ein, eben in englisch geschrieben ist. Anhand einer englischen Anleitung z.B. ein deutsches Windows, eingedeutschte Gruppenrichtlinien usw. zu konfigurieren, irgendwelche Security-Guidelines und Baselines durchzurackern und eventuell per Videosession mit einem Mitarbeiter des Herstellers in der USA zusammen eine Fehlersuche an einem lokalisierten System durchzuführen ist nicht wirklich so prickelnd.

        Weiter oben wurde bezweifelt, dass deutsche Clients mit nem englischen Server kommunizieren kann. Grundlos. Man kann auch deutsche Software auf nem chinesisch-sprachigen Windows-Server installieren, ist zwar doof, geht aber.

        • Pau1 sagt:

          Generell bleibt die Englische Sprache immer im System.
          Es gibt keinen Weg diese zu löschen, weil man in seinem IOT OEM gerne so irgendwas bei 200MB an englischen Texten wegsparen möchte, weil die eh niemand sieht und der Speicher knapp ist.

          Manche .DLL sind komplett sprachunabhängig.
          Andere müssen sprachspezifisch gepatscht werden.
          Wenn MS nur englische Server unterstützt, warum bieten sie dann andere Sprachen an?
          Marketing, klar.

          • Ralph D. Kärner sagt:

            "Manche .DLL sind komplett sprachunabhängig.
            Andere müssen sprachspezifisch gepatscht werden." Wenn Du diese Aussage belegen kannst, dann haben wir aber wirklich die Kacke am dampfen. Lokalisierte Sprache hat gar nichts in einer Bibliothek oder einem Programm zu suchen. Dafür gibt es dann entsprechende Dateien, die die entsprechenden Begriffe beinhalten und bei Bedarf auf das Ausgabegerät werfen lassen.

      • Martin B sagt:

        wir installieren die Server nur auf russisch, ist voll kompatibel und robust.

  10. rainbowd sagt:

    Akut viel wichtiger als philosophische Betrachtung des Themas wäre mir eine technische Lösung. Die genannten Scripte ziehen bei uns nicht. Wir machen jetzt einen Restore. Wenn alles wieder läuft beteilige ich mich auch gerne an der technischen und weiteren Bewertung des Umgangs von Microsoft mit den Kunden

  11. Max sagt:

    Ja es ist schade das Microsoft es nicht begriffen hat, bis heute, das man nicht die Funktionalität sondern die Darstellung lokalisiert.
    Das mit dem Patch heute ist ja mehr gewese als wirklicher Schaden, durchlaufen lassen und die Dienste wieder an den Start bringen, nervig aber lösbar.
    Der Supergau mit Office 97 seinerzeit war erheblich schlimmer, als Microsoft VBA eingedeutscht hat, sprich alle Funktionen wurden eingedeutscht, keine VBA App lief mehr gruselig, das war wirklich schlimm.
    An anderer Stelle las ich auch das man Server Linux und Windows immer in US-EN installiert als Profi, naja unter Windows ist es ratsam wie man sieht aber unter Linux wüsste ich nicht mal wie man es in einer anderen Sprache installieren sollte, da gibs das seit je her, nur eine Scheibe zum Installieren, es ist immer 'en', da gibs nix anderes, wenngleich es Sprachpakete gibt die die Anzeige lokalisieren und diverse Formate, wie sich das gehört.
    Ich find es durchaus legitim auch einen Windows Server in deutsch zu installieren, deshalb muss man niemanden diffamieren. Das hat nix mit Unprofessionalität oder sonstigem zu tun, sondern man nutzt einfach die Möglichkeiten, die man ja auch teuer bezahlt. Unprofessionell ist lediglich die Arbeitsweise vom Hersteller, der es bis Dato nicht begriffen hat wie Lokalisierung funktioniert.

    naja das ist aber auch nur meine Meinung und um mal ganz ketzersich zu sein, wofür braucht ein Server überhaupt eine grafische Oberfläche … das sind doch Sachen die auf nen Client gehören … mal so als Denkanstoss

    • R.S. sagt:

      Ein Server braucht auch keine grafische Oberfläche.
      I.d.R. installiert man den Windows Server in der Core-Version und die hat keine grafische Oberfläche.
      Das bringt auch noch den Vorteil der geringeren Angriffsfläche für Schadsoftware.

      • 1ST1 sagt:

        Kommt drauf an… Es gibt durchaus Software, die grafisch auf einem Server läuft, und das ohne dass es ein Terminalserver ist! Aber ja, Core, wo überall es geht!

  12. Bernd sagt:

    Fehler passieren nun mal. Ich/wir sind auch betroffen aber ich verstehe das so etwas passieren kann. Deswegen geht die Welt nicht unter.

    • 12-gang sagt:

      Hat hier jemand auch um etwa 18.00 bis 20.00 Uhr nochmals Exchange Secupdates gesynct bekommen?

      • M.D. sagt:

        Nein, ich sehe in den WSUS-Sync-Logs nur, dass das betreffende Desaster-Update zurückgerufen wurde (Sync von ca. 17 Uhr). Es wird jetzt als abgelaufen gelistet. Ich hatte es allerdings bereits zuvor auf "Abgelehnt" gestellt. Beim Listing der "Abgelehnten" Upates wird es zwar immer noch angezeigt, allerdings kann es nicht mehr auf "Installieren" gestellt werden, da es von Microsoft zurückgerufen wurde. Ein entsprechender Vermerk wird in der WSUS-Konsole angezeigt.

        Neue Updates für Exchange sind bis 0 Uhr nicht in unserem WSUS aufgetaucht.

    • Pau1 sagt:

      Naja. Kein Weltuntergang aber nur nicht, weil viele ihre Server auf Englisch fahren und immer das Risiko eingehen, ein paar Tage zu warten und zu hören was andere sagen. Ganz schön egoistisch.

    • Pau1 sagt:

      Naja. Kein Weltuntergang aber nur nicht, weil viele ihre Server auf Englisch fahren und immer das Risiko eingehen, ein paar Tage zu warten und zu hören was andere sagen. Ganz schön egoistisch.

  13. elwood sagt:

    Ich habe dieses "Update" auf einem Windows Server 2019 installiert (Version 1809) – die Maschine ist auf Englisch installiert. Ich weiß allerdings nicht, ob die Basisversion unten drunter nicht doch deutsch ist.

    Jetzt hängt der Server: diverse Exchange-Dienste lassen sich nicht mehr starten. Man kann weder senden noch empfangen.

    Hier ein Auszug aus einer Fehlermeldung im Event-Log:

    Microsoft Exchange couldn't start transport agents. The Microsoft Exchange Transport service will be stopped. Exception details: Failed to create type 'Microsoft.Exchange.TextMessaging.MobileDriver.TextMessagingRoutingAgentFactory' from assembly 'C:\Program Files\Microsoft\Exchange Server\V15\bin\Microsoft.Exchange.MobileDriver.dll' due to error 'Invalid agent assembly path.'. : Microsoft.Exchange.Data.ExchangeConfigurationException: Failed to create type 'Microsoft.Exchange.TextMessaging.MobileDriver.TextMessagingRoutingAgentFactory' from assembly 'C:\Program Files\Microsoft\Exchange Server\V15\bin\Microsoft.Exchange.MobileDriver.dll' due to error 'Invalid agent assembly path.'. —> System.ArgumentException: Invalid agent assembly path.
    — End of inner exception stack trace —
    at Microsoft.Exchange.Data.Transport.Internal.MExRuntime.FactoryTable.CreateAgentFactory(AgentInfo agentInfo)
    at Microsoft.Exchange.Data.Transport.Internal.MExRuntime.FactoryTable..ctor(IEnumerable agents, FactoryInitializer factoryInitializer)
    at Microsoft.Exchange.Data.Transport.Internal.MExRuntime.FactoryTable.CreateDefaultFactoryTable(IEnumerable agents, FactoryInitializer factoryInitializer)

    Ich werd wohl versuchen müssen, das System aus dem Backup wiederherzustellen. Eine Möglichkeit zur De-Installation dieses Updates sehe ich nicht….

    • Pau1 sagt:

      Microsoft rät auch vom deinstallieren ab.
      Läss aber offen warum.
      Weil die Löcher, die ja jetzt bekannt sind, so gefährlich sind, oder weil man befürchtet das der Deinstall eine Wüste hinterlassen könnte…

      Microsoft Software:
      Das letzte Abenteuer der EDV, für echte Männer!

  14. carstenp sagt:

    tja, wir haben nicht so viel glück gehabt! unser exchange startet diverse dienste nicht mehr, bzw lassen sich auch nicht mehr starten.

    • Max sagt:

      Moin,

      nach einem Neutsart auch nicht, das ist merkwürdig. Nunja entweder aus dem Backup holen oder die Datenbanken inkl. Logfiles (also DB Transaktionslogs) sichern. Dann eine identische Maschine erstellen (sprich Name IP Partitionen etc. pp, also wirklich identisch) Dann mit /Mode:RecoverServer neu aufsetzen und zum Schluss ihm die Datenbanken wieder unterjubeln.
      Ich denk Hafnium geplagte kennen diese Prozedur aus dem FF ansonsten gibt es eine gute Anleitung bei Franky.

      lg

      p.s. die alte Maschine muss nat. vom Netz getrennt werden

  15. Wolfgang S. sagt:

    Das fragliche Exchange Update wurde bei der letzten Synchronisation gelöscht. Die Exchange zeigen jetzt wieder aktueller Stand (grüner Haken). Hat offenbar MS auch über die WSUS-Aktualisierung rausgenommen.

    • Stefan S sagt:

      Ja es gibt einen Workaround,
      aber es gibt das Deutsche SU nicht mehr zum Download. Hat es irgendwelche Nebenwirkung das EN SU auf einem Deutschen Exchange zu installieren?

    • Anonymous sagt:

      Wenn ich den Workaround richtig interpretiere, liegt es nicht an der Deuschen Sprache auf dem Server, sondern im AD?
      Das Setup erwartet scheinbar den User "Network Service" und nicht wie im Deutschen AD "Netzwerkdienst"?

      • riedenthied sagt:

        Es liegt weder am AD, noch am Server. Es liegt an der Blödheit des Patchprogrammierers (wer hätte das erwartet?), dass er den Accountnamen und nicht die SID nutzt.

    • Olli sagt:

      Danke!

      """ "New-ADUser -Name "Network Service" """"

      Ehrlich Microsoft? Arbeitet dort nur noch ChatGPT und gar kein Mensch mehr?

  16. Dominic sagt:

    Ja das Thema Sicherheitspatch zeitnah zu installieren führt manchmal zu Diskussionen.

    Ich warne ständig davor diese Updates innerhalb kurzer zeit einzuspielen. Weiß gar nicht, ob ich noch die Diskussion hier finde, wo Herr Born selbst ein Verfechter des schnellen einspielen von Sicherheitspatch bei Exchange Servern ist.

    Lernen durch Schmerz. Nur weil alle schreien muss man nicht auch noch so handeln wie diese. Sofern man eine gute Härtung der ganzen Infrastruktur vorweisen kann muss nicht gleich jeder Sicherheitspatch "extrem" zeitnah eingespielt werden.

    • Günter Born sagt:

      Ich werfe mal einen alten Spruch ein, den ein alter Siemens-Mann mal in die Debatte einwarf (ich saß so 1990/91 in einem Standardisierungsgremium zu C.I.M. und wir hatten uns die Köpfe heiß diskutiert). Da kam von dem Mann: "Als ich auf der Autobahn zur heutigen Sitzung gefahren bin, fuhr vor mir ein Beton-Misch-Laster mit der Aufschrift 'Beton, es kommt darauf an, was man daraus macht'".

      Es kommt halt auf den Kontext an – ich gebe das wieder, was Microsoft empfiehlt. Bei einer Schwachstelle wie seinerzeit Hafnium ist es fahrlässig, mit den Patches noch eine Woche zu warten. Bei den Updates wird man von Fall zu Fall entscheiden müssen – immerhin stand ja bei meinem Blog-Beitrag zum den August 2023 Exchange Patches, welches Schwachstellen gefixt wurden und wie diese einzustufen sind (MS hat das im Techcommunity-Beitrag m.W. nicht dokumentiert).

    • Max sagt:

      Ja leider steht man da zwischen den Stühlen, der Fall Hafnium ist da bezeichnend, da war das Erscheinen des Patches fast gleichzusetzen mit der Kompromittierung. War ganz schön blöd seinerzeit und schob eine Welle des AdHoc Patchens an, kann man niemanden verübeln, war sehr stressig damals.

      Ja es gibt diverse Produkte oder Ansätze die Umgebung zu härten aber letztlich wenn etwas passiert und die Patche waren nicht drauf wird die Versicherung nicht zahlen.

      Man ist da sehr gekniffen und kann es kaum richtig machen.

    • Bernd sagt:

      Alle Systeme die von Extern erreichbar sind müssen immer besonders betrachtet werden. Hafnium hat uns gezeigt das ein zögerliches Verhalten durchaus krasse Konsequenzen haben kann. Snapshot und dann einspielen. Etwas "Mut" gehört natürlich dazu und einen Recoveryplan wenn's dann doch schief läuft.

  17. Peter sagt:

    Leider kam die Warnung zu spät. Das Update führt nach dem Auftreten des Fehlers keinen Rollback durch. Alle Exchange-Dienste sind deaktiviert. Im Eventlog findet man zur Zeit des Updates mehrere "Application Error"-Ereignisse (ID 1000). Alle beziehen sich auf die Anwendung msiexec.exe, Modul ntdll.dll und Ausnahmecode 0xC0000374.
    Das Aktivieren und Starten der Dienste hilft nicht, anscheinend wurden beim Update Dateien aktualisiert.

  18. Matthias Hoppe sagt:

    Mal eine andere Sichtweise zu der Sprachendiskussion: Es wird auf Deutsch angeboten, dann sollte man es auch nutzen können! Und vernünftige Software sollte die Anzeigesprache eigentlich gar nicht jucken.
    Natürlich sollte ein Admin grundlegend Englisch beherrschen, aber es SOLLTE nichts dagegen sprechen eine lokalisierte OS Version zu nutzen. Und bzgl. der Fehlermeldungen und Co…. das noch keiner mal auf die Idee gekommen ist bei MS da einen Button einzubauen "Meldung in Originalsprache anzeigen" oder so…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.