Exchange Server 2026年10月更新故障：看到 MapiExceptionMdbOffline，先别急着卸载补丁

2026年10月的 Windows Server 安全更新后，部分本地部署的 Exchange 环境出现了看似“邮件系统半停摆”的症状：OWA 无法登录，Outlook 邮件滞留在发件箱，邮件队列持续增长，DAG 成员之间的通信或仲裁也可能异常。重启有时只能暂时缓解，故障随后仍可能复现。

这类现象容易让运维团队先怀疑 Exchange 累积更新或数据库状态。但微软已说明，问题可能由 Windows Server 更新引起，安装当月 Exchange 安全更新并不是触发条件。排查时，应把操作系统补丁、RPC Endpoint Mapper 和 Exchange 服务间通信放在同一条链路上看，而不是只盯着 Exchange 更新记录。

Exchange Server 更新与 RPC Endpoint Mapper 风险示意图

影响范围：关注 Windows Server 更新，而不只看 Exchange 补丁

微软列出的相关 Windows Server 更新如下：

Windows Server 版本	2026年10月更新
Windows Server 2025	KB5126646
Windows Server 2022	KB5126655
Windows Server 2019	KB5126651
Windows Server 2016	KB5126868

微软指出，运行在受影响 Windows Server 版本上的 Exchange Server 2016、Exchange Server 2019 和 Exchange Server Subscription Edition 都可能受到影响。并非所有服务器都会出现故障，影响程度和出现速度与服务器负载等环境因素有关。因此，不能仅凭“更新已安装”就断定系统必然故障，也不应因暂时没有用户报障就假设没有风险。

判断时建议将补丁清单与实际症状、事件日志和邮件流状态交叉核验。尤其需要注意：微软指出，即使没有安装2026年10月的 Exchange 安全更新，也可能遇到这类由 Windows Server 侧引起的问题。

512 是什么：Endpoint Mapper 的默认并发上限

微软的 Windows 发布健康说明提到，2026年10月更新引入了 Endpoint Mapper 处理 Endpoint Lookup 调用时的默认限制。对于 Exchange 这类工作负载，默认的 512 个并发 Endpoint Lookup 调用可能不足。达到限制后，Exchange 相关组件之间的通信可能受影响，进而表现为邮箱访问、邮件传输或数据库可用性异常。

可以把 Endpoint Mapper 理解为 RPC 通信中的“定位服务”：客户端或服务需要通过它找到目标 RPC 端点。Exchange 的内部服务需要频繁协作；当相关调用达到限制时，应用表层呈现出来的就可能是数据库离线、OWA 登录失败或邮件无法正常发送，而非一个直观的“Windows 更新失败”提示。

微软列出的诊断线索包括：OWA 报错 MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142)，应用程序日志出现 Event ID 1006，以及邮件队列增长、Outbox 滞留或 DAG 成员通信异常。上述现象各自都可能有其他成因；应结合补丁安装时间、服务器负载和其他日志判断，避免把单一事件 ID 当成充分诊断结论。

微软给出的临时缓解方法

微软目前建议不要卸载2026年10月的 Windows Server 安全更新。官方提供的临时缓解方式是在受影响的 Exchange 服务器上，以管理员权限运行命令提示符，设置 Endpoint Mapper 的并发上下文上限，然后重启服务器：

reg add "HKLMSOFTWAREMicrosoftRpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

此后需要观察邮件流和 Exchange 健康状态。如果问题再次出现，微软建议提高该限制并继续评估。微软的公告将其描述为缓解措施，而非永久修复；具体变更前应按组织的生产变更流程进行评估、备份和审批。对使用 DAG 的环境，重启安排还需考虑数据库活动副本、冗余和故障切换能力，宜逐台维护并确认集群恢复后再处理下一台。

这不是建议所有 Exchange 环境不经评估、直接批量修改注册表。应先确认适用的 Windows Server 更新与症状是否吻合，记录当前配置和变更窗口，并安排维护后的验证。微软也说明了可在安装相关 Windows 更新之前预置该注册表值；该键值要在相关更新安装后才会被读取和使用。

运维排查顺序：先证据，再变更，最后观察

核对系统版本与补丁。 确认 Exchange 所运行的 Windows Server 版本，并核查是否安装了上表中的 KB。保留补丁时间、服务器角色和节点信息。
确认故障证据。 检查 OWA 是否出现指定错误，查找应用程序日志 Event ID 1006，并观察 Outlook 发件箱、传输队列、邮箱数据库访问和 DAG 状态。把时间点与负载、重启记录一并对照。
制定受控变更。 如环境与微软描述相符，评估注册表缓解及重启计划。高可用部署应先确认健康节点和数据库副本状态，避免多个节点同时重启造成额外中断。
验证并持续监控。 重启后检查 OWA、邮件收发、队列消退、数据库复制和 DAG 健康情况。若故障复现，记录现象和时间线，再按微软建议进一步提高限制或联系微软支持评估。

另一个迁移问题，不要与已确认故障混为一谈

原始公众号文章还提到 Exchange 混合部署迁移期间 MRSProxy 返回 401，并转述了重命名本地 Administrator 账户后迁移恢复的个案。现有可核验的微软公告针对的是 Windows Server 更新后的 Exchange 稳定性问题，并没有把“重命名本地 Administrator”列为此故障的官方缓解方法。

因此，这一做法不宜作为通用操作建议，更不能未经身份验证、影响评估和变更审批就在生产环境实施。若组织确有 MRSProxy 401，应作为独立问题收集迁移端点配置、认证日志和失败请求信息，并按微软混合部署支持路径排查，不要仅凭个案经验更改本地内置账户。