This white paper provides detailed information about the Microsoft Exchange Autodiscover service. It also includes information about how to configure this service in various deployment scenarios. Use the conceptual information and procedures in this white paper to help you deploy the Autodiscover service.

The Autodiscover service makes it easier to configure and manage Outlook 2007. Earlier versions of Microsoft Exchange and Outlook required that you configure all user profiles manually to access Exchange. Extra work was required to manage these profiles if changes occurred to the messaging environment. Otherwise, the Outlook clients could stop functioning correctly.

The Autodiscover service uses a user's e-mail address and domain account to automatically configure the user's profile. By using the e-mail address and domain account, the Autodiscover service can provide the following information to the client:

• The user’s display name
  
• Separate connection settings for internal and external connectivity
  
• The location of the user’s Mailbox server
  
• The URLs for various Outlook features that govern such functionality as Availability (free/busy) information, the Out of Office Assistant, Unified Messaging, and the Web-based offline address book
  
• Outlook Anywhere server settings
  

To start to communicate with the Exchange messaging infrastructure, Outlook 2007 sends an HTTP POST command to the Autodiscover service. This command includes XML data that requests the connection settings and URLs for the Exchange services that are associated with the Outlook provider. This information is created and stored in Active Directory both during Exchange 2007 Setup and when you configure your Exchange features by using the Exchange Management Shell or the Exchange Management Console.

The Autodiscover Service and the Outlook Provider

The Autodiscover service sends the request to the Outlook provider, which then uses the Services Discovery API to retrieve the values in Active Directory. After the values have been returned, the data is passed to the Autodiscover service, which returns the information to the client in an HTTP response. This HTTP response contains the relevant values in XML.

There are three Outlook provider settings, as follows:

• The WEB setting contains the best URL for Outlook Web Access for the user to use. This setting is not required for Exchange 2007.
  
• The EXCH setting references the Exchange RPC protocol that is used internally. This setting includes port settings and the internal URLs for the Exchange services that you have enabled.
  
• The EXPR setting references the Exchange HTTP protocol that is used by Outlook Anywhere. This setting includes the external URLs for the Exchange services that you have enabled, which are used by clients that access Exchange from the Internet.
  

How the Autodiscover Service Provides Settings to Outlook 2007

The connection settings that the Outlook client uses are translated into MAPI properties. These properties are stored in the user's profile located in the registry on their local computer. However, the URLs for the available Exchange services are cached in the memory of the local computer.

Outlook 2007 automatically connects to the Autodiscover service under the following conditions:

• Every time that the application starts
  
• At intervals on a background thread
  
• Any time that the client's connection to an Exchange server fails
  

There are two parts, which are known as layers, of Outlook 2007 that use the Autodiscover service: the Outlook layer and the MAPI layer. The Outlook layer begins operating when you open Outlook 2007 to retrieve the user profile settings. These settings are refreshed every time that the Time to Live (TTL) period is specified. The setting for the Time to Live is 60 minutes or whenever an error occurs when Outlook 2007 tries to contact an Exchange 2007 server.

If Outlook does not connect to the Autodiscover service, the Outlook layer will reconnect every 5 minutes because the URLs for the available Exchange services are cached in memory on the local computer. If the client cannot connect to the Autodiscover service, the user cannot use the available Exchange services until the specified URLs are obtained.

By contrast, the MAPI layer connects to the Autodiscover service when there are errors connecting to the Exchange server by using the MAPI protocol. For example, this occurs when the user is using a low-bandwidth network connection or when the user tries to open their mailbox after a mailbox move. The first failure detected by the MAPI layer results in an initial Autodiscover service request. Depending on the type of failure, this request may result in changes to the user's profile. This initial Autodiscover service request is known as the free Autodiscover service request. If no other failures occur after the first failure, the MAPI layer will perform an Autodiscover service request every 6 hours to update the user's profile settings. Additionally, the MAPI layer also connects to the Autodiscover service if the user creates a new Outlook profile.

Forcing Outlook 2007 to Update the User Profile Settings

Under most circumstances, Outlook 2007 and the Autodiscover service are intended to provide a seamless experience for users. However, there are instances when it may appear that the Autodiscover service is not functioning correctly. The following scenario is an example of when this might occur:

After you deploy Exchange Server 2007 in the messaging environment of the Contoso company, the IT administrator for Contoso upgrades the users to Outlook 2007. The administrator would also like to deploy Outlook Anywhere so that users can access their Exchange information and services from the Internet. To do this, the administrator configures and enables Outlook Anywhere for Exchange 2007. After enabling Outlook Anywhere, the administrator checks the Outlook profile settings on an Outlook 2007 client and notices that the RPC over HTTPS settings were not received by the client. The administrator then runs the test for the Autodiscover service by using the Test E-Mail AutoConfiguration feature in Outlook 2007. The administrator is surprised to see that the Autodiscover service did not create the connection settings in the Outlook profile.

This scenario occurs when the user's Outlook client runs continually. In this example, the Outlook 2007 client successfully connects to the Mailbox server by using TCP/IP. Because no failure was detected, the Autodiscover service does not try to re-create the Outlook profile settings. Outlook uses the initial Autodiscover "free" request that is performed at six-hour intervals.

Because this scenario is possible, Outlook provides a method to force this update to occur. The following procedure describes how to force Outlook to update the user profile settings by using the Autodiscover service.

To manually force the Autodiscover service to update the user's profile settings

1. Open Outlook 2007.

2. In Outlook 2007, click Tools, and then click Account Settings.

3. On the E-mail Accounts page, on the E-mail tab, click Repair.

4. Follow the steps in the Repair E-mail Account wizard.

Return to top

When you install the Client Access server role, Exchange 2007 setup determines whether an SSL certificate has already been installed on the server. If an SSL certificate is not found, Exchange setup will create a self-signed SSL certificate in Internet Information Services (IIS) that meets validity tests for domain-connected clients. The self-signed certificate has a common name that maps to the NetBIOS name of the server. The self-signed certificate also includes the FQDN of the server as an additional DNS name that is stored in the certificate’s Subject Alternative Name field. This enables domain-connected clients to successfully connect to the Autodiscover service without receiving any certificate warnings if the certificate has not expired and the FQDN of the server you are connecting to is stored in the Subject Alternative Name of the certificate. Although the client is unable to validate the self-signed certificate up to the trusted root, this is the one validity test that is allowed when domain-connected clients connect to the Autodiscover service by using the self-signed certificate.

To summarize, the self-signed certificate allows domain-connected Outlook 2007 clients to work immediately after Exchange setup as completed and without any security warnings. However, we do not recommend long-term use of this self-signed certificate because it was primarily intended to ease the urgency of obtaining a correct certificate so that Outlook 2007 clients can immediately start to use Exchange 2007 features. However, Outlook Anywhere clients and mobile device users who connect by using Exchange ActiveSync will be unable to connect when referencing a certificate whose common name is the NetBIOS name of the server. Instead, the common name of the certificate must be in the form of a FQDN that maps to the external DNS namespace those clients will be connecting to, for example, mail.contoso.com.

Because Outlook 2007 clients connect to the Autodiscover service by using SSL, this introduces a new challenge. Outlook 2007 clients must be able to resolve the DNS namespace, for example, autodiscover.contoso.com, in addition to other externally published Exchange features such as Outlook Web Access or Exchange ActiveSync which might reference a different DNS namespace, such as mail.contoso.com. This can all be done by using an SSL certificate that supports Subject Alternative Names. These types of certificates are known as Unified Communications certificates.

Although using a certificate that supports Subject Alternative Names is a recommended solution, there are other solutions you can implement if you cannot deploy a certificate that supports Subject Alternative Names. These scenarios and solutions are discussed in the following sections, starting with the implementation of a Unified Communications certificate.

We recommend that you provide all the necessary DNS names in the same certificate by using a Unified Communications certificate that supports the Subject Alternative Name field. Using a Unified Communications certificate reduces the complexity of configuring and managing the Autodiscover service and Exchange services URLs. However, using a Unified Communications certificate may increase the cost, as this kind of certificate can be more expensive than the single name certificates which you already may own.

• ISA Server team blog article: Certificates with Multiple SAN Entries May Break ISA Server Web Publishing
  

Obtaining a Unified Communications Certificate

A list of third-party certification authorities (CAs) that currently support Subject Alternative Names is documented in Microsoft Knowledge Base article 929395, Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007.

Or, you could install Windows Certificate Services and create and install your own SSL certificate that includes multiple DNS names. Although this may be the least expensive approach at first, you will incur the additional administrative overhead of distributing and maintaining the root certificates to your users so that clients that are not domain-connected can follow the certificate chain up to the trusted root certificate store. Additionally, your Outlook Anywhere users must manually install the root certificate on their remote workstations and Exchange ActiveSync users must manually install the root certificate on their mobile devices.

Return to top

Although certificates that support Subject Alternative Names are highly recommended, they are not required. Another recommended solution is to use one single-name certificate installed on the Default Web Site.

This warning message, and how to correct it, is documented in Microsoft Knowledge Base article 940726, Warning message when you start Outlook 2007 and then connect to a mailbox that is hosted on an Exchange 2007-based server: "The name of the security certificate is invalid or does not match the name of the site".

If your DNS provider supports SRV records, this solution is the simplest and least expensive way to deploy Outlook Anywhere in hosted and non-hosted Exchange 2007 environments. For more information, see Microsoft Knowledge Base article 940881, A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service, and Microsoft Knowledge Base article 939184, Description of the update rollup for Outlook 2007: June 27, 2007.

Return to top

Sometimes you cannot use a certificate that supports multiple DNS names. For example, this may occur if you want to replace the self-signed certificate with a preexisting certificate exported from an earlier version of Exchange, or if you have already purchased a new single-name certificate before fully understanding the certificate requirements for the Autodiscover service for Exchange 2007. If this describes your situation, there are alternative solutions you can implement to address these types of scenarios which will ultimately give you the same level of functionality. One option is to obtain a second certificate and install it on a second Web site which will be specifically used for Autodiscover.

In this scenario, one certificate is issued with the common name that is used as the entry point for clients that connect from the Internet, for example, mail.contoso.com. The second certificate has a common name that references the FQDN for the Autodiscover service, for example autodiscover.contoso.com. This option requires two separate Web sites and public IP addresses. The Default Web Site will host your primary Exchange features and services such as Outlook Web Access and Exchange ActiveSync while the second Web site will be used to host the Autodiscover service.

Return to top

Until the release of the update rollup for Outlook 2007, described in Microsoft Knowledge Base article 939184 and referred to in Scenario 2: Using One Single-Name Certificate earlier in this white paper, this kind of deployment scenario was, and may still be, the ideal solution to use in situations such as a hosted Exchange 2007 environment. Using the Autodiscover service with redirection may be the ideal solution because some DNS providers do not support SRV records. However, this kind of deployment can also be used for organizations that are not hosting multiple domains. With this option, you install a single-name certificate on the Default Web Site and create another Web site that contains no certificate. Domain-connected clients continue to locate the Autodiscover service by using the SCP object and will not receive any security warnings as long as the URL for connecting to the Autodiscover service which is stored in the SCP object has been changed to refer to the FQDN of the certificate installed on the Default Web Site. Clients that connect from the Internet will at first be unable to find Autodiscover by using DNS, as described in How the Autodiscover Service Works earlier in this white paper. However, before failing to connect to the Autodiscover service, Outlook will try an additional method to connect to the Autodiscover URL by using HTTP (instead of HTTPS) and connect to the Autodiscover Web site and then be redirected to the Autodiscover service hosted under the Default Web Site. When these Internet-based Outlook clients connect to this redirection site, they will see a dismissible warning messaging asking them to verify that they are being redirected to a trusted URL. In this case, you must advise your users to accept this warning message and allow Outlook to connect to this trusted URL.

Return to top

All the previous scenarios are supported by Microsoft but vary in complexity. The effort involved in implementing and managing each solution over the long term may result in increased the total cost of ownership depending on your environment. The following table illustrates the pros and cons associated with each solution.

Scenario	Pros	Cons
Single certificate that supports multiple DNS names	Easy to implement Supports all client connections Microsoft- recommended best practice	Higher cost certificate type (Unified Communications certificate) Requires additional configuration if used together with either ISA Server 2004 or ISA Server 2006
One single-name certificate and Web site	Easy to implement Supports all client connections Least expensive Ideal for hosters if DNS provider supports SRV records	Requires modification of SCP object and Exchange services URLs Requires Outlook 2007 update rollup, described in Microsoft Knowledge Base article 939184 Description of the update rollup for Outlook 2007: June 27, 2007, to support Autodiscover SRV record if also deploying Outlook Anywhere DNS provider may not support Autodiscover SRV record
Two single-name certificates and Web sites	Lower cost than using Unified Communications certificate Both sites are secured with SSL	Requires an additional public IP address Complex to set up and maintain
Single certificate with Redirect	Can be done by using your existing certificate No additional cost Ideal for hosters if DNS provider does not support SRV records	Requires an additional public IP address Somewhat complex to set up
Single certificate generated by using Windows Certificate Services	Smallest up-front costs Supports all client connections	Highest total cost of ownership for administrators and end users

For more information about this security warning, see Microsoft Knowledge Base article 940726, Warning message when you start Outlook 2007 and then connect to a mailbox that is hosted on an Exchange 2007-based server: "The name of the security certificate is invalid or does not match the name of the site".

Return to top

This section discusses how to configure the Autodiscover service that uses either a Unified Communications certificate or a certificate created internally by using Windows Certificate Services. We recommend that you use a Unified Communications certificate that supports Subject Alternative Names.

The list of third-party certification authorities (CAs) that currently support Subject Alternative Names is documented in Microsoft Knowledge Base article 929395, Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007.

The following procedures describe how to create a certificate request for submission to a third-party CA and when to use your own internal PKI by using Windows Certificate Services.

Step 1: Create the Certificate Request

To create a certificate request for a third-party certification authority

• Create the certificate request for submission to your third-party certification authority (CA). On the Client Access server, open Exchange Management Shell and enter the following:

  New-ExchangeCertificate -GenerateRequest -DomainName mail.contoso.com, autodiscover.contoso.com -FriendlyName contosoinc -KeySize 1024 -PrivateKeyExportable:$True -SubjectName "c=US o=contoso inc, CN=server01.contoso.com" -Path c:\certrequest.txt

  Important:
  If your internal DNS namespace differs from your external namespace, you will want to add more DNS names to the DomainNames parameter. For example, you might enter something similar to the following:

  New-ExchangeCertificate -GenerateRequest -DomainName mail.contoso.com, autodiscover.contoso.com, server01.contoso.local, server01 -FriendlyName contosoinc -KeySize 1024 -PrivateKeyExportable:$True -SubjectName "c=US o=contoso inc, CN=server01.contoso.com" -Path c:\certrequest.txt

  Note:
  You may be asked to include additional parameters or may be confused about what to enter for the SubjectName. Confirm the required parameters and necessary information with the CA vendor.

  Important:
  Make sure to include the PrivateKeyExportable parameter and set the value to $true if you plan to use the certificate on additional Client Access servers and ISA Servers computers.

After you request the certificate, see "Step 2: Install the Certificate" later in this section.

Step 1a (Optional) Install Windows Certificate Services and Request a Certificate

You can use Windows Certificate Services to create and manage your own SSL certificates. For additional details about how to manage your own Public Key Infrastructure for Windows Server 2003, see the following resources:

• Public Key Infrastructure for Windows Server 2003
  
• Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure
  

The following procedure describes how to install Windows Certificate Services and request an SSL certificate.

To create a certificate request internally by using Windows Certificate Services

1. If you have not already done this, install Windows Certificate Services on a server that is running Windows Server 2003 in your messaging infrastructure.

2. On a server that is running Windows Server 2003, open Add/Remove Windows Components and install Certificate Services.

   Note:
   During installation of Certificate Services, you will be prompted to select the type of CA to install. Select the option to install an Enterprise CA and complete the wizard.

3. To create the certificate request, on the Client Access server, open the Exchange Management Shell and enter the following:

   New-ExchangeCertificate -GenerateRequest -DomainName mail.contoso.com, autodiscover.contoso.com -PrivateKeyExportable:$True -Path c:\certreq.txt

   Important:
   The first DNS name following the DomainName parameter will automatically become the common name associated with the certificate. Be certain that you enter the FQDN that users will use to connect to services including Outlook Web Access, Exchange ActiveSync, and Outlook Anywhere.

   Note:
   If your internal DNS namespace differs from your external namespace, you will want to add more DNS names to the DomainNames parameter. For example, you might enter something similar to the following:

   New-ExchangeCertificate -GenerateRequest -DomainName mail.contoso.com, autodiscover.contoso.com, machinename, machinename.contoso.local -PrivateKeyExportable:$True -Path c:\certreq.txt

4. On your Client Access server, open Internet Explorer and enter the URL to connect to the Certificate Services administration Web page that is hosted on the server where you installed Certificate Services. For example, http://CAS01/certsrv or https://CAS01/certsrv.

5. Click Request a certificate, click Advanced certificate request, and then select Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file.

6. Copy the contents of the certreq.txt file that you saved in step 3 in the Saved Request field.

7. Select Web Server under Certificate Template.

8. Click Submit.

9. Click Download certificate, and then save the CER file to Drive C, that is, c:\certnew.cer.

Step 2: Install the Certificate

The following procedure describes how to import and enable a third-party certificate or one that you created internally by using Windows Certificate Services. The process is the same for each.

To install and enable the SSL certificate by using the Exchange Management Shell

• To install and enable an SSL certificate, open the Exchange Management Shell on the Client Access server and run the following command:

  Import-ExchangeCertificate -Path <full path to cert file> | Enable-ExchangeCertificate -Services iis

Step 3: (Optional) Administering and Using Root Certificates for End Users

Notice that domain-connected clients will typically obtain the root certificate automatically by using a Group Policy. However, there are circumstances when this may not work correctly. If domain-connected clients cannot automatically install the root certificate, you can manually configure a group to distribute certificates that will be trusted by all member computers of the domain. For more information about how to add a trusted root CA to a Group Policy object, see Add a trusted root certification authority to a Group Policy object.

To obtain the root certificate from Certificate Services

1. Open Internet Explorer on a domain-connected computer, and then enter the URL to connect to the Certificate Services administration Web page.

2. Select the Download a CA certificate, certificate chain or CRL option, and then select Download a CA certificate option.

3. Save the .cer file to the desktop and name the .cer file root.cer.

4. Distribute the CER file to your remote users by using e-mail, an FTP site, or other method.

To install the SSL certificate on your Outlook 2007 clients

1. Copy the root certificate to the desktop.

2. Double-click the root certificate.

3. In the Certificate dialog box, on the General tab, click Install Certificate.

4. In the Certificate Import wizard, click Next.

5. Select Place all certificates in the following store, and then click Browse.

6. In the Select Certificate Store window, select Trusted Root Certification Authorities, and then click OK.

7. Click Next, and then click Finish.

To install a certificate on a Windows Mobile device

1. Right-click the root certificate .cer file on the local computer, and then click Copy.

2. Open Windows Explorer, and then locate My Computer.

3. Double-click the Mobile Device icon to the view the folders on your device.

4. Right-click the folder where you want to copy the root certificate, and then click Paste.

5. When the root certificate has been copied to the device, close Windows Explorer.

6. On your device, open File Explorer and then locate the folder where you copied the root certificate.

7. Select the root certificate.

8. When you are prompted to install the certificate, click Yes.

   Important:
   You will not receive a message to let you know that the installation was successful.

Step 4: Create the Necessary Host Records in DNS

In most cases, you will already have a host record in external DNS for the host name that your users will be using to connect to your Exchange messaging infrastructure by using Outlook Web Access, Exchange ActiveSync or Outlook Anywhere. For example, mail.contoso.com. For the Autodiscover service to function correctly, you must add an additional host record so that Outlook 2007 clients can locate and connect to the Autodiscover service when they use the Outlook Anywhere feature from the Internet. The host record you create should map to the public IP address that will be used as the entry point to your Client Access server.

Step 5: Configure the Exchange Services URLs

Now that you have configured SSL for your Autodiscover service deployment scenario, you must configure your Exchange services for external access. For more information, see How to Configure Exchange Services for the Autodiscover Service later in this white paper.

Summary of Scenario 1

After you configure Exchange to use an SSL certificate that supports multiple DNS names and modify the Exchange services URLs as needed, the domain-connected clients will reference the internal URLs for the Exchange services that were automatically set when the Client Access server role was installed. Clients that are not domain-connected will connect by using the External URLs that you entered as part of this procedure. If your certificate includes all the necessary DNS names, both domain-connected and non-domain-connected clients will be able to successfully connect to the Autodiscover service without receiving security warnings that result from mismatched names. Domain-connected clients will locate the Autodiscover service by referencing the SCP object. Conversely, clients that are not domain connected will not locate the SCP object and will fail over to using DNS.

Return to top

This section describes how to use one single-name certificate where the common name of the certificate references the host name users will use to connect to Exchange from the Internet, for example, mail.contoso.com.

Step 1: Install a Certificate on the Default Web Site

The procedures in the following section assume that you already have obtained a valid third-party SSL certificate that uses the common name your users will be using to connect to your Exchange Messaging infrastructure. The first option describes how to use a preexisting certificate that you would export from an existing Exchange server that runs an earlier version of Exchange. The second option describes how to use a new third-party certificate.

If you must create a certificate request, see "Step 2: Install the Certificate" in the Scenario 1: How to Use a Certificate That Supports Multiple DNS Names section earlier in this white paper.

Option 1: Using an Existing SSL Certificate

The following procedures describe how to use an existing SSL certificate which you have already implemented for an earlier version of Exchange. Using IIS Manager on your existing earlier version of Exchange, export the existing certificate in PFX format by following these steps.

To use an existing SSL certificate from an earlier versions version of Exchange

1. In IIS Manager, right-click Default Web Site, click Properties, and then click the Directory Security tab.

2. Click Server Certificate.

3. On the Web Server Certificate Wizard, select the Export the current certificate to a .pfx file option, and then click Next.

4. Name the file, and then save it to a location that you will use later.

5. Enter a password, and then click Next.

6. Click Next and then click Finish.

7. Import the certificate to the Personal Store by following these steps:

   1. In the Certificates snap-in for MMC, expand the top-level Certificates (Local Computer).
      
   2. Right-click Personal, click All Tasks, and then click Import.
      
   3. In the Certificate Import Wizard, click Browse, locate the .pfx file that you copied to the Client Access server, and then click Next.
      
   4. Enter the password that you applied to the .pfx file, and then select the check box next to Mark this Key as Exportable.
      
   5. Select Place all certificates in the following store, select Personal Certificate Store, and then click Next.
      
   6. Click Finish.
      

8. Determine the Thumbprint attribute of the imported certificate. To do this, open the Exchange Management Shell and run the following command:

   Get-ExchangeCertificate | fl

9. Locate the certificate that you just imported, copy the certificate’s thumbprint, and then run the following command:

   Enable-ExchangeCertificate -Thumbprint <thumbprint_of_new_certificate> -Services iis

Option 2: Using a New Single-Name Certificate

Use the Exchange Management Shell on your Client Access server to install and enable your new third-party certificate.

To use the Exchange Management Shell to install and enable a new third-party SSL certificate

• On the Client Access server, open the Exchange Management Shell, and then run the following command:

  Import-ExchangeCertificate -Path <full path to CER file> | Enable-ExchangeCertificate -Services iis

Step 2: Modify the Service Connection Point

By default, the URL for the Autodiscover service stored in the SCP object in Active Directory will reference the internal FQDN for the Client Access server during Exchange 2007 Setup. You will use the Set-ClientAccessServer cmdlet to modify this URL so that it points to the new location (FQDN) for the Autodiscover service.

To use the Exchange Management Shell to change the internal URL for the Autodiscover service

• In the Exchange Management Shell, run the following command:

  Set-ClientAccessServer -identity <servername> -AutodiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Step 3: Configure the Exchange Services URLs

Now that you have configured SSL for your Autodiscover service deployment scenario, you must configure your Exchange services for external and internal access. For more information, see How to Configure Exchange Services for the Autodiscover Service later in this white paper.

Step 4: Implementing the Autodiscover SRV Record for Outlook Anywhere Users

Because this solution uses one single-name certificate, clients that are not domain-connected that run Outlook 2007 will receive a security warning when they connect to the Autodiscover service. If your external DNS provider supports Autodiscover SRV records, you can address this issue with an Outlook 2007 software update. When this software update is applied, Outlook 2007 clients will perform an additional check for a DNS SRV record to locate the Autodiscover service that does not require multiple Web sites and IP addresses or a new Unified Communications SSL certificate. Although this still requires you to add a DNS record in DNS for the Autodiscover service, you will not have to use a certificate that supports multiple DNS names or have to administer a second Web site.

For more information about this software update for Outlook 2007, see Microsoft Knowledge Base article 940881, A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service. To obtain this update, see Microsoft Knowledge Base article 939184, Description of the update rollup for Outlook 2007: June 27, 2007.

Summary of Scenario 2

In this scenario you installed a single-name certificate where the common name of the certificate references the host name users will use to connect to Exchange from the Internet, for example, mail.contoso.com. This solution required that you modify the SCP and the internal URLs of the Exchange services because the FQDN on the certificate differs from the FQDN referenced in the SCP and the internal URLs for the Exchange services.

This solution is most efficient if the following conditions are true:

• You do not want the additional administrative overhead of managing multiple Web sites and IP addresses.
  
• The certificate does not include a DNS name for the Autodiscover service.
  

This solution also requires an Outlook 2007 software update that supports Autodiscover SRV records. If your external DNS provider supports SRV records, a client that is not domain-connected will first try to locate the Autodiscover service by using the SCP object. Because the client cannot to contact Active Directory, it will fail over and try to locate the Autodiscover service by using the following URLs using DNS: https://contoso.com/autodiscover/autodiscover.xml and then https://autodiscover.contoso.com/autodiscover/autodiscover.xml. This request will then fail over to the HTTP redirect algorithm, and will also be unsuccessful. Finally, the client will try one more method. It will check for an Autodiscover SRV record in DNS, and then connect.

Return to top

This section describes how to use two single-name certificates, where the common name of one certificate references the host name users will use to connect to Exchange from the Internet, and the common name on the second certificate references the Autodiscover host name, for example: autodiscover.contoso.com. The existing certificate will typically be exported from a legacy Exchange server or will be a certificate that was recently purchased. In either case, you must obtain a second certificate for the Autodiscover Web site.

Step 1: Adding a Second IP Address to Your Network Adapter

The first step in this process involves adding a second IP address to your network adapter on your Client Access server.

To add a second IP address to your network adapter

1. On the Exchange 2007 Client Access Server, open the properties of your network adapter.

2. Select Internet Protocol, and then click Properties.

3. Click Advanced.

4. Under IP addresses, click Add, and then, in the TCP/IP Address dialog box, enter an available IP address in the text box for the IP address, as shown in the following figure.

   

5. After you have entered an available IP address, click Add.

Step 2: Create Required DNS Records

In most cases, you will already have a host record in external DNS for the host name that users will be using to connect to Exchange from the Internet, for example, mail.contoso.com. You must also add an additional host record for the Autodiscover service so that Outlook 2007 clients can find and connect to the Autodiscover service when they use Outlook Anywhere from the Internet. This host record should map to a second public IP address that points to another entry point to your Client Access server.

The following procedure describes how to create the host record in internal DNS for the host name that is referenced in the common name of the certificate on the Default Web Site.

To create the required host records in internal DNS

1. Open DNS Manager, and then expand the Forward Lookup Zones container.

2. Right-click your DNS zone, for example, contoso.com, and then click New Host (A).

3. Enter "mail" for the host name that is being used on the Default Web Site, for example, mail.contoso.com, and then assign it the local IP address that is assigned to the Default Web Site.

Step 3: Install a Certificate on the Default Web Site

The procedures in the following section assume that you already have obtained a valid third-party SSL certificate that uses the common name your users will be using to connect to your Exchange Messaging infrastructure. The first option describes how to use a preexisting certificate that you would export from an existing Exchange server that is running an earlier version of Microsoft Exchange. The second option describes how to use a new third-party certificate.

If you must create a certificate request, see "Step 2: Install the Certificate" in the Scenario 1: How to Use a Certificate That Supports Multiple DNS Names section earlier in this white paper.

Option 1: Using an Existing SSL Certificate

The following procedures describe how to use an existing SSL certificate that you have already implemented for an earlier version of Microsoft Exchange. Using IIS Manager on your earlier version of Exchange, export the existing certificate in PFX format by using the following procedure.

To use an existing SSL certificate from an earlier version of Exchange

1. In IIS Manager, right-click Default Web Site, click Properties and then click the Directory Security tab.

2. Click Server Certificate.

3. On the Web Server Certificate Wizard, select the Export the current certificate to a .pfx file option, and then click Next.

4. Name the file and save it to a location that you will use later.

5. Enter a password, and then click Next.

6. Click Next, and then click Finish.

7. Import the certificate to the Personal Store by following these steps:

   1. In the Certificates snap-in for MMC, expand the top-level Certificates (Local Computer).
      
   2. Right-click Personal, select All Tasks, and then click Import.
      
   3. In the Certificate Import Wizard, click Browse, locate the .pfx file that you copied to the Client Access server, and then click Next.
      
   4. Enter the password that you applied to the .pfx file, and then select the check box next to Mark this Key as Exportable.
      
   5. Select Place all certificates in the following store, select Personal Certificate Store, and then click Next.
      
   6. Click Finish.