我们为200家不同的公司提供电子邮件，每个公司都有一个AD森林，我们没有森林信任，或者对那些其他AD域的VPN。 200家公司中的每一家的森林名称都与电子邮件地址的名称相匹配。 我们要求每个公司使用SRVlogging将自动发现查询redirect到https://autodiscover.hoster.com/autodiscover/autodiscover.xml
Exchange域位于http://email.hoster.com并具有自动发现的DNS Alogging。
当用户运行自动发现时，我们注意到查询到的第一个URL是https://company.com/autodiscover/autodiscover.xml 。 由于company.com是他们的AD森林的名称，他们正在查询一个随机AD域控制器为此HTTPS查询。
由于如何configuration他们的AD防火墙，连接速度慢等，在这第一次HTTPS查询期间出现的随机域控制器导致自动发现挂起，我认为这是防止Outlook 2007正常更新。
我已经通过编辑主机文件并将company.com指向Google.com并将IPv6条目添加到::1来testing了这一理论。 结果是Autodiscover运行迅速，没有错误。
题
在查询“company.com”时，解决Autodiscover初始超时的最佳方式是什么？
“company.com”现在指的是什么？ 如果在DNS中有company.com的实际logging，那么它会尝试在那里findautodiscover.xml文件…通常会失败，然后回退到正常的autodiscover.domain.com。 你可以用MS的activesynctesting网站在线testing。 这通常在具有相同内部和外部DNS名称空间的公司中find。
如果没有一个company.comlogging指向它通常失败很快，并继续前进。 如果有的话，那可能是这么长时间…等待它超时。
您也应该在这里看到： http : //support.microsoft.com/kb/2212902
SRVlogging通常接近查询列表的末尾。