Exchange 2007 Autodiscover and certificates

Published Apr 30 2007 03:18 PM 71.9K 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

Not applicable
What about a single wildcard certificate on all servers?
Not applicable

wildcard certificates aren't supported by windows mobile 2005 devices, so if you install such a certificate these devices aren't able to sync anymore. Furthermore, we have also Nokia's E70 and those ones don't like certificates with multiple names. Sync fails when it encounters such a certificate. So all in all, autodiscover is currently a major issue for using externally.

Not applicable

when using outlook 2007 on a non domain joined client, you get prompted for credentials everytime you start outlook (it prompts for, although you have a checkbox 'save password'  in this dialog, this doesn't work at all in outlook 2007. It prompts for the username and password everytime. Any thoughts on this ?

Not applicable
Not a great solution but you can hack the Windows Mobile registry to enable wildcard certificates -
Not applicable

As our entire client computers that need to access OWA and so on are domain members, we use self signed or certificates issued by Windows Server 2003 CA as SSL certificates for OWA and Autodiscover.

Can the Windows Server 2003 CA issue a Unified Communications Certificate or are there tools available (like selfssl.exe) that can generate a Unified Communications Certificate?
Not applicable
So you have a seperate virtual server on the CAS server for and a seperate one for  If your internal AD domain is domain.local, your Outlook client now looks for a certificate of the CAS server's name.  How do you prevent the client from asking for a cert for the CAS server and not just use and  I have run in to this scenario and created a third virtual server using the primary address of the server, then assigning a local server name certificate.
Not applicable

Sounds like the problem we encountered.  Basically the exact problem described in the post with autodiscover also exists with the CAS server's name (eg. cas.domain.local).  We have remote clients wanting to connect solely via Outlook Anywhere.  If the certificate does not contain cas.domain.local then the client will refuse to connect unless it has first connected to the server via a local, non-HTTPS connection (for some reason Outlook won't set up the profile).

The problem is that I don't believe any CA will give you a certificate for cas.domain.local, since you don't "own" this domain.  So none of the solutions posed above will work.  I suppose you have to self-sign and clients have to import this certificate - but unless you have a secure channel already established to transport the self-signed certificate then  there is no security in this option.  Not to mention the hassle.

I would be interested in Microsoft's response to this problem because AFAIK they consider it a good idea to use a domain like domain.local.
Not applicable

I ran in to this problem back in January and really couldn't find a decent documented solution.  So I decided to create a third web site on the CAS server, with the primary IP address of the server and a self-signed certificate.  This eliminated our certificate

errors, but I'm not completely comfortable with the solution as it doesn't seem like the most ideal configuration.  This is not ideal because it breaks common functionality like viewing public folders in ESM or even using PFDavAdmin break.  I created a blog

about this a while back, check it out.

Not applicable
They key to getting everything to work without having to connect to any additional virtual directories or to have any problems with unexpected name spaces is to get everything in AD configured properly.

For internal clients they are going to get their connection point exclusively from the Service Connection Point.  So you need to set that value to  You need to make sure that you can resolve to the internal IP of the CAS server internally ... or your router allows you to loop back in using the public IP. ( this is set using the Set-ClientAccessServer )

Then you need to tell ALL of the virtual directories on the CAS server what their Internal URLs are so that Autodiscover can hand the correct URLs out to the 2007 client.  You set those directories on a PER CAS server basis using the set-XVirtualDirectory cmdlet.

For External Client they are going to Exclusively connect to or  So again here the key is to just make sure that the Autodiscover service is handing out the correct URLs.  You do this again with the set-XVirtualDirectory cmdlet.

If you are seeing that your outlook 2007 client is trying to connect to an unexpected URL (thus you are getting prompted) It is easy to determine where Outlook is getting that URL from.

1) Press and hold the ctrl key then right click on the Outlook icon in the task tray
2) Select the option "Test E-Mail Autoconfiguration"
3) Uncheck the two Guessmart options
4) Make sure the correct email address and password are entered
5) Hit Test

The Results tab will contain the information that the Autodiscover service returned to the client.  The "Exchange RPC" section is for internal clients ... the "Exchange HTTP" section is for external clients.

The Log Tab will show you how that information was obtained; if it was obtained thru the URL (and what URL) or thru the SCP.

So just to recap using either one of these method if you are getting a prompt or being requested to connect to "cas.domain.local" then most likely we are getting a XML file back from Autodiscover indicating we need to connect to that URL; or the service connection point for the CAS server is still set to "cas.domain.local".

Hopefully John and David this has cleared things up.

Not applicable
Hi Dominik,

The Windows CA can issue Subject Alternative Name certificates.  These are esentially Unified Communication Certificates just without the fancy marketing name ... :).

To get a Windows CA to issue a SAN certificate you would just need to setup the request for multiple names using the new-exchangecertificate cmdlet.

The process would be very similar to:

Not applicable
Hi Matt,

When I run "Get-ClientAccessServer" it returns our local CAS server internal netbios name.  Are you saying that we need to change that from the local server name to, to resolve this problem?  I thought, based upon all documentation I've read, that this had to be set to the local internal name of the server.  

Aside from my previous paragraph, I have previously set all internal and external names to the appropriate external names(I.E.  We have DNS both internal and external responding to the appropriate IP addresses, so this shouldn't be the problem.  Somehow the CAS server returns its internal FQDN versus the internal/external name we assigned to all services.

Not applicable
Hi David,

Running " get-clientaccessserver | fl "  You will see in the output the current value that your SCP is set too:

AutoDiscoverServiceInternalUri :

You can change this value using "set-clientaccessserver -AutoDiscoverServiceInternalUri ""


I would strongly recommend you take a look at the script located here: Event if you don't run the script in your environment it contains all of the command and vdirs that you need to set.


Not applicable
My experience has been that with the new UCC certs the CAs dont have an issue setting one of your Subject Alternative Names as your internal only domain name.  As long as the CN and info that you are registering with the cert is correct and they cannot resolve your internal domain you should be OK.
Not applicable
Thanks Matthew, David and others.

Matthew: I have realised that the problem I reported above appears to occur exclusively on Outlook 2003.  Outlook 2007 appears to work fine without the server's real name in the certificate.  It is not related to autodiscovery.  I also tried the exchangeninja's

script changes without success.

To use the setup as an example: Set up an Exchange server, rottweiler.exch2007demo.loc.  Set up Outlook Anywhere in the usual fashion, with external name  Sit outside your network and try setting up a profile

with Outlook utilising Outlook Anywhere in the usual fashion, as described here:  If your server uses a cert which contains the name but not rottweiler.exch2007demo.loc you will find that with Outlook 2007 it works, but that

Outlook 2003 will complain that you are not online and refuse to connect.  Use a cert with both the above mentioned names in it and both versions of Outlook will work OK.  That's why if you check out the cert they are using on you will

see in contains rottweiler.exch2007demo.loc as an alternative name (along with others like autodiscover).

The fact that this internal server name is required seems to be poor design to me.

David: Thanks for your link.  I've seen a few sites going along these lines now.  I messed around and concluded I'll just buy cert with multiple names - you can get them for $200/year and no doubt increasing competition in future will drive the price down further.

 Thanks Christopher for your comment on this - obviously managed to get one!

Not applicable
I am missing a method using ISA 2006. You can create a single listener with two IP adressess, and on each IP address a particular certificate is mapped (e.g. on the first IP address and on the second IP address). Then you should not omit entering in the Outlook Anywhere rule (Public Name tab).
Not applicable

This is a very good topic and a lot is covered - however as a newbie, I could use a little spoon feeding of some of the topics.   If anyone would care to assist it would be GREATLY appreciated.   I know it may be difficult for experts to understand why somethings could use a little more info but this 2007 environment is totally alien to me.

Thanks -

Topics I could use some spoon feeding - a little less how they work and a little more how to get them to work would be great - e.g. go to IIS, click on default web site...

1. Create a new Autodiscover virtual directory in the new virtual server and remove the old one.  - I can figure out how to create one but is that all there is just create one?   No files, security anything else I need to know?

2.  Configure your internal SCP to point to  - frankly I haven't the slightest idea how to do this

3 Configure your Internal and External Service URLs to point to  - in what part of where?  IIS? - exchange mC?

One last question - I'd like my exchange server to serve both mail going to and - some users will only use as an e-mail address and others will only use - seems like autodiscover wants to use one environment and one cert - this was simple in exchange 2003 - not having any success trying to figure out all the steps in exchange 2007.

Not applicable
Is it possible to just run the server autodiscover without a cert requirement?
Not applicable

I tried the wiki script - now for some reason the log from my outlook client shows that it is trying to go to -

Autodiscover to starting

It needs to go to - not sure how to fix it to what it was.

Not applicable


I just now realized that some of the links were moved from their position in the document to the bottom of the document.  Here are the links to the Exchange 2007 Help file information for each of the sections:

Multiple names in one certificate

How to Configure SSL Certificates to Use Multiple Client Access Server Host Names

Method 1: Multiple Certificates

Deployment Considerations for the Autodiscover Service :  Using Multiple Sites for Internet Access to the Autodiscover Service

Method 2: Http Referral

Deployment Considerations for the Autodiscover Service :  Hosted Environments and the Autodiscover Service

Also I will be posting more direct steps per your request at the following link:


In response to your question about Exchange and Certs ... You have to run autodiscover with Certificates.  We will not allow it to work otherwise.  This is to help ensure the security of your users and your data.


Is this an internal or External client?  Internal clients get their connection point from the SCP and in the log your should see:

Attempting URL found through SCP

The Key there is:

Found through SCP

If it is an external client then it will ONLY connect to autodiscover on or ... outlook is Hard Coded to connect using only thoses domains.

Hope this has addressed everyones questions


Not applicable
I run into this problem after applying a cert from godaddy to my CAS box. I run the cmdlet below and all is well from what I can tell. Both OWA and Outlook 2007 clients connect with no certificate errors.

     if you are using a commercial certificate from Verisign or  Godaddy  to work around it you can use the following CMDLET to update the SCP inside of the AD: Set-WebServicesVirtualDirectory -Identity "EWS*" -ExternalUrl "Https://"

-InternalUrl "Https://".-         the previous command will update all of the services (OAB,Free/Busy,OOF,GAL) address, but if you are interested in updating the Autodiscovery SCP only you can use the following CMDLET:

Set-ClientAccessServer -Identity CASserver1 -AutoDiscoverServiceInternalUri this will allow you to use a commercial certificate along with your secure deployment of exchange 2007 and avoid the common errors most of the customers complained from when using AutoDiscovery service

read more here

Not applicable
All set.

Not applicable
In an environment where you have multiple CAS servers in a site how should you approach installing a certificate.  Can you just have one regular 3rd party cert for the CAS server that is accessed from the internet for OWA.  Not sure how you would force clients to query a certain CAS in a site for outlook 2007 clients for FB.  Can you purchase SAN certificates for more then one server and still have overlapping domains.  
Not applicable
Few comments about "autodiscover" to Exchange Architects and bright minds that did think that:
- autodiscover has a clear higher TCO than previous Exchange versions to publish Exchange Services to the Internet
- autodiscover architecture make Outlook 2003 a best-choice over Outlook 2007 for Outlook Anywhere (and Outlook 2007 is no more in Exchange CAL)
- it's simply unmanageable for a medium company hosting many internet mail domains inside the organization (every domain added requires certificate re-submission & web service reconfiguration)
- it's unbelievable that not implementing autodiscovery method (complex, costly, difficult to manage) make simple, robust & consolidated features of Outlook/Exchange like OOF, Calendaring & Meeting scheduling, ... no more usable from outside the company (eg: Outlook anywhere)
- it's unbelievable that an "autoconfiguration" method like autodiscover in my opinion is and should be, it's required even if Outlook client is already configured. The result is that without autodiscover in place outlook (anywhere) is working at 50%.
- it's unbelievable that "out-of-the-box" e2k7/o2k7 do LESS for the users (outside company) than e2k3/o2k3

Information Technology is always getting more complex, and thinking in a complex way doesn't help to get things working. I doesn't understand why my outlook (anywhere) is able to send and receive mail, but not to synchronize GAL, place a meeting, setting Out-of-office, configuring Voice Mail...

If I'm able to talk to a CAS to access Mailbox, AND Active Directory (for authentication & c.) why shouldn't I get FROM THAT WAY even configuration info for which Autodiscover is required?
Why CAS doesn't do for me the initial simple autodiscovery query getting the XML (in other words proxying autodiscover like it proxies other access request)? It seems so simple to me...someone could answer me?

PS: It seems to me that you (Microsoft people) design a product with no respects for your users, and without historical memory of your products, often reinventing the I wrong?
Not applicable
Who are some service providers that offer Subject Alternative Name certficiates?  Thawte won't do it.  The 3 that I'm aware of, Geotrust (which only offers 4 names), is 599/year, Entrust (10 names) is 599/year, and Verisign's Managed PKI services (unknown price).  

Everything seems extremely costly.  

From what I gather I need the following names:

3) autodiscover.domain.local
4) cas.domain.local
5) CASnetbiosname??

Not applicable
Digicert has one for $300 with a 30-day satisfaction.  I don't work for them :)
Not applicable
Right On Alessandro Appiani! AutoDiscover is somebody's crack dream. I have been trying to get it to work correctly on my company's domain before I have to set it up for a customer. I have just gotten all of my Exchange customers on board with using an SSL period. I have 1 or 2 that won't spend the money. Many of my Exchange customers run Small Business Server and Exchange 2003. I can see me trying to explain this dual name SSL to mine and Microsoft's customers. I have never seen so many geeks blogging on one topic. Nobody is getting this one! I did not get why it wasn't working until I got into this blog. Now that I get why it is not working, I have got to say this is the same logic that said, "Let's hide file save as from them!" in Office 2007. Anybody developing these products with any business acumen?

Whether you are new with Exchange like "Jim - Newbie" or have set up and maintained many Exchange Servers, her are my thoughts:

- Many great new features in Exchange 2007
- Most companies I work with don't have separate Exchange Administrators. Breaking user management away from AD & going back to the 5.5 model is more complicated and difficult for me to explain to customers who wear Sys Admin caps when I am not on site.
- Who decided we all were command line freaks and no longer wanted effective GUI management interfaces?
- Like one blogger said, "Stop telling us how way cool Exchange 2007 is" and give us some outstanding straight forward "how to's" on the Knowledge Base.
- Fix this abortion called Autodiscover in Service Pack 2.
Version history
Last update:
‎Jul 01 2019 03:27 PM
Updated by: