Windows Updates Cap RPC Calls and Stall Exchange Mail

Microsoft’s October 13, 2026 Windows Server security updates can stall on-prem Exchange Server mail, blocking Outlook on the web and leaving messages in the Outbox.

The failures come from a new default cap of 512 simultaneous Endpoint Lookup calls in Windows, not from the separate October Exchange security updates. Microsoft lists the issue as Mitigated and is still investigating.

A 512-Call Cap Took Mail Offline

The Exchange Team said on October 16, 2026 that some customer servers became unstable after that Patch Tuesday set. Outlook on the web can fail with MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142), and Event ID 1006 shows up in the Application log.

Mail sent from Outlook can sit in the Outbox. Transport queues can grow until delivery crawls. Database Availability Group members can fail to reach quorum, which takes replica copies and failover with them. A reboot can bring the box back for a while.

SYMPTOMS MICROSOFT TIED TO THE OCTOBER UPDATES

• OWA sign-in: Outlook on the web fails with MapiExceptionMdbOffline and Event ID 1006 in the Application log.
• Outbound mail: Messages stay in the Outlook Outbox and Exchange queues grow during the day.
• Mailbox copies: Replication jobs cannot open mailboxes, and DAG members can miss quorum.
• Reboot pattern: A restart clears the stall for a time, then the same failures can return under load.

Windows release health says the October updates added a default limit of 512 simultaneous Endpoint Lookup calls. That limit is meant to control how much memory Endpoint Mapper spends on those lookups. Heavy Exchange workloads can blow past 512, after which RPC connections to mailbox databases start to fail.

Raising the cap lets Endpoint Mapper use more memory. Microsoft still calls the registry change a temporary mitigation. An extra mitigation is available through Microsoft Support for business for shops that need it.

The Four Windows Updates Tied to the Outages

The Exchange Team named four cumulative Windows Server packages. Installing the October Exchange security updates is not required for the stall to appear. Client SKUs are listed as none. Any Exchange version on an affected Windows build can hit it, and load decides how fast.

WINDOWS SERVER PACKAGES IN THE EXCHANGE NOTICE

KB5126655 is also the last mainstream support update for Windows Server 2022. After that package, Windows Server 2022 moves to extended support, with monthly security updates through October 14, 2031. Exchange shops that stayed on 2022 for the long haul now have a mail-breaking known issue sitting in that last mainstream build.

Not every Exchange server will show the same pain. Microsoft said severity and speed vary with load, and some servers might never see a problem. Quiet lab boxes can look fine while a busy mailbox DAG falls over a day later.

Microsoft Tells Admins to Raise the Cap, Then Reboot

The Exchange Team’s first instruction is to do not uninstall the October Windows updates. The company wants those security packages left in place. The workaround is a DWORD under HKLM\SOFTWARE\Microsoft\Rpc that raises the new cap from 512 to 65536, which is 128 times the default.

Do not uninstall October 2026 Windows Server updates.

The Exchange Team, Microsoft Community Hub, October 16, 2026

THE REGISTRY STEPS MICROSOFT IS USING ON AFFECTED BOXES

1. Leave the updates in: Do not roll back the October 13 Windows Server packages to get mail moving.
2. Set 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.
3. Reboot: The new value takes effect after a restart.
4. Watch, then raise again: If the stall returns, increase the limit further. Microsoft has not published a second number.

The Exchange Team said that sequence has solved the customer cases it has handled so far. After the reboot, watch OWA, outbound queues, mailbox replication, and DAG copy health before you call it done. If 65536 is not enough on a hot mailbox server, Microsoft’s only public guidance is to raise the same value again.

Why a Reboot Only Holds for a While

Endpoint Mapper tracks which RPC service lives on which port. Exchange leans on that path all day for MAPI, store access, and replication. The October packages put a saved-context ceiling on those lookups. Once the ceiling is full, new RPC calls to the mailbox database fail, OWA reports the database as offline, and queues back up.

A reboot wipes the stored contexts, which is why mail comes back after a restart. Under load the count climbs again, and the stall can repeat. That is also why a quiet server can look healthy and a busy DAG node can fail after it has been up for a stretch. Chasing the October Exchange SU first wastes time; the Windows update alone is enough.

The same October 13 packages also close CVE-2026-96300, filed as an RPC Endpoint Mapper Service Denial of Service bug. Microsoft’s summary is uncontrolled resource consumption that lets an unauthorized attacker deny service over a network. The CVE is rated Important, CVSS 5.9, CWE-770 (allocation of resources without limits or throttling). It was not listed as publicly disclosed or exploited, and the exploitability note was Exploitation Less Likely.

Microsoft has not said in the Exchange notice that the 512 cap is the CVE fix. The build numbers still line up. CVE-2026-96300’s patched floors include 10.0.26100.33650, 10.0.17763.9376, and 10.0.14393.9612, which are the OS builds for KB5126646, KB5126651, and KB5126868. A throttle written to stop a mapper resource-exhaustion bug is the same throttle Exchange now trips in ordinary production.

WHAT WE KNOW

• The trigger: The October 13 Windows Server updates, not the October Exchange security updates.
• The cap: 512 Endpoint Lookup calls by default; Microsoft’s working raise is 65536.
• The status: Windows release health still says Mitigated, opened October 16, 2026 at 16:19 PT and last updated that day at 21:48 PT.

WHAT IS UNCONFIRMED

• A shipping fix: No out-of-band Windows update had reset the default as of the October 16 notices, and Microsoft said it would share more when it had it.
• The next DWORD: If 65536 is too low, Microsoft has not named the next value.
• Who always breaks: Load is the only public predictor, so a silent server is not proof the cap will hold.

Until Windows ships a different default, every patched Exchange box is running with either a 512 ceiling that can stall mail or a 128-fold raise that spends more mapper memory on purpose.

Subscription Edition Breaks the Same Way

The report is not limited to Exchange Server 2016 and Exchange Server 2019. The Exchange Team listed Subscription Edition in the same symptom set. SE is the current on-prem product, and it still talks to Windows through the same RPC Endpoint Mapper path.

That matters for anyone who treated an in-place move from 2019 CU14 or CU15 to SE as the end of this class of risk. SE on Windows Server 2025 with KB5126646 is in scope. So is SE on Windows Server 2022 with KB5126655. Hybrid on-prem nodes count too, because the stall is on the Windows box that still hosts the database, not in Exchange Online.

Microsoft’s own wording is blunt on reach: any version of Exchange that runs on the impacted Windows builds could be impacted. The October Exchange SUs for SE RTM, 2019 CU14, 2019 CU15, and 2016 CU23 are a separate stream. They do not cause this outage, and skipping them does not prevent it.

The Last Paid Patch for Exchange 2016 and 2019

Support for Exchange Server 2016 and Exchange Server 2019 ended on October 14, 2025. Paid Extended Security Updates ran in two six-month periods after that. Period 2 runs from May 1, 2026 through October 31, 2026, and October 2026 is the last month of Period 2 ESU coverage for newly released 2016 and 2019 security updates.

EXCHANGE ON-PREM SERVICING AROUND THIS OUTAGE

1. October 14, 2025: Exchange Server 2016 and Exchange Server 2019 reach end of support.
2. May 1, 2026: Period 2 ESU begins for enrolled customers on 2016 CU23 and 2019 CU14 or CU15.
3. October 13, 2026: The last 2016 and 2019 ESU security updates ship, and the four Windows Server packages that stall mail ship the same day.
4. October 16, 2026: The Exchange Team publishes the registry workaround and Windows release health marks the issue Mitigated.
5. October 31, 2026: Period 2 ESU ends. After that, new Exchange security updates are for Subscription Edition only, and Microsoft says it will stop testing 2016 and 2019 for vulnerabilities.

Shops that bought Period 2 to keep 2016 or 2019 patched through October now have a Windows-level mail outage in the same servicing wave as those last Exchange SUs. Uninstalling the Windows packages to restore OWA would also drop whatever else those KBs contain, which is why Microsoft’s first line is to leave them installed and raise the mapper cap instead.

SE remains the only on-prem Exchange SKU that will keep getting new security updates after October 31, 2026. It is also, as of this incident, fully capable of hitting the same 512-call wall.

Dedicated Mail Hosts Get the Night Calls

Exchange Online tenants do not take this hit. The people who do are the ones still running a Windows Server mailbox role: a company DAG in a rack, a hybrid on-prem node that holds a few shared mailboxes, a dedicated or colocated box a hosting customer never migrated. Those are the servers where OWA dies, Outboxes fill, and a DAG copy goes Failed while the database still claims it is Mounted.

For a hoster, the awkward part is the reboot. Microsoft’s workaround requires a restart of the Exchange server after the DWORD is set, and a restart of a mailbox node is a planned mail event even when the cluster is healthy. Applying 65536 before the 512 ceiling fills is cleaner than waiting for Event ID 1006 and then bouncing a DAG member in the middle of the night.

Monitor after the reboot the same way you would after a CU: OWA sign-in, Test-MAPIConnectivity, queue viewer, and copy status. If the stall returns, raise EpmapSavedContextCap again and call Microsoft Support for the extra mitigation rather than removing KB5126646, KB5126655, KB5126651, or KB5126868.

Microsoft is still investigating. Until a later Windows update changes the default, on-prem Exchange stays on a mapper ceiling that was built to save memory and, at 512, is low enough to stop mail.