Microsoft's Exchange Team posted on 16 October that since the 13 October Patch Tuesday, "we have seen some reports of customer issues where Exchange Servers become unstable after a set of October updates are installed".

The symptoms it lists are not subtle. Outlook on the web fails with MapiExceptionMdbOffline, error code 1142, logging event ID 1006. "Exchange email queues might grow during the day, with email crawling to a halt." Database availability group members fail to reach quorum. A reboot fixes it, temporarily.

Exchange Server 2016, 2019 and Subscription Edition can all be affected.

It is not the Exchange update

Microsoft is careful about this, and the care is worth noting: "Issues reported are not related to installation of October 2026 security updates for Exchange Server. This is not a 'known issue' related to October 2026 Exchange update. Any version of Exchange that runs on impacted versions of Windows could be impacted."

The updates that cause it are the Windows Server ones: KB5126646 on Server 2025, KB5126655 on 2022, KB5126651 on 2019 and KB5126868 on 2016.

So an Exchange administrator who skipped the Exchange update and applied the operating system updates is exposed, and one who did the reverse is not. That is the opposite of the instinct most people have about which patch to be nervous of.

The fix is a number, and then a bigger number

Microsoft's recommendation starts with an instruction against the obvious move: "Do not uninstall October 2026 Windows Server updates."

Instead, from an elevated prompt on the Exchange server, set a DWORD named EpmapSavedContextCap under HKLM\SOFTWARE\Microsoft\Rpc to 65536, and reboot.

The October update introduced a cap on simultaneous endpoint lookup calls in the RPC endpoint mapper, and the default it shipped with is 512. The recommended value is one hundred and twenty-eight times that.

Then the sentence that tells you where this actually stands: "After the reboot, monitor the environment and confirm whether the issue recurs. If it re-occurs, raise the limit."

That is not a fix. It is a dial, handed to the administrator, with instructions to turn it until the symptom stops. Microsoft says this has resolved the customer cases it has assisted with to date, which is an honest description of a mitigation and not of a root cause.

Why some servers and not others

"Not all Exchange servers will be impacted by installation of those updates equally; the severity and speed of impact varies based on Exchange server load. Some servers might never see a problem."

A load-dependent default is the worst kind to get wrong, because it passes testing. A lab Exchange server with a handful of mailboxes stays under 512 concurrent lookups and looks fine. A production server at a few thousand users does not, and fails hours or days after the reboot that installed the update, by which point the update is no longer the obvious suspect.

That delay is also why the first reports were confused: the change lands on Tuesday and the mail stops on Thursday.

What to do

  • Apply the registry value on Exchange servers before you need it, if you have installed the October Windows Server updates. Waiting for the symptom costs you the outage.
  • Do not roll back the Windows updates. They are security updates and Microsoft says explicitly not to.
  • If the symptom returns after the change, raise the value rather than assuming the change failed. That is the documented behaviour.
  • Watch queue depth and event ID 1006 rather than waiting for user reports. The failure mode announces itself in the Application log first.
  • Treat a lab that passed as no evidence at all here, because the trigger is load.

What is not established

  • The root cause. Microsoft describes a cap and a workaround, not why Exchange exceeds it.
  • Whether a permanent fix is coming, or in which update.
  • Why 512 was chosen, or whether it was validated against Exchange workloads before shipping.
  • How many organisations are affected. Microsoft says only that reports have come in and that impact varies with load.
  • Whether 65536 is sufficient in the largest environments. The instruction to raise it further implies it is not always.
  • Whether anything other than Exchange is affected by the same cap. The post addresses Exchange because that is where it surfaced.