Updated Oct19: Removed “additional mitigation is available for affected devices” comment, which concerns the same registry key mitigation.

A heads-up not directly related to the October Exchange SUs, but important if you run Exchange on-premises: Reports indicate that last Tuesday’s Windows Server patches might break Exchange functionality.

The Windows Server updates that might cause issues are:

• KB5126646 for Windows Server 2025 (build 26100.33650)
• KB5126655 for Windows Server 2022 (build 20348.5761)
• KB5126651 for Windows Server 2019 (build 17763.9376)
• KB5126868 for Windows Server 2016 (build 14393.9612)

Symptoms

Official and user-reported symptoms include:

• OWA and Outlook losing mailbox connectivity.
• External and internal messages accumulating in mail queues.
• DAG copies no longer replicating; switchovers might not function.
• EAC still showing databases as mounted when they are not.

Also, the following event might be logged in the Application event log:

Source: MSExchange Mailbox Replication
Event ID: 1006
Description: The Microsoft Exchange Mailbox Replication service was unable to process jobs in a mailbox database.
Database: <Mailbox DB>
Error: MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142).

You might want to check your event log using:

Get-WinEvent -FilterHashtable @{ LogName='Application'; Id=1006; StartTime=(Get-Date).AddDays(-1); ProviderName='MSExchange Mailbox Replication' }

These symptoms start around 24 hours after installing the Windows Update. Rebooting the server temporarily resolves the issue, but symptoms may reappear after the same interval.

RPC Endpoint Mapper

As noted in comments on a German website, Frankyweb, someone noticed that these Windows Server updates introduce a 512-stored-search-contexts limit in RpcEpMap.dll (RPC Endpoint Mapper). A search context is how RPC keeps track of which service runs on which port/interface. Microsoft likely introduced this limit to mitigate CVE-2026-96300, which addresses “Uncontrolled resource consumption” that could lead to denial-of-service attacks. Because Exchange might create more requests simultaneously and only release them when the related Exchange process terminates, you might run into RPC port exhaustion.

This sounds like a plausible explanation, as I noticed on my setup, which hosts a Database Availability Group, the event log contains the following “no more endpoints available” events around the same time the 1006 events start to show up:

Source: MSExchangeRepl
Event ID: 4082
Description: The replication network manager encountered an error while monitoring events. Error: Microsoft.Exchange.Cluster.Shared.ClusterApiException: An error occurred while attempting a cluster operation. Error: Cluster API failed: “OpenCluster( … ) failed with 0x6d9. Error: There are no more endpoints available from the endpoint mapper” —> System.ComponentModel.Win32Exception: There are no more endpoints available from the endpoint mapper

The ~24-hour interval also makes sense, as the search contexts slowly fill up. A reboot would clear them.

Workaround

The suggested temporary workaround is to set the contexts registry key to something bigger than the new default of 512, e.g., 65536:

New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Rpc -Name EpmapSavedContextCap -Value 65536 -PropertyType DWORD -Force

Be advised that this undermines CVE-2026-96300, so you may not want to jump straight to the maximum value. If needed, you can always bump it. Should you want to remove the key again, use:

Remove-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Rpc -Name EpmapSavedContextCap

Needless to say, the above puts a band-aid on your servers until Microsoft releases an official fix.

Official statement

On October 17, the Exchange team published a blog confirming the issue. They explicitly recommend against uninstalling Windows Server updates, applying the mitigation through the registry key mentioned above, rather than rolling back the security updates. They recommend setting it initially to 65536 and raising it if issues persist. Implementing the registry key is considered a temporary mitigation. Note that the official statement claims this issue “might happen under load”, but I have seen it occur in my lab environment, which I can assure you is not under load.

The Windows Server known issues page contains information on the OWA issue:
Users might be unable to sign in to OWA or send emails on Exchange Server.

Officially, Microsoft is still investigating this issue. It’s likely more about how to proceed than the root cause, which is clear now. Given how Exchange uses RPC for communication, especially within its own ecosystem, I suspect a fix would require steps from both the Exchange team (RPC Endpoint Mapper connection management) and the Windows Server team. Until then, the registry mitigation works fine.

I will update the post as information becomes available.