EpmapSavedContextCap: Exchange-Rettung per Registry-Zettel – Grams IT

Es gibt Fehlermeldungen, die einem etwas sagen. Und es gibt „Something went wrong“. Wer seit dem Oktober-Patchday ein Outlook on the Web öffnet und statt des Postfachs diesen Satz sieht, dem hilft am Ende ein einziger DWORD-Wert namens EpmapSavedContextCap. Bis man darauf kommt, vergeht allerdings meist ein Tag. Genauer gesagt: ziemlich genau ein Tag. Und das ist schon der halbe Witz an der Sache.

Heute waren wir dran. Server neu gestartet, alles grün, kurzes Durchatmen – und dann die Erkenntnis, dass genau dieses „nach dem Neustart läuft es ja wieder“ das Symptom ist und nicht die Lösung. Jörn Walter hat den Fall heute bei Der Windows Papst ordentlich aufgeschrieben. Ich ergänze das um die Quellenlage bei Microsoft, eine kleine Rechnung und die Frage, wer bei diesem Patch eigentlich die Qualitätssicherung gemacht hat. Kleiner Spoiler: Sie und ich.

Das Fehlerbild: OWA „Something went wrong“ und MapiExceptionMdbOffline

Microsoft beschreibt die Symptome inzwischen selbst in den bekannten Problemen zum Windows-Server-2025-Update KB5134137: Benutzer kommen nicht mehr in OWA, Mails aus Outlook bleiben im Postausgang liegen, die Warteschlangen wachsen, und bei der Postfachreplikation gibt es Zugriffsprobleme. In manchen Konfigurationen meldet OWA MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142), dazu landet Event ID 1006 im Anwendungsprotokoll.

Besonders schön: Laut Borns IT- und Windows-Blog zeigt das Exchange Admin Center die Datenbanken währenddessen weiter als eingebunden an. Exchange ist also nicht kaputt. Es weiß es nur noch nicht. In DAG-Umgebungen kommt laut Born noch der Verlust des Quorums dazu, damit auch wirklich niemand sagen kann, er habe nichts bemerkt.

Der Neustart hilft, und zwar zuverlässig. Für ungefähr 20 bis 24 Stunden, so beschreibt es Der Windows Papst, so berichten es Admins bei Born und im Microsoft-Forum. Wer nach dem Reboot zufrieden Feierabend macht, hat am nächsten Tag zur selben Uhrzeit dieselbe Störung. Das ist kein Bug mehr, das ist ein Dienstplan.

Die Ursache: eine 512er-Grenze im RPC Endpoint Mapper

Schuld ist nicht Exchange, auch nicht die Exchange-SU KB5128895 oder das .NET-Update vom selben Tag, die anfangs im Verdacht standen. Schuld sind die kumulativen Windows-Server-Updates vom 13. Oktober 2026:

Windows Server 2025: KB5126646
Windows Server 2022: KB5126655
Windows Server 2019: KB5126651
Windows Server 2016: KB5126868

Laut Microsoft hat das Oktober-Update eine Standardgrenze für den Speicher eingeführt, den der Endpoint Mapper für Endpoint-Lookup-Aufrufe verwenden darf. Der Endpoint Mapper ist der Dienst hinter Port 135, bei dem RPC-Clients nachfragen, auf welchem Port ein bestimmter Dienst gerade lauscht. Exchange fragt dort ständig. Für Exchange unter hoher Last reiche die Standardgrenze von 512 gleichzeitigen Endpoint-Lookup-Aufrufen womöglich nicht aus, schreibt Microsoft. Die Exchange-Sicherheitsupdates vom Oktober müssen für den Fehler nicht einmal installiert sein.

„Gleichzeitig“ ist dabei ein dehnbarer Begriff. Wenn ein Server einen ganzen Tag braucht, um seine 512 Gleichzeitigkeiten zusammenzusammeln, sind das keine gleichzeitigen Aufrufe, sondern ein Leck mit Deckel. Genau so beschreibt es auch eine Leser-Analyse bei Born: In der RpcEpMap.dll zählt ein neuer Zähler gespeicherte Suchkontexte des Endpoint Mappers, und ab 512 geht es in einen Fehlerpfad. Der Windows Papst ergänzt, dass Exchange diese Kontexte erst wieder freigibt, wenn der zugehörige Prozess endet. Ein Leser bei Born hat den Zähler beobachtet und kam auf rund 18 neue Einträge pro Stunde. Das passt zum Tagesrhythmus.

Und warum das Ganze? CVE-2026-96300

Am selben Patchday hat Microsoft CVE-2026-96300 geschlossen, eine Denial-of-Service-Lücke im RPC Endpoint Mapper Service. Beschreibung: unkontrollierter Ressourcenverbrauch, über das Netzwerk ohne Anmeldung auslösbar, CVSS 5.9. Der Windows Papst nennt diese Lücke als Hintergrund der neuen Grenze. Fairerweise: Microsoft selbst stellt den Zusammenhang in den Known-Issue-Texten nicht her, und in den Kommentaren bei Born wird er als Vermutung gehandelt.

Plausibel ist er trotzdem. Man schließt eine Lücke, über die ein Angreifer den Endpoint Mapper mit Ressourcenverbrauch lahmlegen kann, indem man ihm ein Limit verpasst. Das ist sauberes Handwerk. Dass der fleißigste Angreifer auf dem eigenen Server ausgerechnet Exchange ist, hat dabei offenbar niemand ausprobiert. Der Denial of Service ist jetzt also behoben – Microsoft liefert ihn einfach selbst aus.

Die Lösung: EpmapSavedContextCap setzen, dann den ganzen Server neu starten

Microsofts Workaround ist eine Registry-Änderung, die die Grenze anhebt. Auf jedem Exchange-Server in einer Eingabeaufforderung mit Administratorrechten:

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

Danach muss der komplette Server neu starten, nicht nur die Exchange-Dienste. Der Endpoint Mapper liest den Wert nur beim Systemstart. Bei Born berichtet ein Admin von einem Kunden, der den Wert gesetzt, aber nicht neu gestartet hatte – und sich wunderte, dass am nächsten Tag wieder alles stand. In einer DAG die Knoten nacheinander in den Wartungsmodus nehmen und neu starten. Tritt der Fehler trotzdem wieder auf, den Wert weiter erhöhen, so steht es auch bei Microsoft. Der Windows Papst berichtet von stark belasteten Servern, die erst mit 16777215 stabil liefen.

Ob der Wert überall gesetzt ist und ob seitdem neu gestartet wurde, lässt sich von einem Exchange-Server aus prüfen:

Invoke-Command -ComputerName (Get-ExchangeServer).Name -ScriptBlock {
    [pscustomobject]@{
        Server = $env:COMPUTERNAME
        Cap    = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Rpc' -Name EpmapSavedContextCap -ErrorAction SilentlyContinue).EpmapSavedContextCap
        Boot   = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
    }
} | Format-Table Server, Cap, Boot -AutoSize

Steht bei Cap nichts, gilt die Standardgrenze. Liegt Boot vor dem Zeitpunkt, an dem Sie den Wert gesetzt haben, ist die Änderung noch nicht aktiv.

Was Sie nicht tun sollten: die Oktober-Updates deinstallieren. Microsoft rät ausdrücklich davon ab, und das zu Recht. Damit wäre der Exchange-Fehler weg, aber CVE-2026-96300 und alle anderen Oktober-Lücken wieder offen. Wer mit dem Registry-Wert nicht weiterkommt, kann laut Microsoft über den Support for Business eine zusätzliche Abhilfe bekommen.

Eigene Rechnung: Wie lange hält der Workaround?

Wenn sich die Kontexte gleichmäßig ansammeln und 512 Stück ungefähr einen Tag reichen, lässt sich grob abschätzen, was die neuen Werte bringen. Das ist eine Modellrechnung, keine Messung: Die echte Laufzeit hängt von der Last ab.

Balkendiagramm mit logarithmischer Skala: Bei der Standardgrenze 512 fällt Exchange nach etwa 1 Tag aus, mit 65.536 nach etwa 128 Tagen, mit 16.777.215 nach rund 90 Jahren. Eine gestrichelte Linie markiert den nächsten Patchday nach etwa 30 Tagen.

65536 geteilt durch 512 ergibt 128. Aus einem Tag werden also rund 128 Tage. Mit 16777215 wären es 32.768 Tage, also etwa 90 Jahre, und damit dürfte das Thema für die meisten Server erledigt sein, bevor deren Hardware es ist. Andere kommen auf kürzere Zeiten: Ein bei Born zitierter Admin rechnet mit rund 28 Tagen statt 22 Stunden, ein Kommentator mit etwa 96 Tagen im ungünstigsten Fall. Die Spanne zeigt vor allem, wie stark die Last mitspielt.

Der eigentliche Punkt ist ein anderer. Selbst die vorsichtigste Schätzung landet ungefähr beim nächsten Patchday, und der bringt ohnehin einen Neustart mit. Der Workaround funktioniert also vor allem deshalb, weil Microsoft uns sowieso jeden Monat zum Reboot zwingt. Das ist kein Fix. Das ist ein Wecker mit längerer Schlummertaste.

Was Microsoft dazu sagt – und was nicht

Zur Ehrenrettung: Microsoft hat schnell reagiert. Patchday war am 13. Oktober, am 15. Oktober hat das Exchange-Team die Probleme bestätigt, am 16. Oktober stand der Registry-Workaround im Exchange Team Blog. Microsoft betont, dass nicht alle Server gleich betroffen sind: „Some servers might never see a problem.“ Und die Grenze an sich ist keine dumme Idee, wenn sie eine echte DoS-Lücke schließt.

Nur: Ein Exchange-Server unter Last ist kein exotischer Sonderfall. Er ist einer der klassischen Gründe, warum überhaupt jemand Windows Server betreibt. Dass eine neue RPC-Grenze nie gegen das eigene Mailprodukt unter realistischer Last lief, kann man kaum anders erklären, als dass dieser Test in den Kundenbetrieb verlagert wurde. Ein Admin brachte es im Microsoft-Forum auf den Punkt, zitiert von The Register: „I spent all weekend on my servers because of this.“ Er kritisierte außerdem, dass Kunden nicht Microsofts Tests übernehmen sollten. Dem ist wenig hinzuzufügen.

Der Stand heute: Im Release-Health-Dashboard steht das Problem laut TechRepublic als „Mitigated“, nicht als behoben. Am 26. Oktober kam für Windows Server 2025 das Out-of-Band-Update KB5134137. Es repariert den Exchange-Fehler nicht, sondern führt ihn ordentlich unter den bekannten Problemen auf, samt Verweis auf den Registry-Wert und dem Satz, Microsoft untersuche das Problem weiter. Ein Notfall-Update, das den Notfall nur dokumentiert – auch das ist eine Form von Transparenz. Der Windows Papst schreibt, laut Microsoft sei keine kurzfristige Folgeversion geplant. Eine Microsoft-Quelle mit dieser Aussage habe ich nicht gefunden; offiziell heißt es nur, man untersuche das Problem.

Und dann ist da noch das Timing. Der Oktober 2026 ist laut eSecurity Planet und anderen Berichten das Ende der verlängerten Sicherheitsupdates für Exchange 2016 und 2019. Wer noch auf diesen Versionen sitzt, bekommt also zum Abschied ein letztes Exchange-Update und dazu einen Windows-Patch, der den Server täglich umwirft. Würdevoller kann man ein Produktende kaum inszenieren.

Was Exchange-Admins jetzt prüfen sollten

Die Abarbeitung ist kurz, aber jeder Punkt ist schon mindestens einem Admin auf die Füße gefallen:

Ist eines der vier Oktober-Updates (oder ein späteres kumulatives Update) auf den Exchange-Servern installiert?
Ist EpmapSavedContextCap auf allen Exchange-Servern gesetzt, nicht nur auf dem, der gerade ausgefallen ist?
Wurde jeder Server nach dem Setzen komplett neu gestartet?
Wird Event ID 1006 im Anwendungsprotokoll überwacht, damit ein Rückfall auffällt, bevor die Benutzer anrufen?
Steht die Änderung im Änderungsprotokoll, mit Grund und Hinweis, dass sie nach einem echten Fix wieder raus kann?

Ein Leser bei Born lässt seine Server per Watchdog automatisch neu starten, sobald Event 1006 auftaucht. Als Notnagel verständlich, als Betriebskonzept eher ein Geständnis. Ein anderer Leser berichtet, nach der Änderung würden freigegebene Postfächer nicht mehr automatisch eingebunden. Das ist bislang nur dieser eine, unbestätigte Bericht, aber ich würde nach dem Neustart kurz hinschauen.

Fazit

Der Oktober-Patch schließt eine echte Lücke im RPC Endpoint Mapper und baut dabei eine Grenze ein, die Exchange unter Last nach einem Tag reißt. Der Workaround ist ein Registry-Wert und ein Neustart, er funktioniert, und er ist genau das, was Microsoft selbst sagt: vorübergehend. Ärgerlich ist weniger der Fehler als die Tatsache, dass er bei einem so naheliegenden Szenario wie „Exchange auf Windows Server“ erst im Echtbetrieb auffiel.

Setzen Sie den Wert heute auf allen Exchange-Servern, starten Sie neu und dokumentieren Sie, warum. Lassen Sie die Updates drauf. Und schauen Sie an jedem Patchday ins Release-Health-Dashboard, ob aus „Mitigated“ irgendwann „Resolved“ geworden ist.

Ob es bei uns hält, weiß ich morgen um diese Uhrzeit.

Quellen: