Many mobile devices, have problems with Exchange Autodiscover, if the following is true:
- You have a webserver on the root domain (many companies usually do!)
- The root webserver respons on HTTPS, but with wrong certificate and also have no Autodiscover setting.
This is due to the way autodiscover works (In steps):
- Connect to: https://contoso.com/AutoDiscover/AutoDiscover.xml
- Connect to: https://autodiscover.contoso.com/AutoDiscover/AutoDiscover.xml
- Autodiscover redirect URL for redirection: http://autodiscover.contoso.com/autodiscover/autodiscover.xml
- Search for DNS SRV record
When you have many domains on an Exchange server, you cannot have a autodiscover DNS A or CNAME record for them all, as you can only have one certificate on the Exchange server.
Therefore you can ex. use SRV records:
In your DNS zone editor add a SRV record with the following information:
-
Service
_autodiscover
-
Protocol
_tcp
-
Name Enter one of the following values:
-
Enter
@
if your registered domain is your cloud-based domain. For example, if your registered domain is contoso.com and your cloud-based domain is contoso.com, enter@
. -
Enter the subdomain name if your cloud-based domain is a subdomain of your registered domain. For example, if your registered domain is contoso.com, but your cloud-based domain is the subdomain test.contoso.com, enter
test
.
-
-
Priority
10 (or as per your design)
-
Weight 10 (or as per your design)
-
Port
443
-
Target
autodiscover.domain.dk
-
TTL Verify that an appropriate TTL is selected, 1 hour is a common default. (If you are approaching a migration, this should be decremented to allow for quicker cutover)
Test with NSLOOKUP (Allow for propagation):
> set type=srv
> _autodiscover._tcp.martinsblog.dk
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
_autodiscover._tcp.martinsblog.dk SRV service location:
priority = 10
weight = 10
port = 443
svr hostname = autodiscover.domain.dk
>
So now the SRV record is ready.
BUT, the problem with the mobiledevice is not solved, as if the mobile device fails step 1, due to a https response and wrong certificate, the device will prompt you for additional infos (Outlook clients will not do this, as the just keep moving through the steps). So for the purpose of Autodiscover, it will fail!
To fix:
We need to make sure, that if the root domain does respond on https AND has a valid certificate!, that it can redirect to the real autodiscover, in other words, we need to make step 1 work!
For Linux web servers, you can use .htaccess file:
RedirectMatch 302 (?i)^/Autodiscover/(.*)$ https://autodiscover.domain.dk/Autodiscover/$1
For Windows IIS:
Make a seperate directory called autodiscover and redirect all traffic to
https://autodiscover.domain.dk/Autodiscover
Ex: https://jaapwesselius.com/2014/03/28/autodiscoverredirect-in-exchange-2013-sp1-on-windows-2012-r2/
When the above has been setup the root domain lookup for autodiscover on https will not fail, and the device will beredirected to the Exchange server 🙂
Hey Martin, thanks for the article, this has been quite helpful in explaining why mobile autodiscover stopped working when we started using SRV record for autodiscover! Would you mind elaborating on how to redirect using IIS? Thanks!
Hi Charlie,
Thanks 🙂
Try with this link:
https://jaapwesselius.com/2014/03/28/autodiscoverredirect-in-exchange-2013-sp1-on-windows-2012-r2/
🙂
regards Martin