【问题标题】:Can EWS Impersonation be used with Office365 Email Account service provider?EWS 模拟可以与 Office365 电子邮件帐户服务提供商一起使用吗?
【发布时间】:2018-04-26 19:34:54
【问题描述】:

我们正在构建一个最初需要大量消息下载的服务。我们正在尝试找到所有技巧来增加我们的消息下载吞吐量。

看到这个帖子

推荐标准:行之有效的工业级解决方法 好是在循环队列中使用一个帐户池来执行 使用 EWS 模拟的 EWS 呼叫。通过这样做,服务器将看到 负载较小的同一帐户。这是通常的推荐 方法,需要认真研究——尤其是当 上面的其他建议不起作用。它是最具可扩展性的,并且将 处理从小到大的负载。小公司一路走好 直到最大的公司都使用这种方法。

https://blogs.msdn.microsoft.com/webdav_101/2018/03/20/ews-serverbusyexception-the-server-is-too-busy-for-you/

我们认为我们会要求我们要求每个用户授予我们代表他们执行 EWS 模拟的能力,这不属于标准权限包的一部分。这是真的?

除非是单击,否则从业务角度来看,它基本上是行不通的。

如果有,还有其他提高消息下载性能的建议吗?

【问题讨论】:

    标签: office365 exchangewebservices ews-managed-api


    【解决方案1】:

    使用交换管理外壳,您可以配置和授予ApplicationImpersonation 角色而无需提示用户。

    当您开始看到 ServerBusyExceptions 时,大容量应用程序将需要使用多个模拟帐户或调整 throttling policies

    在性能方面 - 这取决于。只提取您需要的属性。如果您要提取所有邮件并且时间不是问题 - 请考虑push\pull notifications。如果您需要尽可能接近实时,请查看streaming notifications

    【讨论】:

    • 澄清一下。我们将成为服务提供商。因此,我们将无法保持 PowerShell 窗口打开并观察人们创建帐户。帐户创建将是 24/7,用户将不受我们控制。话虽如此,我们可以从 C# 代码中授予 ApplicationImpersonation 吗?如果是这样,那将有所帮助。请注意,我们确实已经看到了 ServerBusyExceptions 并且已经对建议的时间量进行了重试和回退。此外,我们只是在阻止消息下载期间遇到问题。
    • 作为服务提供商,您是否在目标用户的 azure 域中拥有用作模拟帐户的服务帐户?如果是这样,那么只需向该帐户授予一次 ApplicationImpersonation 将适用于新帐户,因为它们已添加到域中。
    • 由于这些人与我们没有任何关系,因此我们在用户 azure 域中没有 Azure 帐户。
    • 这整个技术似乎都适合在公司内部工作。 ?
    • 模拟模型适用于本地安装和 o365 安装 - 后者似乎为在用户组织之外运营的服务提供商提供了一些障碍。鉴于电子邮件的敏感性,这是可以理解的。也许您可以尝试包装 powershell 以模拟并将其粘贴在单个按钮后面。 blogs.msdn.microsoft.com/kebab/2014/04/28/…
    猜你喜欢
    • 1970-01-01
    • 2019-03-30
    • 2016-01-18
    • 2011-12-04
    • 1970-01-01
    • 1970-01-01
    • 2018-07-28
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多