senn-techsenn-tech
Infrastruktur
Infrastruktur2026-10-18· Von Franz Senn

Exchange Server 2016 und 2019 endgültig ohne Updates, und das Oktober-Patch wirft Exchange um

Am 13. Oktober hat Microsoft das letzte Sicherheitsupdate für Exchange Server 2016 und 2019 ausgeliefert. Damit endet das ESU-Programm für beide Versionen; Organisationen ohne ESU bekamen ohnehin seit Oktober 2025 nichts mehr. Zwei Tage später meldeten Administratoren ein zweites Problem: Exchange-Server bleiben nach den Windows-Updates desselben Tages mit stehender Datenbank hängen, auch die längst gepatchte Subscription Edition. Microsoft bestätigt den Vorfall, einen Fix gibt es nicht.

Was das Update-Ende praktisch heißt

Die Lifecycle-Seiten von Microsoft führen Exchange 2016 und 2019 mit Support-Ende Mitte Oktober 2025. Wer danach ohne ESU weiterlief, bekam auf legalem Weg keine Sicherheitsupdates mehr. Das ESU-Programm gab noch ein Jahr Aufschub und endet mit dem Update vom 13. Oktober 2026. Microsoft schreibt über dieses Update selbst, dass es das letzte für 2016 und 2019 ist und künftige Sicherheitsupdates nur noch für die Subscription Edition erscheinen. Wer am ESU-Programm teilgenommen hat, kann auch nach dem Programmende dieses eine Update noch laden und installieren, aus dieser Quelle kommt danach nichts mehr.

Das Abschluss-Update war kein Formalakt. Der Exchange-Experte Frank Carius zählt darin sechs kritische Schwachstellen, darunter CVE-2026-70571 mit CVSS 8,1, eine unauthentisierte Einschleusung von Code über eine präparierte Mail. Schon das September-Update hatte eine Lücke schließen müssen, mit der ein normal angemeldeter Nutzer fremde Postfächer lesen konnte (CVE-2026-96940, CVSS 8,8). Die Bedrohungslage ist also unverändert, nur die Nachschubleitung ist zu.

Der eigentliche Schaden taucht im November auf. Wenn Microsoft den nächsten Patch-Dienstag die Updates für die Subscription Edition ausliefert, stehen in den CVE-Meldungen die Lücken, die auf den 2016er und 2019er Servern noch offen sind. Angreifer lesen die Meldungen, vergleichen den Code der beiden Versionen und haben freie Bahn, bis jemand migriert. Carius rechnet fest mit diesem Muster, und wer die Exchange-Jahre seit 2020 begleitet hat, kennt die Geschwindigkeit solcher Exploits.

Der Windows-Patch, der die Datenbanken einfriert

Größer als das Support-Thema ist diese Woche der Windows-Patch. Microsoft lieferte am 13. Oktober die Sicherheitsupdates KB5126646 für Windows Server 2025, KB5126655 für Server 2022, KB5126651 für Server 2019 und KB5126868 für Server 2016. Ab dem 15. Oktober berichteten Administratoren, dass Exchange-Server rund 24 Stunden nach der Installation stehenbleiben.

Die Symptome aus den Meldungen: Outlook on the Web antwortet mit MapiExceptionMdbOffline (ec=1142), das Application-Eventlog schreibt Ereignis-ID 1006 vom Dienst für die Postfachreplikation, die SMTP-Warteschlangen wachsen, Cluster-Gruppen verlieren das Datei-Quorum oder die Replikation stoppt. Ein Neustart der Exchange-Dienste hilft nicht. Erst ein kompletter Neustart des Servers räumt den Zustand, für einige Stunden.

Microsoft bestätigte den Vorfall am 16. Oktober auf der Release-Health-Seite mit dem Satz „Users might be unable to sign in to OWA or send emails on Exchange Server". Bestätigt sind Server 2022 und 2025 mit Exchange 2019 oder SE auf den genannten KBs, gemeldet wird das Muster aus Umgebungen mit allen vier Server-Versionen und allen drei Exchange-Versionen. Microsoft betont, dass die Exchange-Updates selbst die Ursache nicht sind, und liefert weder Fix noch KIR, die Windows-Updates bleiben im Katalog.

Die Mechanik haben Blog-Leser und unabhängig davon Frank Carius herausgearbeitet, der dafür den RPC-Baustein RpcEpMap.dll disassemblierte. Der Fix gegen CVE-2026-96300, einen Denial of Service im RPC Endpoint Mapper (CVSS 5,9), zieht eine neue Obergrenze ein: Ein Prozess darf höchstens 512 gespeicherte Lookup-Kontexte des Endpoint Mappers halten. Für einen Webserver mit wenigen RPC-Verbindungen pro Minute ist das sinnvoll, Exchange führt RPC-Dauerbetrieb rund um die Uhr. Sind die 512 Kontexte aufgebraucht, schaltet die RPC-Kette ab und die Datenbanken gehen offline.

Inoffiziell, aber von einem Microsoft-Mitarbeiter im Forum bestätigt ist ein Workaround: unter HKLM\SOFTWARE\Policies\Microsoft\Rpc\EpMap den DWORD-Wert EpmapSavedContextCap auf 65536 setzen und neu starten. Wer die KBs noch nicht ausgerollt hat, setzt den Wert vorher. Es bleibt ein Support-Verzicht: Der Wert senkt eine Sicherheitsbegrenzung wieder ab, die der Patch gerade eingebaut hat.

Warum nach dem Oktober-Patch die Exchange-Datenbank stehenbleibt13.10.: Windows-SUslaufen anKB5126646, KB5126655,KB5126651, KB5126868Neue Grenze greiftmaximal 512 gespeicherteRPC-Kontexte je ProzessNach Stunden sind dieKontexte aufgebrauchtExchange führtRPC-DauerbetriebDatenbanken offline,WarteschlangenwachsenMapiExceptionMdbOffline,Ereignis 1006Kompletter Neustarthilft für StundenNeustart der Dienste alleinreicht nicht
Die Kette nach den Analysen von Frank Carius und Blog-Lesern, von Microsoft am 16.10.2026 als Vorfall bestätigt. Die Exchange-Updates selbst sind laut Release-Health-Eintrag an den Ausfällen unbeteiligt. (Quelle: MSXFAQ und Borncity, 17.10.2026)
Gespeicherte RPC-Kontexte: neue Grenze und WorkaroundGrenze seit Oktober-Patch512Workaround-Wert aus dem Forum65536070000
Der Fix gegen CVE-2026-96300 begrenzt gespeicherte Kontexte im Endpoint Mapper auf 512 je Prozess. Der im Forum genannte Workaround-Wert 65536 ist das 128-Fache, die erste Säule ist deshalb kaum zu sehen. (Quelle: Microsoft Community Hub 4565382 und MSXFAQ, 17.10.2026)

Auch Exchange Online stolperte

Microsoft verteilt die Windows-Updates auch in den eigenen Rechenzentren, und dort stolperte am Wochenende der Dienst Exchange Online. Der Service-Health-Eintrag EX1489902 (Stand 17. Oktober, offene Untersuchung) meldet Mails, die in Übertragungs- und Zustellungs­warteschlangen hängen bleiben und schließlich mit 5.4.11 MapiExceptionMaxSubmissionExceeded abgewiesen werden, dazu Anmeldeprobleme bei Outlook on the Web. Dieselben KBs, derselbe RPC-Pfad, ein vergleichbares Symptom. Der Unterschied: Im Microsoft-Rechenzentrum räumt Microsoft, im Serverkeller setzt ein Mensch nachts den Registry-Wert. Gegen die Cloud ist das kein Argument, gegen ungeplante Update-Fenster überall ist es eines.

Die vier Auswege

Frank Carius sortiert die Restoptionen in vier Gruppen, und nach Abzug der Werbelogen der Anbieter bleibt genau diese Liste:

  1. Tausch auf die Subscription Edition. Von Exchange 2019 CU14 oder CU15 klappt das In-Place-Setup inklusive Datenbankübernahme, von Exchange 2016 gibt es diesen Weg nicht, dort gehört ein neuer SE-Server daneben und die Postfächer wandern in einem Zug. Die Subscription Edition steht seit 1. Juli 2025 in der Microsoft-Liste und läuft nach der Modern Lifecycle Policy ohne festes Enddatum.
  2. Exchange Online. Der Hybrid-Server lässt sich mit isExchangeCloudManaged zum reinen Verwaltungsclient ohne eigene Postfächer machen, die Lizenz „Last Exchange Server" gibt es zwölf Monate kostenlos über einen Microsoft-Partner. Voraussetzung ist ein Plan mit Exchange-Online-Postfächern. Welche alten Integrationen beim Tenant-Wechsel hängen bleiben, haben wir bei der EWS-Abschaltung durchgeklopft.
  3. Anderes Mailsystem. Ein IMAP-Zug bringt die Mails, Kalender, Kontakte und öffentliche Ordner brauchen eigene Züge. Für den Selbstbau-Weg haben wir Stalwart als Exchange-Nachfolger im Vergleichstest durchgerechnet.
  4. Restrisiko tragen. Eigenes Subnetz, Web Application Firewall mit erzwungener Voranmeldung, Minimalschema: Carius hält jede dieser Maßnahmen für sinnvoll und zusammen für nicht ausreichend, die BSI-Empfehlung lautet Abschaltung. Wer trotzdem weitermacht, dokumentiert die Entscheidung und setzt den Novembertermin auf die Agenda.

Was Administratoren diese Woche tun

  • Die vier KBs auf allen Exchange-Servern prüfen, inklusive der Subscription Edition, denn die ist genauso betroffen.
  • EpmapSavedContextCap auf 65536 setzen, vor der Installation der KBs oder beim nächsten Wartungsfenster, mit dokumentierter Freigabe.
  • Ereignis-ID 1006 im Application-Log und die Länge der SMTP-Warteschlangen monitoren. Beides läuft der Benutzermeldung voraus.
  • Die KBs nicht nachträglich deinstallieren. Microsoft rät davon ab, und auf clustergeschützten Knoten beschädigt die Deinstallation Replikation und Cluster-Betrieb.
  • Exchange 2016 und 2019 im Bestand zählen und den Weg aus Option 1 bis 4 bis November durchrechnen. Ab dem nächsten Patch-Dienstag arbeitet die Uhr gegen diese Server.

Was das für uns bedeutet

Wir betreiben keinen Exchange-Server. Die Autodiscover-Einträge der Firmendomains der Gruppe zeigen auf autodiscover.outlook.com, die Postfächer liegen in Microsoft 365, der Einlaufverkehr läuft über unsere NSP-X-Gateways (DNS-Messung vom 18. Oktober 2026). Das Labor mailed über Stalwart. Diese Update-Woche betrifft damit unsere Kunden und Partner, nicht unseren Bestand. Auf deren Servern gilt: Ein Support-Ende stoppt keine Funktion, es stoppt nur den Nachschub an Sicherheitsupdates. Der Server läuft scheinbar normal weiter, und der November-Patch macht öffentlich, welche Lücken dann nur noch in den neuen Versionen gestopft werden.

Weiterführende Quellen

Fragen?
Muss ich jetzt die Windows-Updates installieren oder lieber meiden?+

Die Windows-Lücken, gegen die die Patches vom 13. Oktober schützen, sind real, auf einem Server mit Internetzugang sind sie keine Theorie. Der saubere Weg ist: Registry-Wert EpmapSavedContextCap auf 65536 setzen, dann die KBs installieren, dann kontrolliert neu starten. Wer die KBs noch nicht ausgerollt hat und erst die Vorlage testen will, kann sie kurz zurückstellen. Das ist eine Risikoabwägung zwischen zwei Bekanntheitsgraden, keine Schonung.

Ist der Registry-Workaround eine Dauerlösung?+

Er verschiebt die Schwelle von 512 auf 65536 gespeicherte Kontexte und kauft Zeit. Microsoft hat den Wert im Forum als vorläufige Maßnahme genannt, ohne Unterstützungsgarantie, ein richtiger Fix steht aus. Nach dem November-Patchlauf gehört der Wert auf den Prüfstand. Bis dahin ist es eine freizugebende Support-Entscheidung, die eine gerade eingezogene Sicherheitsgrenze wieder herabsetzt.

Wir laufen vollständig in Exchange Online, betrifft uns das?+

Serverseitig müssen Sie nichts installieren, den Störungseintrag EX1489902 räumt Microsoft im eigenen Dienst. Nachzusehen ist nur, ob in der Nacht zum Wochenende Mails hängen blieben oder mit 5.4.11 abgewiesen wurden. Verwaltungs-Workstations mit Exchange-Tools patchen mit. Und wer nur Online sagt: Die EWS-Abschaltung für alte Integrationen läuft, die Fristen stehen in unserem Beitrag zur EWS-Abschaltung.