3月11日，微软给Exchange Online加了个"虚拟账户"功能。26天后，Outlook移动端和Mac用户还在间歇性翻车。
这个被标记为EX1256020的故障，4月1日曾被微软宣布"已解决"。但用户投诉没停，微软只好重新打开案子，换了新编号EX1268771继续查。
一个"已解决"的故障，为什么复活了
微软上周首次承认问题时，把锅扣在"新引入的虚拟账户"上。4月1日 flagged 为 resolved 后，受影响的企业租户反馈：问题照旧。
微软工程师现在的说法是：「我们收到受影响租户的反馈，EX1256020中描述的故障场景仍在持续。我们正在重启Notification Broker服务的受影响部分，同时继续分析根因。」
Notification Broker是Exchange Online里负责推送通知的组件。你可以把它理解为快递分拣中心——邮件到了，它负责喊Outlook"你的货到了"。这个环节卡壳，用户端就表现为：邮箱刷不出来，或者显示空白。
但微软没解释为什么4月1日的"修复"没生效。是根因判断错了？还是修复方案只覆盖了部分场景？官方口径里只有"继续分析"四个字。
过去三个月，Exchange Online的故障清单
这次故障不是孤立事件。微软的云端邮箱服务正在经历一波密集的稳定性考验：
本月初，Exchange Online曾出现更严重的 outage：Outlook网页版、桌面客户端、Exchange ActiveSync 等协议全部沦陷，用户连邮箱和日历都打不开。同一天，Office.com和Microsoft 365 Copilot的网页登录也挂了，波及Copilot桌面应用、Teams里的Copilot、以及Office应用内的Copilot。
再往前数：1月份，IMAP4协议间歇性阻断；去年11月，经典版Outlook桌面客户端连接故障。
微软把这些都标记为"incident"——这是它内部对"关键服务故障、有明显用户影响"的定级。换句话说，过去五个月，Exchange Online的关键故障至少发生了五起。
企业邮箱的稳定性承诺，正在变成一张需要不断修补的网。
为什么移动端和Mac成了重灾区
这次故障有个值得注意的特征：集中在Outlook移动应用和"新版Outlook for Mac"。
这两个客户端有个共同点——都依赖微软的"现代认证"架构和通知推送机制。经典版Outlook for Windows用的是另一套同步协议，所以受影响较小。
这暴露了一个产品架构问题：微软在推"新Outlook"的过程中，移动端和Mac端可能共享了某些服务端组件。Notification Broker的故障，像一把精准的手术刀，切中了这套新架构的软肋。
但微软至今没有披露：哪些区域的用户受影响？规模有多大？三周多的间歇性故障，到底影响了多少企业租户？
这些信息缺失，让企业IT管理员很难做决策。是等微软修？还是临时切换客户端？或者干脆迁回本地Exchange？
修复进展：重启服务+继续分析
周四晚的最新更新里，Exchange Online团队的说法是：仍在调查根因，同时准备"额外措施"防止复发。
目前的应急手段是重启Notification Broker服务——这相当于把卡住的快递分拣中心断电重启。能缓解症状，但不保证根治。
微软没有给出修复时间表。对于依赖Exchange Online的企业来说，这意味着未来几周仍要准备应对间歇性邮箱访问中断。
一个细节：这次故障的追踪编号从EX1256020换成了EX1268771。在微软服务健康仪表盘的体系里，换编号通常意味着"原问题未解决，按新案件处理"。26天过去，这个虚拟账户引发的连锁反应，还在等一个真正的终点。
你的企业邮箱最近出现过"连不上"的情况吗？是Outlook移动端、Mac端，还是全平台中招？
热门跟贴