Exchange ServerTroubleshooting

Exchange unstable after October 2026 Windows Server updates: MdbOffline and the RPC fix

October 2026 Windows Server updates can make Exchange fail hours later with MapiExceptionMdbOffline (ec=1142), growing queues and DAG issues. Confirm it, apply the registry fix, verify.

If your Exchange servers were fine on Patch Tuesday and then, a day or so later, OWA started failing with MapiExceptionMdbOffline while the queues kept growing, the Exchange security update is probably not to blame. Microsoft has documented that the October 2026 Windows Server cumulative updates can destabilize Exchange. In this post I'll stick to what Microsoft has published about the issue, then walk through how to confirm it on your servers, roll out the documented registry workaround safely across a DAG, and prove the fix held.

Errors this guide fixes

  • MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142)OWA / ECP
  • Event ID 1006Application log
How this guide is organized: Symptoms → Why it happens → How to fix it → Verify the fix → Prevent it next timeFlow diagram of the article's sections in reading order: 1. Symptoms. 2. Why it happens. 3. How to fix it (4 steps: Confirm the update and the symptom; Rule out look-alikes; Apply Microsoft's workaround one server at a time; Only then consider a higher value). 4. Verify the fix. 5. Prevent it next time. Toolbox: Event ID 1006, Event ID 1135, Get-Queue, Test-ReplicationHealth, Get-MailboxDatabaseCopyStatus.1Symptoms2Why it happens3How to fix it4Verify the fix5Prevent it nexttime1Confirm the update andthe symptom2Rule out look-alikes3Apply Microsoft'sworkaround one server…4Only then consider ahigher valueTOOLBOXEvent ID 1006Event ID 1135Get-QueueTest-ReplicationHealthGet-MailboxDatabaseCopyStatusHow this guide is organized: Symptoms → Why it happens → How to fix it → Verify the fix → Prevent it next timeFlow diagram of the article's sections in reading order: 1. Symptoms. 2. Why it happens. 3. How to fix it (4 steps: Confirm the update and the symptom; Rule out look-alikes; Apply Microsoft's workaround one server at a time; Only then consider a higher value). 4. Verify the fix. 5. Prevent it next time. Toolbox: Event ID 1006, Event ID 1135, Get-Queue, Test-ReplicationHealth, Get-MailboxDatabaseCopyStatus.1Symptoms2Why it happens3How to fix it1Confirm the update and the symptom2Rule out look-alikes3Apply Microsoft's workaround one server at atime4Only then consider a higher value4Verify the fix5Prevent it next timeTOOLBOXEvent ID 1006Event ID 1135Get-QueueTest-ReplicationHealthGet-MailboxDatabaseCopyStatus
At a glance: how this guide is organized · 4 fix steps · 5 key tools

Status (November 2026): Microsoft added this issue to Windows release health on 16 October 2026 (Windows Server 2025, 2022, 2019 and 2016) with status Mitigated, and published KB5133432 and an Exchange Team Blog post the same day. Originating updates: KB5126646 (Server 2025), KB5126655 (2022), KB5126651 (2019) and KB5126868 (2016). Exchange SE, 2019 and 2016 can all be affected. A registry workaround is available; Microsoft says there's no imminent follow-up release from Windows or Exchange and that you shouldn't wait for one. Re-check the official pages, because the status will change.

Symptoms#

As documented by Microsoft in KB5133432, the Windows release health entry and the Exchange Team Blog:

  • Outlook on the web fails with this error, and the Exchange Team Blog adds that Event ID 1006 is logged in the Application log at the same time:
    Text
    MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142)
  • Mail queues grow during the day until mail flow slows down or stops; messages sent from Outlook can stay in the Outbox.
  • Database availability group (DAG) members can't communicate or establish quorum, and mailbox access during mailbox replication can be affected.
  • A restart may clear the problem for a while. How fast it comes back depends on server load, and some servers never show it.

The delay is the giveaway: the servers work after the reboot that finishes patching, then degrade hours later. Admins have reported a gap of roughly a day, but Microsoft only says the severity and speed vary with workload.

Why it happens#

According to the Windows release health entry, the October 2026 update introduced a default limit on the memory the RPC Endpoint Mapper uses for Endpoint Lookup calls. The default allows 512 simultaneous Endpoint Lookup calls, which Microsoft says might not be enough for workloads such as Exchange Server under heavy load. The registry value EpmapSavedContextCap raises that maximum, which in turn lets the Endpoint Mapper use more memory.

Two points from Microsoft matter when you explain this to a change board:

  • It is not a known issue of the October 2026 Exchange security update. Installing the Exchange SU isn't required for the problem to appear, so removing it won't help.
  • Microsoft explicitly says not to uninstall the October Windows Server updates. They carry a significant security payload.

How to fix it#

Is it the October 2026 Windows Server update issue?Is the October 2026 Windows Server update installed? if No: Look at other causes first (Back pressure, IIS or cluster problems can look similar); if Yes: Does OWA show MdbOffline ec=1142 or do queues keep growing? if Yes: Apply the registry workaround (EpmapSavedContextCap = 65536, then restart one DAG member at a time); if Not yet: Add the value before it bites (Microsoft says creating it ahead of time is safe)Is the October 2026 WindowsServer update installed?NOTELook at other causesfirstBack pressure, IIS or clusterproblems can look similarNoDoes OWA show MdbOfflineec=1142 or do queues keepgrowing?FIXApply the registryworkaroundEpmapSavedContextCap =65536, then restart oneDAG member at a timeYesOKAdd the value before itbitesMicrosoft says creating itahead of time is safeNot yetYesIs it the October 2026 Windows Server update issue?Is the October 2026 Windows Server update installed? if No: Look at other causes first (Back pressure, IIS or cluster problems can look similar); if Yes: Does OWA show MdbOffline ec=1142 or do queues keep growing? if Yes: Apply the registry workaround (EpmapSavedContextCap = 65536, then restart one DAG member at a time); if Not yet: Add the value before it bites (Microsoft says creating it ahead of time is safe)Is the October 2026 Windows Server updateinstalled?NoNOTELook at other causes firstBack pressure, IIS or cluster problems can look similarYesDoes OWA show MdbOffline ec=1142 or doqueues keep growing?YesFIXApply the registry workaroundEpmapSavedContextCap = 65536, then restartone DAG member at a timeNot yetOKAdd the value before it bitesMicrosoft says creating it ahead of time is safe
Figure 1 · Decision tree Is it the October 2026 Windows Server update issue?. Confirm the Windows update and the symptom first, then apply Microsoft's registry workaround one server at a time.

1. Confirm the update and the symptom#

On each Exchange server, check that the October update for its Windows Server version is installed, whether the registry value already exists, and whether Event ID 1006 has been logged since patching:

PowerShell
Get-HotFix | Where-Object HotFixID -in 'KB5126646','KB5126655','KB5126651','KB5126868'
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Rpc' -Name EpmapSavedContextCap -ErrorAction SilentlyContinue
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; Id = 1006; StartTime = (Get-Date).AddDays(-7) } -MaxEvents 20 |
  Format-List TimeCreated, ProviderName, Message

Then look at Exchange from the Exchange Management Shell:

PowerShell
Get-Queue | Where-Object { $_.MessageCount -gt 50 } | Format-Table Identity, Status, MessageCount, LastError -AutoSize
Get-MailboxDatabaseCopyStatus -Server $env:COMPUTERNAME | Format-Table Name, Status, CopyQueueLength, ContentIndexState
Get-DatabaseAvailabilityGroup -Status | Format-List Name, OperationalServers, PrimaryActiveManager

The October update installed, no EpmapSavedContextCap value, the OWA error above and queues that keep growing on a server that was healthy before patching together match the documented issue.

2. Rule out look-alikes#

What you seePoints to
Queues with 452 4.3.1 Insufficient system resources and Event 15004Back pressure: see fixing back pressure
OWA HTTP 500 right after the reboot, before any load buildsA setup or IIS problem: see OWA and ECP HTTP 500 causes
Cluster Event 1135 on servers that never got the October updateA network or witness problem: see DAG quorum and Event 1135

3. Apply Microsoft's workaround one server at a time#

The documented change is a single DWORD followed by a restart. From an elevated Command Prompt on the Exchange server:

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

In a DAG, treat the restart like patching: put the server into maintenance mode, restart it, take it out again and check the database copies before moving to the next member. The full sequence is in DAG maintenance mode for patching. The value is read when Windows starts, so it has no effect until the restart.

Microsoft's FAQ confirms you can also create the value before installing the October update: it's only used once the update is present and survives the installation. That makes it worth adding to your Exchange build checklist now, including for servers you haven't patched yet.

4. Only then consider a higher value#

KB5133432 says to increase the limit if the issue comes back. The Exchange Team added on 20 October 2026 that it hadn't yet seen a case that needed more than 65536. If symptoms return with the value in place, open a case: the release health entry mentions an additional mitigation that's only available through Microsoft Support for business.

Verify the fix#

  • The value is present on every Exchange server and each one has restarted since it was set: (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Rpc').EpmapSavedContextCap returns 65536.
  • No new Event ID 1006 with MapiExceptionMdbOffline after a full business day under normal load. One quiet hour proves nothing, because the issue builds up over time.
  • Get-Queue stays near zero, Get-MailboxDatabaseCopyStatus * shows Healthy copies and Test-ReplicationHealth passes on each DAG member.
  • OWA sign-in and a test message between two mailboxes on different servers work at the end of the day, not just after the restart.
  • The Exchange Server Health Checker runs clean. See fixing what Health Checker finds.

Prevent it next time#

  • Patch one Exchange server, let it carry production load for at least a day, and only then patch the rest. This issue only showed itself under load, hours after a clean restart.
  • Watch Windows release health for the Windows Server versions your Exchange servers run, not only the Exchange Team Blog. This one surfaced as a Windows known issue.
  • Keep the Windows Server updates. Uninstalling them trades one problem for every vulnerability they close.
  • Exchange 2016 and 2019 received their last ESU update in October 2026, so the long-term fix for those servers is a move to Exchange Server SE. For the other open items after each update, see the Exchange Server known issues roundup.

References#

Written and checked against current Microsoft Learn documentation. Test changes with a pilot group before rolling them out to everyone, and if an admin center path has moved since, search for the setting name instead.

Spotted a mistake, or did this fix work differently for you? Email me or message me on LinkedIn — corrections are credited in the article.

Written by

Omer Eltayeb

M365 Subject Matter Expert, former Microsoft Cloud Solutions Architect, Microsoft Certified Trainer and Microsoft Innovative Educator Expert (2024–26) and Microsoft Elevate Educator Expert (2026–27). I share practical, step-by-step guides, study plans, scripts and toolkits for Microsoft Intune, Configuration Manager, Microsoft Entra ID, Microsoft Defender, Exchange and Microsoft 365 with the community.

Microsoft Certified Trainer (MCT) 2026Microsoft Innovative Educator Expert 2025–2026Microsoft Elevate Educator Expert 2026–2027ISC2 Certified Information Systems Security Professional (CISSP)Microsoft 365 Certified: Enterprise Administrator Expert (MS-102)