Exchange 2007 Autodiscover and certificates
Published Apr 30 2007 03:18 PM 75.4K Views

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 or (where 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 or 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 This continues to work for OWA in Exchange 2007, but now we also have to handle an SSL connection to (Microsoft recommends using for the Autodiscover service.) This requires us to either resolve and 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 and any other names you need. (e.g., , etc)
  2. Apply the Certificate to the CAS server.
  3. Configure your internal SCP to point to
  4. Configure your Internal and External Service URLs to point to
  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 certificate and a new 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 on one IP address and the other services the remaining web services on using a different IP address.

Here's an outline of this setup process:

  1. Get a certificate for and one for
  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
  6. Configure your Internal and External Service URLs to point to
  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 using DNS to make the connection to Autodiscover. In both cases, the clients are referred to 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
  4. Configure your internal SCP to point to
  5. Configure your Internal and External Service URLs to point to
  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 over http and get a referral to 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 for Autodiscover.


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.

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:

Matthew Byrd

Version history
Last update:
‎Jul 01 2019 03:27 PM
Updated by: