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

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


In the first part of this article, we looked at why AutoDiscover Redirection can be useful if you’ve got a growing number of domains, or just a large number of domains and want to maintain great client compatibility for AutoDiscover without having a large number of domain names on your SAN certificate. We also looked at the first method to configure this server-side, by using an IIS website with HTTP redirection configured.

In the final part of this series, we’ll look at the other options available for configuring AutoDiscover redirection, by using a Load Balancer and Forefront TMG. We’ll then look at how to configure the external DNS records, along with internal PinPoint DNS zones that avoid a full split-DNS implementation.

Configuring the AutoDiscover redirection web site continued…

Load Balancer Redirection

Our second method of AutoDiscover Redirection is ideal if you’ve already got a Load Balancer in place, as on most load balancers the configuration required is minimal. For this example, we’ll be using a KEMP load balancer to configure a new Virtual IP address and service bound to port 80 only, and configure it to perform the HTTP redirect.

First, we’ll log in to the KEMP Configuration web interface, then navigate to Virtual Services and choose Add New. Next, we’ll add a new IP address and set the port to listen to, to port 80:

Figure 6: Creating a new Virtual Service for Redirection

Next, after creating the new virtual service, we’ll modify it’s properties to add the AutoDiscover redirect, as shown below:

Figure 7: Configuring Redirection options

The settings that need to be configured are located under the Not Available Redirect Handling section. Similar to the IIS configuration, we’ll configure the settings as follows:

  • Error code: 302 Found
  • Redirect URL: Your AutoDiscover URL, for example

After completing these settings, the Load Balancer configuration is complete – we don’t need to add any servers to perform load balancing for, as this redirect is handled within the Load Balancer itself.

We don’t have the fine-grained control available we had with IIS; however it’s a great compromise that can make use of existing hardware already in place.

Forefront Threat Management Gateway Redirection

Our final method of redirection is particularly suitable for clients accessing the Exchange organization via an existing Forefront TMG server or array.

To use this method of redirection, the most important thing we need is an external IP address bound to the TMG server that currently doesn’t listen on HTTPS, port 443. Examples of common scenarios where you’ll find an available address include where a different IP address listens for SMTP traffic, or if you publish HTTP-only services already via TMG.

After assigning an additional IP address to the server (if required), we’ll then need to create a new Listener along with a new Web Publishing Rule, by choosing Publish Web Sites:

Figure 8: Creating a new Web Publishing Rule in TMG

After the Web Publishing Rule Wizard begins, we’ll configure a rule with the following options:

  • Deny Traffic
  • Publish (or rather, Deny) a path of /AutoDiscover/AutoDiscover.xml
  • Accept requests for either:
    • Any Domain Name
    • A specific domain name such as that we’ll be redirecting. We’d then add the additional AutoDiscover domains later if required.

  • Do not require SSL secured connections with clients.
  • As part of the wizard, we can also create a new listener, with options as below:

    • Web Listener IP address: An IP address bound to the TMG server, that is not currently listening on port 443.
    • No authentication configured for the listener.

    After configuring the rule, we’ll then edit the properties to configure the redirection, which can be found on the Action tab:

    Figure 9: Configuring Redirection within the TMG rule

    As with the previous methods, we’ll add in the HTTPS address of our central AutoDiscover instance, for example

    If you’ve chosen to specify the AutoDiscover domains, you’ll need to add these on the Public Name tab, which in a similar fashion to the IIS Bindings configured earlier for IIS, specify the AutoDiscover names we’ll redirect for additional domains.

    Finally, to complete the TMG changes, we’ll choose OK to confirm the new rule changes, then select the Apply button to save and apply the changes to our TMG server or array:

    Figure 10: Completing configuration within TMG and applying the new rule

    DNS Configuration

    The final part of the configuration required is to configure appropriate DNS entries to make the configuration work, both externally and internally as required.

    If the IP address of the IIS, Load Balancer or TMG you are using for redirection is the same both externally and internally, then you’ll probably need to only edit the external DNS zone for each of your additional accepted domains. If you use different IP addresses for AutoDiscover redirection is different internally and externally, then you’ll also need to create DNS records internally so that clients connected to your network can find the internal IP address without issue.

    External DNS Records

    The external DNS records are typically the easiest to configure as you’ll either manage these via a self-service portal, or use an external company to manage them.

    For each domain, we’ll need to add a new record named autodiscover. In our example, we’ll create an A record, which is a pointer from the name to the external IP address of our AutoDiscover redirector with the following details:



    IP Address

    Table 1

    In our DNS control panel, you’ll see how this appears below:

    Figure 11: Example external DNS control panel configuration

    We’ll then repeat that process for each domain we’re performing AutoDiscover Redirection for.

    Internal DNS Records

    For the internal DNS records, where required, we have two options available:

    Split DNS is the method of creating a copy of the external DNS zone for an entire domain, replacing external IP addresses with corresponding internal IP addresses. A PinPoint Zone avoids this complexity by creating a zone just for the fully qualified domain name of the single entry that differs from the external DNS zone. As you can imagine, managing split DNS for a large number of domains is complex, therefore we’ll use PinPoint Zones.

    To configure a PinPoint zone, create a new zone on your internal DNS server with the full AutoDiscover name, e.g.

    Figure 12: Creating a new PinPoint zone within Windows DNS Server

    After creating the zone, add a single A record, leaving the Name field blank, with the internal IP address used for AutoDiscover redirection:

    Figure 13: Configuring the internal IP address for AutoDiscover redirection

    Alternatively, if you’ve got the DNSCMD utility installed, you can create an AD-integrated zone using a command similar to below, replacing the DNS Server IP, Domain name and Internal AutoDiscover Redirection IP as appropriate:

    dnscmd <DNS Server IP> /zoneadd autodiscover.<Domain> /dsprimary
    dnscmd <DNS Server IP> /recordadd autodiscover.<Domain> @ A < AutoDiscover Redirection IP>

    Testing the configuration

    To test the configuration, we can use the Microsoft Remote Connectivity Analyser available at this URL.

    We’ll then attempt to confirm functionality using a test user on each domain that uses AutoDiscover Redirection. You should see successful results similar to the output below:

    Figure 14: Remote Connectivity Analyser output showing sucessfull AutoDiscover Redirection


    In this article we’ve explored a straightforward technique to allow for reliable AutoDiscover functionality across a large or growing number of accepted domains within your organization that avoids increasing the number of names on internal certificates. While this technique may not be appropriate for every organization, it’s certainly useful if you need to be able to react quickly to organization changes without losing client functionality.

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

    Steve Goodman

    Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

    Published by
    Steve Goodman

    Recent Posts

    Hardware RAID vs. software RAID: Pros and cons for each

    RAID is a technique to virtualize independent disks into arrays for improved performance. Should you…

    3 days ago

    After the plague: What IT will look like in a post-COVID-19 world

    COVID-19 has changed everything, but once it disappears, we will not go back to how…

    3 days ago

    Solved: Outlook defaults to Microsoft 365 version with Exchange server

    An Exchange server with a hybrid connection to Microsoft 365 is usually pretty seamless —…

    4 days ago

    How chatbots are changing the way teams communicate internally

    Chatots are primarily thought of as consumer-facing solutions. They bring life to customer interactions by…

    4 days ago

    Hakbit ransomware campaign targeting specific European countries

    The newly uncovered Hakbit ransomware campaign spread via spear-phishing emails may indicate a shift in…

    4 days ago

    Credential stuffing: Everything you need to know to avoid being a victim

    Credential stuffing is yet another weapon being used by cybercriminals. Here’s what credential stuffing is…

    5 days ago