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 and but your email address is In this case your Outlook client will automatically start looking for a DNS record called which points to the 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 name. In IIS requests for this website are automatically redirected to the correct website/virtual directory. In the Fabrikam namespace you create a CNAME DNS record called which points to the website.

Note. In my lab environment I will be using the domain as the base domain so I’ll have and The additional domain I’m hosting on this environment is, our user there is

To implement this you have to follow the these steps:

  1. Configure an additional IP address on the Client Access server.
  2. 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.


  1. In Windows Explorer create two additional directories C:\Inetpub\AutodiscoverRedirect and C:\Inetpub\AutodiscoverRedirect\Autodiscover.
  2. 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:


  1. 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.
  2. In the HTTP Redirect window check the Redirect request to this destination and enter the normal autodiscover URL like as shown in the following figure:


The only thing left is to create a DNS record for which should point to the additional IP address. The DNS record should be a CNAME record and point to

If you want to test this you can use the Remote Connectivity Analyzer (RCA) which can be found on 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

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

This is shown in the following figure:


When you start Outlook (2013) and logon to the 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.


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.

23 thoughts on “AutodiscoverRedirect in Exchange 2013 SP1 on Windows 2012 R2”

  1. 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 in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned:
    Elapsed Time: 8 ms.
    Testing TCP port 80 on host 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 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.


  2. 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: [] 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
    + FullyQualifiedErrorId : URLNotAvailable,PSSessionOpenFailed

    Intead, if I stop the application in IIS, there’s no error.
    Thanks in advance.


    1. 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 😦


  3. Hi jaapwesselius,
    Can I ask why we need an additional IP address for but not use same ip address with ?
    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.


    1. 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.


  4. 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 first.
    Then when i press Yes i get the redirect warning.

    What could i have done wrong?


    1. Hi,
      The only thing I can think about is that your is pointing to the Client Access server. This should not be the case, should be a CNAME record pointing to the Autodiscoverredirect website.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s