AutodiscoverRedirect in Exchange 2013 SP1 on Windows 2012 R2

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.

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

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.

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.

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 😦

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.

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.

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.