Outlook Anywhere clients are returning a strange certificate (possibly from Plesk or cPanel) when attempting to connect to your SBS 2008 machine running Exchange 2007 using your public domain name.
Check your domain's DNS settings to see if you have a * record that handles all queries for subdomains that don't explicitly exist. For example *.mydomain.com. Remove it if it exists.
The Long Story:
Outlook Anywhere Queries several subdomains of your main SMTP domain looking for the autoconfiguration information. After the queries for domains like autoconfigure.my-SMTP-domain.com fail, then Outlook will query for a SRV record. SBS 2008 relies on a SRV record to point the Outlook Anywhere clients to the proper URL using the proper hostname that was registered in your SSL cert.
My clients were returning a certificate error with a host of problems.
After some heart palpitations in which I fretted that I had munged the certificate creation process somehow, I clicked "View Certificate" and found something puzzling:
The certificate was issued to Plesk! Plesk is the control panel that our domain is managed with. Somehow or another, Outlook was getting sent to something on our domain that was returning our control panel's certificate.
I tried some things, and then realized that I could type any nonsense gibberish as a subdomain of my main domain and be sent to our website. That caused a few minutes of childish fun as I typed silly subdomains in just to see them successfully bring up the organization's web site. That still didn't clue me in to the real problem though... because I'm a nublet and was not aware of DNS * records. After some sleuthing I happened to come across a forum that mentioned a "*" record which jogged my memory. I had actually seen a * record in our DNS control panel and hadn't thought much about it.
I quickly deleted the * record from our DNS control panel and after DNS propagated, Outlook Anywhere worked for my clients.
Personally, I think Outlook's requirement that DNS resolution fails for certain subdomains before it seeks out the SRV record is a bit flakey and error prone. In fact, you will see exactly why that might cause grief for some people that use OpenDNS or even certain ISPs in a post later this week...
The succession of autodiscover attempts done by an Outlook 2007 SP1 client is now thus:
- Autodiscover posts to https://contoso.com/Autodiscover/Autodiscover.xml. This fails.
- Autodiscover posts to https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml. This fails.
- Autodiscover performs the following redirect check:
- Autodiscover uses DNS SRV lookup for _autodiscover._tcp.contoso.com, and then "mail.contoso.com" is returned.
- Outlook asks permission from the user to continue with Autodiscover to post to https://mail.contoso.com/autodiscover/autodiscover.xml.
- Autodiscover's POST request is successfully posted to https://mail.contoso.com/autodiscover/autodiscover.xml.