Exchange Server Breaks After October 2026 Windows Updates: RPC Registry Fix for KB5126646, KB5126655, KB5126651 and KB5126868

The Exchange team posted the advisory on October 16. It says that since October 13, 2026 (Microsoft "Patch Tuesday" release cycle), we have seen some reports of customer issues where Exchange Servers become unstable after a set of October updates are installed. The October Exchange security update is not the cause. The trigger sits one layer down, in the Windows operating system.

Which updates and which servers are affected​

Four Windows Server cumulative updates are involved:

The problem comes from the OS, so any Exchange version running on an affected Windows Server build can be hit. That includes Exchange Server 2016, Exchange Server 2019 and Exchange Server Subscription Edition (SE). Microsoft's own KB5126651 release notes for Windows Server 2019 now list the issue as a known problem. They also state plainly that installing the October 2026 Exchange security updates isn't required for the issues to occur.

This explains why early diagnosis was confusing. On Günter Born's blog, early reader reports blamed the Exchange security update. Commenters later pointed to the Windows cumulative update instead, and several comments on the Exchange blog or at Franky's confirm that the SU without the October CU causes no problems (translated from German).

Summary: if an Exchange server runs Windows Server 2016 through 2025 and has the matching October KB installed, it's a candidate, whatever its Exchange patch level.

What failure looks like​

According to Microsoft's KB notes, the symptoms are:

• Users can't sign in to Outlook on the web (OWA).
• Messages sent from Outlook stay in the Outbox and never go out.
• Exchange has trouble reaching mailboxes during mailbox replication.
• Email queues keep growing.
• In some configurations, OWA fails with MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142), and Event ID 1006 is logged in the Application log.

Not every server fails. Microsoft says severity and speed depend on Exchange server load, and some servers may never hit the problem. Rebooting brings the server back, but only for a while.

The community has put a rough number on that. On Franky's Web, Frank Zöchling relays a reader's analysis that depending on the load, the limit is reached after approximately 20 to 24 hours, after which RPC connections fail and Exchange reports the databases as offline. Treat that as field observation, not a Microsoft figure. A quiet server could run much longer than a busy one.

The root cause: a new limit on RPC lookups​

The technical explanation is in Microsoft's release-health notes, not the Exchange blog. The October update added a default limit on how much memory the RPC Endpoint Mapper can use when it handles Endpoint Lookup calls. That default allows 512 simultaneous lookups. Microsoft acknowledges this may not be enough for workloads such as Exchange Server under heavy load.

Community reverse-engineering adds detail. Born's readers compared the old and new copies of RpcEpMap.dll and found that in the October version 10.0.26100.33648, exactly one new configuration name appears: EpmapSavedContextCap (under HKLM\SOFTWARE\Microsoft\Rpc) (translated from German). The reader analysis on Franky's Web adds that Exchange continuously creates these contexts, which are only released when the associated Exchange process terminates. A reboot resets the counter, which is why restarts only buy time.

Why add a cap at all? Franky's Web says the October updates for Windows Server close the vulnerability CVE-2026-96300 in the RPC Endpoint Mapper ("Uncontrolled resource consumption," Denial of Service). Microsoft's release notes don't link the cap to that CVE, so take the connection as Franky's Web's reading, not Microsoft's confirmation. It would explain the design, though: limiting resources an attacker could exhaust is good hardening. The problem is that Exchange legitimately uses a lot of them.

Summary: a security-minded limit of 512 Endpoint Mapper lookup contexts collides with how Exchange holds those contexts open. Once the limit is reached, RPC fails and Exchange reports its databases as offline.

The fix: what Microsoft tells admins to do​

Microsoft's guidance is clear. The first step in its advisory is: Do not uninstall October 2026 Windows Server updates. Removing a month of OS security fixes to get mail working again is a bad trade when a supported workaround exists.

Step-by-step mitigation (per Microsoft's Exchange team):

1. Confirm exposure. Check that the server has the relevant KB installed. For example, on Windows Server 2019 run Get-HotFix -Id KB5126651 in PowerShell, and use the matching KB number for other versions.
2. Optionally check the current value. Windows FAQ points out that you can query any existing setting with reg query "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap. On an untouched server it most likely won't exist yet.
3. Raise the cap. From an elevated Command Prompt on the Exchange server, run:
   reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f
   This creates or overwrites a REG_DWORD named EpmapSavedContextCap with a decimal value of 65536.
4. Restart the server. The reboot is part of the procedure, not an optional extra.
5. Monitor. Watch OWA sign-ins, transport queues, database mount status and the Application log for Event ID 1006. If the problem comes back, Microsoft says to raise the limit further.

Success means OWA stays reachable, queues drain normally and databases stay mounted well past the point where the server used to fail. In a DAG or any multi-server setup, follow the Microsoft Support guidance Born published and coordinate the reboots so that you don't take every node down at once.

Microsoft is careful not to oversell this. The Exchange team says the change has resolved the problem in the customer cases it has worked on so far. The Windows release-health entry describes the registry edit as a temporary mitigation. It also says an additional mitigation is available through Microsoft Support for business, and that Microsoft is still investigating. No replacement cumulative update has been announced.

Community variations, and why they need care​

Some admins are going further than Microsoft. Franky's Web published a PowerShell script that sets the value to 16777215 and first saves the registry key as a .reg file under C:\ProgramData\EpmapWorkaround, so the change can be rolled back. The backup is a good habit. The much higher number, however, is not Microsoft's recommendation. Microsoft notes that raising the cap also lets Endpoint Mapper use more memory, and given the possible CVE connection, a very high cap may give back more of the new protection than you need. Start at Microsoft's 65536 and raise it only if the issue returns.

The Grams-IT blog has a practical tip for servers that haven't installed October's patches yet: first set the registry value EpmapSavedContextCap, then install the Windows CU, then restart. The value only matters once the new RpcEpMap.dll is running, so setting it first means the server boots straight into the higher limit. That avoids the failure window altogether. This is a community suggestion, not official Microsoft procedure, but it follows directly from how the mitigation works.

The bigger picture​

Microsoft hardened a core Windows component, and that broke one of its own flagship server products for a few days. The response was fairly quick. Grams-IT notes that within three days, Microsoft named the cause, published a registry workaround and added the problem to the Windows release notes (translated from German).

Some of the credit goes to the community. Disassembly work posted in blog comments narrowed down the culprit at about the same time as Microsoft's own advisories.

For on-premises Exchange admins, the lesson is familiar: an Exchange server depends on the Windows build underneath it as much as on its Exchange patches. Testing patches on a lab server that sees no real load wouldn't have caught this, because the failure only shows up under sustained production-level traffic. If your test plan only checks that the server boots and mail flows for an hour, it's worth extending.

Bottom line: keep the October security updates installed, set EpmapSavedContextCap to 65536, reboot, watch your queues, and keep an eye on Microsoft's release-health page for a permanent fix.