0

如果我执行以下操作

var autodiscoverService = new AutodiscoverService{
    // Timeout = 100,  // Appears to have no impact
    EnableScpLookup = false,
    RedirectionUrlValidationCallback =
        delegate { return true; },
    PreAuthenticate = true,
    TraceEnabled = true,
    TraceFlags = TraceFlags.All,
    TraceListener = listener,
    Credentials =
        new WebCredentials("billg@microsoft.com", "anything", null)
};

我得到的第一条跟踪消息是：

<Trace Tag="AutodiscoverConfiguration" Tid="19" Time="2012-07-06 16:05:09Z">
   Determining which endpoints are enabled for host microsoft.com
</Trace>

注意时间 (:09)。下一个事件大约是 40 秒后：

<Trace Tag="AutodiscoverConfiguration" Tid="19" Time="2012-07-06 16:05:51Z">
   Determining which endpoints are enabled for host autodiscover.microsoft.com
</Trace>

此后很快（如预期的那样，身份验证失败）。

如果我在https://www.testexchangeconnectivity.com/上使用 Exchange 连接测试仪，即使我使用了无效的身份验证信息，我也几乎可以立即得到答案。

我没有要测试的有效 MS 帐户，但我请一个人对其进行测试，即使使用有效的用户名/密码，他们也看到相同的 40 秒超时。

我发誓就在几周前，我对此进行了测试，并没有发现 Microsoft 的自动发现设置有任何问题；我怀疑最近发生了一些变化。

虽然这个问题以 microsoft.com 为例，但我担心可能还有其他配置不当的 Exchange 设置会产生同样的延迟，这对我的用户来说会很糟糕。

我试过设置autodiscoverService.Timeout = 100，但没有帮助。

有什么方法可以更精细地控制 EWS 的自动发现功能？

我还能如何解决/解决这个问题？

4

1 回答 1

0

我认为问题在于域“microsoft.com”没有在预期的庄园中实现自动发现。结果，自动发现服务会尝试所有可能的端点，最终失败。

我使用我的电子邮件地址/凭据尝试了您的代码，并根据 MS 在AutodiscoverService.GetUserSettings Method提供的示例发出了 GetUserSettings 请求。

我同时使用了 onprem Exchange 和 Office 365 进行测试，onprem Exchange 在大约 2 秒内完成，Office 365 从开始到完成需要 7 秒。

然后我更改了我的代码以使用您使用的电子邮件地址/凭据，我看到了相同的 40 超时。

您是否尝试过针对 microsoft.com 之外的另一个域进行测试？

于 2012-07-08T04:55:31.373 回答