Windows-Update legt Exchange lahm: Was das Oktober-Patch an Mailservern anrichtet

Wer am Montagmorgen nach dem Oktober-Patchday plötzlich Beschwerden über Outlook Web App bekommt, ist nicht allein. Microsoft hat in einem Techcommunity-Beitrag (öffnet in neuem Tab) bestätigt, dass die Windows-Sicherheitsupdates vom 13. Oktober 2026 bei einem Teil der on-premises Exchange-Server zu Instabilität führen können – mit Symptomen, die sich erst im Laufe des Tages zeigen und auf den ersten Blick nach einem ganz anderen Problem aussehen.

Was konkret ausfällt

Laut Microsofts eigener Beschreibung treten mehrere Symptome auf, einzeln oder kombiniert: Outlook Web App (OWA) schlägt mit der Fehlermeldung "MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142)" fehl, begleitet von Event-ID 1006 im Anwendungsprotokoll. Parallel dazu wachsen die Mail-Warteschlangen im Tagesverlauf an, bis der Versand praktisch zum Erliegen kommt. Bei Servern, die in einer Database Availability Group (DAG) laufen, berichtet Microsoft zusätzlich von Problemen beim Erreichen des Quorums. Ein Neustart des Exchange-Servers behebt die Symptome laut Microsoft vorübergehend – bis sie erneut auftreten.

Betroffen sind laut Microsofts Statusseite für Windows Server 2025 (öffnet in neuem Tab) Exchange Server 2016, 2019 und die Subscription Edition, sofern sie auf einem der folgenden Windows-Server-Updates laufen: KB5126646 (Windows Server 2025), KB5126655 (Windows Server 2022), KB5126651 (Windows Server 2019) oder KB5126868 (Windows Server 2016). Entscheidend ist dabei nicht die eingesetzte Exchange-Version an sich, sondern das Windows-Betriebssystem darunter – das eigene Exchange-Sicherheitsupdate vom Oktober muss laut Microsoft für das Problem nicht einmal installiert sein.

Die eigentliche Ursache: ein neues Limit im Endpoint Mapper

Nach Microsofts Angaben auf der Statusseite (öffnet in neuem Tab) führt das Oktober-Update eine neue Standardbegrenzung ein, wie viel Arbeitsspeicher der Windows-eigene Endpoint Mapper für gleichzeitige Endpoint-Lookup-Aufrufe verwenden darf. Bei Workloads wie Exchange Server reicht das Standardlimit von 512 gleichzeitigen Lookup-Aufrufen unter hoher Last nicht aus – und genau das löst die beschriebenen Symptome aus. Nicht jeder Server ist gleich stark betroffen: Microsoft schreibt ausdrücklich, dass die Schwere und Geschwindigkeit vom individuellen Server-Load abhängt und manche Installationen das Problem möglicherweise nie bemerken.

Das erklärt auch, warum Betriebe mit wenig genutzten Exchange-Servern das Update unbemerkt installieren können, während stärker ausgelastete Systeme noch am selben Tag OWA-Ausfälle melden.

Was Microsoft rät – und was nicht

Die zentrale Botschaft aus dem Techcommunity-Beitrag ist unmissverständlich: Die Oktober-Updates sollen nicht deinstalliert werden. Microsoft begründet das damit, dass die Updates eine erhebliche Sicherheitsfracht transportieren und ihre Installation nicht wegen eines einzelnen Interoperabilitätsproblems mit Exchange verzögert werden sollte.

Stattdessen empfiehlt Microsoft einen Registry-Eingriff auf dem Exchange-Server selbst. Aus einer erhöhten Eingabeaufforderung wird folgender Befehl ausgeführt:

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

Anschließend ist ein Neustart des Servers erforderlich. Laut Microsoft kann dieser Registry-Schlüssel auch vor der Installation der Oktober-Updates gesetzt werden, ohne negative Auswirkungen – der Wert wird erst wirksam gelesen, sobald das Update installiert ist. Microsoft weist in seinem FAQ-Abschnitt außerdem darauf hin, dass bislang kein Fall bekannt ist, in dem der vorgeschlagene Grenzwert von 65536 nicht ausgereicht hätte, und dass derzeit kein separates Korrektur-Update von Windows- oder Exchange-Seite geplant ist – wer wartet, verzögert also nur die eigene Behebung.

Der Techcommunity-Beitrag beantwortet im FAQ-Teil auch die naheliegende Frage, ob es sinnvoller wäre, mit der Installation auf ein korrigiertes Update zu warten: Microsoft verneint das ausdrücklich und verweist erneut darauf, dass beide Teams – Windows und Exchange – das Problem zwar weiter untersuchen, aber keine kurzfristige Nachbesserung in Aussicht steht. Für Umgebungen, bei denen der Registry-Workaround nicht ausreicht, bietet Microsoft eine weitergehende Abhilfe über den offiziellen Support-Kanal an, die laut eigener Aussage nur im direkten Kontakt mit Microsoft Support for Business bereitgestellt wird – ein Hinweis darauf, dass es für einzelne, besonders stark ausgelastete Umgebungen noch keine pauschale zweite Stufe der Lösung gibt.

Kein Einzelfall: der Oktober-Patchday als Ganzes

Dass ausgerechnet ein Sicherheitsupdate auf Betriebssystemebene ein Produkt wie Exchange ausbremst, liegt auch daran, wie tief beide Systeme ineinandergreifen: Exchange verlässt sich auf den Windows-eigenen RPC-Endpoint-Mapper für seine interne Kommunikation zwischen Diensten, und genau an dieser Stelle hat das Oktober-Update eine neue Grenze eingezogen, ohne dass dies in den ursprünglichen Release Notes als Risiko für Exchange gekennzeichnet war. Wer bereits die Sicherheitslücke CVE-2026-62911 in Exchange im eigenen Haus nachverfolgt hat, kennt das Muster: on-premises betriebene Mailserver brauchen eine aktive Beobachtung über den reinen Patch-Status hinaus, weil Wechselwirkungen zwischen Windows- und Exchange-Updates sich erst im Betrieb zeigen, nicht beim Einspielen.

Für Mittelständler mit eigenem Mailserver: was jetzt zu tun ist

Dieses Problem trifft gezielt Unternehmen, die Exchange noch on-premises betreiben, statt vollständig auf Microsoft 365 umgestiegen zu sein – eine Konstellation, die im Mittelstand nach wie vor verbreitet ist, etwa aus Datenschutz-, Compliance- oder Kostengründen. Für diese Betriebe ergibt sich eine klare Reihenfolge:

1. Oktober-Update trotzdem installieren. Das Sicherheitsrisiko eines ungepatchten Servers wiegt laut Microsofts eigener Einschätzung schwerer als das vorübergehende Interop-Problem.
2. Registry-Schlüssel setzen, bevor OWA-Beschwerden eingehen. Da sich der Eingriff risikofrei vorab vornehmen lässt, spart das einen Vorfall und einen hektischen Neustart während der Geschäftszeit.
3. DAG-Umgebungen besonders beobachten. Wer mehrere Exchange-Server in einer Database Availability Group betreibt, sollte laut den gemeldeten Symptomen gezielt auf Quorum-Probleme achten, nicht nur auf OWA-Zugriffe.
4. Die eigene Monitoring-Routine um Event-ID 1006 ergänzen, damit ein wiederkehrendes Auftreten nach dem ersten Neustart nicht erst durch Nutzerbeschwerden auffällt.

Wer unsicher ist, ob die eigene Exchange-Installation betroffen sein könnte, findet die vollständige Liste der KB-Nummern in der offiziellen Statusseite (öffnet in neuem Tab) – ein Abgleich mit der installierten Windows-Server-Version und dem zuletzt eingespielten Update dauert wenige Minuten.

Ein wiederkehrendes Muster bei Patchdays

Dieser Vorfall reiht sich in eine Serie von Problemen ein, die der Oktober-2026-Patchday bei verschiedenen Windows-Versionen ausgelöst hat, wie auch heise online berichtet (öffnet in neuem Tab). Für IT-Verantwortliche im Mittelstand bedeutet das: Ein großer monatlicher Patchday ist kein einmaliger Installationsvorgang, sondern verlangt in der ersten Woche danach erhöhte Aufmerksamkeit für genau die Systeme, die am stärksten unter Last stehen – und bei Mailservern ist das praktisch immer der Fall.

Wer die eigene Patch-Routine bislang so gestaltet hat, dass Updates automatisch und ohne Nachkontrolle einlaufen, sollte diesen Fall zum Anlass nehmen, zumindest für geschäftskritische Server wie Exchange eine kurze Beobachtungsphase nach jedem großen Patchday einzuplanen – nicht um das Patchen zu verzögern, sondern um auf bekannte Nebenwirkungen wie diese vorbereitet zu sein, statt erst auf Nutzerbeschwerden zu reagieren.