0

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 mail.ourhostingdomain.com 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 thisuser@ourprimarydomain.com, and it connects to the HLB as it should on mail.ourhostingdomain.com. Why would the webserver of ourprimarydomain.com reply instead of the exchange/hlb which got the correct certificate?

Ourprimarydomain.com got an _autodiscover SRV record to throw the requests to mail.ourhostingdomain.com (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 autodiscover.ourprimarydomain.com, just the SRV)

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

xstnc
  • 842
  • 1
  • 12
  • 20

2 Answers2

1

The default autodiscover queries DOMAIN.COM first before it queries AUTODISCOVER.DOMAIN.COM. Because of this, if you have a certificate on DOMAIN.com 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 DOMAIN.com into a browser it wouldn't resolve though...only www.DOMAIN.com would.

Choice #2 - http://windowsitpro.com/windows/how-can-i-force-my-microsoft-outlook-2007-client-particular-autodiscovery-server

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.

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\Autodiscover]

for instance on Outlook 14.

TheCleaner
  • 32,627
  • 26
  • 132
  • 191
  • 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 06: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 06:47
0

Use http://www.testexchangeconnectivity.com - 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 'yourdomain.com'

Snellgrove
  • 712
  • 4
  • 14
  • 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 09: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 09:55
  • It won't find this as the server hosting the e-mail is on ourhostingdomain.com and not thecustomersdomain.com. The customers have typically: hisorhername@thatcompany.com. The autodiscover will the search for - http(s)://thatcompany.com/Autodiscover/AutoDiscover.xml 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