Autodiscover is essential for providing external access to you Exchange multi-tenant users.  What I would like to cover is how to properly deploy autodiscover for Exchange 2010 Multi-Tenant /hosting deployments.   To get a better understanding of autodiscover you can read White Paper: Exchange 2007 Autodiscover Service. The mechanisms between Exchange 2007 and Exchange 2010 are the same so the article will apply here. Below is a chart from that article that provides you with four different scenarios to configure Autodiscover for an Exchange Environment. 

Scenario 1: Using a certificate that supports multiple DNS names
Scenario 2: Using one single-name certificate
Scenario 3: Using two single-name certificates
Scenario 4: Using the Autodiscover service with redirection




As you can see there are multiple scenarios for connecting to the autodiscover service from the internet. So what I want to do explain how to deploy autodiscover for an Exchange Multi-tenant /hosting environment. In essence there are 2 ways to publish autodiscover for the hosted email tenants.

Autodiscover SRV Record

In this scenario you will use a single-name on the certificate and will only be implementing SRV records for autodiscover. You will only require 1 public ip address since the SRV record will point to the FQDN name on that certificate.

With this solution the Outlook 2007/2010 client will use the SRV record when trying to resolve the autodiscover record for that users smtp address. That client will directly connect to you Exchange CAS server’s public ip address. Your Tenant administrator will have to create a SRV record with the DNS service provider handling the tenant’s public DNS records.

For more information on configuring a SRV record go to the following link:
http://support.microsoft.com/kb/940881  

Note In this example, mail.contoso.com is a name for which your certificate is valid. Usually, this is the same DNS name that you use for Outlook Anywhere and for Outlook Web Access.

In this example, the Autodiscover service does the following when the client tries to contact the Autodiscover service:

1. Autodiscover posts to https://testorg1.org/Autodiscover/Autodiscover.xml. This fails.
2. Autodiscover posts to https://autodiscover.testorg1.org/Autodiscover/Autodiscover.xml. This fails.
3. Autodiscover posts to http://autodiscover.testorg1.org/Autodiscover/Autodiscover.xml This fails.
4. Autodiscover performs the following redirect check using the looking for SRV record:
5. Autodiscover uses DNS SRV lookup for _autodiscover._tcp.testorg1.com, and then "mail.contoso.com" is returned.
6. Outlook asks permission from the user to continue with Autodiscover to post to https://mail.contoso.com/autodiscover/autodiscover.xml.
7. Autodiscover's POST request is successfully posted to https://mail.contoso.com/autodiscover/autodiscover.xml.

Here is an Example of a Test-E-mail AutoConfiguration connection



Note: Not all DNS service providers have the ability to create SRV records. If the DNS provider being used is unable to create a SRV records then the autodiscover redirection
method can be used.

Autodiscover redirection method

This method permits your tenant users to connect to your Exchange using the same SSL certificate despite the domain that your tenants use. For the autodiscover feature to work with hosted e-email domains you must redirect the request to the matching name on the SSL certificate on the Exchange. The preferred method is to use create a redirect website as per the following Technet article. This will require a dedicated ip address for the autodiscover redirect and a second ip address for your Exchange server.

Configure Autodiscover Redirection for the Multi-Tenant Organization

Note: The Client Access Server and the Domain controller can’t be the same server.

At this point let me give you a bird’s eye view of what is happening with the client connection and why this is the best choice for you and your organization. In this scenario you will need the following:

1. Certificate with on the CAS server with your External URLS's that your clients will use to Connect
2. Two dedicated public ip address assigned for you Multi-Tenant Environment 
    a. Public IP address 1 = Public ip address pointing to you IIS Redirect Servers 
    b. Public IP address 2 = Public IP address pointing to your CAS servers


Step 1: The Outlook client will attempt to locate and connect to the autodiscover server based on the email domain provided by the client. In the Test-Email AutoConfiguration output you will see the following

1. Autodiscover posts to https://testorg1.org/Autodiscover/Autodiscover.xml. This fails.
2. Autodiscover posts to https://autodiscover.testorg1.org/Autodiscover/Autodiscover.xml. This fails.
3. Autodiscover posts to http://autodiscover.testorg1.org/Autodiscover/Autodiscover.xml. Connect to Redirect site

Step 2: The IIS Redirect server will then redirect the client to the Redirect URL for example:

https://mail.contoso.com/autodiscover/autodiscover.xml

Step 3: The client will then try to connect to the Autodiscover Service using the Redirected URL. The autodiscover service will require authenticating
Step 4: Outlook client will then get the Exchange Services URL provided by the autodiscover service.

Here is an Example of a Test-E-mail AutoConfiguration connection



The majority of the support calls I get in CSS are autodiscover issues when administrators try to deploy the autodiscover redirect directly on the Client Access Server. As per the TechNet article I provided states that the prerequisites is that the autodiscover redirect can’t be on the same server as the Client Access Server. This will cause Exchange Management Shell to fail when trying to connect to the Client access server and hosted tenant to fail with autodiscover.

Now let’s talk about adding redundancy to your Exchange Organization for Auto Discover request. I believe the below diagram will show you how scalable having dedicated IIS servers are and how easy it is to implement some sort of a network load balancing.




Note: I’m aware that TMG can be utilized to perform the redirection for the hosted email address and a single public ip address can be used but that configuration is out of the scope of this article.

Configure the Client Access Servers Services

After configuring the how the tenant users will connect to your Exchange environment you will need to configure the public facing client access servers to handle the autodiscover requests for the following services.

• Outlook Anywhere
• Offline address book
• Autodiscover
• Exchange Web Services
• Exchange Control Panel (ECP)
• Exchange Active Sync

The commands are listed in the following link

OUTLOOK ANYWHERE
Enable-OutlookAnywhere -Server CAS01 -ExternalHostname "mail.contoso.com" -DefaultAuthenticationMethod "Basic" -SSLOffloading:$False

OFFLINE ADDRESS BOOK (OAB)
Set-OABVirtualDirectory -identity "CAS01\OAB (Default Web Site)" -externalurl https://mail.contoso.com/OAB -RequireSSL:$true

AUTODISCOVER
Set-AutodiscoverVirtualDirectory -identity "CAS01\Autodiscover (Default Web Site)" -externalurl https://mail.contoso.com/autodiscover/autodiscover.xml

EXCHANGE WEB SERVICE (EWS)
Set-WebServicesVirtualDirectory -identity "CAS01\EWS (Default Web Site)" -externalurl https://mail.contoso.com/EWS/Exchange.asmx -BasicAuthentication:$True

EXCHANGE CONTROL PANEL (ECP)
Set-EcpVirtualDirectory -identity "CAS01\ECP (Default Web Site)" -ExternalUrl https://mail.contoso.com/ecp

Exchange Active Sync
Set-ActiveSyncVirtualDirectory -Identity "CAS01\microsoft-server-activesync" -BasicAuthEnabled:$true -ExternalURL https://mail.contoso.com/Microsoft-Server-ActiveSync

Conclusion

We’ve discussed how autodiscover clients will try to connect to the Exchange autodiscover service. Once the client does connect to the Autodiscover service you will need to configure the Exchange Server to publish the correct ExernalURL’s. If you would like to get more information about configuring DNS and IIS redirection you can read my other blog. 
 
Exchange 2010 Multi-Tenant AutoDiscover and DNS Configuration


written: Ed Bringas
reviewed: Konstantin Papadakis