In earlier versions of Exchange you can use the Autodiscoverredirect option to retrieve autodiscover information if your primary SMTP domain in your email address does not match the domain name of the autodiscover DNS record in your Exchange deployment. You’ll face this issue when your Client Access server is using webmail.contoso.com and autodiscover.contoso.com but your email address is john@fabrikam.com. In this case your Outlook client will automatically start looking for a DNS record called autodiscover.fabrikam.com which points to the autodiscover.contoso.com. As a result a certificate warning is presented since the name of the request does not match the name on the certificate.
To overcome this you can use a so called autodiscoverredirect mechanism. This hasn’t changed much in Exchange 2013. On the Client Access server you have to configure an additional website (in IIS Manager) working with an autodiscoverredirect.contoso.com name. In IIS requests for this website are automatically redirected to the correct autodiscover.contoso.com website/virtual directory. In the Fabrikam namespace you create a CNAME DNS record called autodiscover.fabrikam.com which points to the autodiscoverredirect.contoso.com website.
Note. In my lab environment I will be using the domain Exchange16.com as the base domain so I’ll have autodiscover.exchange16.com and autodiscoverredirect.exchange16.com. The additional domain I’m hosting on this environment is inframan.nl, our user there is patrick@inframan.nl
To implement this you have to follow the these steps:
- Configure an additional IP address on the Client Access server.
- In IIS Manager, bind the Default Web Site to the original IP address of the Client Access server for port 443 as shown in the following figure. Before you continue, make sure the Client Access server keeps working with this new binding.
- In Windows Explorer create two additional directories C:\Inetpub\AutodiscoverRedirect and C:\Inetpub\AutodiscoverRedirect\Autodiscover.
- In IIS Manager, create a new website, name is AutodiscoverRedirect and use the C:\Inetpub\Autodiscover as its Physical Path. Make sure the binding of this web site is set to the additional IP address we configured earlier as shown in the following figure:
- In the AutodiscoverRedirect web site in IIS Manager you’ll see an Autodiscover Virtual Directory show up. Select this Autodiscover Virtual Directory and in the details pane double click HTTP Redirect.
- In the HTTP Redirect window check the Redirect request to this destination and enter the normal autodiscover URL like https://autodiscover.exchange16.com/autodiscover as shown in the following figure:
The only thing left is to create a DNS record for autodiscoverredirect.exchange16.com which should point to the additional IP address. The autodiscover.inframan.nl DNS record should be a CNAME record and point to autodiscoverredirect.exchange16.com.
If you want to test this you can use the Remote Connectivity Analyzer (RCA) which can be found on https://testconnectivity.microsoft.com. In RCA select Outlook Autodiscover under Microsoft Office Outlook Connectivity Tests. In the next window enter the test user’s credentials as shown in the following figure:
When you click Perform Test RCA will perform an Autodiscover test en thus go thought the Autodiscoverredirect process we just configured. Don’t let the Connectivity Test successful with warnings fool you. You will see that the normal autodiscover tests fail (with the red cross) but that the HTTP redirect option succeeds as shown in the following figure:
When you expand the HTTP redirect method you can exactly see what’s happening under the hood.
Step 1 is the DNS lookup for autodiscover.inframan.nl
Step 2 is checking port 80 for this URL
Step 3 is the actual redirect response from the autodiscoverredirect website
Step 4 is the HTTP post to https://autodiscover.exchange16.com/autodiscover/autodiscover.xml
This is shown in the following figure:
When you start Outlook (2013) and logon to the patrick@inframan.nl mailbox the autodiscover request will be redirected. Outlook will notice this and show a warning message:
You can safely check the Don’t ask me about this website again and Outlook will continue working normally.
Summary
You can use the Autodiscoverredirect option in Exchange 2013 (in this blog on Windows 2012 R2) if you have an Exchange 2013 environment with multiple SMTP domains. You can use these domains without adding these domains to the SSL certificate on the Client Access server. I’ve seen this autodiscoverredirect option at hosting companies where thousands of additional SMTP domains are hosted, but have seen this as enterprise customers as well. And it’s fully supported by Microsoft so you’re good to go.
Many thanks for sharing such a document. I am stuck on an issue after implementing the steps:
It says ” An HTTP 403 forbidden response was received. The response appears to have come from Unknown”. The redirection works and port 80 is able to open. But finally it throws the error:
Attempting to contact the Autodiscover service using the HTTP redirect method.
The attempt to contact Autodiscover using the HTTP Redirect method failed.
Additional Details
Elapsed Time: 5558 ms.
Test Steps
Attempting to resolve the host name autodiscover.domain.com in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: 1.1.1.1
Elapsed Time: 8 ms.
Testing TCP port 80 on host autodiscover.domain.com to ensure it’s listening and open.
The port was opened successfully.
Additional Details
Elapsed Time: 636 ms.
The Microsoft Connectivity Analyzer is checking the host autodiscover.domain.com for an HTTP redirect to the Autodiscover service.
The Microsoft Connectivity Analyzer failed to get an HTTP redirect response for Autodiscover.
Additional Details
An HTTP 403 forbidden response was received. The response appears to have come from Unknown.
Body of the response: HTTP Response Headers: X-FEServer: EXCHANGE-CAS-01 Content-Length: 0 Date: Thu, 23 Oct 2014 16:08:50 GMT Server: Microsoft-IIS/8.5 X-Powered-By: ASP.NET
Elapsed Time: 4913 ms.
LikeLike
Hi Manu,
Do you seen this behaviour in the Remote Connectivity Analyzer?
Thanks,
Jaap
LikeLike
Thanks Jaap, this is like some mis-configurations and I figured it out 🙂
LikeLike
If I follow these instructions, the Exchange Administrative Center is no longer available on https://localhost/ecp/?ExchClientVer=15. Is it possible to get the EAC working on https://localhost/ecp/?ExchClientVer=15?
LikeLike
You have to check the binding to see where 127.0.0.1 lands. you can also use https://servername/ecp. Or even better, implement the redirection site on a different (web) server.
LikeLike
Hi Jaap,
I followed your guide, but if I start AutodirectRedirect in IIS, I receive this error in Exchange PowerShell (this is the first of 5 :
New-PSSession: [mail.myserver.com] mail.myserver.com Connecting to remote server failed with the following error message: The WinRM client: HTTP URL not available on the HTTP server to the requested destination. Usually this message is returned by a HTTP server that does not support WS-Management protocol. For more information, see the topic of about_Remote_Troubleshooting Guide.
In row:1 char:1
+ New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Microsoft.Excha …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : URLNotAvailable,PSSessionOpenFailed
Intead, if I stop the application in IIS, there’s no error.
Thanks in advance.
LikeLike
I’m afraid this is more a generic PowerShell issue than something with Autodiscover or AutodiscoverRedirect. What i think is that PowerShell connects to the new AutodiscoverRedirect site instead of the default web site and in this new site PowerShell ends up nowhere 😦
LikeLike
Jaap, latest question: is it possible to make Autodiscover Redirect without setting external DNS records?
LikeLike
well, clients need to be able to find your autodiscoverredirect.contoso.com, so somehow you do need a DNS record I’m afraid……
LikeLike
Good blog entry. Is this possible ONLY create a CNAME ?
autodiscover.inframan.nl –> autodiscoverredirect.exchange16.com
LikeLike
No, I’m afraid this is not possible.
LikeLike
a little update.
autodiscover.inframan.nl –> autodiscover.exchange16.com
LikeLike
No, I’m afraid this is not possible
LikeLike
Hi jaapwesselius,
Can I ask why we need an additional IP address for autodiscoverredirect.exchange16.com but not use same ip address with autodiscover.exchange16.com ?
My clients will not get a certificate warning but still get a redirect URL warning message right ?
If Increasing the number of subject alternative names on the certificate is the best way for my clients won’t get any warning ?
Thanks in advance.
LikeLike
You need a seperate website since port 80 is already used by Exchange, and you cannot have to listeners to the same IP address and port.
Yes, you will still get the autoredirect warning in Outlook.
The best solution is to have multiple names in your SSL certificate as you already mentioned.
LikeLike
Hello jaapwesselius,
i followed the instructions as you showed them.
I am using Server 2012 R2, Esxchange 2013 SP1 and Outlook 2013
But still i get the certificate error.
It keeps looking for autodiscover.domainB.com first.
Then when i press Yes i get the redirect warning.
What could i have done wrong?
LikeLike
Hi,
The only thing I can think about is that your autodiscover.domain.com is pointing to the Client Access server. This should not be the case, autodiscover.domain.com should be a CNAME record pointing to the Autodiscoverredirect website.
LikeLike
Well i added a second ip address for the autodiscoverredirect.
And made the DNS autodiscover.domainA.com CNAME autodiscoverredirect.MainDomain.com
LikeLike
What would the setup look like if we use host names (host headers) in the binding, with one IP address?
LikeLike
On the Exchange server you mean? I have no idea, but looking at the complexity of Exchange and IIS I would think things will break (but I might be wrong)
LikeLike
Has this stopped working for IPhones/IPads since IOS11? It was working perfectly prior to this.
LikeLike
Not that I’m aware of. I do know there have been issues with iOS11 en Exchange 2016 running on Windows 2016, but that should be solved with later (minor) updates of iOS11
LikeLike
Ok, not a problem, thank you for this information.
LikeLike
Doing a IIS Redirect is a bad idea. I had a support ticket yesterday with an Exchange 2010 Server with this IIS style. Everything works fine. And then we installed the first Exchange 2016 in Front as new Entry Point. OWA, EAS etc ist working fine but Autodiscover breaks. It tool some time to find these redirect on the old Ex2010 Server. Removing is and the Ex2016 Frontend was happy to talk to that Ex2010 Backend
LikeLike