GEOZ

Exchange Online 的 EWS 进入退役倒计时:2027 年 4 月前必须完成的迁移清单

2026/9/22
Exchange Online 的 EWS 进入退役倒计时:2027 年 4 月前必须完成的迁移清单

AIAI Summary (BLUF)

微软宣布 Exchange Online 中的 Exchange Web Services (EWS) 将分阶段停用,从 2026 年 10 月开始默认阻止,2027 年 4 月完全关闭。管理员需尽快评估 EWS 使用情况,创建 AppID 允许列表或迁移到 Microsoft Graph。

核心洞察

微软这次把 EWS 的退役时间表钉死了:2026 年 10 月开始分批禁用,2027 年 4 月 1 日彻底关停,而且明确说了没有例外。最狠的一点是,如果你的租户到 2026 年 10 月还保持默认的 Null 状态,系统会自动把它改成 False,等于直接掐断所有 EWS 调用。现在距离那个时间点还有一年多,但迁移 Graph 不是一两天的事,建议尽早动手排查。


Exchange Web Services(EWS)在 Exchange Online 里快要走到终点了。

这事其实早有预告。2018 年微软就说过 EWS 不再更新功能,2023 年又宣布 2026 年 10 月会在 Exchange Online 里禁用 EWS。现在具体方案出来了:分批禁用,管理员可以控制节奏,2026 年 10 月启动,2027 年彻底关停。

需要说清楚的是,这次调整只影响 Microsoft 365 和 Exchange Online 的所有环境。Exchange Server 上的 EWS 不受影响。

核心结论

  1. Exchange Online 的 EWS 将于 2026 年 10 月 1 日起分批禁用,2027 年 4 月 1 日彻底永久关停,且 2027 年 4 月之后没有任何延期例外。

  2. 2026 年 10 月 1 日起,EWSEnabled 仍为默认值 Null 的租户会被系统自动改为 False,届时该租户所有应用的 EWS 调用将被直接切断。

  3. 如需在 2026 年 10 月后继续使用 EWS,管理员必须在 2026 年 9 月底前将 EWSEnabled 设为 True 并配置 AppID Allow List,否则租户会被纳入默认禁用范围。

  4. 本次退役仅影响 Microsoft 365 和 Exchange Online,本地 Exchange Server 的 EWS 不受影响;混合场景下本地邮箱可继续使用 EWS,云端邮箱必须迁移至 Microsoft Graph

  5. 管理员自行创建的 AppID Allow List 不会被微软的全租户自动化流程修改,但若仅设置 EWSEnabled=True 而由微软自动填充列表,可能会纳入管理员不知情的应用。

为什么要退役 EWS

EWS 是快 20 年前的东西了。它当年确实好用,但放到今天,安全性、扩展性、可靠性都跟不上。

这几年微软做了不少准备。Microsoft Graph 已经覆盖了绝大多数 EWS 场景,功能对齐度接近完整。微软自己的应用要么已经迁走,要么正在迁。大量第三方厂商也完成了过渡,或者正在做。

退役 EWS 之后,微软能减少遗留接口的维护面积,简化平台行为,整体体验也会更统一。

禁用怎么分批做

微软会按租户逐个禁用,靠的是 EWSEnabled 这个属性。它有三个值:True、False 和 Null(目前的默认值)。另外还有一个新功能叫 AppID Allow List,管理员可以配置一份白名单,只有在名单上的应用才能访问 EWS。

2026 年 10 月 1 日(或之后不久),你租户里的 EWSEnabled 会按下面的规则变化:

EWSEnabled 值 2026 年 10 月之前 2026 年 10 月开始
True 没有 Allow List 时全部放行;有 Allow List 时只放行名单上的应用;Allow List 为空时全部放行 只放行 Allow List 上的应用。如果列表存在但为空,全部禁止。跨租户组织关系的 EWS 流量两种情况都放行
False 全部禁止 全部禁止
Null 全部放行 从 Null 变为 False。如果之后改回 Null,全部放行(忽略 Allow List)

2026 年 10 月 1 日还是 Null 的租户,随着部署推进,值会被改成 False。那一刻,租户里所有应用的 EWS 都会被切断。

想继续保持禁用状态?什么都不用做。

如果还需要用 EWS,有两条路:

  1. 把 EWSEnabled 设为 True,同时维护一份 AppID Allow List(可以通过 Baseline Security Mode 或 Exchange Online PowerShell 配置)。
  2. 把 EWSEnabled 改回 Null,这样 EWS 会不受限制地重新启用,直到最终弃用。这个操作只能用 Exchange Online PowerShell 完成。

另外,如果你在 2026 年 9 月底之前主动配好 AppID Allow List 并把 EWSEnabled 设为 True,你的租户不会被 10 月 1 日的自动变更波及。

为了帮大家过渡,微软会根据每个租户的实际使用情况,给还没创建 Allow List 的客户预填一份。如果到了 10 月你发现还需要 EWS,管理员可以在被禁用之后重新启用(把 EWSEnabled 设为 True)。但注意,这中间会有服务中断。

现在该做什么

这个阶段 EWS 还能用,但管理员应该开始准备了:

  • 去 Microsoft 365 管理中心看 EWS 使用报告,需要更多信息的话可以用微软发布的脚本。参考那篇《Notes From the Field: Finding and Remediating EWS App Usage Before Retirement》。
  • 可选操作:在 2026 年 9 月底之前填好 AppID Allow List,并把 EWSEnabled 设为 True。
  • 开始把应用往 Microsoft Graph 迁移。

第一轮禁用:2026 年 10 月 1 日起

没有在 2026 年 9 月明确选择保留 EWS(配 Allow List 加 EWSEnabled=True)的 Exchange Online 租户,EWS 会被默认禁用(EWSEnabled=False)。这时候:

  • 除非租户已经做了管理员操作,否则 EWS 调用会被拦截。
  • 如果关键工作流受影响,管理员可以临时启用 EWS(EWSEnabled=True)。

最终关停:2027 年 4 月 1 日

从 2027 年 4 月 1 日起,EWS 会彻底永久禁用:

  • 租户管理员将无法再控制 EWSEnabled。

时间线大致就是这样。

为了不让管理员措手不及,微软会每月通过 Message Center 发送租户专属的 EWS 使用摘要和提醒。

微软还可能会做临时性的“尖叫测试”,也就是短时间关掉 EWS 再打开,用来暴露隐藏的依赖。更多细节会在接下来几周公布。如果你的组织现在就把 EWSEnabled 设为 True,就不会受到尖叫测试影响。

现在就该评估环境、和应用负责人沟通、规划迁移到 Graph 的路线了。早动手,少踩坑。

常见问题

我们已经用 EWSApplicationAccessPolicy 配了 EWS 拦截,新的 AppID Allow List 和现有列表怎么配合?

新的 AppID Allow List 优先级更高。一个应用必须同时通过两道检查才能访问。

我们有一堆应用还在用 EWS,完全不知道迁移工作量有多大,怎么办?

先用微软发布的工具。全球版租户看这里,政府和主权云看这里。大多数应用其实只用了少数几个 EWS 操作,配合现代工具(包括 AI 辅助迁移),很多比想象中好迁。

Graph API 还有功能缺口,怎么从 EWS 迁过去?

微软在持续跟踪并公布剩余缺口。大多数基于 EWS 的工作负载现在就能迁。最新状态看这里:Deprecation of Exchange Web Services in Exchange Online | Microsoft Learn。这个页面会保持更新。

本地 Exchange 和混合场景怎么办?

本地 EWS 不退役。混合场景要看应用怎么访问数据。本地邮箱可以继续用 EWS,云端邮箱必须迁到 Graph。Autodiscover 会帮应用自动判断邮箱位置。但注意,只有 Exchange SE 支持对 Exchange Online 的 Graph 调用,所以混合客户必须用 Exchange SE 来托管本地邮箱。更多信息看这里。

我们到 2027 年 4 月肯定准备不好,怎么申请延期?

2027 年 4 月之后没有任何例外。

9 月设 EWSEnabled=True 但不创建自己的 AppID Allow List,行不行?

行,但建议管理员自己建,这样才能精确控制。微软会自动根据每个租户的使用情况填充 Allow List。如果你只设了 EWSEnabled=True 让微软帮你填,可能会把一些你都不知道的应用也加进去(只要它们有使用记录)。建议管理员自己创建 Allow List,明确控制 2026 年 10 月之后哪些 EWS 应用可以放行。详情看这里。

如果我们自己创建了 AppID Allow List,微软在全租户自动处理时会改它吗?

不会。你自己创建的 Allow List,自动化流程不会动。它会保持原样。

10 月之前任何时候设 EWSEnabled=True,微软到 10 月会尊重这个设置吗?

只要你的 EWSEnabled 在微软开始把 Null 改成 False 之前就已经是 True,微软会尊重你的设置。

如果微软给租户自动填充了列表,管理员之后能用 PowerShell 手动覆盖或追加吗?

可以。管理员能修改 AppID Allow List 的内容。

EWSAllowList 设置怎么办?要把应用 ID 加进去吗?

EWSAllowList 和 EWSBlockList 属于 EwsApplicationAccessPolicy 这个老功能,和 Exchange Online 的 EWS 弃用无关。EwsApplicationAccessPolicy 是更早的 EWS 应用访问控制功能,用的是 User Agent 而不是 AppID。修改它只是给客户端应用多加一道门,应用必须先通过上面说的 AppID Allow List,才能过这道门。所以如果你同时用 EWSAllowedAppIDs 和这个,App ID 和正确的 User Agent 都得各自通过检查,否则请求会因为 EWS 被拦截而拒绝。


本文更新记录:

  • 2026/9/9:做了一些小澄清,删掉了 8 月的说法,改成 9 月
  • 2026/9/4:修改 FAQ 和正文,反映微软为尚未创建 Allow List 的租户自动创建的时间点
  • 2026/9/1:新增 FAQ,说明 EWSAllowList 与 Exchange Online EWS 弃用无关,和 AppID Allow List(EWSAllowedAppIDs)是两回事
  • 2026/9/1:把文中的“Allow List”统一改成“AppID Allow List”,明确 EWSAllowedAppIDs 对应的是接收应用 ID 的 AppID Allow List
  • 2026/8/31:新增 FAQ,说明如果客户已经修改过 AppID Allow List,微软不会改动
  • 2026/8/24:澄清表格中指的是 AppID Allow List
  • 2026/8/19:同上
  • 2026/8/18:澄清表格中 10 月 EWSEnabled 为 Null 的状态
  • 2026/8/14:FAQ 新增两组问答
  • 2026/8/11:在表格中补充跨租户组织关系 EWS 流量的说明
  • 2026/7/21:澄清表格中 EWSEnabled=True 加已定义 Allow List 的情况(2026 年 10 月之前)
  • 2026/6/19:加入 Allow List 功能相关信息
  • 2026/3/17:添加《Notes From the Field》链接
  • 2026/2/9:补充说明,现在设 EWSEnabled=True 的组织不会被未来的尖叫测试影响

Exchange 团队

常见问题(FAQ)

EWS 2026年10月被禁用后,我还能临时重新启用吗?

可以。若关键工作流受影响,管理员可把 EWSEnabled 设为 True 临时启用,但会有服务中断。2027年4月1日彻底关停后,管理员将无法再控制该属性,没有任何例外。

怎么提前配置才能不被2026年10月的自动禁用影响?

在2026年9月底前,把 EWSEnabled 设为 True 并配好 AppID Allow List。这样租户不会被10月1日的自动变更波及。建议管理员自己创建 Allow List,以精确控制哪些应用可继续访问 EWS。

本地 Exchange 和混合场景下 EWS 也会被停用吗?

本地 EWS 不退役,本地邮箱可继续用。但云端邮箱必须迁到 Microsoft Graph。混合客户需用 Exchange SE 托管本地邮箱,因为只有它支持对 Exchange Online 的 Graph 调用。

晓婷深圳
本文由 晓婷 审核,最后更新于 2026年9月22日
联系编辑 →
← 返回文章列表
分享到:微博

版权与免责声明:本文仅用于信息分享与交流,不构成任何形式的法律、投资、医疗或其他专业建议,也不构成对任何结果的承诺或保证。

文中提及的商标、品牌、Logo、产品名称及相关图片/素材,其权利归各自合法权利人所有。本站内容可能基于公开资料整理,亦可能使用 AI 辅助生成或润色;我们尽力确保准确与合规,但不保证完整性、时效性与适用性,请读者自行甄别并以官方信息为准。

若本文内容或素材涉嫌侵权、隐私不当或存在错误,请相关权利人/当事人联系本站,我们将及时核实并采取删除、修正或下架等处理措施。也请勿在评论或联系信息中提交身份证号、手机号、住址等个人敏感信息。