0

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 https://autodiscover.hoster.com/autodiscover/autodiscover.xml

The Exchange Domain is located at http://email.hoster.com and has a DNS A record for autodiscover.

When a user runs Autodiscover we notice the first URL queried is https://company.com/autodiscover/autodiscover.xml. Since company.com 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 company.com to Google.com and adding an IPv6 entry to ::1. The result is that Autodiscover ran quickly, with no errors.

Question

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

makerofthings7
  • 8,821
  • 28
  • 115
  • 196

1 Answers1

1

What does "company.com" point to right now? If there's an actual record for company.com in DNS then it will try and find that autodiscover.xml file there...usually fail, and then fall back to the normal autodiscover.domain.com. 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 company.com 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: http://support.microsoft.com/kb/2212902

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

TheCleaner
  • 32,352
  • 26
  • 126
  • 188
  • company.com 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. – makerofthings7 Nov 16 '12 at 20:01
  • does the external DNS have a record for domain.com? 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. – makerofthings7 Nov 16 '12 at 20:17
  • Understood, but it should continue on to autodiscover.domain.com 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: http://support.microsoft.com/kb/2612922 if that helps. – TheCleaner Nov 16 '12 at 20:34
  • That KB should do the trick! TY – makerofthings7 Nov 16 '12 at 21:11