No account settings were returned from the Autodiscover response

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.

The problem

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 apond@contoso.com 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.

Note: These instructions assume you are not using cPanel mailboxes.

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.

Note: It may take up to 1 hour for this setting to propagate. (Credit: Roberto T.)

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.

Reader Interactions

Comments

Great Info! I have faced this issue some weeks ago and I was really wondering if it possible or why ms never change the order outlook queries. As that organization had very specific needs (no internet browsing at that laptop just outlook access externally from a Van) I changed the hosts file so that domain always points to the ip of exchange. Not a recommended change for other people that might read this post but under the specific scenario (and without having access to the cpanel ) I came across was working just fine.

You can also try other temporary solution. Add name, email address with “@domain.onmicrosoft.com ” on initial Outlook setup page, don’t enter the password and click next. It will go to O365 directly. When prompted for credentials, enter correct email address “@domain.com” with password. This should configure the mailbox easily.

Thanks Bhavin. I could certainly see how that would work and it’s a decent workaround. But, the challenge is that I don’t see this alleviating help desk call volume. And support costs are important to the business.

Users are probably not going to know their tenant onmicrosoft.com address versus their primary email address. I would say this is especially true for your power users that configure their own Outlook profiles, or, moreso their own mobile devices.

If you have automated provisioning processes in place, or, a help desk that typically handles all Outlook and mobile phone provisioning then this is a good workaround. Otherwise I would say fix the root problem of the cPanel autodiscover.

The other records you can exclude, also under the Autodiscover key are as follows. Use a value of 1 to enable, delete the key if you no longer want to exclude these checks. DWORD: ExcludeScpLookup DWORD: ExcludeHttpsAutoDiscoverDomain DWORD: ExcludeHttpRedirect //I DON’T EXCLUDE THIS ONE BECAUSE I USE IT DWORD: ExcludeSrvRecord

I have seen this issue with cPanel and having to resolve this issue without having access to the cPanel settings myself as a service provider was quite frustrating.

What would put the issue to bed immediately would be if Microsoft could alter the order in which Outlook attempts to obtain account settings.

Outlook attempts to contact topleveldomain.com/autodiscover.xml as it’s first port of call, before eventually getting to autodiscover.topleveldomain.com/autodiscover.xml. If it instead tried autodiscover.topleveldomain.com/autodiscover.xml first, the problem would disappear immediately.

This would also resolve issues with certificate warnings that can be received on Outlook clients when configuring accounts.

I agree. I really wish the order of autodiscover was changed so that the top level domain query was not first in the list. The vast majority of environments I encounter use autodiscover.domain.com for their external lookup (obviously using the SCP internally).