There’s a fairly common issue that occurs with mobile devices connecting to Exchange Server or Exchange Online for mailbox access.
Before we go further though, I just want to point out two other potential causes of this issue that you should check first, as they’re simpler solutions:
- User principal names (UPNs) for user accounts should match primary SMTP addresses. If they don’t, then some mobile devices will fail to setup with Autodiscover.
- Some Android devices need the username (UPN/email) to be entered as “username”, for example “alex.heyne@exchangeserverpro.net”
Assuming neither of the above suggestions fixed your problem, you may be having issues due to Autodiscover and root domain lookups. When the mobile device begins the Autodiscover process, it will often fail and prompt the user to manually configure their device settings.
When clients use Autodiscover to locate server configuration details, the first attempt is usually to try the root domain for the user’s email address, e.g. a user of alex.heyne@exchangeserverpro.net will mean an Autodiscover attempt is sent to https://exchangeserverpro.net/Autodiscover/Autodiscover.xml. You can see this behavior by running the ActiveSync Autodiscover test using the Remote Connectivity Analyzer.
The root domain lookup makes absolutely no sense to me, since no customer I’ve ever dealt with has their root domain resolving in DNS to their Exchange server where the Autodiscover service is available. But that’s the behavior, so we need to deal with it.
Now, most clients will handle that root domain lookup failure gracefully, and (just like the Remote Connectivity Analyzer does) move on to the next Autodiscover method. As long as the Autodiscover CNAME or SRV record is implemented (or both), the client will successfully connect to Autodiscover and the device or application is configured correctly.
But, for a random assortment of devices and applications, the root domain failure is interpreted as a complete Autodiscover failure, and the user is prompted to manually configure server details. This can occur when the root domain resolves to a web server (which is normally where it resolves to) that has HTTPS enabled and listening, but has an SSL certificate installed that doesn’t match the root domain name that the device is trying to connect to. This is very common when shared hosting is used to host multiple websites for different domains.
In the example above, a device connecting over HTTPS to “contoso.com” will see a certificate of “sr100283.webhostingcircus.com”, and the HTTPS connection will not be successful. To fix this situation, some changes on the web server are required.
- Enable SSL for the website. This will involve adding an SSL certificate, which you may need to purchase if the web host can’t arrange it for you. Depending on the web host this may involve an extra cost and potentially a static IP, although most good web hosts these days will let you enable SSL at no additional cost. Some even use Lets Encrypt to provide free SSL for customers. Another alternative is to use Cloudflare to get free SSL for your website (this doesn’t require you to move the website itself to a different server).
- On the web server, configure a redirect for all requests to the /Autodiscover virtual directory to be redirected to the autodiscover.contoso.com instead (where “contoso.com” is your domain name). Configuring the redirect itself will depend on the type of web server your site is running on. Some web hosts provide a control panel to allow you to configure redirects yourself.
When the SSL and redirect are in place, Autodiscover lookups to the root domain will not fail the HTTPS connection, and will be redirected to your Exchange server instead.
Hi Paul,
What we should do if the website is hosted on CPanel?
We are in to the same issue, even remote connectivity analyzer is directing us to root domain.
Your help will be greatly appriciated.
Hi,
did you have an answer. I am running in the same problem
Is the CNAME record actually what helps the client get past the root domain lookup failure for the autodiscover.xml file?
Is there any way to fix the failure at the root domain lookup for the autodiscover.xml file when the web server is not IIS?
Hi Paul,
We have added a new accepted domain to our exchange server, added alias to an user with the new domain name, later set that as the primary SMTP. Post that user is unable to receive email on his mobile device, when we try to re-configure mobile device its prompts for user name and password, entered the new email address and the password, it keep prompting for password. If we enter the old email and the password it got configured however no emails on the mobile device.
Your suggestion is highly appreciated, as we planning to use new domain as primary for all the existing mailboxes.
Thank Paul for this.
love your work.
we have this already configured and its working fine however iPhone users are not getting their exchange automatically added.
each time we need to add the server manually.
Outlook internal and external the domain is working fine .
is this some redirection configuration on the exchange side ?
Thank you
Thank you for the great article.
I have just one addition.
I had to configure on the web server, a redirect for all requests to the “/Autodiscover” virtual directory to the “autodiscover.domain.com:443/Autodiscover/Autodiscover.xml”!
Now it works!
I am facing the same issue but our DNS is hosted on Azure and I can not find the place to redirect /autodiscover
The Real Person!
The Real Person!
It’s not a DNS redirect. The redirect is configured on the web server that the root domain resolves to.
Sorry, how can i config cas server IIS to redirect root domain request.
Or do i need to create front web server to mapping root domain and to redirect ?
The Real Person!
The Real Person!
I don’t really understand what you’re trying to do.
Hi Paul,
We have the situation like we purchased the wildcard certificate with the name *.contoso.com but my SMTP name space is user@contoso.net. COnsidering this scenario can i use cname record pointing autodiscover.contoso.net to autodiscover.contoso.com? Doing like this can i avoid certificate warnings?
A SRV record will account for this
Hey Paul, nice article. I think we are experiencing exactly this, but we are having a hard time resolving this issue. Can you provide a little more detail on how the actual redirect should look?
According to how I interpreted your explanation, one should create a redirect at https://domain.com/autodiscover to redirect all traffic to autodiscover.domain.com? I advised our web host of this and they didn’t even want to try it because they said it wouldn’t work because autodiscover.domain.com didn’t respond. I just wanted to see if you could clarify this for me?
Thanks.
The Real Person!
The Real Person!
Yes you do need to make sure the URL you’re redirecting to actually exists in DNS.
Hello Paul,
Are yo recommend this link for redirect the Autodiscover? https://jaapwesselius.com/2014/03/28/autodiscoverredirect-in-exchange-2013-sp1-on-windows-2012-r2/
Best regards!!
I’ve also seen that https:///Autodiscover/Autodiscover.xml fails but it takes a loooong time (minute or so) and Connectivity Analyzer shows this with the Duration of each test. This seems to be because of some web hosting providers and sometimes hard to get them to change things. No solution for mobile devices but for Outlook, there’s a GPO setting that enables you to skip this with the setting in Administrative Templates -> Microsoft Outlook X -> Account Settings -> Exchange -> Disable Autodiscover and ticking “”Exclude the root domain query based on your primary SMTP address””
Great Article, I am dealing with same situation, I am trying to fix other teams cert , will just fixing the cert will not help ? Redirect would also be necessary on their server to autodiscover ?
Some mobile devices get cert warning but still they finish it successfully..so I was thinking of just fixing the cert .
Another option is to put static XML file to the following WebSite path: https://contoso.com/autodiscover/autodiscover.xml
XML file content:
email
redirectUrl
http://autodiscover.contoso.com/autodiscover/autodiscover.xml
CAN i use this méthod , if i have mutiple domain?
I would like TO use the same certificat
You might want to make sure your web server is not a hosted linux server C-panel. The Godaddy C-panel (and maybe others) are set to automatically reject autodiscover requests and return error code 400 for ALL remote domains. That means the autodiscover request is denied/rejected by policy before it gets to the specified domain address- BEFORE it can be redirected to your exchange server. That is the current setting (Nov. 2016).
Another gotcha I found is when the root website has soft 404 fail. It responds with a 200 ok for a GUI error page but this messes with the outlook profile creation.
HTTP redirect will result in a prompt/popup in outlook for externally users with outlook right? And does this also happen for ActiveSync devices?
The Real Person!
The Real Person!
Every mobile device I’ve seen will follow the redirect without complaining.
The Outlook Autodiscover redirect warning is unavoidable unless you can suppress it with GPO, which obviously only helps for domain joined computers. For non-domain joined computers, at least the user can accept the redirect and then Autodiscover will work without them having to manually configure any profile settings.
Keep in mind also this is mainly an issue for externally connecting devices.