在使用 Office365 日历文件夹的请求订阅时，我在 SendNotification 请求中收到大量 ErrorReadEventsFailed 消息。此错误本质上意味着无法再找到订阅，并且服务器不应再期待新的通知。
检查Microsoft's recommended error handling ，解决方案是使用自动发现重新发现ExternalEwsUrl或EwsPartnerUrl，并创建新的订阅。
对于 Office365，自动发现服务似乎几乎不可能与 OAuth2 服务帐户组合使用，因此我一直使用 https://outlook.office365.com/EWS/Exchange.asmx 作为主要帐户EWS 端点。
但是，当我尝试为特定日历文件夹创建新订阅时，我不断收到通用 500 ErrorNoRespondingCASInDestinationSite 错误:
Exchange Web Services are not currently available for this request because none of the Client Access Servers in the destination site could process the request.
奇怪的是这只在收到初始ErrorReadEventsFailed错误后立即发生。如果我在 30 秒内重试，请求就会顺利通过。
经过一些研究后，似乎大多数用户发现确保为服务帐户希望模拟的用户正确设置 X-AnchorMailbox header 很有帮助。我仔细检查了这个 header ，它确实是随着重新订阅的请求一起发送的。
这个问题可以通过指数退避解决方案来解决，或者只需重试 X 次直到请求通过。在我看来，当订阅“丢失”时，O365服务需要时间来更改Exchange服务器的DNS(这是我唯一能想到的)。
任何帮助将不胜感激!
最佳答案
鉴于文档:https://msdn.microsoft.com/en-us/library/office/dn458788(v=exchg.150).aspx
当订阅丢失或无法再访问时，最好创建一个新订阅，并且不要在新订阅中包含旧水印。使用旧水印重新订阅会导致对事件进行线性扫描，成本高昂。
相反，创建一个新的订阅并比较文件夹属性以查找丢失的订阅和新订阅之间发生的内容更改。我们建议您检查的扩展文件夹属性是 PR_LOCAL_COMMIT_TIME_MAX (0x670a0040) 和 PR_DELETED_COUNT_TOTAL (0x670b0003)。
您可以通过创建扩展属性定义来完成此操作。 我想这可能对你有帮助!!
关于exchange-server - EWS API - 重新创建通知订阅时出错，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31527083/