在本地 Exchange 邮箱上执行操作的推荐方法答案

【问题标题】：Recommended way to perform operations on on-premises Exchange mail box在本地 Exchange 邮箱上执行操作的推荐方法
【发布时间】：2019-05-03 22:01:23
【问题描述】：

我的问题与推荐的方式（未来）与本地 Exchange 邮箱通信并以编程方式从外部应用程序对其执行操作有关？

基于以下几篇文章，EWS API 和相应的 SDK 看起来很有前景：

https://blogs.msdn.microsoft.com/webdav_101/2018/06/19/about-using-ews-and-powershell/

但基于此，将来是否会继续支持它有点混乱：

https://blogs.technet.microsoft.com/exchange/2018/07/03/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/

虽然上面只讨论了 o365，但 EWS 将不再被投资这一事实引发了一个问题，即本地交换的新应用程序是否应该继续使用它。
PowerShell、远程 PowerShell 等也可能有效，但它似乎不太适合在外部应用程序中使用/集成，更适合自动化操作。

有人可以介绍一下与本地 Exchange 合作的推荐方式吗？

【问题讨论】：

标签： powershell microsoft-graph-api exchangewebservices

【解决方案1】：

试试 Microsoft GraphAPI。详情https://developer.microsoft.com/en-us/graph/graph-explorer在这里。登录。试试https://graph.microsoft.com/v1.0/me/messages 示例。登录后点击左侧栏的“显示更多示例”查看更多示例。

它是方式（tm）吗？我不知道，但很酷。我有一些我正在使用的示例代码，没有什么可以分享的格式，但看起来 API 涵盖了很多领域。一些仅限客户端的规则看起来需要一些工作才能公开，也许它们会在以后的版本中得到加强。

【讨论】：

感谢您的回复。我的问题更多来自“仅限本地”的角度。 Graph API 不是更多的混合设置解决方案吗？

【解决方案2】：

取决于您尝试编写的应用程序的类型，EWS 将出现在 Exchange 2019 中，因此与 2013 年、16 年和 19 年的 OnPrem 对话也能正常工作。与新的 REST API 相比，使用 EWS 有优点和缺点，但它是特定于应用程序的并且变化很快。但同样，这完全取决于您尝试编写的应用程序类型以及您需要支持的 Exchange 版本。并且通常不会将出现在新 OnPrem 版本中的新功能向后移植到旧版本中。因此，适用于 Office365 和 Exchange 2019 的一个很棒的新功能可能在 2016 年不起作用，您可能需要使用一些较旧的旧 API 来实现相同的功能。如果您是 ISV 并且需要对 OnPrem Exchange 版本的广泛覆盖支持，那么截至今天的底线是需要同时使用 EWS 和 REST。如果您只是为一个将在未来迁移到 2019 年的组织创建应用程序，那么您可能只使用 REST。

【讨论】：

谢谢格伦。我的问题是反过来的。基本上，1. 适用于 2013 年的 EWS Api 将继续适用于 2019 年。 2. 2019 年的新功能将在 EWS 中得到支持，即使仅适用于该版本。对我来说 1 似乎很可能，但鉴于 EWS 将不再得到增强 2 似乎不太可能。另外，当您提到新的 REST API 时，您指的是什么 API？我读到的关于新 API 的大部分内容都只讨论混合设置或 o365。
1.是的，EWS 将在 2019 年得到全面支持，但是您进行身份验证的方式可能会发生变化。随着基本身份验证中的当前问题，这将成为公司越来越多的症结所在。 2. Mail 中的新功能通常是客户端驱动的，但这实际上取决于您的应用程序是什么以及它的作用，对邮箱的底层访问在 2019 年的 EWS 中保持不变，实际上比您目前在 Graph 或 REST 中可以做的更好（例如，图表不提供访问隐藏项目和文件夹等的能力）。 REST API 是 Graph 和 Outlook 端点，但需要混合等。
谢谢格伦。您的回复非常有用-不幸的是，我的赞成票不算数:)。我希望 MS 会在某处添加关于本地 EWS API 方向的官方说明 - 或者可能存在一个但我没有找到它。大多数文档似乎只谈论云\混合。