Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

Env: 4 Exch 2010 Sp1 hosting mode MBXs, 2 CASHUBs, HLB infront.

This setup runs multiple domains for several different customers. The HLB can be reached at and is where all the clients connect for anything (as this loadbalances the CAS-servers). When we run autodiscover tests against our own domain which differs form the hosting domain, the WEBSERVER of our primary domain replies with it's SSL certificate. This gives a faulty autodiscover, and warns the users that something is wrong.

I'm running tests with, and it connects to the HLB as it should on Why would the webserver of reply instead of the exchange/hlb which got the correct certificate? got an _autodiscover SRV record to throw the requests to (This seem to partially work, as we get connected to the correct server?)

If anyone could explain this behaviour, it would be much appreciated!

(No, there is no A or CNAME for, just the SRV)

The same thing happens for others on the same platform, and all of them got an SRV record that points to

share|improve this question
up vote 1 down vote accepted

The default autodiscover queries DOMAIN.COM first before it queries AUTODISCOVER.DOMAIN.COM. Because of this, if you have a certificate on it will query that certificate and throw up the error. You can ignore the cert error in Outlook and then it will find the second cert and work ok, but it is a pain and will happen every time.

You have a few choices from what I can recall.

Either DON'T have an A record in DNS for the domain itself and only use a www record, etc. for webhosting. This would mean that if someone typed into a browser it wouldn't resolve though...only would.

Choice #2 -

Choice #3 - I think you can use this registry key: “ExcludeHttpsRootDomain” in the Autodiscover section in the registry under Outlook on the clients computer. You'll need to set it to 1.


for instance on Outlook 14.

share|improve this answer
Option 4: Don't use Autodiscover. It's not a requirement. There's nothing wrong with giving your customers directions on how to manually configure Outlook. – joeqwerty Apr 11 '13 at 14:27
@TheCleaner - I was thinking the same thing. It reports the first cert it can get a hold of, even if it's the webhost that serves it up. The choices themselves aren't really a "good" solution for us. Still, thanks for the tips! It's fantastic to get an explanation and have something to work with! – xstnc Apr 12 '13 at 6:47
@joeqwerty - That's indeed true. Even if the cert-check fails autodiscover still works and connects to the correct server. Even if you supply the correct information to a user, it doesn't neccecary help them very much! (Thinking about the general knowledgelevel of the end-users....) Thank you very much anyway! – xstnc Apr 12 '13 at 6:47

Use - run the Autodiscover test and it will show you what order Exchange clients use for autodiscover information. I think it tries connecting in such a way, that your web server is effectively 'answering' one of the requests, and then this causes autodiscover to fail.

You can probably get round this by making your webserver only respond for 'www.' rather than ''

share|improve this answer
That works in the same way as testing it from outlook 2013 doesn't it? Outlook logs the requests, and everything but the SRV record fails. The lookup from SRV points to the correct server, but the SSL still gets delivered from the webserver. – xstnc Apr 11 '13 at 9:36
I'm sorry, I don't have any experience of 2013 yet so I don't know. The first thing it looks for is https://yourdomain/AutoDiscover/AutoDiscover.xml - is it finding this? if not, it'll then try https://autodiscover.yourdomain/AutoDiscover/AutoDiscover.xml obviously these are HTTPS, but it is still trying to get that XML file - it doesn't exactly care about the certificate, other than the name that is within the certificate. – Snellgrove Apr 11 '13 at 9:55
It won't find this as the server hosting the e-mail is on and not The customers have typically: The autodiscover will the search for - http(s):// and so on. If that domain serves a certificate - could that be the issue? It just uses the first and best cert? Cause it looks like it's the default cert for the webserver, even if it's our internal one (hosting for the same customer) or they are using a diffrent webhost. – xstnc Apr 11 '13 at 11:46

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.