November 2026 Windows Server Updates Fix Exchange OWA Sign-In and Stuck Mail Issues

This was not a quick outage. Many Exchange shops spent close to a month on a registry tweak while waiting for Microsoft to fix its own default setting.

What broke, and why it was hard to spot​

According to Microsoft's Windows release health entry, after the October 2026 Windows security update some on-premises Exchange servers had trouble reading or sending email. The documented symptoms were:

• OWA sign-in failures: users couldn't log in to Outlook on the web.
• Stuck outgoing mail: messages sent from Outlook stayed in the Outbox and were never delivered.
• Mailbox replication trouble: Exchange couldn't reach mailboxes during replication.
• A specific error signature: in some configurations OWA failed with MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142), and Event ID 1006 was logged in the Application log.
• Growing mail queues, which Microsoft also lists as a reported symptom.

The failure was slow. Swiss Exchange consultant Rafael Pfister wrote that after the October 13 updates, Exchange servers report MapiExceptionMdbOffline (ec=1142) after around 24 hours: OWA fails, queues grow, and DAG copies stop replicating. A server could pass every post-patch check on Tuesday afternoon and start failing on Wednesday, after the change window had closed.

Microsoft's Exchange team also warned that the impact varied. Some servers degraded quickly, some slowly, and some never had a problem, depending on load.

The root cause: a new limit in the RPC Endpoint Mapper​

The October update added a default limit on how much memory the Endpoint Mapper can use when it handles Endpoint Lookup calls. The Endpoint Mapper is the Windows RPC service that tells clients which port a service is listening on. Microsoft's release health entry says the default of 512 simultaneous Endpoint Lookup calls may not be enough for workloads like Exchange under heavy load.

Techzine summarized it this way: the updates limit the number of concurrently stored RPC Endpoint Mapper contexts to 512 by default. Exchange continues to accumulate these contexts under load. Exchange keeps adding contexts and the Endpoint Mapper refuses to store more, so the failures arrive gradually.

The cap probably exists for a reason. Limiting memory use in a core RPC service is a common way to harden it, which would explain why it arrived in a security update. That part is my inference: Microsoft's published notes describe what the limit does but don't say why it was added. Either way, nobody seems to have tested the default against a busy Exchange server.

Which systems were affected​

BleepingComputer's report described the affected systems as Windows Server 2019 and later. Microsoft's own release health entry is broader:

Windows Server 2016 is on the list. Exchange admins still on 2016-era servers should not assume they were spared.

Several outlets also mapped the October trigger updates to each Windows Server version. Pro IT NW reported that Microsoft ties the problem to the October 2026 Windows Server cumulative updates — KB5126646 (Server 2025), KB5126655 (Server 2022), KB5126651 (Server 2019), and KB5126868 (Server 2016). Microsoft's own pages confirm KB5126651 as the Server 2019 trigger and show that the November Server 2025 update supersedes KB5126646.

The Exchange version didn't matter. ITdaily noted that any Exchange version running on an affected Windows version may be impacted. Microsoft says the problem could occur without the October 2026 Exchange Server security updates installed. It has repeatedly told customers not to uninstall those Exchange updates, because they weren't the cause.

The timing made this worse. Fanpino.com reported that on 13 October 2026 Microsoft shipped what it calls the last security update that Exchange Server 2016 and 2019 will ever get. Admins installing that last patch saw Exchange fall over a day later, and the obvious suspect turned out to be innocent.

The fix: November 2026 Patch Tuesday​

Microsoft has marked the issue resolved. The fix is in Windows updates released November 10, 2026 and later:

• Windows Server 2025: KB5131080 (OS Build 26100.33822). The release notes include an [Exchange Server] entry saying the update fixes the OWA sign-in, Outbox, and mailbox replication problems on on-premises Exchange servers.
• Windows Server 2019: Microsoft's release health page lists KB5131085 as the resolving update and marks the entry Resolved as of November 10.
• KB5131090: BleepingComputer names it alongside KB5131080 as a November update that fixes the issue.
• Windows Server 2022 and 2016: Microsoft says updates released on or after November 10 resolve the issue, so install the November cumulative update for your version. I couldn't confirm the exact November KB numbers for these two versions in Microsoft's documentation, so check them in your patching console instead of relying on a number from a news article.

Microsoft's guidance is that once the November 10 update (or later) is installed, the workaround isn't needed.

Patching notes for Server 2025 admins​

The KB5131080 notes include a few details that matter if you install manually:

1. Servicing stack prerequisite: you need servicing stack update version 26100.33822 or later. Check it from an elevated prompt with DISM /Online /Get-Packages | findstr /i "ServicingStack".
2. Checkpoint update: the Microsoft Update Catalog package needs the checkpoint cumulative update (KB5043080) installed first. Alternatively, put all the MSU files in one folder and let DISM install them in order.
3. WSUS sync: the product is listed as "Microsoft Server operating system-24H2" with the Security Updates classification.

The same update makes two other changes worth testing on Exchange servers:

• NTLM signing: clients now offer NTLM message signing by default for non-anonymous connections.
• PowerShell script signing: encoding validation is stricter, so signed scripts with invalid UTF-8 encoding may fail signature checks even if they passed before. Exchange admins with a library of signed maintenance scripts should test them before relying on scheduled tasks.

The workaround if you can't patch yet​

For servers that can't take the November cumulative update right away, Microsoft's temporary registry workaround still applies. It raises the limit on simultaneous Endpoint Lookup calls, which also raises the memory the Endpoint Mapper can use.

Step by step:

1. Open an elevated Command Prompt on the affected Exchange server.
2. Run:
   reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f
3. Restart the server. The change doesn't take effect until you do.
4. Check that the value is set:
   reg query "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap
5. Monitor Exchange after the reboot: OWA sign-ins, transport queues, and DAG copy health.
6. If symptoms come back, Microsoft's guidance is to raise the limit further.

ITdaily reported that, according to Microsoft, this approach resolved the issue for the customers the company has assisted so far. Microsoft's release health entry also says Microsoft Support can provide an additional mitigation for affected devices.

What "fixed" looks like: OWA logins succeed, Outbox items go out, queues drain instead of growing, database copies show healthy, and Event ID 1006 / ec=1142 errors stop appearing in the Application log. Remember that failures took around a day to appear, so don't declare success after an hour. Watch through at least one full business day of normal load.

What not to do: don't uninstall the October Windows updates. TechRepublic noted that Microsoft advises against uninstalling October's Windows Server updates because doing so would remove their security fixes. Don't remove the October Exchange security update either. It didn't cause the problem, and for Exchange 2016 and 2019 it's the last one those versions will get.

Analysis: lessons for patching Exchange​

Microsoft handled the response reasonably well. It warned customers within days, published a workaround about three days after Patch Tuesday, and shipped a permanent fix in the next monthly cycle. It also made clear the problem came from Windows, not Exchange, which stopped admins from pulling a security update they needed.

Still, a security hardening change shipped with a default that busy Exchange servers could exceed, and Exchange is one of the heaviest RPC workloads Microsoft owns. The delayed failure also beat the usual patch-validation process. Most change windows run smoke tests right after the reboot. That catches crashes, not slow resource exhaustion that appears a day later.

Practical takeaways:

• Test under real load. A test lab with a few dozen mailboxes would probably never have reached 512 concurrent Endpoint Lookup contexts. A pilot ring on production-like load would have had a better chance.
• Watch for delayed failures. Add queue length and DAG copy health checks to the 24 to 48 hours after patching, not just the first hour.
• Track registry workarounds. If you applied EpmapSavedContextCap, record which servers have it. Microsoft says the workaround isn't needed after the November update. Its notes don't say explicitly whether to remove the value, so make that decision on purpose and document it.

Summary​

• Cause: the October 2026 Windows Server cumulative updates added a 512-call default cap on Endpoint Mapper lookups, which busy on-premises Exchange servers exceeded.
• Affected: Windows Server 2016, 2019, 2022, and 2025 running Exchange 2016, 2019, or Subscription Edition. Not every server failed; it depended on load.
• Symptoms: OWA sign-in failures, mail stuck in Outboxes, growing queues, replication problems, and MapiExceptionMdbOffline ec=1142 with Event ID 1006.
• Fix: Windows updates released November 10, 2026 or later, including KB5131080 for Server 2025 and KB5131085 for Server 2019.
• Interim workaround: set EpmapSavedContextCap to 65536, reboot, monitor, and raise the value if symptoms return.
• Keep installed: the October Windows and Exchange security updates.