Question

如果我执行以下操作

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>

此后很快（正如预期的那样，auth失败）。

如果我在https://www.testexchangeconnectivity.com/使用Exchange连接测试程序，即使我使用无效的身份验证信息，我也会立即得到答案。

我没有有效的MS帐户可供测试，但我要求一个人测试它，即使使用有效的用户名/ pw，他们也会看到相同的40秒超时。

几周前我发誓我测试了这个，并没有看到微软的自动发现设置有任何问题;我怀疑最近发生了一些变化。

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

我已尝试设置autodiscoverService.Timeout = 100但这没有帮助。

有没有办法对EWS的自动发现功能进行更细粒度的控制？

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

Answer 1

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

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

我同时使用onprem Exchange和Office 365进行测试，并且onprem Exchange在大约2秒内完成，而Office 365则需要7秒才能完成。

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

您是否尝试过针对microsoft.com旁边的其他域进行测试？

EWS自动发现不可接受的超时

1 个答案: