Autodiscover.xml Error Office 365 Solution – cPanel

Header image featuring the title of the page

I ran into a very strange error the other day with one of my clients. You see, they had an external provider for their Microsoft Office 365 email hosting, and they were trying to take advantage of the “Autodiscover” functionality to automatically get their Outlook 2016 configured.

Now, I’m not expert in email configuration or Office 365. I’ve helped clients set it up, but it’s really not something I claim to know a ton about.

However, I’d say I’m probably in the top 0.1% of the population in terms of my understanding of it, and I can honestly say that most of it baffles me.

What even is autodiscover? You’d think it would be really straightforward: you click a button, Outlook checks some records, and automatically connects to your mail server without needing to manually input servers, ports, and more.

Tired of dealing with your slow WordPress website? Email me at brian@pagecrafter.com and mention the code #FreeHosting10 for two free months of lightning-fast WordPress hosting. We will even migrate you for free!

And I think that’s… sort of what it does? Honestly I’ve never once seen it work properly so it’s hard to tell. Here’s Microsoft’s own description of what autodiscover is:

The Autodiscover service minimizes user configuration and deployment steps by providing clients access to Exchange features. For Exchange Web Services (EWS) clients, Autodiscover is typically used to find the EWS endpoint URL. However, Autodiscover can also provide information to configure clients that use other protocols. Autodiscover works for client applications that are inside or outside firewalls and in resource forest and multiple forest scenarios.

Huh?

I mean, I’m a tech person, so I can sort of follow along with that, but WOW. I know everyone tends to hate marketing people but please, Microsoft, please hire some of them and have them write your content.

Here, let me give it a go:

“Autodiscover allows Microsoft users to automatically configure all of their devices in one easy step.”

Or maybe,

“I’m a PC, and Autodiscover was… My idea???”

Okay the first one is better. And the second one is a reminder that even the marketing people at Microsoft aren’t capable of making any sense.

The problem with the first one, though, is that it isn’t really automatic, and it also never seems to work. But the idea of it is great!

Anyway, I guess I’m going off on a bit of a rant on Microsoft, sorry about that. Let’s move on!

The error that prompted it all

Here is the error message my clients received when attempting to set up their Outlook 2016 using autodiscover (sic – note the typos – nice job Microsoft):

Screenshot of the Microsoft Office 365 Error from Outlook

It reads:

We found a problem.

We got an unexpected autodiscover response.

We an see taht your mailbox is in Office 365. However, AutoDiscover service seems to have configuration issues that prevent Outlook to connect o Office 365. An intermediate web server at http://domain.com/Autodiscover/Autodiscover.xml is interfering with AutoDiscover service and responding with incomplete data.

Your administrator need to either remove or correct the AutoDiscover component from http://domain.com/Autodiscover/Autodiscover.xml.

To work around this issue if your administrator can’t resolve the above soon, please take the following action:

Create an Outlook registry key to exclude the HTTPS root domain. For more information about how to do this, see the following Microsoft Knowledge Base article: 2212902
Important Excluding the HTTPS root domain is not a long-term solution for this issue. This workaround is provided as immediate relief for it. As soon as your administrator resolves the above AutoDiscover issue, the Outlook registry key must be removed.

So if you’re like me, you tried to do what it asked. You tried to remove or correct the AutoDiscover component. But how exactly do you do that?

You probably noticed that the folder /Autodiscover/ doesn’t actually exist in your file structure. I tried creating it, and it didn’t help. I even created that xml file, which then started loading at that URL, but it didn’t solve the problem.

So what’s the solution?

Basically you just need to change one setting in cPanel. This should work as long as your Office 365 is hosted elsewhere.

  1. Go to your cPanel and under the “Email” section, click “Email Routing”.
  2. Select the domain you’re having issues with.
  3. Select “Remote Mail Exchanger” and click “Change.”

Screenshot of the "Mail Routing" settings of cPanel correctly configured to "Remote Mail Exchanger" for use with an external Office 365 Provider

Now try autodiscover again. You should find that it works!

What’s going on here?

I believe the issue is that some cPanel setups include an Exchange server. Even if you’ve never set it up, it’s there.

Now you might be asking, “But I set up all of the DNS records specifically to point to the correct exchange server: why would Outlook care what’s on the host server?”

And that’s a great question! Sadly, I have no answer for you. It’s completely asinine. Just know that one of the first things autodiscover checks is the server hosting the website. Go figure.

So when it checks your site hosted with cPanel, it gets a response because there is a service running on the site to respond to autodiscover. But since it’s not the Exchange server you want, it doesn’t actually work.

Again, you’d think that since it’s not working, autodiscover would just skip it and use the DNS records whose sole purpose of existing is to make sure autodiscover locates the right server. But the geniuses at Microsoft have brains much bigger than those of you and I, and we shouldn’t presume to understand what’s going on in those giant skulls of theirs.

For more info on the priority order of different records and also a fuller explanation of the technical steps taken by Autodiscover, check out this excellent post by Jaap Wesselius.

Now, when you looked at the mail routing, you may have seen that it was set to “Automatic”, and that automatic had chosen “Remote Mail Exchanger”. So you’d think that would be all set.

The problem is, I believe it’s still listening for something that will tell it that it should start using the local mail exchanger. So when it hears an autodiscover request, it answers, and is prepared to switch to local if things work out.

By manually choosing “Remote Mail Exchanger”, you stop it from listening, and thus disable the AutoDiscover Component.

In conclusion: Microsoft is hard to work with and autodiscover is bad.

 

 

 

About Brian Johnson

Brian Johnson is a website developer and designer living in Minneapolis, Minnesota with a passion for code and WordPress. He spends his days building WordPress websites for small businesses, developing new code with the online community, and living life.