October's Windows Server updates and on-premises Exchange: what broke and what to do

If you still run Exchange on-premises, this month's Windows Server updates may have caused you a bad week. The fault isn't in the Exchange security update at all. It's a new limit in a core Windows component, and busy Exchange servers can run into it a day or so after a reboot.

What happened

Microsoft has confirmed that the October Windows Server security updates can make some Exchange servers unstable. The updates involved are:

KB5126646 for Windows Server 2025
KB5126655 for Windows Server 2022
KB5126651 for Windows Server 2019
KB5126868 for Windows Server 2016

Exchange Server 2016, Exchange Server 2019 and Exchange Server Subscription Edition can all be affected. According to Microsoft, the updates bring in a default limit of 512 simultaneous Endpoint Lookup calls for the RPC Endpoint Mapper, the Windows service that tells clients which port an RPC service is listening on. Heavy Exchange workloads can go over that limit, and when they do, database connections start to fail.

Not every server will show it. Microsoft says the impact depends on workload, and some servers may never have a problem. A server can be affected even if you haven't installed the October Exchange security update, because the cause is the Windows update.

How to spot it

The symptoms look like a general Exchange outage, which is what makes this one easy to misdiagnose:

Users can't sign in to Outlook on the web.
Messages sit in the Outbox in Outlook.
Mail queues keep growing.
In a Database Availability Group, copies stop replicating and members can struggle to reach quorum.
The error MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142) appears, along with Event ID 1006 in the Application log.

One write-up from an Exchange engineer reports that the failure tends to show up about 22 to 30 hours after a restart. A reboot brings the service back, but only for a while. If you've been rebooting an Exchange box every day since Patch Tuesday and calling it fixed, this is probably why.

A quick check from an elevated PowerShell window on the Exchange server:

Get-HotFix -Id KB5126646, KB5126655, KB5126651, KB5126868 -ErrorAction SilentlyContinue
Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1006} -MaxEvents 20

The workaround

Microsoft's advice is to raise the limit with a registry value and restart the server. From an elevated Command Prompt:

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

The value is only read when the server starts, so the restart is not optional. Afterwards, confirm it's there:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Rpc" -Name EpmapSavedContextCap

Editing the registry on a production Exchange server is a change, so log it and do it in a window where a restart is acceptable. In a DAG, move active databases off the member first and do one server at a time.

Microsoft says this has fixed the problem in the customer cases it has handled. If failures come back, it says the limit should be raised further, but it hasn't published a higher figure. It also offers an extra mitigation through Microsoft Support.

Don't uninstall the update

The tempting fix is to remove the Windows update and move on. Microsoft specifically says not to. These are security updates, and one engineer reports that a reader had RDP sign-in problems after removing the Windows Server 2016 update. The same write-up suggests taking the registry value back out once Microsoft ships a proper fix, because the higher limit weakens the protection the new cap was added for. Keep a note of which servers you changed so you can do that later.

What I'd take from this

Exchange servers are some of the most fragile Windows boxes we still look after, and they're getting a Windows update every month whether the Exchange team has tested it or not. A few habits make months like this much easier:

Patch Exchange hosts last, not first. Let general servers and a test box take the update a few days earlier.
Watch for at least 48 hours. This fault doesn't show at reboot. It shows the next day. Keep an eye on queues and the Application log for two days after patching.
Check Windows release health before you blame Exchange. When Exchange falls over after Patch Tuesday, the Windows update is now just as likely a cause as the Exchange one.
Keep a change log per server. Registry workarounds like this one are meant to be temporary. If nobody writes them down, they never get removed.

Microsoft lists the issue as mitigated, not resolved, so expect a follow-up fix. Until then, the registry value and a restart is the answer.

Sources

← All posts