senn-techsenn-tech
Infrastructure
Infrastructure2026-10-18· By Franz Senn

Exchange 2016 and 2019 are out of updates for good, and the October Windows patch freezes the databases

On 13 October Microsoft shipped the final security update for Exchange Server 2016 and 2019. That closes the ESU program for both versions; organizations without ESU had received nothing through legal channels since October 2025 anyway. Two days later administrators reported a second problem: Exchange servers stall with a dismounted database about a day after installing the Windows updates from that same Tuesday, and the fully patched Subscription Edition is not immune. Microsoft has confirmed the incident. A fix does not exist yet.

What the end of updates means in practice

Microsoft's lifecycle pages list mid-October 2025 as end of support for Exchange 2016 and 2019. Teams that kept running past that date without ESU got no more security updates by legal means. ESU bought one extra year and ends with the update from 13 October 2026. Microsoft says about that update itself that it is the last one for 2016 and 2019 and that future security updates ship only for the Subscription Edition. ESU participants can still download and install this one update after the program ends; nothing arrives from that source afterward.

The parting update was no formality. Exchange expert Frank Carius counts six critical vulnerabilities in it, among them CVE-2026-70571 with CVSS 8.1, an unauthenticated code injection through a single crafted mail. The September update had already closed a hole that let a normally signed-in user read other people's mailboxes (CVE-2026-96940, CVSS 8.8). The threat picture has not changed at all, only the supply line has been cut.

The real damage shows up in November. When Microsoft ships the Subscription Edition updates on the next Patch Tuesday, the CVE advisories will describe the holes that are still open on the 2016 and 2019 boxes. Attackers read those advisories, compare the code of the two versions, and get a free run until somebody migrates. Carius expects this pattern as a matter of routine, and those who followed the Exchange years since 2020 know how fast such exploits spread.

The Windows patch that freezes the databases

This week the Windows patch is the bigger topic than the support one. On 13 October Microsoft delivered the security updates KB5126646 for Windows Server 2025, KB5126655 for Server 2022, KB5126651 for Server 2019 and KB5126868 for Server 2016. From 15 October administrators reported Exchange servers coming to a standstill roughly 24 hours after installation.

The symptoms from those reports: Outlook on the Web answers with MapiExceptionMdbOffline (ec=1142), the application event log writes event ID 1006 from the mailbox replication service, SMTP queues grow, cluster groups lose the file share witness or replication stops. Restarting the Exchange services does not help. Only a complete server reboot clears the state, and only for a few hours.

Microsoft confirmed the incident on 16 October on the Release Health page with the sentence "Users might be unable to sign in to OWA or send emails on Exchange Server". Confirmed are Server 2022 and 2025 running Exchange 2019 or SE on the KBs named above; the pattern is reported from environments with all four server versions and all three Exchange versions. Microsoft stresses that the Exchange updates themselves are not the cause, ships neither a fix nor a KIR, and leaves the Windows updates in the catalog.

The mechanics were worked out by blog readers and, independently of them, by Frank Carius, who disassembled the RPC component RpcEpMap.dll for this. The fix for CVE-2026-96300, a denial of service in the RPC Endpoint Mapper (CVSS 5.9), draws a new ceiling: a process may hold at most 512 saved lookup contexts in the Endpoint Mapper. For a web server with a few RPC connections per minute that makes sense, while Exchange runs RPC around the clock. Once those 512 contexts are used up, the RPC chain switches off and the databases go offline.

A workaround exists, unofficial but confirmed by a Microsoft employee in the forum: set a DWORD value named EpmapSavedContextCap to 65536 under HKLM\SOFTWARE\Policies\Microsoft\Rpc\EpMap and reboot. If the KBs are not deployed yet, set the value first. It stays a support waiver: the value lowers a security limit that the patch has just built in.

Why the Exchange database freezes after the October patch13 Oct: Windowssecurity updates shipKB5126646, KB5126655,KB5126651, KB5126868New cap takes effectAt most 512 saved RPCcontexts per processHours later thecontexts run outExchange runs RPC around theclockDatabases go offline,queues growMapiExceptionMdbOffline,event 1006A full reboot buys afew hoursRestarting the servicesalone is not enough
The chain from the analyses by Frank Carius and blog readers, confirmed as an incident by Microsoft on 16 Oct 2026. According to the Release Health entry, the Exchange updates themselves are not involved in the outages. (Quelle: MSXFAQ and Borncity, 17 Oct 2026)
Saved RPC contexts: new cap and workaround valueCap since the October patch512Workaround value from the forum65536070000
The fix for CVE-2026-96300 limits saved contexts in the Endpoint Mapper to 512 per process. The workaround value of 65536 named in the forum is 128 times that, so the first bar is barely visible. (Quelle: Microsoft Community Hub 4565382 and MSXFAQ, 17 Oct 2026)

Exchange Online stumbled too

Microsoft pushes the Windows updates through its own datacenters as well, and there the Exchange Online service stumbled over the weekend. The service health entry EX1489902 (as of 17 October, investigation still open) reports mail stuck in transport and delivery queues and finally rejected with 5.4.11 MapiExceptionMaxSubmissionExceeded, plus sign-in problems in Outlook on the Web. Same KBs, same RPC path, comparable symptom. The difference: in a Microsoft datacenter Microsoft cleans up, in a server room a human applies the registry value at night. Against the cloud that proves nothing, against unplanned update windows everywhere it proves a lot.

The four ways out

Frank Carius sorts the remaining options into four groups, and once you subtract the marketing haze of the vendors this is exactly the list that stands:

  1. Move to the Subscription Edition. From Exchange 2019 CU14 or CU15 the in-place setup works including the databases, from Exchange 2016 that path does not exist, so a new SE server goes up beside the old one and the mailboxes move in a single pass. The Subscription Edition has been on Microsoft's list since 1 July 2025 and runs on the Modern Lifecycle Policy with no fixed end date.
  2. Exchange Online. The hybrid server can be reduced to a management-only machine with no own mailboxes through isExchangeCloudManaged, and the "Last Exchange Server" license is free for twelve months through a Microsoft partner. The prerequisite is a plan with Exchange Online mailboxes. Which old integrations break at a tenant change, we tested while covering the EWS shutdown.
  3. A different mail system. IMAP brings the mail; calendars, contacts and public folders each need their own migration. For the self-hosted path we ran the numbers in Stalwart as Exchange successor, compared.
  4. Carry the residual risk. Own subnet, web application firewall with forced pre-authentication, minimal schema: Carius holds each of these measures sensible and all of them together insufficient, the BSI recommendation is shutdown. Anyone who continues anyway documents the decision and puts the November date on the calendar.

What administrators should do this week

  • Check the four KBs on every Exchange server, Subscription Edition included, because it is affected the same way.
  • Set EpmapSavedContextCap to 65536, before the KB installation or at the next maintenance window, with a documented approval.
  • Monitor event ID 1006 in the application log and the length of the SMTP queues. Both fire ahead of user reports.
  • Do not uninstall the KBs afterwards. Microsoft advises against it, and on cluster-protected nodes the uninstall damages replication and cluster operation.
  • Count the Exchange 2016 and 2019 servers in the estate and work through options 1 to 4 before November. From the next Patch Tuesday the clock runs against these servers.

What this means for us

We do not run an Exchange server. The Autodiscover records of the group's company domains point to autodiscover.outlook.com, the mailboxes live in Microsoft 365, inbound mail runs over our NSP-X gateways (DNS measurement from 18 Oct 2026). The lab mails over Stalwart. This update week therefore concerns our customers and partners, our own estate stays untouched. On their servers the rule reads: an end of support stops no feature, only the supply of security updates. The server keeps running as if nothing happened, and the November patch makes public which gaps then get closed only in the newer versions.

Further reading

Questions?
Should I install the Windows updates now or hold them back?+

The Windows flaws that the patches from 13 October defend against are real, and on an internet-facing server they are anything but theory. The clean path is: set the EpmapSavedContextCap registry value to 65536, install the KBs, then reboot in a controlled way. Teams that have not deployed the KBs yet and want to test the pattern on a pilot first can hold them back for a short time. That is a risk decision between two known dangers, nothing gentler than that.

Is the registry workaround a permanent solution?+

It moves the threshold from 512 to 65536 saved contexts and buys time. A Microsoft employee named the value in the forum as a temporary measure, with no support guarantee, and a proper fix is still missing. The November patch round is the point to put the value back on the table. Until then it stays a support decision that lowers a security limit which was just raised.

We run Exchange Online only, does this affect us?+

There is nothing to install on the server side, Microsoft clears the incident EX1489902 inside its own service. Worth checking is whether mail hung in queues or bounced with 5.4.11 during the weekend night, and whether admin workstations carrying Exchange tooling got patched too. And anyone who says Online only: the EWS shutdown for old integrations is running, the deadlines are in our post about the EWS shutdown.