Additional diagnostic findings from our eight independent Exchange Server SE environments.
We manage eight Exchange Server SE servers running Windows Server 2019 and Windows Server 2025. All eight servers experienced the same MapiExceptionMdbOffline error after installing the October 2026 Windows updates.
Affected Windows updates:
Windows Server 2019: KB5126651
Windows Server 2025: KB5126646
- Consistent failure timing
Five independent servers were found to have failed at the following system uptimes:
22 hours 8 minutes
22 hours 17 minutes
22 hours 19 minutes
22 hours 40 minutes
22 hours 45 minutes
On another server, the issue occurred a second time after a complete reboot without changing the installed updates.
Last boot: October 15, 2026 at 08:46:29
First recorded Event ID 1006: October 16, 2026 at 06:45:55
Uptime to first recorded error: 21 hours 59 minutes 25 seconds.
On one server, all three MAPI connectivity tests were successful at 22 hours 1 minute 19 seconds of uptime and failed at 22 hours 2 minutes 28 seconds.
The transition was observed within 69 seconds.
The timestamps represent when failures were detected, not necessarily the exact beginning of the underlying issue.
- Exchange processes remained running
We verified that Microsoft.Exchange.Store.Service, Microsoft.Exchange.Store.Worker and Microsoft.Exchange.RpcClientAccess.Service retained their original process IDs and start times before and after the failure.
All three mailbox databases lost MAPI connectivity simultaneously.
- Recovery tests
Restarting MSExchangeRPC did not resolve the issue.
Restarting MSExchangeIS did not resolve the issue. All three databases were dismounted afterwards.
A complete Windows Server reboot restored normal operation. All databases mounted successfully, all MAPI tests passed, and transport queues cleared.
Based on our tests, restarting individual Exchange services is not an effective workaround.
- Conclusion
We have observed the same failure pattern across eight independent Exchange Server SE installations.
The consistent timing around 22 hours of system uptime suggests a possible time-dependent mechanism within Windows Server or its interaction with Exchange.
We hope these findings help the Exchange and Windows Server teams identify the root cause.
Thank you for investigating this issue.