Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We host email for 200 different companies, each of them has an AD forest and we have no forest trust, or VPN to those other AD Domains. The forest name of each of the 200 companies matches the name of the email address. We ask each company to use a SRV record to redirect autodiscover queries to

The Exchange Domain is located at and has a DNS A record for autodiscover.

When a user runs Autodiscover we notice the first URL queried is Since is the name of their AD forest, they are querying a random AD Domain Controller for this HTTPS query.

Due to how their AD is configured with firewalls, slow connections, etc, the random domain controller that comes up during this first HTTPS query causes Autodiscover to hang, and I think it is preventing Outlook 2007 from updating properly.

I've tested this theory by editing the hosts file and pointing to and adding an IPv6 entry to ::1. The result is that Autodiscover ran quickly, with no errors.


What is the best way to address Autodiscover's initial timeout when querying for a ""?

share|improve this question
up vote 1 down vote accepted

What does "" point to right now? If there's an actual record for in DNS then it will try and find that autodiscover.xml file there...usually fail, and then fall back to the normal You can test this online with MS' activesync test site. This is typically found in companies that have the same internal and external DNS namespace.

If there isn't a record to point to it usually fails pretty quick and moves on. If there is one, that could be what is taking so long...waiting for it to timeout.

You should see here as well:

The SRV record is typically near the end of the query list.

share|improve this answer points to every DC in the forest. I can't edit this without breaking DNS or Kerberos needed for workstation authentication. This is a byproduct of setting up an AD forest. This is split DNS and the connectivity test can't see the DNS behind the firewall. – LamonteCristo Nov 16 '12 at 20:01
does the external DNS have a record for It shouldn't in this instance or if it does it needs to make sure it doesn't resolve to a host with a certificate or you'll get cert errors in Outlook while it tries autodiscover. Internally, I understand it pointing to the DC's. But internally it should fail quickly when it tries to get the autodiscover.xml from a DC. – TheCleaner Nov 16 '12 at 20:13
That is exactly my point; in the internal scenario is the problem. I suspect it's due to Proxies, firewalls, etc. Autodiscover.xml always fails >30 sec after connecting to a DC. Since the machines I'm working with are desktops external DNS isn't used and shouldn't matter. – LamonteCristo Nov 16 '12 at 20:17
Understood, but it should continue on to at that point. The problem here seems to be that Exchange isn't hosted locally and the internal and external domain is the same (against best practices). You can look at changing the way they query here: if that helps. – TheCleaner Nov 16 '12 at 20:34
That KB should do the trick! TY – LamonteCristo Nov 16 '12 at 21:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.