[English]Microsoft hat zum 14. Oktober 2025 das "Oktober 2025" Sicherheitsupdate für Exchange Server freigegeben. Das Sicherheitsupdate gilt Exchange Server 2016, Exchange Server 2019, und erstmals für Exchange Server Subscription Edition (SE). Exchange Online-Kunden sind bereits geschützt, die tangiert das Update nicht.
Ich bin über einen Hinweis im Diskussionsbereich (danke an den Leser für den Hinweis) und nachfolgenden Tweet auf die Veröffentlichung aufmerksam geworden. Microsoft hat dazu den Techcommunity-Artikel Released: October 2025 Exchange Server Security Updates veröffentlicht.
Die Security Updates (SUs) sind für die folgenden spezifischen Versionen von Exchange Server verfügbar:
Die SUs vom Oktober 2025 beheben Sicherheitslücken, die Microsoft von Dritten gemeldet und durch interne Prozesse von Microsoft in Exchange Server 2016, Exchange Server 2019, und Exchange Server Subscription Edition (SE) entdeckt wurden. Gemäß dieser Webseite wurden folgende Schwachstellen behoben:
- CVE-2025-53782: Server Elevation of Privilege Vulnerability; CVSS 3.1 Score 7.3
- CVE-2025-59248: Spoofing Vulnerability; CVSS 3.1 Score 7.5
- CVE-2025-59249: Server Elevation of Privilege Vulnerability; CVSS 3.1 Score 7.7
Obwohl Microsoft keine aktiven Exploits bekannt sind, empfiehlt Redmond Kunden, diese Updates sofort zu installieren, um die Exchange-Umgebung zu schützen. Exchange Online-Kunden sind bereits vor den in diesen SUs behobenen Sicherheitslücken geschützt und müssen keine weiteren Maßnahmen ergreifen, außer die Exchange-Server oder Exchange Management Tools-Workstations in ihrer Umgebung zu aktualisieren.
Letzte Patches für Exchange Server 2016 / 2019
Die SUs vom Oktober 2025 sind die letzten öffentlich verfügbaren SUs für Exchange Server 2016 und 2019. Ab diesem Zeitpunkt erhalten nur noch Kunden, die sich an ihr Microsoft-Kundenteam gewandt haben, um das Extended Security Update (ESU) für diese Versionen zu erhalten, neue SUs, die wir möglicherweise bis April 2026 für Exchange 2016 und 2019 veröffentlichen. Microsoft empfiehlt Nutzern dieser Exchange-Versionen das Upgrade auf Exchange SE.
Export von Authentifizierungszertifikaten nicht mehr möglich
Ab Oktober 2025 SU wird der Export des Exchange Server-Authentifizierungszertifikats und seines privaten Schlüssels mit Export-ExchangeCertificate aus Sicherheitsgründen blockiert (weitere Informationen finden sich unter KB5069337).
Maßnahmen und weitere Informationen
Nach der Installation des für den Exchange Server passenden Sicherheitsupdates sollen Administratoren den Health Checker erneut ausführen, um zu überprüfen, ob weitere Maßnahmen erforderlich sind. Treten während oder nach der Installation von Exchange Server Fehler auf, ist das SetupAssist-Skript auszuführen. Der Techcommunity-Artikel Released: October 2025 Exchange Server Security Updates enthält zudem Hinweise, was bei Problemen zu tun ist.
Ähnliche Artikel:
Exchange Server 2019: Keine weiteren CUs mehr in 2023; CU14 und CU15 kommen 2024
Exchange Server 2019: CU15 kommt erst Januar 2025
Microsoft Exchange: Wann kommt CU 15? Und weitere Neuigkeiten
Exchange Server 2016 / 2019 erreichen im Oktober 2025 ihr EOL
Exchange Emergency Mitigation Service nur für aktuelle Systeme
Exchange 2016/2019: Nov. 2024 SU nicht im Microsoft Update Catalog
Exchange 2016/2019: Nov. 2024 SUv2 enthält Bug
Microsoft Exchange Server Nov. Updates Re-Release (27.11.2024)
Microsoft Exchange Server Hybrid durch CVE-2025-53786 gefährdet
Exchange Server Sicherheitsupdates August 2025
MVP: 2013 – 2016
Bei uns lief das Update KB5066367 per WindowsUpdate augenscheinlich ordentlich durch, aber bei zwei 2019er Servern waren danach alle Dienste deaktiviert. Das Script unter https://www.alitajran.com/wp-content/uploads/scripts/RestartExchangeServices.ps1 hat da erstmal geholfen. Dann habe ich das KB manuell runtergeladen und nochmal per Hand nachinstalliert. Bei den betroffenen Servern hat das Windowsupdate etwa 2 Stunden für das KB gebraucht, aber brav bis 100% gezählt, bei einem konnte ich das sogar beobachten. Es ist ja bekannt, das PreScript des Update deaktiviert die Exchange Dienste. Dann klappt es nicht – aber WU kann das nicht erkennen, schließt nach unendlich Wartezeit das Update ab und schon ist der Server OutOfOrder.
Die manuelle Installation hat dann dennoch etwas über 30 Minuten gedauert, weil das Setup ewig im OWA Ordner Dateien in allen gefühlt 5000 Sprachen rumgesucht hat (validating Install). Gegen Ende der Installation kam dann eine Fehlermeldung, dass der Netzwerklistendienst und NLA (Network Location Awareness) nicht auf Steuerungsanfragen reagieren, mit der Option zum Abbruch oder Neuversuch. Manuell konnte ich die Dienste nicht beenden, ich habe die Prozesse dann kurzerhand beendet und die Dienste deaktiviert, ein Klick auf Retry in der KB Installation brachte eine erneute Durchforstung aller OWA Ordner und wieder 30 Minuten Wartezeit… Dann kam endlich das eigentliche Update, Dateien kopieren, dotNet Kompilierungen, Registry Anpassungen. Ich habe dann, als das Setup die Dienste wieder startete, meine beiden vorher deaktivierten Dienste NLA und Netzwerklistener wieder aktiviert und gestartet. Nunja, ich verbuche das mal unter dem Motto: selber Schuld, wenn SE noch nicht drauf ist und wir dir ein Update ausliefern, was mit aller Deutlichkeit unterstreicht, dass gestern Support-Ende war.
Ich werde wohl nie verstehen, warum Leute immer noch versuchen Exchange Updates per Windows Update oder WSUS zu installieren. Das gab in der Vergangenheit schon bei so vielen Leuten Probleme. Ich bleibe dabei, Exchange Updates installiert man am besten manuell über das Updatepaket aus dem Downloadcenter. Und mit der Meinung stehe ich nicht alleine da.
Ja, ich hatte in den letzten 15 Jahren auch schon Probleme mit einem Exchange Patch, aber nur weil es alle 2-3 Jahre mal Probleme mit einem Exchange gibt installiere ich die Updates nicht von Hand sondern per WSUS. Ob es damals tatsächlich keine Probleme gegeben hätte, hätte ich das Update manuell installiert ist ebenfalls fraglich.
Die Updates habe ich dafür per PowerShell Skript automatisiert und setze zudem wo immer möglich ein DAG ein. Wenn einer der Server nicht mehr läuft wird das Update des 2. Servers nicht durchgeführt und es passiert nichts weiter. Die Updates laufen am Tag im laufenden Betrieb, damit kann ich schnellstmöglich eingreiffen bei anderweitigen Problemen. Hat bisher viel Arbeit gespart und praktisch nie irgendwelche Probleme gegeben. Ich bin zufrieden damit.
Wenn die Zeit egal wäre bzw. die Kosten könnte ich auch jedes Update von Hand installieren, aber das liegt heutzutage einfach oft nicht mehr drin.
Von alles Hochverfügbarkeitsfunktionen von Microsoft Software (Hyper-V, SQL, Direct-Access, …) funktioniert das Exchange DAG am besten, finde ich.
Wie Daniel A. geschrieben hat, NIE über Windows Updates sondern IMMER über die CMD (als Administrator) und vorher das Pakte bei MS herunterladen. Dies wurde schon x-mal so kommuniziert und auch von MS empfohlen.
Das mit der CMD ist seit die auf EXE-Dateien umgestellt haben nicht mehr notwendig, das war nur bei dem vorherigen Format notwendig. Der exe-installer holt sich automatisch die höheren Rechte, das war eine der Verbesserungen. Falls der angemeldete User die nicht bekommen kann fragt der entsprechende Credentials ab. Vorher haben das viele Leute falsch gemacht.
Es ist nicht so, dass wir dies wollten. Trotz entsprechender Richtlinien hat WU heute 7:12 das einfach gemacht, außerhalb der erlaubten Zeiten, außerhalb des erlaubten Umfang. Und zu Zeiten der ZeroDay Auslieferung von so ziemlich jedem Update bei Microsoft ist manchmal ein paar Stunden keine Mails senden besser als das Nachsehen zu haben, wenn dein Server für alle angreifbar wird mangels Update, da verbau ich nicht alle Wege mit der ausschließlichen Freigabe per wsus.
Alles gut.
Wir haben das an unserem WSUS „ausgeklammert" damit das nicht passiert, ebenso wie bei SQL Updates. SQL und Exchange packen wir manuell an.
Wer betreibt eigentlich solchen Frickelmüll und warum? Ist das Dummheit oder einfach masochistiche Veranlagung?
Wir die hier schreiben, bist du immer so clever?
Dazu muss man nicht clever sein, um zu erkennen, dass das grandios vor die Wand fährt.
Aber einige sind halt verblendet….
Selbst das ist nicht mehr notwendig. Doppelklick reicht. Das Setup macht dann mittlerweile alles von allein :)
Korrekt aber ich vertraue dem alten Ansatz.
Thema Exchange-Updates über WSUS oder eher nicht. Bitte keine Diskussion, sondern Links zu entsprechender Doku von Microsoft. Ich habe jetzt mal 15 min in Netz gesucht und keine klaren Hinweise / Aussagen dazu gefunden. Jeder kann seine Systeme administrieren, wie er es mag oder am besten findet. Ich versuche meistens mich an die Hinweise der Hersteller zu halten, wenn es nicht offensichtlich Unsinn ist.
Und weil "man es schon immer so macht" oder "es irgendjemand mal irgendwann gesagt hat" hilft einem nicht weiter. Mir rennt in Wartungsfenster immer mehr die Zeit davon und daher habe ich die letzten Updates per WSUS (Exchange 2019 / SE, MSSQL 2019 und 2022) gemacht. Bisher habe ich nichts Negatives festellen können.
Offiziell schreibt MS da in der Doku nichts zu, sonst würden sie es (hoffentlich) auch nicht anbieten. Die MS-Blog Posts mit den neuen Updates liefern aber auch nur die manuellen Downloadlinks und keinen Hinweis auf WU/WSUS. Auch der KB-Artikel verweist ausschließlich auf den manuellen Download.
Wenn man mal die diversen IT-Foren durchgeht finden sich immer wieder genug Leute, die massiv Probleme nach dem Einspielen per WU/WSUS hatten, während diejenigen, die manuell updaten das nicht hatten. Und wenn diejenigen, die die Probleme hatten, nach einem Restore des Servers dann doch manuell installiert haben gab es die Probleme dann auch nicht.
Spätestens beim CU muss man sowieso manuell Hand anlegen, die gab es nämlich noch nie per WU/WSUS. Dann kann ich das auch bei den SU manuell machen und sicher sein, dass man da nicht in Probleme läuft.
Nachtrag:
Ein gutes Bsp. ist SharePoint Server.
"Offiziell schreibt MS da in der Doku nichts zu, sonst würden sie es (hoffentlich) auch nicht anbieten."
–> Hier installieren viele Kunden die Sicherheitsupdates auch über WSUS/Windows Updates und denken der Drops ist gelutscht. Dann kommen die Anrufe, dass die Suche nicht mehr geht, bis hin zum kompletten Stillstand der ganzen Farm (nicht ausgedacht, alles erlebt). Grund ist, wie einige ggf. Wissen, man muss nach den SharePoint Updates (Step 1), diese noch im Step 2 auf die DB anwenden. und das macht z.B. das Windows Update nicht. Dies ist z.B. ein Fall, wo man sieht was Sie meinen mit "hoffentlich".
Hallo,
grundsätzlich gebe ich Ihnen Recht, aber aus 20 Jahren Berufserfahrung und gefühlt >500 (1000) Sicherheitsupdates und unzähligen CU Updates/Upgrades kann ich Ihnen auch bestätigen, dass die geringsten Probleme bei der manuellen Ausführung der SUs passieren.
Alle Notfallwiederherstellungen durfte ich bisher lösen, wenn Kunden "versehentlich" die MS Exchange SUs per Windows Updates ausgerollt haben oder gar bei dem Prozess abgebrochen haben.
Eine indirekte Empfehlung von Microsoft, über diesen Weg zu gehen, kommt meiner Meinung nach aus dem Artikel raus, sonst würde MS auf Windows Updates verweisen. Bei Windows Updates finde ich es persönlich unschön dass man A nix sieht, wie weit er ist und B, wenn parallel noch andere Updates installiert werden, könnte es ja ggf. auch zu "Abhängigkeiten" kommen.
https://support.microsoft.com/en-us/topic/new-exchange-server-security-update-and-hotfix-packaging-kb5011363-ecc40b66-3b64-4eea-977f-a937f33990d0
Wahrscheinlich sind es genau diese Admins wo via WSUS Exchange-Patches installieren wo auch Exchange OnPrem mit hunderten Mailboxen ohne DAG und Reverse-Proxy betreiben. Dazu würden mir mehrere Begriffen einfallen …