While attempting to configure an Outlook client with an Exchange mailbox I ran into an issue where the account creation would not complete. Instead, Outlook would stop on “Search for server settings” and prompt me for a username and password. The credentials of my Exchange account did not work and kicked back the login prompt.
When I attempted to test Autodiscover using testconnectivity.microsoft.com I ran into an even stranger error. Autodiscover appeared to work. But I received the error “No account settings were returned from the Autodiscover response”.
Examining the Autodiscover response I noticed that the test successfully completed against the root of supertekboy.com. This was odd as supertekboy.com is redirected to the website www.supertekboy.com where no Autodiscover responses should be happening.
However, when attempting to plug the Autodiscover URL into a web browser I found that something was responding to Autodiscover requests. It was responding with an error of “Autodiscovery must be provided a valid email address”.
This isn’t an Exchange or Office 365 autodiscover response. Instead, this was my web hosting provider responding to my Autodiscover request. Specifically, cPanel. cPanel has its own implementation of autodiscover, which allows Outlook and other email clients to automatically configure themselves for a cPanel mailbox. Unfortunately, this conflicts with autodiscover locating an Exchange or Office 365 mailbox.
For many organizations, their email address and website domain name are one in the same. For example, a company may use www.contoso.com for their website and firstname.lastname@example.org for their primary email address. Typically most companies will also specify that the root of their domain, contoso.com redirects to www.contoso.com. That way anyone forgetting to add the “www” still ends up on that companies website. This is common practice.
Where this becomes a problem is that Outlook when performing Autodiscover, will first query the root domain. In our example, this would be contoso.com. For the majority of implementations, this first query would fail as this would end up at that companies website and nothing would respond to Autodiscover. Outlook would then proceed to the second query of autodiscover.contoso.com which is what most Exchange and all Office 365 implementations use.
Even in recent years when cPanel started to respond to Autodiscover requests, this would still fail. The reason is that even though cPanel was responding there was no valid certificate at the web host. With more companies switching their website over to HTTPS this means that the root domain now has a valid certificate. Hence the first Autodiscover method, which almost always used to fail, is now passing. When this passes Outlook does not proceed to query autodiscover.contoso.com or any of the later lookup methods.
For internal domain-joined clients, this should not be an issue as they should first look up autodiscover via a Service Connection Point (SCP) in Active Directory. However, when that domain-joined computer is off-network, or, you are accessing Exchange with a non-domain joined computer or mobile client, this is where the issue would present itself.
In summary, if your email domain and website domain match, you host your website on cPanel and, your website is delivered over HTTPS, you will more than likely see this issue.
Tell cPanel to stop responding
The solution is to tell cPanel to stop responding to Autodiscover requests. Following are instructions on how to perform this action in GoDaddy. While these instructions will vary between hosting providers the concept remains the same.
Log into GoDaddy and navigate over to your cPanel. From cPanel scroll down to the Email section and select MX Entry.
From the MX Entry screen select Remote Mail Exchanger and click the Change button. Remote Mail Exchanger should now become bold to identify it as the current setting.
At this point, cPanel should stop responding to Autodiscover requests. Subsequent testing with testconnectivity.microsoft.com shows that the root domain query of supertekboy.com is now failing. As long as you have another autodiscover method configured correctly your Outlook clients should now connect to Exchange or Office 365. In our case the Autodiscover HTTP redirect method is successful.
Have you ever run into this problem? What did you do to fix it? Drop a comment below or come join the conversation on Twitter @SuperTekBoy.