Exchange Outages After the October 2026 Windows Server Updates: MapiExceptionMdbOffline (ec=1142)

Since Patch Tuesday on October 13, 2026, Exchange servers have been failing after around 24 hours of uptime: clients lose their mailbox connection, OWA reports MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142), emails remain in queues, and database copies in DAGs no longer replicate. Microsoft added a note to the announcement of the October Exchange SUs on October 15, 2026: the October updates for Windows Server are the cause, and installing the Exchange SU is not required for the issue to occur. No fix or official workaround is available yet (as of October 16, 2026).

Symptoms

The symptoms reported so far:

• OWA fails with MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142); Event ID 1006 is recorded in the Application Log.
• Outlook clients lose their mailbox connection.
• Emails are delivered neither internally nor externally, and transport queues grow.
• In DAGs, database copies no longer replicate; according to reader reports at Born, switchovers when entering maintenance mode fail.
• The Exchange Admin Center still shows the databases as mounted (Frankys Web).

The error does not occur immediately after installation, but according to reports after approximately 22 to 30 hours of uptime. Restarting the server restores operation, but the outage recurs after approximately the same period. Comments at Born note that the mailbox replication service stops during or after database maintenance tasks, after which the MdbOffline errors begin; this has not been confirmed.

Affected updates

In the addendum to the Exchange announcement, Microsoft lists these cumulative Windows updates:

The same Patch Tuesday also saw the release of the Exchange SUs (Exchange SE: KB5128895, “SU11”) and cumulative updates for the .NET Framework. The following three packages were installed on an affected Exchange SE server running Windows Server 2019:

• Security Update For Exchange Server Subscription Edition (KB5128895)
• 2026-10 Cumulative Update for .NET Framework 3.5, 4.7.2 and 4.8 for Windows Server 2019 for x64 (KB5128923)
• 2026-10 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5126651)

Microsoft does not mention the .NET update in the addendum. However, readers at Born report outages with the combination of the Windows and .NET updates (KB5128928 there on Windows Server 2022), as well as a server with KB5126651 and the Exchange SU but without the .NET update that was still running after more than 24 hours. Whether the .NET update is involved therefore remains unclear.

Regarding the Exchange SU: forums and comments state that the situation improves when Exchange SU11 is installed. This cannot be confirmed; outages also occurred on a server with SU11. Conversely, several administrators report outages without an installed Exchange SU, which is consistent with Microsoft’s statement. The Exchange SU closes six vulnerabilities, including a critical remote code execution vulnerability through a crafted email; details are in the article on the October SU. Withholding it does not resolve the issue.

Check the status

First, determine which October updates are installed on each Exchange server:

$kbs = "KB5126646", "KB5126655", "KB5126651", "KB5126868", "KB5128923"
Get-HotFix -Id $kbs -ErrorAction SilentlyContinue |
  Select-Object PSComputerName, HotFixID, InstalledOn

Get-HotFix does not reliably list .NET updates on all systems; when in doubt, the update history in Settings shows the complete status. Check the Exchange build in the Exchange Management Shell with Get-ExchangeServer | Format-Table Name, AdminDisplayVersion and compare it with the Exchange build numbers.

Then check the status of databases, copies, and queues in the Exchange Management Shell:

Get-MailboxDatabaseCopyStatus -Server $env:COMPUTERNAME |
  Format-Table Name, Status, CopyQueueLength, ReplayQueueLength, ContentIndexState
Get-Queue | Where-Object MessageCount -gt 0 |
  Format-Table Identity, DeliveryType, Status, MessageCount, LastError
Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1006; StartTime=(Get-Date).AddDays(-2)} |
  Select-Object TimeCreated, ProviderName, Message

Several Exchange components log Event ID 1006; the decisive entry is the one containing the MdbOffline message in its text.

What to do until a fix is available

Microsoft says it is investigating the issue together with the Windows team and has not yet provided either a workaround or rollback. In the meantime:

1. Exchange servers not yet updated: Defer the October Windows updates (and the .NET update from the same day) on Exchange servers in WSUS, Intune, or your own update management system. This requires weighing the risks: the Windows updates also close security vulnerabilities. Exchange servers accessible from the Internet should therefore be monitored particularly closely.

2. Install the Exchange SU anyway: According to Microsoft, Exchange SU KB5128895 (or the ESU packages for 2016/2019) is not the cause and closes a critical vulnerability that can be exploited by email without an account.

3. Servers already affected: A restart restores operation for around one day. Schedule controlled restarts at intervals well below 22 hours, for example every night, rather than waiting for the next outage. According to readers at Born, restarting only the Exchange services also helps temporarily; how long it lasts is unconfirmed.

4. DAG: Restart members one at a time and move active databases to a freshly restarted server first. After each restart, use Get-MailboxDatabaseCopyStatus to verify that copies are Healthy again and queues are draining before restarting the next server.

5. Monitor queues: Keep an eye on Get-Queue and Event ID 1006, ideally with alerting so that an outage is not discovered only through user reports.

6. Check backups: A reader at Born reported a failed VSS writer in the backup after the outage. Check backups from the last few nights.

For uninstalling the Windows updates: since 2021, Microsoft has delivered the cumulative update together with the Servicing Stack Update as a combined package. wusa /uninstall does not remove such a package; DISM /Online /Remove-Package with the package name from DISM /Online /Get-Packages is required. Microsoft has not approved uninstallation as a workaround, and no reports of a successful rollback followed by stable operation are available so far. If you test this at all, test it on a single server first.

According to Frankys Web, Microsoft does not yet list the issue as a Known Issue in the Windows updates (as of October 16, 2026). Keep an eye on the Microsoft announcement; Microsoft posts additions there at the end under “Updates to this blog post.” This article will be updated as soon as a fix or official workaround is available.