Exchange fails 24 hours after the October patch, and the mitigation undoes the patch

Five hundred and twelve divided by twenty-three point seven is twenty-one and a half hours. That division is how long your Exchange server lasts from the moment you install the October Windows Server update until mailboxes start dropping off. If you patched on Tuesday afternoon, mail stopped mid-morning on Wednesday, with the change window closed, the record signed off, and nobody looking at the patch any more.

What the 13 October updates introduced

The Windows Server security updates released on 13 October 2026 — KB5126646 for Windows Server 2025, KB5126655 for 2022, KB5126651 for 2019 and KB5126868 for 2016 — introduce a new cap in the Endpoint Mapper, the piece of the Windows RPC subsystem that resolves which dynamic port serves each service. The cap is 512 saved lookup contexts at a time, and it lives in RpcEpMap.dll.

Microsoft's note on the Windows release health dashboard frames it as a memory limit: "the October 2026 update introduced a default limit on the amount of memory used by Endpoint Mapper when handling Endpoint Lookup calls. For workloads such as Exchange Server, the default limit of 512 simultaneous Endpoint Lookup calls might not be sufficient under heavy load." That wording is a large part of why nobody ties the failure to the patch: "simultaneous" sounds like something that releases itself when load drops, and what the cap counts is saved contexts, which accumulate and are never let go. Hence the twenty-one hours. It is not a load spike: it is a tank filling up. And the note leaves out why that cap is there. The person who has put it in writing is Michel de Rooij, who places the change in RpcEpMap.dll and ties it to CVE-2026-96300: an uncontrolled resource consumption flaw (CWE-770) in the RPC Endpoint Mapper service itself, scored 5.9, which lets any machine able to talk to that service exhaust its memory and bring it down. If that reading is right — and it fits everything else — the 512 cap is the fix for that flaw. Microsoft does not say so on the update page.

Why it takes a day to show up

Denis Grebner measured it on a production mail server and published the numbers on Franky's Web: 135 contexts in 5.68 hours of uptime, 23.7 an hour. With a cap of 512 and nothing releasing them, the counter hits the ceiling at 21.6 hours — and the server he measured went down at 21 hours and 27 minutes. Reports put the failure between 20 and 24 hours depending on load. From then on the Endpoint Mapper stops handing out endpoints, and the Exchange components that talk to each other over RPC — which is nearly all of them — have no way to find each other.

Twenty-one hours of delay break the whole change procedure. A typical maintenance window runs two hours, three if the team is generous. You install, reboot, check that webmail loads, that a test message goes out and that the databases are mounted, and you sign off. All of those checks pass. They pass because at that moment the server is twenty contexts into its 512, and there is nothing to see.

What you will see when it fills

The symptoms arrive piecemeal and none of them says "RPC". What is being reported:

• Users unable to sign in to Outlook on the Web, and Outlook clients losing the connection to the mailbox.
• Messages sitting in the outbox and queues growing without delivering.
• Database copies in a DAG that stop replicating.
• In the application log, Event ID 1006 from MSExchange Mailbox Replication with MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142).
• The one that points at the right place: Event ID 4082 from MSExchangeRepl, where the replication network manager fails with OpenCluster(...) failed with 0x6d9 and, at the end of the trace, "There are no more endpoints available from the endpoint mapper".

While all this is happening, the databases still show as connected and mounted in the Exchange Admin Center. Your dashboard says the service is fine while mailboxes are unreachable. If your monitoring checks database mount state rather than making a real client connection, that is not where you will find out: you will find out by phone.

Microsoft's mitigation, and the small print

Microsoft recommends raising the cap from an elevated command prompt and rebooting:

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

That is 65536, one hundred and twenty-eight times the original cap, and Microsoft adds that if the problem persists you can raise it further. The vendor is not giving you the right number, it is giving you a big number and instructions to make it bigger. Nobody knows your number because it depends on your load, and that includes whoever wrote the note.

Microsoft is explicit about two things, and they are worth keeping apart. First, the instruction: "do not uninstall October 2026 Windows Server updates". The patch you will want to pull at three in the morning is precisely the one they ask you to leave in place. Second, that the cause is not the Exchange updates: "issues reported are not related to installation of October 2026 security updates for Exchange Server". On the update's own page they add that Microsoft Support can provide an additional mitigation for affected devices, and that the case remains under investigation. And there is a third point that is not in the note but is in what the people living through it report: rebooting the server clears the contexts and makes the symptom go away, for another twenty hours. That is the trap that turns a fault into an office legend — "it is fine, I rebooted it on Monday" — and the reason people have spent the weekend on top of their servers.

The trade-off, said out loud

If the 512 cap is the fix for CVE-2026-96300, raising it to 65536 undoes most of that fix. It is the direct consequence, and it belongs written in the ticket rather than left implied. That said, our recommendation is to apply the mitigation. Stopped mail is today's outage, measurable in people not working; the CVE is a 5.9 denial of service that requires somebody to have a line open to your Endpoint Mapper. On a Wednesday afternoon those are not the same size of risk.

But with two non-negotiable conditions. First: port 135/TCP must not be exposed to the internet. If it is, your problem today is not the registry value, it is the port, and the CVE is the least of what can reach you through it. Second: that EpmapSavedContextCap is now an undocumented dependency of your mail availability. It travels in no patch, appears in no software inventory and vanishes the day somebody rebuilds that server from a template. Give it an owner, give it a review date, and write it down where you write the things that have to be undone.

What to do this week

• Check which KB each Windows server hosting Exchange has installed. If it is one of the four above, you are in scope.
• Search for Event ID 4082 and 1006 in the application log for the last seven days, even if nobody has complained. A server that reboots nightly for another reason may have been grazing the ceiling for days without crossing it.
• Apply the registry value and reboot. In a DAG, node by node.
• Record the change as temporary, with the date it must be reviewed and the reason (CVE-2026-96300) written beside it. A value with no reason written down survives for years.
• Verify from outside that 135/TCP does not answer from the internet. Today, not from memory.
• Change your monitoring check: make a real client connection to a mailbox rather than reading database mount state. This failure leaves the dashboard green.
• And put a calendar reminder to revisit the Windows release health note: when the permanent fix ships, the value has to come out.

Two hours of validation for a twenty-one-hour failure

Validation lasted two hours. The failure took twenty-one to be born. A change window that ends before the failure exists certifies that the install finished, and that is all it certifies. That gap will still be there when this particular patch is a memory.

What does work is unglamorous: one server first and the rest afterwards, with a gap longer than the slowest failure you know about. If you have a DAG, the lab is already built — update one node, wait forty-eight hours, update the next. If you only have one mail server, you have to buy that gap somewhere else: in the deployment rings of the rest of the estate, where the desktop goes first and warns you. We wrote about that recently in who tests the changes before you do, and the reasoning is the same here.

If you are still on Exchange 2016 or 2019

The fault hits them just the same — 2016, 2019 and Subscription Edition are all on the list — but the way out is not. Support for Exchange Server 2016 and 2019 ended on 14 October 2025. Microsoft's own page lists it without euphemism: since that date there is no technical support, no bug fixes for issues affecting server stability and usability, no security fixes and no time zone updates. The only supported on-premises version is Exchange Server SE.

Put another way: this week you apply the registry value and get through it, but the next incident that needs a fix in the product will not have one. It is the same reasoning we applied to the Exchange you left running, the server still in the rack because you need it to manage recipients: since October 2025, that server has nobody to call.

And no, moving to the cloud is not the easy answer

On 12 October 2026, eight days before writing this, a configuration change left the Exchange Online admin center returning internal errors to administrators for around 5.4 hours, until Microsoft rolled the change back. Nobody touched a registry, nobody rebooted anything, and nobody could do a single thing while it lasted.

What changes when you move to Microsoft 365 is not that outages disappear: it is which kind of failure you get and who spends the weekend with it. You lose the server filling up with RPC contexts and the registry value nobody remembers; you gain a dependency you cannot reboot: when it falls over, your only lever is a case number. When we come across it, the trade usually makes sense — a machine inventory disappears, and so do nights — but it makes sense with your eyes open and a plan for the days when the dashboard is red and you have no controls. That last part, the one nobody puts in a migration proposal, is what we write down before moving the first mailbox.

Sources and method: the Microsoft quote about the default limit is on the update's own page, in the known issues section of KB5126646 (Windows Server 2025, build 26100.33650, 13 October 2026), consulted on 20 October 2026; the same page states that Microsoft Support can provide additional mitigation. The verbatim instruction not to uninstall the Windows Server updates and the sentence about the Exchange updates come from the Exchange team's advisory on Tech Community, 16 October 2026 — techcommunity.microsoft.com. The list of symptoms and the exact command come from BleepingComputer's coverage of 19 October 2026 — bleepingcomputer.com. The KB numbers per Windows Server version, the 20-24 hour window and the detail that databases still show as mounted in the admin center come from Frank Zöchling's article on Franky's Web; the measurement of 23.7 contexts per hour (135 contexts in 5.68 hours), the 21.6-hour projection and the real 21 h 27 min outage are Denis Grebner's, published in the technical thread under that same article; both on frankysweb.de; Event ID 1006 and 4082 and the 0x6d9 code come from Michel de Rooij's analysis — eightwone.com, who is also the one placing the cap in RpcEpMap.dll and tying it to CVE-2026-96300; the public Microsoft note we read does not explicitly link the two. The description of CVE-2026-96300 (uncontrolled resource consumption, CWE-770, 5.9) comes from its public record. The end-of-support dates and conditions for Exchange Server 2016 and 2019 are from Microsoft's official page — learn.microsoft.com. The 12 October 2026 Exchange Online admin center outage and its approximate duration are reported by Petri — petri.com. To be clear, the 21.6-hour projection is not ours; what is ours is the reading of that number: it is longer than any change window we have ever seen signed off. We have no telemetry of our own for this incident: everything above is a reading of public documentation and of the reports of those who have lived it. What is ours is the judgement: the recommendation to apply the mitigation, the two conditions we attach to it, and this week's list.