Exchange Online 中的 EWS 将于 2027 年 4 月 1 日终止：把您的集成迁移到 Microsoft Graph

昏暗房间里一台打开的笔记本电脑，屏幕上是电子邮件收件箱

微软已经开始在 Exchange Online 中关闭 Exchange Web Services（EWS）。第一批强制措施在本月执行，此后，从未动过 EWS 设置的租户会被逐一关闭，而从 2027 年 4 月 1 日起，所有 Microsoft 365 租户的 EWS 都将不复存在。微软已经明确表示，2027 年 4 月之后不会有任何例外。

如果贵公司开发的某个东西通过 EWS 访问 Microsoft 365 邮箱，它最迟会在那一天停止工作，也可能早得多。常见的有这些：把客户邮件归档到对应客户账户下的 CRM、归档或保留脚本、会议室预订屏幕、读取共享支持邮箱的工单系统、按团队统计邮件数量的报表任务。解决办法是基于 Microsoft Graph 重写，而 EWS 能做的事情里，有一部分在 Graph 中根本没有对应功能。

逐日发生什么

微软通过 EWSEnabled 设置按租户控制 EWS，它有三个值：Null（默认值）、True 和 False。现在它旁边多了第二个设置 EWSAllowedAppIDs：一份仍可使用 EWS 的应用程序 ID 列表。Microsoft Learn 上的当前页面给出了大纲：“2026 年 10 月：开始对所有组织全局禁用 EWS”，以及“2027 年 4 月：EWS 被完全禁用。”

细节见 Exchange 团队 10 月 1 日的文章 EWS Deprecation Is Here。对于全球商业云：

2026 年 10 月 2 日，太平洋时间当天结束时：微软记录所有将 EWSEnabled 设为 True 但没有允许列表的租户。
2026 年 10 月 8 日和 9 日：微软为这些租户创建允许列表，并填入过去 60 天内使用过 EWS 的应用程序 ID。
自 2026 年 10 月 10 日起：当 EWSEnabled 为 True 时，必须有允许列表。不在列表上的应用会被拒绝。
此后的第二阶段：仍为 Null 的租户，其 EWSEnabled 会被设为 False，这会对所有应用阻止 EWS。每个租户都会在消息中心收到 7 天的预先通知，微软会在此前不久根据 60 天的使用情况填好一份允许列表，这样管理员可以设为 True 重新启用 EWS。
2027 年 4 月 1 日：EWS 被“完全且永久地禁用”，租户管理员也将完全无法再更改 EWSEnabled。

微软其他云中的租户，会通过消息中心收到各自的时间表。

允许列表争取的是时间，不是解决方案

自动生成的列表基于 60 天的流量，微软自己 9 月 4 日的指南也提醒，它“可能遗漏不经常运行的应用程序”。季末导出或年末归档任务不会在列表上，下一次运行时就会失败。

允许列表的更改需要 24 小时才能生效，EWSEnabled 的更改大约需要一个小时。故障发生后再做任何修复，至少要花一天。

要查看您的租户处于什么状态，拥有 Exchange Online PowerShell 权限的管理员可以运行：

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

本文写给谁，谁可以不用往下读

本地部署的 Exchange Server 不受影响。 微软表示，这次停用“仅适用于 Microsoft 365 和 Exchange Online”，并且“Exchange Server 中的 EWS 没有任何变化”。如果您所有的邮箱都在自己的服务器上，读到这里就可以了。

混合部署需要仔细看。 本地邮箱可以继续使用 EWS；云端邮箱必须迁移到 Graph。微软 9 月 30 日关于混合部署的文章介绍了需要立即采取行动的两种情况，其中包括存档位于 Exchange Online 的本地邮箱，目前的建议是保持 EWS 启用，并把混合应用程序加入允许列表。

套装软件是厂商的事。 如果调用 EWS 的是一款商业产品，交付 Graph 版本是厂商的工作，您要做的是从厂商那里拿到一个日期并安装更新。微软自己的客户端也一样：有些仍然出现在使用情况报告中，在更新之前需要放在允许列表上。

自研代码是您的事。 脚本、内部服务、定制的开源工具，以及某家外包公司多年前做的集成，上游都没有人来修。工作量就在这里。说一个规模上的参考：exchangelib 是一个通过 EWS 与 Exchange 通信的 Python 库，过去一个月在 PyPI 上被下载了 1174625 次。其中一部分是本地部署的使用，但这能让人感受到有多少代码是直接通过 EWS 通信的。

第一步：找出所有使用 EWS 的东西

从 Microsoft 365 管理中心的 EWS 使用情况报告开始（报表、使用情况、Exchange，然后是 EWS 使用情况选项卡）。对于每个应用程序，它列出 Microsoft Entra 应用程序 ID、该应用调用过的每一个 SOAP 操作、调用量和最后活动日期。您可以回溯 7 天、30 天或 90 天，并导出为 CSV。

关于这份报告，有三点需要知道：

数据按周汇总，可能需要长达 10 天才会出现。
应用程序 ID 不等于负责人。把每个 ID 与 Microsoft Entra 中的企业应用程序对应起来，再找到运行它的人或团队。可以预料会有几个 ID 没人认得。
SOAP 操作这一列告诉您每项工作有多大。只调用 FindItem 和 GetItem 的应用是个小活。调用 SyncFolderItems、Subscribe 和 ExportItems 的应用是一个项目。

即使是 90 天也会漏掉年度任务，所以还要从另一头检查：计划任务和 cron 条目，以及在代码仓库中搜索 EWS 端点（Exchange.asmx）、适用于 .NET 的 EWS Managed API 和 exchangelib。微软的停用说明页面还链接了一个针对 .NET 代码的 EWS 分析器（它会在 Visual Studio 和 VS Code 中标出 EWS 调用并给出对应的 Graph 写法），以及一篇关于 AI 辅助重构的教程。

第二步：决定每个集成何去何从

清单上的每个应用程序，都会得到以下四种答案之一：

停用。 有些集成之所以还存在，只是因为没人把它关掉。
更新。 厂商产品由厂商升级。现在就把日期定下来。
基于 Microsoft Graph 重写。 这是自研代码的默认选项。
重新设计。 适用于任何依赖 Graph 永远不会提供的功能的东西（见下文）。

微软还把 Power Platform 列为重新实现工作流的一种方式。对于一个把附件转存到文件夹的脚本，这可能是最便宜的答案。

用 Graph 重写实际上涉及什么

大多数 EWS 操作在 Graph 中都有直接对应的操作，微软维护着一份 EWS 到 Graph 的映射表。映射是容易的部分。更难的部分，是映射表里看不到的那些。

权限变窄了，这是好事

一个在没有登录用户的情况下使用 EWS 的应用，持有的是 EWS 应用程序权限，微软将其描述为“对所有邮箱的完全访问权限”。Graph 把它拆分成了多个独立的权限：Mail.Read、Mail.ReadBasic、Mail.Send、Calendars.ReadWrite、MailboxSettings.Read 等等。

您还可以限制一个应用能访问哪些邮箱。Exchange Online 中的应用程序 RBAC 针对一个管理范围或一个管理单元分配权限，它取代了旧的应用程序访问策略。一块会议室预订屏幕可以只读取十二个会议室邮箱的日历，别的什么都读不到。有一个陷阱：用这种方式授予的权限，会叠加在 Microsoft Entra 中任何租户范围的授权之上，所以如果 Mail.Read 在那里仍然处于已同意状态，您的范围限制就什么也限制不了。把 Entra 中的授权删掉。

应用身份验证尽可能使用证书而不是客户端密码，并且不要把凭据放在脚本和代码仓库里。

同步和通知要重建，而不是翻译

对于任何保存邮箱数据本地副本的东西，这通常是最大的变化。

同步。 SyncFolderItems 对应 Graph 的邮件增量查询，SyncFolderHierarchy 对应邮件文件夹增量查询。邮件增量查询一次只处理一个文件夹，所以完整同步一个邮箱，意味着要跟踪文件夹树，并为每个文件夹分别保存一个增量链接。筛选能力有限（只能按接收日期），而且结果中会包含删除、移出文件夹和已读状态变更，即使它们不符合您的筛选条件。

通知。 EWS 的流式订阅和推送订阅变成了 Graph 更改通知，投递到您运行的 webhook，或投递到 Azure Event Hubs 或 Event Grid。webhook 必须能从微软一侧访问到，对于一个过去在防火墙后保持一条连接的脚本来说，这是一次架构变更。邮件、日历和联系人的订阅最长持续 10080 分钟（不到七天），如果通知中携带数据则为 1440 分钟，所以必须有东西负责续订。每个邮箱在所有应用中最多允许 1000 个活跃订阅。

经得起考验的模式是：把通知当作一个提示，运行增量查询来看看什么变了，同时还要定时运行增量查询，以捕获因漏掉通知而丢失的任何变化。

数据、ID 和吞吐量

已保存的 ID。 如果您的 CRM 或工单系统保存了 EWS 项目 ID，用来把邮件关联到记录，这些关联就需要转换。Graph 正好为此提供了一个 translateExchangeIds 函数。把这次转换作为一个单独的迁移步骤来规划。
查找。 ResolveNames 对应 People API，GetUserAvailability 对应 getSchedule，外出设置对应邮箱设置。它们是相近的对应，而不是完全相同的。
限制。 Graph 对每一对应用和邮箱的限制是：每 10 分钟 10000 次请求、四个并发请求，以及每 5 分钟 150 MB 的上传量。一个过去针对单个邮箱开几十个并行 EWS 线程的批量任务，必须围绕这些数字重新设计。

缺口，以及永远不会到来的功能

微软发布了一份路线图，列出 Graph 中仍然缺失的 EWS 功能。其中包括存档邮箱、公用文件夹邮箱和组邮箱的完整保真导入和导出、对就地存档的访问、通过 Exchange Admin API 管理文件夹权限，以及从 MIME 创建非草稿邮件。大多数功能的目标时间是 2026 年第四季度。有几项原定在第三季度交付，而第三季度现在已经结束，所以在围绕它们做设计之前，先确认哪些已经真正发布。微软自己的提醒是：如果某个功能不在路线图上，就“不要指望”在 EWS 关闭之前会有对应的 Graph 功能。

有三项功能已经确认永远不会进入 Graph：

通用的公用文件夹访问（文件夹和项目的创建、读取、更新、删除）。
通用的 Microsoft 365 组邮箱访问。Graph 改为覆盖组对话、会话线程和帖子。
发现邮箱访问。微软建议改用 Purview 电子数据展示（eDiscovery）。

如果某个工具依赖其中任何一项，光移植代码是不够的：数据或工作流必须先迁移到别处，而这比重写花的时间更长。

六个月计划

从今天到 2027 年 4 月 1 日，还有不到六个月。比较现实的顺序是：

2026 年 10 月：弄清现状。 检查 EWSEnabled 和允许列表。导出 90 天的使用情况报告。审查微软填好的列表，删掉不应该在上面的，并加上您所知道的那些不常运行的任务。如果您的租户仍然是 Null，可以考虑自己设置列表并设为 True，而不是等微软把它切换为 False，再去发现什么坏了。

2026 年 11 月：分类处理。 为每个应用程序 ID 指定一个负责人和一个答案（停用、更新、重写、重新设计）。扫描代码。标出任何涉及公用文件夹、组邮箱或发现邮箱的东西，现在就开始重新设计。创建带有限定范围权限的 Graph 应用注册。

2026 年 12 月至 2027 年 1 月：开发。 从业务部门最先会想念的那个集成开始。同步和通知的底层机制只建一次，然后复用。转换已保存的 ID。

2027 年 2 月：新旧并行运行。 趁 EWS 还能用，让新旧两个版本针对相同的邮箱运行，并比较输出。每验收通过一个，就把它的 ID 从允许列表中移除。这本身也是测试：等 24 小时，确认没有别的东西停止工作。

2027 年 3 月：自己关掉 EWS。 在 4 月 1 日之前留足余量，把 EWSEnabled 设为 False。任何您漏掉的东西，都会在您还能重新启用 EWS 的时候出问题。4 月 1 日之后，这个选项就没有了。在此之前，也要有意识地把季度和年度任务测试运行一遍：一个在第一季度结账时运行的任务，会在 EWS 消失之后才第一次运行。

从哪里获得帮助

最难的情况，是原开发者已经离开的集成。我们的遗留系统维护服务正是为此而设：我们阅读现有代码，基于 Microsoft Graph 重写其中的 EWS 部分（权限、同步、通知、ID 迁移），并让新旧版本并行运行，直到数字对上为止。如果您需要的是在您自己团队内部工作的工程师，请参阅我们的人员增补服务。

如果您的使用情况报告里满是没人认得的应用程序 ID，请写信到 office@c9group.dev。