Using AutoDiscover with large numbers of accepted domains (Part 1)

If you would like to be notified of when Steve Goodman releases the next part in this article series please sign up to our Real Time Article Update newsletter.

If you would like to read the other part in this article series please go to: Using AutoDiscover with large numbers of accepted domains (Part 2).


One of the great benefits of using Subject Alternative Name (SAN) SSL certificates with Exchange is that you’re able to specify additional names on your certificate to cater for your Exchange needs, covering multiple domains.

But what if you’ve got a large number of accepted domains within your organization and don’t want to specify AutoDiscover records for these on your SAN certificate, or you’re regularly adding additional domains? Then you could take a leaf out of Office 365’s book and use a simple technique known as AutoDiscover Redirection to allow you to only need your core names on your SAN certificate.

In this two part article series, we’ll cover the various methods of performing AutoDiscover redirection – IIS, a Load Balancer or TMG, along with how to simplify the DNS changes necessary internally and externally. In this part we’ll quickly example the other options available and look at how to create and configure IIS for redirection.

Our Example Exchange Organization

For the context of this article, we’ll base our problem against a simple Exchange organization, consisting of two multi-role Exchange Servers, a load balancer and a TMG server for external access to the organization:

Figure 1: Example Exchange Organization

Both internally and externally, we’ve got an assortment of clients, using both domain-joined Outlook for Windows, along with Mac Outlook and Tablet Devices. We’re using split-DNS, a method of presenting a single consistent namespace to clients regardless of whether they’ll contact an internal IP address or an external IP address to access our Exchange organization; with internal clients accessing our Load Balancer and external client first accessing our Forefront Threat Management Gateway (TMG) 2010 server which is configured as a reverse proxy within the DMZ. All clients use the following HTTPS namespace to access Exchange Client Access servers:


Additionally, we’ve configured a Client Access Array for RPC access, which is also load balanced, with the name, which is only configured in the internal side of the split DNS configuration. Therefore we’ve been able to use just two names on our SAN certificate; just and

However, recent changes mean that the number of accepted domains used within Exchange has increased and will continue to increase as time goes on, and each of these accepted domains is used for primary email addresses for a proportion of users. So to maintain AutoDiscover functionality across the board, we’ve got a number of practical options:

  1. Increase the number of subject alternative names on the certificate by replacing it or requesting the certificate vendor re-issue it, along with the addition of AutoDiscover DNS records for each domain.
  2. Add a Service Location DNS record (SRV record) for each new domain, as described in KB940881.
  3. Use AutoDiscover Redirection to provide a single point for HTTP redirect to our single HTTPS name.

In an ideal world, the first option is preferred and if the additional domain names are known or small in number it’s a straightforward solution that requires no additional configuration to work. However, if new domain names are added regularly, the organization doesn’t own those domains and just hosts another company’s email, or there’s a large number of additional domains, using this technique isn’t necessarily practical.

The second option, to use SRV records, seems at first glance the easiest– only DNS records are needed to make the AutoDiscover information to clients. There’s one major drawback to using SRV records however – although supported by Outlook, mobile clients such as Tablets and Smartphones have very little support.

This leaves us with option three, which is to use AutoDiscover Redirection. This technique allows the client to lookup the AutoDiscover DNS record as normal, and after attempting (and failing to connect) via HTTPS, the client will attempt to connect via standard HTTP.

Upon connecting via HTTP, a redirect is sent to the client advising it to attempt connection to our single AutoDiscover endpoint, instead.

Configuring the AutoDiscover redirection web site

To provide AutoDiscover Redirection, we’ll need to configure a HTTP-only web site or web listener on an IP address that’s not already providing HTTPS service. That means we can’t share the same internal or external IP address that Exchange’s HTTP namespaces such as and already use.

We’ve got a number of options available for providing these services, and the one you choose depends on your environment and what resources you’ve got available:

  1. A dedicated IIS website listening on it’s own IP address.
  2. A new Virtual Server or Virtual IP address on a Load Balancer providing a simple redirect for all traffic on port 80, listening on an IP address that isn’t already providing HTTPS services.
  3. A listener in TMG, again bound to an IP address that doesn’t provide HTTPS services, with a rule set to deny traffic and redirect it.

You might find that a combination of two of these techniques suits you; for example using a load balancer redirect internally and a TMG deny-redirect externally. In this section we’ll cover each one, starting with the IIS method in the first part of this article.

IIS Redirection

The IIS method is straightforward to configure and can be applied to either a local on-premises server, an additional IP address and web site within Exchange or even a Virtual Machine in Windows Azure.

As with all these suggested methods, the key thing we’ll need is to listen on an IP address that’s not being used for SSL traffic; otherwise AutoDiscover will attempt to connect to the SSL site first and likely fail due to certificate errors, and not continue. If it’s a fresh installation of IIS on a new server, this will be the default so further configuration isn’t necessary.

When installing IIS, we don’t need many additional components; if this will be dedicated to AutoDiscover redirection, then we won’t need components such as ASP.NET or Authentication. The key component to select during the installation of IIS is the URL Redirect module:

Figure 2: Selecting the HTTP Redirection IIS role service

After installation and configuration, we’ll then create an AutoDiscover subdirectory within the Default Web Site (or any other web site of your choosing), and then select this in the IIS Management Console, then choose HTTP Redirect:

Figure 3: Configuring HTTP Redirection for the AutoDiscover Virtual Directory

In the HTTP Redirect options, configure the following options:

  • Redirect all requests to this destination: Configure this to your AutoDiscover URL, for example
  • Select the following checkboxes:
    • Redirect all requests to exact destination (instead of relative to destination)
    • Only redirect requests to content in this directory (not subdirectories)
  • Choose the status code Found (302).

When you’re finished, choose Apply.

Finally, you might want to ensure that only requests to your correct full AutoDiscover DNS names are redirected; for example if this will be a multi-purpose web server then you might host other web sites alongside this one. We can do this by configuring the Bindings within IIS. To access this, right click the website (in our case Default Web Site) and select Edit Bindings:

Figure 4: Configuring Bindings for IIS

For each AutoDiscover DNS name, enter a separate host header entry bound to port 80:

Figure 5: Modifying the Host Header list for IIS

After configuring this optional step, requests to names other than those specified in the site bindings list will fail; so if it’s not strictly required for your environment (for example, you’ve used a dedicated IP address for the site, or even a dedicated server).


In part one we’ve looked at the underlying reasons why you might want to use AutoDiscover redirection and explored the first IIS-based technique of implementation. In part two, we’ll look at how to perform redirection using a Load Balancer and Forefront TMG, configure internal and internal DNS zones and perform basic functionality tests.

If you would like to be notified of when Steve Goodman releases the next part in this article series please sign up to our Real Time Article Update newsletter.

If you would like to read the other part in this article series please go to: Using AutoDiscover with large numbers of accepted domains (Part 2)

4 thoughts on “Using AutoDiscover with large numbers of accepted domains (Part 1)”

  1. Hello.
    I just followed this guide and it was very Helpful.
    However I found that in order for the connectivity Analyser to pass on the HTTP Redirect Method, you had to actually ensure “Redirect all requests to exact destination (instead of relative to destination)” was NOT CHECKED.

    This was due to the fact that Connectivity Analyser goes to /Autodiscover/Autodiscover.xml and if the textbox is enabled then this URL will not get redirected, instead the IIS Server returns a 404 Error.

    With this Tickbox not checked then any URL request beyond the root / will all be redirected to the correct URL.

  2. I will also note that I had to keep “Redirect all requests to exact destination (instead of relative to destination)” and “Only redirect requests to content in this directory (not subdirectories)” unchecked and simply use https://autodiscover.DOMAIN.COM as the redirect.

    In the small environments that I deal with that do not use Forefront, we were able to add another site to the Exchange server called “Autodiscover Redirect”, listed on port 90 only and add a NAT rule that answers on one of our other public IP addresses and translates 80>90 on the exchange server. No second server or second internal IP required on the Exchange server. Internal devices use the SCP or SRV methods for connection whereas external devices, phones and such can still use the redirect. Works well.

    Now if only microsoft would check FIRST rather than I know we can stop root domain lookups via the registry patch but its annoying when many website hosts offer email and still respond to this request.

    1. @Justin,

      Is there a way i could contact you? I would like to use the way you use, but i have got a couple of questions.

      Hope to hear from you soon.

      Thanks in advance.
      Kind Regards,


  3. Knut Kristan Weber

    How do you handle this problem with the TEAMS client? This does not know the redirection mechanism. Teams does only work fully functional with mailboxes in the cloud. The on premises ones don´t reach their calendar.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top