Exchange API权限限制：域内账户预约跨账户创建与取消问题

看起来你已经把个人账户的日历预约流程跑通了，但切换到Exchange Impersonation处理域内其他账户时踩了权限/限流的坑——这在Office 365环境里太常见了，我来给你梳理几个排查和解决的方向：

1. 先确认Impersonation权限是否配置到位 #

首先得确保你的服务账户（用来做Impersonation的那个账户）拿到了正确的权限：

• 登录Microsoft 365管理中心，进入Exchange管理中心
• 转到权限>管理员角色，找到「应用程序Impersonation」角色组
• 把你的服务账户加进去，或者自定义一个包含ApplicationImpersonation权限的角色组再添加账户
• 注意：权限生效需要15-30分钟，刚配置完别急着测试，等一会儿再试

2. 检查认证方式和API权限范围 #

如果你用的是EWS Managed API，确保连接时正确设置了Impersonation身份，举个代码例子：

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2016);
service.Credentials = new WebCredentials("service-account@yourdomain.com", "your-service-password");
service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, "target-user@yourdomain.com");
service.Url = new Uri("https://outlook.office365.com/EWS/Exchange.asmx");

要是已经转到Graph API了，得在Azure AD里给应用程序开应用权限的Calendars.ReadWrite（不是委派权限），而且必须让管理员同意这个权限。

3. 排查是否触发了API限流 #

Office 365对Exchange/Graph API有请求频率限制，批量处理大量账户时很容易触发：

• 看错误响应，如果是429 Too Many Requests或者带Throttling字样的提示，那就是限流了
• 解决办法：加个指数退避重试机制，遇到限流错误时先等1秒，再等2秒，依此类推，最多重试5次，别死磕着发请求
• 另外优化下批量逻辑，能合并的请求尽量合并，减少单次请求的数量

4. 验证目标账户的邮箱状态别出问题 #

有时候目标账户可能被禁用了，或者邮箱有特殊设置（比如诉讼保留、存档），也会导致Impersonation失败：

• 去Microsoft 365管理中心查下目标账户的邮箱是否正常启用
• 确认账户没被设置成「仅内部访问」之类的限制策略

5. 查Audit日志找具体错误细节 #

要是前面的都排查完还是不行，就去Audit日志里挖细节：

• 进入Microsoft 365管理中心>合规性>Audit
• 搜索服务账户的操作记录，看失败请求的错误代码和描述，一般能精准定位到是权限问题还是配置问题

最后提个小细节：如果你的服务账户开了MFA，别用普通用户名密码认证了，换证书认证或者Client Credentials流（应用密码已经逐步淘汰了，不推荐用）。

内容的提问来源于stack exchange，提问作者Joe Schmoe