Exchange Server Ausfall Oktober 2026: Falscher Verdächtiger

Von /

Update 18. Oktober 2026: Microsoft hat am 16. Oktober einen eigenen Beitrag mit Ursache und Workaround veröffentlicht. Das Problem steht jetzt auch in den Windows-Release-Notes, betroffen ist zusätzlich Windows Server 2016. Details im neuen Abschnitt „Update: Ursache und offizieller Workaround“ weiter unten; die Empfehlungen am Ende sind entsprechend angepasst.

Seit Mittwochnacht melden Exchange-Admins in Deutschland dasselbe Bild: Rund 24 Stunden nach dem Oktober-Patchday 2026 hängt OWA, Outlook verliert die Verbindung, Mails bleiben in der Queue. Die Datenbanken zeigen sich im Admin Center weiter als gemountet, aber der Informationsspeicher antwortet nicht mehr. Ein Neustart hilft, zumindest bis zum nächsten Tag.

Günter Born hat das am 15. Oktober unter dem Titel „Achtung: Exchange Server Okt. 2026-SU führen zu Ausfällen“ aufgegriffen. Der Titel war zu dem Zeitpunkt die naheliegende Lesart, aber er stimmt so nicht mehr. Noch am selben Nachmittag hat Microsoft im Exchange Team Blog bestätigt, dass die Windows-Server-Updates vom 13. Oktober das Problem auslösen, und zwar unabhängig davon, ob das Exchange-Sicherheitsupdate installiert ist.

Ich habe die Quellenlage für diesen Artikel direkt bei Microsoft nachgezogen. Hier steht, was belegt ist, was noch offen ist, und was ich daraus für die nächsten Tage ableite.

Was Microsoft zum Exchange Server Ausfall sagt

Microsoft hat den Techcommunity-Beitrag Released: October 2026 Exchange Server Security Updates am 15. Oktober 2026 um einen gelb hinterlegten Hinweis ergänzt. Darin nennt das Exchange-Team drei Windows-Updates als Auslöser: KB5126646 für Windows Server 2025, KB5126655 für Windows Server 2022 und KB5126651 für Windows Server 2019. Symptome laut Microsoft: OWA fällt mit der Fehlermeldung MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142) aus, im Application Log steht die Event ID 1006, und die Mail-Warteschlangen wachsen.

Der entscheidende Satz im Hinweis lautet: „Installation of October 2026 Exchange updates is not required for issues to occur.“ Microsoft untersuchte den Fall nach eigener Aussage zusammen mit den Windows-Kollegen. Einen Workaround gab es an diesem Tag noch nicht.

Auffällig war am 15. Oktober, wo der Hinweis nicht stand. Der Support-Artikel zu KB5126655 für Windows Server 2022 listete unter „Bekannte Probleme“ nur den WSUS-Fehlerdetail-Bug, und die Release-Health-Seiten für Windows Server kannten keinen Eintrag zu Exchange. Wer sich nur über die Windows-Kanäle informierte, erfuhr von dem Problem nichts. Das hat sich inzwischen geändert, dazu unten mehr.

Wie der Verdacht auf das Exchange-Update fiel

Die Verwechslung ist nachvollziehbar. Windows-Updates und Exchange-SU erscheinen am selben Dienstag und landen meist im selben Wartungsfenster. Als am Donnerstagmorgen die ersten Server standen, war das Exchange-Update der sichtbarste Neuzugang.

Frank Zöchling hat auf Frankysweb zunächst ebenfalls das Exchange-Update KB5128895 als Ursache genannt und den Artikel noch am 15. Oktober korrigiert. Den Ausschlag gaben die Kommentare: Mehrere Admins berichten von Exchange SE mit installiertem SU11, aber ohne Windows-Oktober-Updates, auf denen alles läuft. Umgekehrt beschreibt ein Kommentator den Ausfall auf einem Server mit OWA-Version 15.2.2562.53, also noch dem September-SU v2, bei dem nur die Windows-Updates neu waren. Zöchling selbst betreibt seine SE-Server nach eigener Angabe mit SU11 ohne Windows-Oktober-Updates und ist nicht betroffen.

Bei Born bestätigen Leser das gleiche Muster. Ein Kommentator nennt für seinen Ausfall ausdrücklich KB5126655 und das .NET-Update KB5128928, beide 24 bis 30 Stunden vor dem Stillstand installiert, das Exchange-Oktober-SU fehlte. Born hat seinen Artikel entsprechend ergänzt, nachdem ihm beim Überarbeiten der neue Microsoft-Hinweis aufgefallen war.

Die Frage, ob die .NET-Updates eine Rolle spielen, hat sich inzwischen erledigt: Microsoft nennt als Ursache ausschließlich die kumulativen Windows-Updates, und die technische Erklärung (siehe Update-Abschnitt) passt dazu.

Das Exchange-Update KB5128895 ist nicht das Problem, aber nötig

Dass das Sicherheitsupdate selbst unschuldig ist, ändert nichts an seiner Dringlichkeit. Das Oktober-2026-SU für Exchange SE (KB5128895), intern SU11, schließt sechs Schwachstellen: eine Remote-Code-Execution-Lücke, vier Rechteausweitungen (CVE-2026-77910, CVE-2026-87692, CVE-2026-87695, CVE-2026-87696) und eine Spoofing-Lücke (CVE-2026-70279). Es ersetzt das September-SU v2 (KB5121608) und behebt nebenbei zwei bekannte Fehler: den HTTP-500-Fehler bei veröffentlichten Kalendern (.ics) und den ContentEngine-Deadlock durch fehlende koreanische WordBreaker-Dateien.

Die RCE-Lücke CVE-2026-70571 stuft Microsoft als kritisch ein, CVSS 3.1 Basis-Score 8.1. Laut MSRC kann ein nicht authentifizierter Angreifer eine präparierte E-Mail an den Server schicken und darüber einen internen Konvertierungsprozess auslösen, der Code auf dem Server ausführt. Keine Benutzerinteraktion nötig. Die Angriffskomplexität ist mit „hoch“ bewertet, die Ausnutzung gilt Microsoft als „wahrscheinlicher“, bekannt ausgenutzt ist sie nach Stand vom 13. Oktober nicht. Für einen Mailserver, der per Definition fremde Mails annimmt, ist das eine Lücke, die ich nicht wochenlang offen lassen würde.

Hinzu kommt die Lage für ältere Versionen. Das Oktober-2026-SU ist laut Exchange-Team das letzte Update, das Teilnehmer des Period-2-ESU-Programms für Exchange 2016 und 2019 erhalten. Ab November gibt es Updates nur noch für die Subscription Edition. Microsoft schreibt dazu ausdrücklich, dass künftige CVE-Veröffentlichungen Exchange 2016 und 2019 nicht mehr nennen werden, obwohl die Versionen weiterhin betroffen sein können, weil Microsoft sie nicht mehr auf Schwachstellen testet. Wer noch auf 2016 oder 2019 steht, hat mit diesem SU das letzte Sicherheitsnetz in der Hand.

Was gerade in den Logs steht

Die Kommentare bei Frankysweb und Born geben ein recht einheitliches Bild, das sich mit Microsofts Beschreibung deckt. OWA liefert eine MailboxOfflineException, dahinter steckt die MapiExceptionMdbOffline mit ec=1142. Der Mailbox Replication Service meldet, dass er Jobs in einer Datenbank nicht verarbeiten kann. Dienste wie der IMAP4-Back-End stürzen ab, Anwendungspools werfen Kommunikationsfehler, Health-Mailbox-Cmdlets scheitern.

Mehrere Admins berichten zusätzlich von Veeam-Fehlern mit dem Exchange-VSS-Writer im Zustand VSS_WS_FAILED_AT_BACKUP_COMPLETE. Am 15. Oktober war noch unklar, ob das Backup den Ausfall auslöst oder nur das erste ist, was in der Nacht gegen den kranken Server läuft. Ich hatte auf einen Zähler oder Timer getippt, weil die Ausfälle fast immer nach etwa 24 Stunden kamen, egal wann das Backup lief. Das hat sich bestätigt, nur dass der Zähler nicht im Store sitzt, sondern im RPC Endpoint Mapper von Windows.

Update: Ursache und offizieller Workaround

Am 16. Oktober hat das Exchange-Team einen eigenen Beitrag veröffentlicht: Exchange servers may become unstable after installation of October 2026 Windows updates. Darin kommt eine vierte Plattform dazu: Neben KB5126646 (Server 2025), KB5126655 (Server 2022) und KB5126651 (Server 2019) nennt Microsoft jetzt auch KB5126868 für Windows Server 2016. Betroffen sein können Exchange 2016, 2019 und SE. Zu den bekannten Symptomen kommen DAG-Member, die kein Quorum mehr erreichen.

Microsoft schreibt, dass nicht alle Server gleich reagieren. Wie schnell und wie hart es einen Server trifft, hängt von der Last ab, manche Server sehen das Problem nie. Das erklärt, warum einzelne Admins in den Kommentaren bei Born und Zöchling mit installierten Oktober-Updates problemlos durchgekommen sind.

Die technische Erklärung steht nicht im Exchange-Beitrag, sondern im Windows-Release-Health-Eintrag Users might be unable to sign in to OWA or send emails on Exchange Server, eröffnet am 16. Oktober, Status „Mitigated“. Das Oktober-Update führt demnach ein neues Limit für den Speicher ein, den der Endpoint Mapper für Endpoint-Lookup-Aufrufe verwenden darf. Voreingestellt sind 512 gleichzeitige Lookups. Für eine Workload wie Exchange reicht das unter Last nicht, und wenn das Limit erreicht ist, scheitern die RPC-Verbindungen zum Store. Ein Neustart leert den Zähler, deshalb hilft er genau einen Tag lang.

Frank Zöchling bringt das Limit mit CVE-2026-96300 in Verbindung, einer Denial-of-Service-Lücke im RPC Endpoint Mapper (CWE-770, „Allocation of Resources Without Limits or Throttling“, CVSS 5.9), die Microsoft mit genau diesen Oktober-Updates geschlossen hat. Microsoft selbst stellt diese Verbindung in keinem der beiden Dokumente her, aber die Beschreibung der Lücke und die Beschreibung des neuen Limits passen so gut zusammen, dass ich die Deutung für sehr wahrscheinlich halte. Das hätte dann eine Konsequenz: Wer das Limit anhebt, hebt den Schutz vor dieser Lücke weitgehend wieder auf. Die Lücke gilt Microsoft als „Ausnutzung weniger wahrscheinlich“ und hat einen mittleren Score, das Risiko ist überschaubar. Aber man sollte wissen, was man tut.

Der offizielle Workaround besteht aus vier Schritten. Erstens: Die Windows-Oktober-Updates nicht deinstallieren, Microsoft sagt das ausdrücklich. Zweitens: In einer administrativen Eingabeaufforderung auf dem Exchange-Server das Limit anheben:

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

Drittens: Server neu starten, der Endpoint Mapper liest den Wert nur beim Start. Viertens: Beobachten und, falls das Problem wiederkommt, den Wert weiter erhöhen. Microsoft schreibt, dass dieser Weg in allen bisher betreuten Support-Fällen geholfen hat. Wer eine weitere Mitigation braucht, soll sich an den Business-Support wenden; was das ist, verrät die Release-Health-Seite nicht.

Zöchling hat auf Frankysweb ein PowerShell-Skript veröffentlicht, das den bestehenden Registry-Wert vorher als .reg-Datei sichert, einen deutlich höheren Wert (16777215) setzt und sich mit einem -Remove-Schalter wieder zurücknehmen lässt. Das ist für den Tag gedacht, an dem Microsoft einen echten Fix liefert und man das Limit wieder auf Standard stellen will. Einen Termin dafür nennt Microsoft nicht, in den Release Notes steht nur „We are investigating“.

Eine Warnung aus den Frankysweb-Kommentaren halte ich noch für erwähnenswert: Ein Admin berichtet, dass sein Windows Server 2016 nach der Deinstallation von KB5126868 auf einen Build von November 2016 zurückgefallen ist und RDP wegen CredSSP nicht mehr ging. Ich kann das nicht nachprüfen, aber es ist ein weiterer Grund, Microsofts Rat zu folgen und das CU drauf zu lassen.

Was ich jetzt tun würde

Stand 18. Oktober sieht die Empfehlung anders aus als am 15.

Für Server, die die Windows-Oktober-Updates noch nicht haben: Erst den Registry-Wert EpmapSavedContextCap setzen, dann das Windows-CU installieren, dann neu starten. So ist das Limit schon beim ersten Start nach dem Update hoch genug, und man spart sich den 24-Stunden-Ausfall. Das Zurückhalten der Windows-Updates, das ich am 15. Oktober empfohlen hatte, ist damit nicht mehr nötig, die CUs schließen zu viele Lücken, um sie wochenlang liegen zu lassen.

Für Server, die schon betroffen sind oder gerade im 24-Stunden-Rhythmus neu gestartet werden: Registry-Wert setzen, neu starten, Neustart-Skript abschalten. Bei einer DAG die Member nacheinander durchgehen und zwischendurch den Status der Datenbankkopien prüfen.

Für das Exchange-SU KB5128895 gilt unverändert: installieren, es hat mit dem Problem nichts zu tun und schließt eine kritische RCE-Lücke. Nach der Installation den Exchange Health Checker laufen lassen.

Und für Exchange 2016 und 2019: Dieses SU ist das letzte. Wer es jetzt wegen der Windows-Probleme auslässt, bekommt keine zweite Gelegenheit.

Den Registry-Wert würde ich mir in die Patch-Dokumentation schreiben, mit Datum. Sobald Microsoft das Problem in Windows selbst behebt, gehört er wieder weg, sonst bleibt der DoS-Schutz dauerhaft ausgehebelt.

Fazit

Die Schlagzeile vom Donnerstagmittag hatte den falschen Täter. Nicht das Exchange-Sicherheitsupdate legt die Server lahm, sondern die kumulativen Windows-Server-Updates vom 13. Oktober, auf allen vier Server-Versionen von 2016 bis 2025. Innerhalb von drei Tagen hat Microsoft die Ursache benannt, einen Registry-Workaround veröffentlicht und das Problem in den Windows-Release-Notes nachgetragen. Das ist schneller, als ich am 15. Oktober erwartet hatte, und die Kritik an der Kommunikation, die ich damals geschrieben habe, ist damit zum größeren Teil erledigt.

Was bleibt: Ein Sicherheitsfix im RPC Endpoint Mapper, der eine der wichtigsten Microsoft-Workloads nach einem Tag abschaltet, hätte im Test auffallen müssen. Exchange ist kein Exot.

Wer ein Wartungsfenster vor sich hat: Registry-Wert setzen, Windows-CU und Exchange-SU installieren, neu starten, 36 Stunden beobachten. Wer schon mittendrin steckt: Registry-Wert setzen, neu starten, Neustart-Skript löschen. Und den Techcommunity-Beitrag im Blick behalten, bis Microsoft den eigentlichen Fix liefert.

Quellen:

Nach oben scrollen