ISW-Tools
Jörn Walter Veröffentlicht 5 Min. Lesezeit Office & Exchange
Der Windows Papst · Exchange · 04.11.2026

OWA zeigt „Something went wrong“: Exchange-Ausfall nach dem Oktober-Update und der Registry-Wert EpmapSavedContextCap

Nach dem Oktober-Patchday lief der Exchange-Server zunächst völlig normal – und nach rund einem Tag meldete Outlook on the Web nur noch „Something went wrong“. Die Ursache liegt nicht in Exchange und auch nicht im .NET Framework, sondern in einer neuen Grenze im RPC Endpoint Mapper von Windows Server. Abhilfe schafft ein einziger DWORD-Wert.

Das Fehlerbild

Bei mir zeigte sich das Problem zuerst in OWA: Nach der Anmeldung erschien statt des Postfachs die Meldung „Something went wrong“. Ein Neustart des Servers half – aber nur bis zum nächsten Tag. Typisch sind folgende Symptome:

  • OWA-Anmeldung schlägt fehl bzw. endet in „Something went wrong“
  • Exchange meldet die Postfachdatenbanken als offline, in den Details taucht MapiExceptionMdbOffline (ec=1142) auf
  • Outlook-Clients verlieren die Verbindung, die Mail-Warteschlangen laufen voll
  • Nach einem Neustart läuft alles wieder – für etwa 20 bis 24 Stunden

Gerade dieses Muster „läuft nach dem Reboot, fällt nach einem Tag aus“ ist der deutlichste Hinweis auf die Ursache.

Die Ursache: neue Grenze im RPC Endpoint Mapper

Die kumulativen Windows-Server-Updates vom Oktober 2026 begrenzen die Zahl der gespeicherten Endpoint-Lookup-Kontexte im RPC Endpoint Mapper (RpcEpMap.dll) standardmäßig auf 512. Hintergrund ist die am selben Patchday geschlossene Denial-of-Service-Lücke CVE-2026-96300 im RPC Endpoint Mapper (unkontrollierter Ressourcenverbrauch).

Exchange legt diese Kontexte im laufenden Betrieb fortlaufend an und gibt sie erst wieder frei, wenn der zugehörige Exchange-Prozess beendet wird. Unter Last ist die Grenze daher nach etwa einem Tag erreicht. Ab diesem Moment nimmt der Endpoint Mapper keine neuen Lookups mehr an, RPC-Verbindungen zur Postfachdatenbank schlagen fehl – und OWA zeigt „Something went wrong“.

Nicht das .NET-Update: Am selben Patchday erschienen auch die Exchange-SU (Exchange SE: KB5128895, „SU11“) und kumulative .NET-Framework-Updates. Deshalb wurde anfangs oft das .NET-Update verdächtigt. Auslöser ist laut Microsoft aber das Windows-Server-Update – die Exchange-SU muss für den Fehler nicht einmal installiert sein.

Betroffene Windows-Updates

Betriebssystem Update Oktober 2026
Windows Server 2025 KB5126646
Windows Server 2022 KB5126655
Windows Server 2019 KB5126651
Windows Server 2016 KB5126868

Betroffen ist jede Exchange-Version, die auf einem dieser Systeme läuft. Wie schnell der Fehler auftritt, hängt von der Last ab – manche Server laufen nie in die Grenze.

Die Lösung: EpmapSavedContextCap setzen

Microsoft rät ausdrücklich davon ab, die Oktober-Updates zu deinstallieren – sie schließen zu viele Sicherheitslücken. Stattdessen wird die Grenze per Registry angehoben.

Schritt 1: Wert setzen

In einer Eingabeaufforderung mit Administratorrechten auf jedem Exchange-Server:

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

Im Registrierungs-Editor steht der Wert danach unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc als EpmapSavedContextCap vom Typ REG_DWORD mit 0x00010000 (65536).

Schritt 2: Server neu starten

Der Endpoint Mapper liest den Wert nur beim Systemstart. Ein Neustart der Exchange-Dienste genügt nicht – der ganze Server muss neu gestartet werden. In einer DAG die Knoten nacheinander in den Wartungsmodus nehmen und neu starten.

Schritt 3: Alle Exchange-Server prüfen

Mit PowerShell lässt sich der Stand aller Exchange-Server auf einmal abfragen:

$server = (Get-ExchangeServer).Name
Invoke-Command -ComputerName $server -ScriptBlock {
    $wert = (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Rpc' -Name EpmapSavedContextCap -ErrorAction SilentlyContinue).EpmapSavedContextCap
    $start = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
    [pscustomobject]@{
        Server               = $env:COMPUTERNAME
        EpmapSavedContextCap = if ($null -eq $wert) { 'nicht gesetzt (Standard 512)' } else { $wert }
        LetzterNeustart      = $start
    }
} | Select-Object Server, EpmapSavedContextCap, LetzterNeustart | Format-Table -AutoSize

Liegt der letzte Neustart vor dem Setzen des Werts, ist die Änderung noch nicht aktiv.

Fallstricke aus der Praxis

Wert gesetzt, Fehler bleibt? Der häufigste Grund ist der fehlende Neustart. Danach gilt: Kehrt der Fehler zurück, muss die Grenze laut Microsoft weiter erhöht werden. In der Praxis berichten Administratoren von stark belasteten Servern, die erst mit deutlich höheren Werten (bis 16777215) stabil liefen.
  • Nur ein Knoten angepasst: Der Wert gehört auf jeden Exchange-Server, nicht nur auf den, der gerade ausfällt.
  • Updates zurückgerollt: Das beseitigt zwar den Fehler, öffnet aber CVE-2026-96300 und alle anderen Oktober-Lücken wieder. Nicht empfehlenswert.
  • Auf ein Fix-Update warten: Laut Microsoft ist keine kurzfristige Folgeversion geplant. Der Registry-Wert ist bis auf Weiteres die Lösung.
  • Dokumentation vergessen: Den Wert im Änderungsprotokoll festhalten. Sobald Microsoft ein korrigiertes Update liefert, kann er wieder entfernt werden.
# Erst nach einem korrigierten Update von Microsoft wieder entfernen
Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Rpc' -Name EpmapSavedContextCap

Compliance-Einordnung

Der Fall zeigt gut, warum Patch- und Änderungsmanagement zusammengehören: Das Update darf nicht aus Bequemlichkeit zurückgenommen werden (BSI IT-Grundschutz OPS.1.1.3 Patch- und Änderungsmanagement, NIS2 Art. 21 Abs. 2 – Umgang mit Schwachstellen), die Abweichung von der Standardkonfiguration muss aber nachvollziehbar dokumentiert werden (BSI APP.5.2 Microsoft Exchange und Outlook). Wer Updates vor dem Rollout auf einem Testsystem unter realistischer Last laufen lässt, sieht solche Effekte früher.

Fazit

Zeigt OWA nach dem Oktober-Update „Something went wrong“ und fällt Exchange immer etwa einen Tag nach dem Neustart aus, ist mit hoher Wahrscheinlichkeit die neue 512er-Grenze im RPC Endpoint Mapper schuld. EpmapSavedContextCap auf 65536 setzen, Server neu starten, beobachten – und bei erneutem Auftreten den Wert weiter erhöhen. Die Updates bleiben installiert.

Passende ISW-Tools

ISW Windows Patch Compliance Analyzer – zeigt, welche Server die Oktober-Updates bereits erhalten haben, inklusive KB-Suche und Patch-Tuesday-Übersicht.

ISW Exchange Configuration Analyzer – liest die Konfiguration aller Exchange-Server aus und dokumentiert sie als HTML, PDF oder CSV.

ISW Exchange SMTP Tester – prüft nach dem Neustart schnell, ob Mailfluss und SMTP wieder sauber laufen.

ISW Windows Live-Ereignismonitor – überwacht die Ereignisprotokolle live und meldet Ausfälle, bevor die Anwender anrufen.

Quellen: Microsoft Exchange Team Blog „Exchange servers may become unstable after installation of October 2026 Windows updates“ (17.10.2026); Frankys Web „Exchange Server SE: Probleme mit den Oktober-Updates für Windows Server“; Borns IT- und Windows-Blog (17.10.2026); Rafael Pfister „Exchange-Ausfälle nach den Windows-Server-Updates vom Oktober 2026“; eigene Erfahrung aus dem Kundenbetrieb.

Porträt Jörn Walter

Jörn Walter

Inhaber von IT-Service Walter in Euskirchen, betreut Windows-Umgebungen von Unternehmen und entwickelt die ISW-ADTools.

Alle Beiträge von Jörn Walter