Eine Grafik mit rotem Hintergrund, die eine digitale IT-Struktur in einem abstrakten Design darstellt. Geeignet für technische Themen.
Am Patchday vom 13. Oktober 2026 hat Microsoft wie gewohnt Sicherheitsupdates für alle unterstützten Windows-Server-Versionen verteilt. Zwei Tage später häuften sich die Meldungen: Exchange-Server stellten rund einen Tag nach der Installation den Dienst ein. Postfächer waren nicht mehr erreichbar, E-Mails blieben in den Warteschlangen hängen.
Microsoft hat das Problem bestätigt, ein Registry-Eintrag schafft vorerst Abhilfe. Was genau passiert ist, wie der Workaround funktioniert und was der Fall über einen verlässlichen IT-Betrieb verrät, lesen Sie hier.
Das Wichtigste in Kürze
- Die Windows-Server-Updates vom 13. Oktober 2026 (KB5126646, KB5126655, KB5126651, KB5126868) führen auf Exchange-Servern nach rund 24 Stunden zu Ausfällen
- Betroffen sind Exchange Server 2016, 2019 und Subscription Edition im eigenen Rechenzentrum; die Exchange-Updates selbst sind nicht der Auslöser
- Ursache ist ein neues Limit in der Windows-Komponente RPC Endpoint Mapper, das auf Exchange-Servern nach etwa einem Tag erreicht wird
- Microsoft hat einen Registry-Eintrag als vorübergehenden Workaround freigegeben; die Windows-Updates sollen nicht deinstalliert werden
- Der Fall zeigt, wie wichtig gestaffelte Updates, funktionsnahes Monitoring und klare Zuständigkeiten sind
Was nach dem Oktober-Patchday passiert ist
Die ersten Meldungen kamen am 15. Oktober 2026. Administratoren berichteten, dass ihre Exchange-Server etwa 22 bis 24 Stunden nach der Installation der Windows-Updates die Verbindung zu den Postfachdatenbanken verloren.
Benutzer konnten sich nicht mehr anmelden, Outlook im Web funktionierte nicht mehr und E-Mails blieben in den Warteschlangen hängen, bis der Mailfluss vollständig zum Stillstand kam.
Das Kritische daran: Im Exchange Admin Center wurden die Datenbanken weiterhin als verbunden angezeigt. Wer nur auf diese Ansicht schaute, sah also kein Problem. Im Anwendungsprotokoll tauchte dagegen das Ereignis 1006 mit der Meldung „MapiExceptionMdbOffline“ auf. In einigen Umgebungen mit Database Availability Groups erreichten die Mitglieder zudem kein Quorum mehr. Ein Neustart des Servers half – allerdings nur bis zum nächsten Tag.
Welche Systeme betroffen sind
Betroffen sind Exchange Server 2016, Exchange Server 2019 und die Exchange Server Subscription Edition (SE) im eigenen Rechenzentrum, sofern auf dem Server eines der folgenden Windows-Updates installiert ist:
| Windows Server | Update vom 13.10.2026 |
|---|---|
| Windows Server 2025 | KB5126646 |
| Windows Server 2022 | KB5126655 |
| Windows Server 2019 | KB5126651 |
| Windows Server 2016 | KB5126868 |
Wichtig: Die Exchange-Sicherheitsupdates vom Oktober müssen dafür nicht installiert sein. Der Fehler entsteht allein durch das Windows-Update. Ob auch Exchange Online betroffen war, ist nicht bestätigt. Medienberichten zufolge wird der Zusammenhang mit einer zeitgleichen Störung vermutet.
Ursache und Workaround
Microsoft hat das Problem am 15. Oktober bestätigt – die offizielle Stellungnahme gibt es hier.
Für den Workaround kursieren zwei Werte: 65536, den Microsoft nennt und 16777215, den unter anderem ein verbreitetes PowerShell-Skript setzt.
Der Workaround von Microsoft
- Deinstallieren Sie die Windows-Server-Updates vom Oktober 2026 nicht.
- Führen Sie auf dem Exchange-Server in einer Eingabeaufforderung mit Administratorrechten folgenden Befehl aus:
reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f
- Starten Sie den Server neu.
- Beobachten Sie die Umgebung nach dem Neustart und prüfen Sie, ob das Problem erneut auftritt. Falls ja, erhöhen Sie den Grenzwert. In allen Kundenfällen, die wir bisher betreut haben, hat dieses Vorgehen das Problem gelöst.
- 65536 reicht in der Regel aus: Der Zähler steigt nach Beobachtungen von Administratoren annähernd gleichmäßig. Wird die alte Grenze von 512 nach rund einem Tag erreicht, hält der neue Wert rechnerisch etwa drei Monate, also deutlich über den nächsten Patchday hinaus, dessen Neustart den Zähler zurücksetzt
- Höher ist nicht automatisch besser: Das neue Limit soll vermutlich eine Überlastung des RPC Endpoint Mappers verhindern. Je höher der Wert, desto stärker wird dieser Schutz wieder aufgeweicht. Bestätigt hat Microsoft diesen Zusammenhang bislang nicht
- Ohne Neustart keine Wirkung: Der Eintrag greift erst nach einem Neustart des Servers. Ein Neustart einzelner Dienste genügt nicht
- Ereignis 1006 im Blick behalten: Treten trotz Eintrag und Neustart erneut Fehler auf, den Wert gezielt erhöhen, statt ihn pauschal auf das Maximum zu setzen
Die Empfehlung: Mit dem von Microsoft genannten Wert starten, die Server beobachten und nur bei erneuten Ausfällen nachjustieren.
Was der Fall über den IT-Betrieb verrät
Fehlerhafte Updates gibt es immer wieder, auch bei sorgfältig arbeitenden Herstellern – zuletzt etwa beim .NET-Update, das Druck und PDF-Export stoppte. Spannend an diesem Fall ist weniger der Fehler selbst als die Frage, wie gut ein Unternehmen darauf vorbereitet ist. Vier Grundsätze lassen sich daraus ableiten, ganz gleich, ob die IT intern oder von einem Dienstleister betrieben wird.
1
Updates brauchen eine Testphase
Der Fehler trat erst nach rund 24 Stunden auf. Wer Updates direkt nach dem Patchday auf allen Servern gleichzeitig einspielt, bemerkt so ein Problem erst, wenn alles steht. Eine gestaffelte Verteilung, bei der zunächst ein Teil der Systeme aktualisiert und einige Tage beobachtet wird, hätte den Schaden deutlich begrenzt. Sicherheitsupdates sollen trotzdem zügig installiert werden – ein festgelegter Patch-Prozess mit klaren Ringen und Zeitfenstern bringt beides zusammen.
2
Monitoring muss genauer hinschauen als die Konsole
Die Datenbanken galten in der Verwaltungsoberfläche als verbunden, obwohl nichts mehr ging. Ein Monitoring, das nur prüft, ob ein Dienst läuft, hätte hier nicht angeschlagen. Aussagekräftiger sind Prüfungen, die die tatsächliche Funktion messen: wachsende Mail-Warteschlangen, bestimmte Ereignis-IDs im Protokoll oder Testnachrichten, die regelmäßig durch das System laufen.
3
Wissen aus der Community nutzen
Die entscheidenden Hinweise zu Ursache und Workaround kamen nicht aus offiziellen Mitteilungen, sondern aus Blogs, Foren und Kommentarspalten. Wer diese Quellen nach jedem Patchday aufmerksam verfolgt, ist oft einen Tag schneller als die offizielle Dokumentation. Im Tagesgeschäft fehlt dafür in vielen IT-Abteilungen schlicht die Zeit.
4
Dokumentation und Rückwege planen
Ein Registry-Workaround ist schnell gesetzt und ebenso schnell vergessen. Damit er beim nächsten Update nicht für Verwirrung sorgt, gehört er dokumentiert: auf welchen Servern, mit welchem Wert, ab wann. Genauso wichtig ist ein vorher getesteter Weg zurück, falls ein Update zurückgenommen werden muss, etwa über aktuelle Backups oder Snapshots.
Empfehlungen für IT-Admins
Wer Exchange im eigenen Haus betreibt, sollte jetzt die folgenden Punkte prüfen. Dass ungepatchte Exchange-Server keine Alternative sind, zeigt der Beitrag zur Exchange-Sicherheitslücke CVE-2026-62911.
- Updatestand prüfen: Ist auf den Exchange-Servern eines der Oktober-Updates KB5126646, KB5126655, KB5126651 oder KB5126868 installiert?
- Workaround setzen: Den Registry-Eintrag EpmapSavedContextCap anlegen und die Server danach neu starten, bei mehreren Servern nacheinander
- Update nicht deinstallieren: Microsoft rät ausdrücklich davon ab, weil das Update Sicherheitslücken schließt
- Funktion überwachen: Ereignis 1006 im Anwendungsprotokoll und die Länge der Mail-Warteschlangen im Blick behalten, nicht nur den Dienststatus
- Änderung dokumentieren: Auf welchen Servern, mit welchem Wert und ab wann der Eintrag gesetzt wurde
- Microsoft-Hinweise verfolgen: Sobald ein Korrekturupdate erscheint, den Workaround prüfen und gegebenenfalls zurücknehmen
- Patch-Ringe einrichten: Künftige Updates zuerst auf einem Teil der Systeme einspielen und einige Tage beobachten
Wo Full Managed IT ansetzt
Die genannten Grundsätze sind keine Geheimnisse. Sie scheitern in der Praxis nicht am Wissen, sondern an der Kapazität. Gerade in mittelständischen Unternehmen kümmern sich oft ein oder zwei Personen um die gesamte IT, vom Drucker bis zum Exchange-Server.
Ein Patch-Prozess mit Testringen, ein feingliedriges Monitoring und das tägliche Verfolgen von Fachquellen lassen sich daneben kaum dauerhaft leisten.
Bei einem Full-Managed-IT-Modell liegen genau diese Aufgaben bei einem Team, das viele Umgebungen gleichzeitig betreut. Das hat ganz praktische Folgen:
- Erfahrung aus vielen Umgebungen: Tritt ein Fehler bei einem Kunden auf, ist er für alle anderen sofort bekannt. Updates können bei Bedarf zurückgehalten werden, bevor sie Schaden anrichten
- Feste Abläufe statt Einzelentscheidungen: Patch-Ringe, Wartungsfenster und Freigaben sind vorab festgelegt. Ein Update wie dieses landet nicht ungeprüft auf allen Systemen gleichzeitig
- Überwachung rund um die Uhr: Wachsende Warteschlangen fallen auch nachts oder am Wochenende auf, also genau dann, wenn ein Fehler wie dieser 24 Stunden nach einem Update zuschlägt
- Klare Verantwortung: Wer zuständig ist, steht fest. Im Ernstfall muss niemand erst klären, wer sich um den Server kümmert
Full Managed IT verhindert keine fehlerhaften Updates. Es sorgt aber dafür, dass ein solcher Fehler früh bemerkt, sauber eingegrenzt und dokumentiert behoben wird. Ob ein Unternehmen das selbst organisiert oder auslagert, hängt von Größe, Ressourcen und Anspruch ab. Die Fragen, die dieser Vorfall aufwirft, sollte sich aber jedes Unternehmen stellen: Wie schnell hätten wir den Ausfall bemerkt? Und wer hätte ihn behoben?
FAQ zu den Exchange-Problemen nach dem Oktober-Patchday
Microsoft nennt die Windows-Server-Updates vom 13. Oktober 2026 als vermutliche Ursache: KB5126646 für Windows Server 2025, KB5126655 für Windows Server 2022, KB5126651 für Windows Server 2019 und KB5126868 für Windows Server 2016.
Exchange Server 2016, Exchange Server 2019 und die Subscription Edition im eigenen Rechenzentrum. Die Exchange-Updates vom Oktober müssen dafür nicht installiert sein. Ob auch Exchange Online betroffen war, ist nicht bestätigt.
Etwa einen Tag nach der Installation verlieren die Postfachdatenbanken ihre Verbindung. Im Anwendungsprotokoll erscheint das Ereignis 1006 mit der Meldung MapiExceptionMdbOffline, Outlook im Web funktioniert nicht mehr und die Mail-Warteschlangen wachsen. Im Exchange Admin Center werden die Datenbanken trotzdem als verbunden angezeigt.
Nein. Microsoft rät ausdrücklich davon ab, weil das Update Sicherheitslücken schließt. Stattdessen wird der Registry-Eintrag EpmapSavedContextCap unter HKLM\SOFTWARE\Microsoft\Rpc gesetzt und der Server anschließend neu gestartet.
Nein. Microsoft bezeichnet ihn als vorübergehende Abhilfe. Einige Administratoren mussten einen höheren Wert setzen. Sobald Microsoft ein Korrekturupdate veröffentlicht, sollte der Eintrag geprüft und gegebenenfalls zurückgenommen werden.
Den Fehler im Update selbst nicht. Seine Auswirkungen lassen sich aber deutlich begrenzen: mit gestaffelten Updates, die zunächst nur auf einem Teil der Systeme laufen, und mit einem Monitoring, das die tatsächliche Funktion von Exchange prüft und nicht nur den Dienststatus.
Fazit
Die Windows-Updates vom Oktober 2026 haben Exchange-Server in vielen Unternehmen lahmgelegt. Mit dem Registry-Workaround gibt es eine von Microsoft gestützte Übergangslösung, die endgültige Korrektur steht noch aus. Wer Exchange im eigenen Haus betreibt, sollte prüfen, ob die betroffenen Updates installiert sind, den Workaround gegebenenfalls umsetzen und die weiteren Mitteilungen von Microsoft verfolgen.
Über den konkreten Fall hinaus lohnt sich ein Blick auf den eigenen Patch- und Überwachungsprozess. Der nächste fehlerhafte Patch kommt bestimmt, und dann entscheidet die Vorbereitung darüber, ob daraus ein kurzer Hinweis oder ein ganzer Tag ohne E-Mail wird.
Fanden Sie den Blogbeitrag hilfreich und interessant?
Vielen Dank für Ihre Rückmeldung!