This blog post will explain a solution to prevent the need to use a massive SAN (Subject Alternate Name) SSL certificate for all your tenant domain names. Exchange 2010 can be setup for Multi-Tennant easily by using only a much smaller and cheaper SSL certificate for both the Exchange RPC proxy endpoint and autodiscover DNS names. The RPC proxy endpoint normally stays the same no matter how many domains/tenants you are hosting for and is generally mail.domain.com.
Bit of background, in Exchange 2010, all Outlook clients will normally use MAPI/RPC or Outlook Anywhere (RPC over HTTPS) to connect to a Client Access Server. The MAPI/RPC clients (normally LAN and internal clients) connect to the non-externally resolvable CAS Array Object FQDN (aka RPC endpoint) for Mailbox access and the external/remote HTTPS based clients connect to Outlook Anywhere hostname (aka RPC proxy endpoint) for all Mailbox and Public Folder access. Generally the RPC endpoint is an internally resolvable DNS name only e.g. outlook.internal.com and the RPC proxy endpoint can be both, an internal and external resolvable DNS name e.g. mail.domain.com.
As for autodiscover, when you setup mail for the first time, or each time you re-open your mail client, autodiscover is always working automatically in the background without the user knowing. If setting up their mail for the first time, all the user has to do is enter their email address/username and password, upon clicking next, autodiscover will work its magic and grab the exchange server name, connection settings, free/busy and other important URLs needed for the client to have a successful connection experience.
For autodiscover, there is a certain order to the way a client checks this. For example, take a user which has an email address of firstname.lastname@example.org Autodiscover would take the domain name section of this email address only (domain-a.com), then run some checks for autodiscover in the following order stopping at the first one that is successful:
- Attempting to test potential Autodiscover https://domain-a.com/autodiscover/autodiscover.xml
- Attempting to test potential Autodiscover https://autodiscover.domain-a.com/autodiscover/autodiscover.xml
- Attempting to contact the Autodiscover service using the HTTP redirect method http://autodiscover.domain-a.com/autodiscover/autodiscover.xml
- Attempting to contact the Autodiscover service using the DNS SRV redirect method _autodiscover._tcp.domain-a.com
If all methods fail, then autodiscover fails. As you can see above, the first two connections are HTTPS connections and are the only true methods for autodiscover, the 4th method is used primarily for internal use. The 3rd method is an HTTP redirect, which simply redirects autodiscover requests, normally to an HTTPS URL. As HTTPS is used, there needs to be an SSL certificate with a SAN of the autodiscover URL e.g. (https://autodiscover.contoso.com). It’s not possible in a multi-tenant environment to have a single SAN certificate to cover all the many different domains which you host.
Let’s say you run a multi-tenant environment and you have the following domains:
- Choose a master domain in which to host your HTTPS autodiscover DNS name (e.g. contoso.com), use a DNS name in this domain which will be listed on your SSL certificate and will be the DNS name in which all your tenants point to for their autodiscover CNAME record. For example, use autodiscover-redirect.contoso.com
- Dedicate an IIS server used for the HTTP redirection method (Step 3 above). Setup a DNS A record (hostname) which points autodiscover-redirect.contoso.com to the IP address of this IIS server. Open port 80 inbound only as we are only using HTTP for the redirection.
- Get your tenants (for each one of your hosted Exchange domains) to create a DNS CNAME record. For example, for tenant domain-a.com, they would create a DNS CNAME record which points autodiscover.domain-a.com to autodiscover-redirect.contoso.com
- The DNS name autodiscover-redirect.contoso.com would point to a dedicated HTTP redirection IIS server
- The HTTP redirect IIS server would through a redirect (HTTP 301/302) response with a redirect URL of https://autodiscover.contoso.com/autodiscover/autodiscover.xml
The diagram below includes the steps in order:
HTTP Redirect IIS server setup
- Install IIS on a Windows server of your choice, ensure you choose HTTP Redirection
- Create a folder C:\inetpub\wwwroot\autodiscover add a blank file called autodiscover.xml
- Create a new virtual directory called ‘autodiscover’. Select this new virtual directory > click on Content View > Right click on autodiscover.xml > Select ‘Switch to Features View’
- Double click on HTTP Redirect
- Change the HTTP Redirect settings to reflect the screenshot below.
- Right click on Default Web Site > click on Edit Bindings
- Add in all your Tenant domains as HTTP bindings.
Outlook clients might get a pop up like this, Allow this website to configure <alias>@<domain> server settings?. In this message, click to select the Don’t ask me about this website again check box, and then click Allow.
I found that you need to allow “Directory Browsing” on the site to make it properly work. Otherwise Exchange Connectivity Analyzer returns an error. Same for the outlook as well.