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 a 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. The 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 in to 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.
Thank you so much — Thomson Reuters and I were about to fistfight!
I was looking all over for a solution to not being able to add an email account in my domain. I was pulling the remaining 3 hairs out of my head and hitting against the wall.
I can’t say enough how much you helped me with this. Holy smokes. Seriously great info!
That is perfect. I think you saved many life with this information.
This worked for me.
Hi
You saved me from hell.
God bless you.
Thanks a lot.
Wonder full finding brother.
You saved my life and job. Well written and explained.
Thanks a lot for your effort.
This was one of the most difficult, irritating problems I have ever encountered in 20 years in IT. You, sir, are nothing short of a hero. Who the hell expects the change of a web host to lead to email issues? Anyway, thank you very much.
Oh man you just saved my life. Thanks!
Oh Boy!. Worked perfectly .
Thanks a lot and appreciate the steps. especially the GoDaddy one
Recently had moved domain & Hosting from Net4.com to Godaddy.com due to former going into insolvency.
Had spent the whole day figuring this out.
Alternately, had to set to IMAP/POP server for temporary usage.
But, Mails were taking long time to sync.
Thank you so much been smashing my head against the wall for the last 4 hours!
This article saved my life! We launched our new public website and all of a sudden, all hell broke loose with our hybrid environment. Thank you so much for taking the time to put this on the internet. I could hug you. Hahahahah. Cheers.
Gareth,
I rarely ever post comments but I have to give you a huge public thanks for this fix. I have spent over 10 hours going through every other solution I could find and this “simple” fix is what did the trick.
Many thanks!
RS
Just the answer I was looking for!
Thanks!
Hello Gareth,
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.
Thanks,
Alexios
I got the same problem some weeks ago.
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.
There is a solution :
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover\
DWORD: ExcludeHttpsRootDomain
Value: 1
See https://support.microsoft.com/en-us/help/2212902/unexpected-autodiscover-behavior-when-you-have-registry-settings-under
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
This is a great alternative Jean-Marc. Thanks for posting.
Hey Gareth,
Great article, thanks for posting it.
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.
You can also ask the website provider to simply disable POP, IMAP and Autodiscover protocols, as they are rarely used. That is actually a permanent solution here.
Also funny thing is, this affects only one user in entire domain, regardless of location or computer he uses.
Also you can try to use Microsoft tool to identify this: SaRA from https://diagnostics.outlook.com
Hey Matt,
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).
Perfect!!!