我们为 200 家不同的公司托管电子邮件，每家公司都有一个 AD 林，我们没有林信任，也没有 VPN 连接到其他 AD 域。这 200 家公司中每家公司的林名称都与电子邮件地址的名称相匹配。我们要求每家公司使用 SRV 记录将自动发现查询重定向到https://autodiscover.hoster.com/autodiscover/autodiscover.xml
Exchange 域位于http://email.hoster.com并具有自动发现的 DNSA记录。
当用户运行自动发现时，我们注意到查询的第一个 URL 是https://company.com/autodiscover/autodiscover.xml。由于是company.com其 AD 林的名称，因此他们正在向随机 AD 域控制器查询此 HTTPS 查询。
由于他们的 AD 配置了防火墙、慢速连接等，在第一次 HTTPS 查询期间出现的随机域控制器导致自动发现挂起，我认为这阻止了 Outlook 2007 正确更新。
我通过编辑 hosts 文件并指向company.comGoogle.com 并向 中添加 IPv6 条目来测试此理论::1。结果是 Autodiscover 运行迅速，没有任何错误。
问题
查询“company.com”时解决自动发现初始超时的最佳方法是什么？
答案1
“company.com”现在指向什么？如果 DNS 中确实有 company.com 的记录，那么它会尝试在那里找到 autodiscover.xml 文件……通常会失败，然后返回到正常的 autodiscover.domain.com。您可以使用 MS 的 activesync 测试站点在线测试这一点。这通常在拥有相同内部和外部 DNS 命名空间的公司中发现。
如果没有 company.com 记录指向，它通常会很快失败并继续。如果有，那可能是花费这么长时间的原因...等待它超时。
您还应该在这里看到： http://support.microsoft.com/kb/2212902
SRV 记录通常位于查询列表的末尾。