UPDATE: Checked with Exchange 2010, and this also resolves the issue.
Today I was dealing with a customer who was receiving errors in Outlook for autodiscover each time they opened Outlook. This was all after they’d changed their domain name.
I’d run a script I use to alter all of the host names, to check that they were all correct and then spent considerable time hunting around Exchange for this incorrect setting, and eventually found it.
It’s in the OutlookAnywhere settings, rather than in all of the other URL’s my other script alters. Usually, this URL doesn’t change, and so I’d missed it, but as they’d changed their domain name, this also needed alteration.
So, if you get SSL mismatch errors, and you think you’ve changed all of the necessary URL’s, check this one:
get-outlookanywhere | select Identity, ExternalHostName
if the External Host Name is incorrect, then adjust it with this:
get-outlookanywhere | set-outlookanywhere -externalhostname "insert.hostname.here"
This certainly works with Exchange 2007, I’ve not yet checked it on Exchange 2010, but believe it’s the same cmdlets.
I’ll write up a full blog post this weekend with a list of all of the places that need to be changed, so that it’s all in one place.
Over the last several years I’ve come across all sorts of issues connecting mobile phones to Exchange servers for syncing purposes… These have ranged in fixes for Exchange 2003 and needing to create an exchange-oma virtual directory, with some registry key changes, to fixing security problems within AD to resolve the issues.
In the past 6 months or so, I’ve been using this site to test these configurations (it saves messing around with your phone, or Windows Phone simulators):
This is the Exchange Remote Connectivity Analyser, and it works miracles!
It’ll test Autodiscover for you… as well as then trying to sync (with the account details you provide) with your mailbox (change the password before and after!). It then gives detailed steps and error messages (as well as links pointing to the usual causes of the problem) which can be used to troubleshoot further.
Sometimes it’ll complain about public certificates (usually if there is an intermediate CA in the certificate path), but if this is the case, just tick the “Ignore SSL Errors” check box, and it’ll happily run the test and only give you a warning instead of an error.
This site has helped me so many times before, and is extremely useful for troubleshooting… I always make this my first port of call should I have any Outlook Anywhere/ActiveSync errors.
I hope you find it as useful as I do!