Exchange 2007 Autodiscover and certificates

[The_Exchange_Team]

Update 10/4/2007: Since this post has been published, we've updated the Exchange 2007 Autodiscover Service whitepaper to include this information. Please consult the whitepaper for most up-to-date information.

In Exchange 2007, we introduce the idea of the Autodiscover service. This service allows your Outlook 2007 clients to retrieve the URLs that it needs to gain access to the new web services offered by Exchange 2007. These web services (OAB, Unified Messaging, OOF, and Availability) provide a good portion of the new functionality available to Outlook 2007. For more details about the Outlook 2007 features that light up based on the Exchange server version, please see Outlook 2007 feature matrix based on Exchange Server version.

For domain-joined clients, Outlook is able to find the Autodiscover service using a service connection point (SCP). The SCP is an Active Directory entry specific to each client access server. When Outlook 2007 is able to securely connect to the domain and read this entry from Active Directory, it can connect directly to this URL. Once connected to the Autodiscover end-point, the Autodiscover service provides the client with the URLs of the other exchange web services.

For non-domain-joined clients or clients that are not able to directly access the domain, Outlook is hard-coded to find the Autodiscover end-point by looking up either https://company.com/Autodiscover/Autodiscover.xml or https://Autodiscover.company.com/Autodiscover/Autodiscover.xml (where company.com is the portion of the user's SMTP e-mail address following the @ sign). This means that to service clients in this scenario we must provide connectivity to one of these URLs.

On the surface this should not be hard; but this connection is made over SSL and requires a valid certificate.

SSL and Certificates

The communication to the Autodiscover end-point and subsequent communications to the services all occur over SSL. This requires that we have valid certificates (signed by a trusted CA, with a Subject Name matching the URL the user is connecting to, and not expired) for the Autodiscover connection point and the services URLs. By default the services URLs are all variations of https://serversname.

When you install a Client Access server, Exchange Setup creates a self-signed certificate that meets validity tests for domain joined clients. When a client connects to a server over SSL and the server presents a self-signed certificate, the client will be prompted to verify that the certificate was issued by a trusted authority. The client must explicitly trust the issuing authority. Long-term use of this self-signed certificate is not recommended by Microsoft. Instead, it should be replaced with a commercially available Internet trusted, or a trusted internal PKI Infrastructure issued certificate as soon as possible. The problem is that we must be able to resolve Autodiscover.company.com or company.com with a trusted certificate in addition to other externally published exchange services like OWA.

Most of our smaller customers currently only have an Exchange related certificate for use with OWA. This certificate usually has a Subject Name like mail.contoso.com. This continues to work for OWA in Exchange 2007, but now we also have to handle an SSL connection to Autodiscover.contoso.com. (Microsoft recommends using Autodiscover.company.com for the Autodiscover service.) This requires us to either resolve mail.contoso.com and Autodiscover.constoso.com to separate IP addresses, or to provide both names in the same certificate.

Multiple names in one certificate

Microsoft recommends that you provide both names in the same certificate. This is done thru something called a Unified Communications certificate, also know as a Subject Alternative Name certificate. There are a number of vendors that can provide you with this type of certificate (we covered experience with one of them here). The advantage of a Unified Communications certificate is that it makes configuration of Autodiscover much easier; the down side for our customers is that currently, this type of certificate can cost up to 10 times more than any existing single name certificates that they may already own.

Configuration with this type of certificate is very easy. Here is a general outline of the process:

1. Get a Unified Communications certificate for your environment with Autodiscover.company.com and any other names you need. (e.g. mail.company.com, www.company.com , etc)
2. Apply the Certificate to the CAS server.
3. Configure your internal SCP to point to Autodiscover.company.com
4. Configure your Internal and External Service URLs to point to mail.company.com
5. Make sure that your configured URLs resolves via DNS to the expected IP address of the CAS server

Alternative methods

If you're not able to get a Unified Communications certificate, there are two other methods you can use to get the same level of functionality. Both of these methods are supported by Microsoft but are harder to implement and manage over the longer term and thus could have a higher total cost of ownership depending on your environment. Both also require that you have two external IP addresses available.

Method 1: Multiple Certificates

To work around the need for a Unified Communications certificate, you can get two certificates for your environment – your existing mail.company.com certificate and a new autodiscover.company.com certificate. As long as we can serve up the correct certificate at the correct time we're able to connect with no issues.

Doing this simply requires that we setup two virtual servers on the CAS server. One services Autodiscover.company.com on one IP address and the other services the remaining web services on mail.company.com using a different IP address.

Here's an outline of this setup process:

1. Get a certificate for mail.company.com and one for autodiscover.company.com
2. Create a new virtual server in IIS on the Clien Access server
3. Create a new Autodiscover virtual directory in the new virtual server and remove the old one
4. Assign separate IP address and certificates to each Virtual server
5. Configure your internal SCP to point to Autodiscover.company.com
6. Configure your Internal and External Service URLs to point to mail.company.com
7. Make sure that your configured URLs will resolve internally and externally via DNS to the expected IP address for each of the services

In this configuration, internal domain member clients find the SCP to make the connection to Autodiscover. External clients find Autodiscover.company.com using DNS to make the connection to Autodiscover. In both cases, the clients are referred to mail.company.com for the actual Exchange Services.

Method 2: Http Referral

This option allows us to redirect the client to another URL for Autodiscover. The major downside of this configuration is that users are prompted in Outlook to confirm this redirection. There is a check box on the prompt to not get prompted again for this URL to limit the impact for users.

To implement this configuration we still have to use two IP addresses and two virtual servers; but we only need one certificate.

Here's an outline of this setup process:

1. Create a virtual server on the Client Access server with a new IP address
2. Create a stub Autodiscover virtual directory and Autodiscover.xml file thru IIS
3. Redirect the Autodiscover.xml file to mail.company.com
4. Configure your internal SCP to point to mail.company.com
5. Configure your Internal and External Service URLs to point to mail.company.com
6. Make sure that your configured URLs will resolve via DNS to the expected IP address of the Client Access server

In this configuration, domain member clients get the SCP and connect to the Autodiscover service using that URL. External clients connect to Autodiscover.company.com over http and get a referral to mail.company.com. External Outlook clients are prompted the first time they make this connection to verify they are being redirected to a trusted URL; once that is accepted Outlook connects to the mail.company.com for Autodiscover.

Conclusion

There are multiple ways to setup Exchange 2007 to support Outlook 2007 clients and the new services URLs. You have to decide what method is best for your environment, technical skill level, and cost.

Implementation	Pros	Cons
Unified Communications certificate	Easy to implement Supports all client connections Future proof Microsoft Recommended best practice	Higher cost of the Unified Communications certificate
Multiple certificates and websites	Lower cost Both sites are secured with SSL	Requires an additional public IP address Somewhat complex to setup and maintain
Single certificate with redirect	Can be done with only your existing certificate No additional Cost	Requires an additional public IP address Non Domain joined users receive a prompt when they first connect Somewhat complex to setup

Additional resources / related reading:

• White Paper: Exchange 2007 Autodiscover Service
• Unified Communications Certificate Partners for Exchange Server and for Communications Server
• Set-ClientAccessServer cmdlet help
• How to Configure SSL Certificates to Use Multiple Client Access Server Host Names
• Deployment Considerations for the Autodiscover Service: Using Multiple Sites for Internet Access to ...
• Deployment Considerations for the Autodiscover Service: Hosted Environments and the Autodiscover Ser...
• How to Configure Exchange Services for the Autodiscover Service

• There's an excellent script at http://www.exchangeninjas.com/set-allvdirs that can assist you in setting up all of the URLs and the SCP without having to type out all of the commands. This script is provided as is and use of the script is solely at your own risk.

Matthew Byrd