Exchange 2007 Autodiscovery White Paper

White Paper: Exchange 2007 Autodiscover Service
Table of Contents
 Introduction
 How the Autodiscover Service Works with Clients
 How Outlook 2007 and Autodiscover Interoperate
 Autodiscover and Certificates
 Understanding the Exchange Setup Self-Signed Certificate
 Supported Scenarios for Connecting to the Autodiscover Service from the Internet
 Scenario 1: Using a Certificate That Supports Multiple DNS Names
 Scenario 2: Using One Single-Name Certificate
 Scenario 3: Using Two Single-Name Certificates
 Scenario 4: Using the Autodiscover Service with Redirection
 Summary of Supported Scenarios for Connecting to the Autodiscover Service from the Internet
 How to Configure the Autodiscover Service for Internet Access
 Scenario 1: How to Use a Certificate That Supports Multiple DNS Names
 Scenario 2: How to Use One Single-Name Certificate
 Scenario 3: How to Use Two Single-Name Certificates
 Scenario 4: How to Use a Single SSL Certificate and the Autodiscover Redirect Web Site
 Optional Deployment Information for a Large-Scale Hosted Environment
 Additional Deployment Scenarios and Considerations for the Autodiscover Service
 Configuring the Autodiscover Service to Use Site Affinity for Internal Communication
 How to Configure the Autodiscover Service to Use Site Affinity
 Configuring the Autodiscover Service for Multiple Forests

 How to Configure the Autodiscover Service When You Use Multiple Forests
 Managing the Autodiscover Service
 How to Configure the Autodiscover Service for Cross Forest Moves
 How to Configure Exchange Services for the Autodiscover Service
 Autodiscover and ISA Server 2006
 Conclusion
Introduction
Microsoft Exchange Server 2007 includes a new Microsoft Exchange service named the Autodiscover service. The
Autodiscover service configures and maintains server settings for client computers that are running
Microsoft Office Outlook 2007. The Autodiscover service can also configure supported mobile devices. An important
function of the Autodiscover service is to provide access to Microsoft Exchange features for Outlook 2007 clients
that are connected to your Microsoft Exchange messaging environment. These features include the Web-based
offline address book (OAB), the Availability service, and Unified Messaging (UM). The Autodiscover service must be
deployed and configured correctly for Outlook 2007 clients to automatically connect to Microsoft Exchange
features.
How the Autodiscover Service Works with Clients
When you install the Client Access server role on a computer that is running Exchange 2007, a new virtual
directory named Autodiscover is created under the Default Web Site in Internet Information Services (IIS). This
virtual directory handles Autodiscover service requests from Outlook 2007 clients in the following circumstances:
 When a new Outlook profile is configured or updated
 When a client periodically checks for changes to the Exchange Web Services URLs
 When underlying network connection changes occur in your Exchange messaging environment
Additionally, a new service connection point (SCP) Active Directory object is created for each server where the
Client Access server role is installed. The SCP object is used by domain-connected clients to locate the
Autodiscover service. The SCP object contains two pieces of information, the serviceBindingInformation
attribute and the keywords attribute. The serviceBindingInformation attribute has the Fully Qualified Domain
Name (FQDN) of the Client Access server in the form of https://cas01.contoso.com/autodiscover/autodiscover.xml,
where cas01.contoso.com is the fully qualified domain name (FQDN) for the Client Access server. The keywords
attribute specifies the Active Directory sites to which this SCP record is associated. By default, this attribute
specifies the Active Directory site to which the Client Access server belongs.
When a domain-connected client connects to the Active Directory directory service, the Exchange 2007 client
authenticates to Active Directory and tries to locate the Autodiscover SCP objects that were created during Setup
by using the user's credentials. In deployments that include multiple Client Access servers, an Autodiscover SCP
record is created for each Client Access server. By using the user credentials, the Outlook 2007 client authenticates
to Active Directory and searches for the Autodiscover SCP objects. After the client obtains and enumerates the
instances of the Autodiscover service, the client connects to the first Client Access server in the enumerated and
sorted list and obtains the profile information in the form of XML data that is needed to connect to the user's
mailbox and available Microsoft Exchange features.
An Outlook 2007 client connects to the Autodiscover service as follows:
1. Outlook 2007 sends a Lightweight Directory Access Protocol (LDAP) query to Active Directory looking for
all available SCP objects.
2. Outlook 2007 sorts and enumerates the returned results based on the client's Active Directory site by
using the keyword attribute of the SCP record. One of two lists is created, an in-site list or an out-of-site
list. The in-site list provides the SCP records that have AutodiscoverSiteScope
information. AutodiscoverSiteScope is a parameter that is set on the Client Access server by using the
Set-ClientAccessServer cmdlet. The parameter specifies the site for which the Autodiscover service is
authoritative. The AutodiscoverSiteScope information contained in the SCP records for the in-site list
matches the Active Directory site for the Outlook client. If there are no in-site records, an out-of-site SCP
record list will be generated. The list is not sorted in any particular order. Therefore, the list is
approximately in the order of oldest SCP records (based on creation date) first.
Note:
In environments where Outlook 2007 is deployed in remote sites that do not have Exchange 2007 Mailbox
and Client Access servers, you can use site affinity to configure the SCP objects for Outlook 2007 clients to
use SCP objects that are physically closer
3. Outlook first tries to connect to each Autodiscover URL that it had previously generated from either an in-
site list or an out-of-site list. If that doesn't work, Outlook will try to connect to the predefined URLs (for
example, https://autodiscover.contoso.com/autodiscover/autodiscover.xml) by using DNS. If that fails
also, Outlook will try the HTTP redirect method and, failing that, Outlook will try to use the SRV record
lookup method. If all lookup methods fail, Outlook will be unable to obtain Outlook Anywhere configuration
and URL settings.
4. The Autodiscover service queries Active Directory to obtain the connection settings and URLs for the
Exchange services that have been configured.
5. The Autodiscover service returns an HTTPS response with an XML file that includes the connection settings
and URLs for the available Exchange services.
6. Outlook uses the appropriate configuration information and connection settings to connect to your
Exchange messaging environment.
The following figure illustrates how a client connects to a Client Access server the first time from inside the
Exchange messaging organization.
The Autodiscover service process for internal access
When Outlook 2007 is started on a client that is not domain-connected, it first tries to locate the Autodiscover
service by looking up the SCP object in Active Directory. Because the client is unable to contact Active Directory, it
tries to locate the Autodiscover service by using Domain Name System (DNS). In this scenario, the client will
determine right side of the user’s e-mail address, that is, contoso.com, and check DNS by using two predefined
URLs. For example, if your SMTP domain is contoso.com, Outlook will try the following two URLs to try to connect
to the Autodiscover service:
 https://contoso.com/autodiscover/autodiscover.xml
 https://autodiscover.contoso.com/autodiscover/autodiscover.xml
Important:
For Outlook to be able to locate the Autodiscover service by using DNS, there must be a host record in DNS
for the Autodiscover service that maps the entry point, or public IP address, to the Client Access server
where the Autodiscover service is hosted.
The following figure illustrates a simple topology with a client connecting from the Internet.
The Autodiscover service process for external access

Another option related to DNS is made possible 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 which does not require multiple Web sites and IP addresses or a new Unified Communications Secure
Sockets Layer (SSL) certificate. Although this still requires that you add a DNS record in DNS for the Autodiscover
service, you do not have to use a certificate that supports multiple DNS names and or have to administer a second
Web site.
How Outlook 2007 and Autodiscover Interoperate

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.
Autodiscover and Certificates
One of the most important aspects of a successful Exchange messaging deployment is how you configure your SSL
certificates for securing client communication to your Exchange infrastructure. This is because all communication
between Outlook clients and the Autodiscover service endpoint, in addition to communication between the Outlook
client and Exchange services, occurs over an SSL channel. For this communication to occur without failing, you
must have a valid SSL certificate installed. For a certificate to be considered valid, it must meet the following
criteria for the Autodiscover service:
 The client can follow the certificate chain up to the trusted root.
 The name matches the URL that the client is trying to communicate with.
 The certificate is current and has not expired.

Note:
For domain-connected clients, Outlook 2007 is designed to ignore the first validity check in the previous list.
This design enables Outlook 2007 to function without any certificate warnings when Outlook uses the self-
signed certificate that is installed by Exchange 2007 Setup.
Understanding the Exchange Setup Self-Signed Certificate
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.
Note:
The Subject Alternative Name field is a special field that is available in X.509 v.3 certificates that lets you
add multiple DNS names to a single 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.
Note:
We recommend that you immediately replace the self-signed certificate with a commercially available
Internet trusted certificate or a trusted internal public key infrastructure (PKI)-issued certificate.
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.
Supported Scenarios for Connecting to the Autodiscover Service from the Internet
If you are providing external access to Microsoft Exchange by using Outlook Anywhere (formerly known as RPC
over HTTP) you must install a valid SSL certificate on the Client Access server by using one of the following four
scenarios. Additionally, you must correctly configure your Exchange services, such as the Availability service,
before the Autodiscover service can provide the correct external URLs to clients.
When the client tries to connect to your Microsoft Exchange messaging environment, the client locates the
Autodiscover service on the Internet by using the right side of the user's e-mail address that was entered. Notice
that, for the Autodiscover service to function correctly, this must be the user's primary SMTP address. The
Autodiscover service URL will be either of the following URLs:
 https://<smtp-address-domain>/autodiscover/autodiscover.xml
 https://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml.
For example, if the user's e-mail address is [email protected], the Autodiscover service should be located at
either https://contoso.com/autodiscover/autodiscover.xml or
https://autodiscover.contoso.com/autodiscover/autodiscover.xml. This means that you must add a host record for
the Autodiscover service to your external DNS zone.
There are several methods for configuring your Client Access server to support connections to the Autodiscover
service from the Internet. Which method that you choose should be decided after you weigh the advantages and
disadvantages associated with the following methods.
Scenario 1: Using a Certificate That Supports Multiple DNS Names

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.
Note:
There are special considerations when you use Unified Communications certificates with Internet Security
and Acceleration (ISA) Server 2004 and ISA Server 2006. For more information, see the following articles:
 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.
Scenario 2: Using One Single-Name Certificate and the Autodiscover SRV Record
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.
Important:
In this scenario, you must update the Autodiscover URL in the SCP object in Active Directory and the
internal URLs for the Exchange services so that Outlook clients do not receive the following error:
The name of the security certificate is invalid or does not match the name of the 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.
Scenario 3: Using Two Single-Name Certificates

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.
Scenario 4: Using the Autodiscover Service with Redirection

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.
Note:
Similar to using two single-name certificates, this solution also requires a second public IP address which
must be assigned to the second Web site.
Summary of Supported Scenarios for Connecting to the Autodiscover Service from the Internet
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  Easy to  Higher cost certificate type (Unified

that supports
implement Communications certificate)
multiple DNS
names
 Supports all  Requires additional configuration if used
client connections together with either ISA Server 2004 or ISA
Server 2006
 Microsoft-
recommended best
practice
One single-name  Easy to  Requires modification of SCP object and

certificate and Web
implement Exchange services URLs
site
 Supports all  Requires Outlook 2007 update rollup,

client connections described in Microsoft Knowledge Base article
939184 Description of the update rollup for
 Least expensive Outlook 2007: June 27, 2007, to support
Autodiscover SRV record if also deploying
 Ideal for hosters Outlook Anywhere
if DNS provider
supports SRV records  DNS provider may not support
Autodiscover SRV record
Two single-name  Lower cost than  Requires an additional public IP address

certificates and
using Unified
Web sites
Communications  Complex to set up and maintain
certificate
 Both sites are

secured with SSL
Single certificate  Can be done by  Requires an additional public IP address

with Redirect
using your existing
certificate  Somewhat complex to set up
 No additional
cost
 Ideal for hosters

if DNS provider does
not support SRV
records
Single certificate  Smallest up-  Highest total cost of ownership for

generated by using
front costs administrators and end users
Windows
Certificate Services
 Supports all
client connections
Note:
Whichever solution you implement to replace the default self-signed certificate, your internal Outlook 2007
users may report that they receive the following security warning when they start Outlook:
The name of the security certificate is invalid or does not match the name of the site.
How to Configure the Autodiscover Service for Internet Access
This section describes how to configure the Autodiscover service in the following four scenarios:
 Scenario 1: Using a certificate that supports multiple DNS names
 Scenario 2: Using one single-name certificate
 Scenario 3: Using two single-name certificates
 Scenario 4: Using the Autodiscover service with redirection
The following table outlines the various requirements for each scenario.
Requirements Scenario Scenario Scenario Scenario 4

1 2 3
Primary IP address Yes Yes Yes Yes
Secondary IP address No No Yes Yes
Primary public IP resolving to Default Web Site* Yes Yes Yes Yes
Secondary public IP resolving to Autodiscover No No Yes Yes

Web site**
# of certificates 1 1 2 1
Modification of SCP object No Yes Yes Yes
Modification of Web services URLs No Yes Yes Yes

* Must resolve to the host name that users use to connect to Exchange services, for example, mail.contoso.com.
** Must resolve to the FQDN for the Autodiscover service, for example, autodiscover.contoso.com.
Scenario 1: How to Use a Certificate That Supports Multiple DNS Names

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 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:
Copy Code
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:
Copy Code
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:
Copy Code
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:
Copy Code
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.
Note:
The Import-ExchangeCertificate cmdlet installs the certificate in the Personal certificate store on the
server and the Enable-ExchangeCertificate cmdlet installs the certificate on the Web site.
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:
Copy Code
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.
Important:
Installing a root certificate on a mobile device requires that you connect the device with your Windows
operating system. If you are running Windows XP, you must install the latest version of the desktop
ActiveSync application. If you are running Windows Vista, you can use the integrated Windows Mobile
Device Center in Control Panel but you must first download the Windows Mobile Device Center application.
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.
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.
Scenario 2: How to Use One Single-Name Certificate

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.
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:
a. In the Certificates snap-in for MMC, expand the top-level Certificates (Local Computer).
b. Right-click Personal, click All Tasks, and then click Import.
c. In the Certificate Import Wizard, click Browse, locate the .pfx file that you copied to the
Client Access server, and then click Next.
d. Enter the password that you applied to the .pfx file, and then select the check box next to Mark
this Key as Exportable.
e. Select Place all certificates in the following store, select Personal Certificate Store, and
then click Next.
f. Click Finish.
8. Determine the Thumbprint attribute of the imported certificate. To do this, open the Exchange
Management Shell and run the following command:
Copy Code
Get-ExchangeCertificate | fl
9. Locate the certificate that you just imported, copy the certificate’s thumbprint, and then run the following
command:
Copy Code
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:
Copy Code
Import-ExchangeCertificate -Path <full path to CER file> | Enable-
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.
Important:
You must repeat this step for every Client Access server that is installed in your Exchange messaging
infrastructure.
To use the Exchange Management Shell to change the internal URL for the Autodiscover service
 In the Exchange Management Shell, run the following command:
Copy Code
Set-ClientAccessServer -identity <servername> -
AutodiscoverServiceInternalUri
https://autodiscover.contoso.com/autodiscover/autodiscover.xml
Exchange services for external and internal access
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.
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.
Scenario 3: How to Use Two Single-Name Certificates

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.
Note:
If your internal DNS namespace differs from your external namespace, you must create an additional DNS
zone that matches your external namespace, and then create the host record within that zone.
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.
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:
a. In the Certificates snap-in for MMC, expand the top-level Certificates (Local Computer).
b. Right-click Personal, select All Tasks, and then click Import.
c. In the Certificate Import Wizard, click Browse, locate the .pfx file that you copied to the
Client Access server, and then click Next.
d. Enter the password that you applied to the .pfx file, and then select the check box next to Mark
this Key as Exportable.
e. Select Place all certificates in the following store, select Personal Certificate Store, and
then click Next.
f. Click Finish.
8. To determine the Thumprint attribute of the imported certificate, open Exchange Management Shell and
run the following command:
Copy Code
Get-ExchangeCertificate | fl
9. Locate the certificate that you just imported, copy the thumbprint of the certificate, and then run the
following command:
Copy Code
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, in the Exchange Management Shell, run the following command:
Copy Code
Import-ExchangeCertificate -Path <full path to CER file> | Enable-
Step 4: Configure the Default Web Site
The next step in this process is to configure the Default Web Site by using IIS Manager. The following procedure
describes this process.
To configure the Default Web Site by using IIS Manager

1. In IIS Manager, expand Web Sites, right-click Default Web Site, and then click Properties.
2. By default, the IP address will be assigned to All Unassigned. Select your primary IP address and assign it
to the Default Web Site.
3. Click Advanced, click Edit, and then change the IP assignment for port 443 to the primary IP address.
Step 5: Configure the Autodiscover Web Site
The next step in this process is to configure the Autodiscover Web site by using IIS Manager. The following
procedure describes this process.
To configure the new Autodiscover Web site

1. In IIS Manager, right-click Web Sites, click New, and then select Web Site.
2. When the Web Site Creation Wizard opens, click Next.
3. In the Web Site Creation Wizard, on the Web Site Description page, in the Description field, enter the
name of your Web site. For example, "Autodiscover Web Site". Click Next.
4. On the IP Address and Port Settings page, select the second IP address that you added from the drop-
down list, and then click Next.
5. On the Web Site Home Directory page, click Browse, select c:\Inetpub\wwwroot, and then click OK.
Leave the Anonymous access check box selected, and then click Next.
6. On the Web Site Access Permissions page, accept the default setting for Read permission, click Next,
and then click Finish.
Step 6: Installing a Certificate on the Autodiscover Web Site
The following procedure in this section assumes that you have already obtained a valid third-party certificate with
the common name users will be using to connect to the Autodiscover service, for example,
autodiscover.contoso.com. Because the Enable-ExchangeCertificate command only works for certificates
installed on the Default Web Site, you must use IIS Manager to install this certificate on the Autodiscover Web site.
To use the Exchange Management Shell and IIS Manager to install and enable a new third-party SSL certificate
1. In the Exchange Management Shell, enter the following command to import the second certificate into the
Personal Certificate store on the server:
Copy Code
Import-ExchangeCertificate -path <full_path_to_CER_file>
2. In IIS Manager, expand Web Sites, right-click the Autodiscover Web Site, and then click Properties.
3. On the Directory Security tab, click the Server Certificate button.
4. When the Web Server Certificate Wizard opens, click Next.
5. On the Server Certificate page, select Assign an existing certificate and then click Next.
6. On the Available Certificates page, select the certificate that was provided by your CA for the
Autodiscover Web site and then click Next.
7. On the SSL Port page, accept the default setting of 443 and then click Next.
8. On the Certificate Summary page, confirm the details are correct, click Next and then click Finish to
complete the Web Server Certificate Wizard.
Step 7: Create a New Autodiscover Virtual Directory
After you have configured the new Autodiscover Web site in IIS, you will use the Exchange Management Shell to
create a new Autodiscover virtual directory.
To use the Exchange Management Shell to create a New Autodiscover virtual directory
Copy Code
New-AutodiscoverVirtualDirectory -WebSite "Autodiscover Web Site"
Note:
The name of the Web site that you enter is case-sensitive.
Step 8: Modify the SCP Object
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.
Important:
You must repeat this step for every Client Access server that you install in your Exchange messaging
infrastructure.
Copy Code
Set-ClientAccessServer -identity <servername> -
AutodiscoverServiceInternalUri
https://autodiscover.contoso.com/autodiscover/autodiscover.xml
After you configure Exchange to use two single-name certificates and Web sites, domain-connected clients will
connect to the Autodiscover service that is hosted under the Default Web Site that is found by using the SCP
object. Conversely, non-domain-connected clients will locate the Autodiscover service by using DNS and connect to
the Autodiscover service hosted under the second Web site. Because each Web site contains a valid certificate, all
clients should be able to connect without receiving any security warnings.
Scenario 4: How to Use a Single SSL Certificate and the Autodiscover Redirect Web Site
The following section describes how to configure the Autodiscover service when you use one single-name certificate
with an SSL Web site in addition to a second Web site responsible for redirecting incoming requests over port 80 to
the Autodiscover virtual directory set to accept requests over port 443.
Note:
If you are a large-scale hoster and unable to implement Scenario 2, review the optional information that
appears after the following steps.
Note:
These steps assume that you have already obtained a valid third-party certificate with the common name
users will be using to connect to Exchange from the Internet which is installed on the Default Web Site of
your Client Access server, for example, mail.contoso.com.
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 enter an available IP address.
Step 2: Create Required DNS Records
In most cases, you will already have a host record in external DNS for the host name 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 required host
records in internal DNS.
To create the required host records in internal DNS

1. Open DNS Manager and expand the Forward Lookup Zones container.
2. Right-click your DNS zone, for example, contoso.com, and then click New Host (A).
3. Enter "autodiscover" and the second IP address which you already assigned to your network adapter.
4. Create an additional host record for the host name being used on the Default Web Site, for
example.mail.contoso.com, and assign it the local IP address which is assigned to the Default Web Site.
Step 3: Configure the Default Web Site
The next step in this process is to configure the Default Web site. The following procedure describes this process.
To configure the Default Web Site

1. In IIS manager, right-click the Default Web Site and then click Properties.
2. By default, the IP address will be assigned to All Unassigned. Select your primary IP address and assign it
to the Default Web Site.
3. Click Advanced, and then click Edit and change the IP assignment for port 443 to the primary IP
address.
Step 4: Create a New Autodiscover Directory Structure

The following procedure describes how to create a new Autodiscover directory structure which will be used by the
Autodiscover redirect Web site that you create in the next step.
To create a new Autodiscover directory structure

1. On the Client Access server, open a new Windows Explorer window, and then locate C:\Inetpub.
2. Create a new folder under c:\Inetpub named Autodiscover.
3. Create a subfolder under c:\Inetpub\Autodiscover named Autodiscover.
4. Create a new blank text file, and then name it autodiscover.xml.
Step 5: Create the Autodiscover Redirect Web Site
To use IIS Manager to create the Autodiscover redirect Web site

1. In IIS Manager, right-click Web Sites, and then click New Web Site.
2. In the New Web Site Wizard, in the Description box, enter the name of the Web site, for example,
Autodiscover Web Site, and then click Next.
3. In the IP Address and Port Settings window, select the second IP address that you added and then
click Next.
4. In the Web Site Home Directory window, browse and then select c:\Inetpub\autodiscover, leave the
Anonymous access check box selected, and then click Next.
5. Expand the Autodiscover Web Site and select the Autodiscover virtual directory under the Web site.
6. In the right pane, right-click the autodiscover.xml file, and then select Properties.
7. Select the A redirection to a URL option and enter the URL to the Autodiscover.xml file that is located
under the Default Web Site by using the FQDN users will use to connect to Outlook Web Access, Exchange
ActiveSync and Outlook Anywhere, for example, https://mail.contoso.com/autodiscover/autodiscover.xml.
Step 6: Modify the Service Connection Point Object
internal FQDN for the Client Access server during Exchange 2007 Setup. For internal users who use Outlook 2007,
you will use the Set-ClientAccessServer cmdlet to modify the URL so that it references the common name of the
certificate on the Default Web Site.
Copy Code
Set-ClientAccessServer -AutodiscoverServiceInternalUri
https://mail.contoso.com/autodiscover/autodiscover.xml
Step 7: Configure the Web Services URLs
Optional Deployment Information for a Large-Scale Hosted Environment
For large-scale hosted environments, using a single redirect Web site as discussed earlier may not be appropriate.
If you expect heavy Web traffic, you should consider configuring the Autodiscover service so that incoming
requests for the Autodiscover service are managed by individual Web sites for each domain. These requests can
then be redirected for each hosted domain to the Autodiscover virtual directory under the Default Web Site in
Internet Information Services (IIS). Also, you may even host the Autodiscover service on a dedicated Web server if
you want. The following figure illustrates the Autodiscover service in a hosted environment.
The Autodiscover service in a hosted Exchange environment

In this scenario, you create separate Web sites, each with its corresponding DNS entries for each hosted e-mail
domain. For example, the domain named contoso.no would be called autodiscover.contoso.no, and the domain
named contoso.se would be called autodiscover.contoso.se. In the site in the previous figure, there is no need for
any virtual directories and you do not have to set up SSL certificates.
To configure this kind of scenario, in IIS Manager, configure redirection for each of your sites by modifying each
Web site's autodiscover.xml file so that it points to https://mail.contoso.com/autodiscover/autodiscover.xml.
Note:
These sites should be configured only for HTTP (port 80) traffic.
After you configure Exchange to use an SSL certificate with redirection, domain-connected clients will continue
locating the Autodiscover service by using the SCP object and connect to the Autodiscover service that is hosted
under the Default Web Site. On the other hand, clients that are not domain-connected will be unable to locate the
SCP object and fail over to using DNS. These clients will also be unable to locate Autodiscover by using the
following URLs:
 https://contoso.com/autodiscover/autodiscover.xml
 https://autodiscover.contoso.com/autodiscover/autodiscover.xml
The clients will instead use an alternative method: an HTTP redirect. When the redirect happens, the client will
receive a redirect from the Autodiscover site to the site that is dedicated to handling e-mail. When this occurs, a
warning message is displayed in Outlook 2007 that says:
Allow this website to configure server settings?
Outlook 2007 enables users to turn off the option for this warning message to continue to appear. We recommend
that you instruct your users to turn off the warning message on their Outlook 2007 client.
Additional Deployment Scenarios and Considerations for the Autodiscover Service
If your topology includes multiple sites or forests, other considerations must be addressed when you configure the
Autodiscover service to handle these types of Exchange deployments. For the Autodiscover service to function
correctly for Outlook 2007, you must make sure that your Exchange organization meets the following
requirements:
 You must have at least one Exchange 2007 Client Access server installed in each Active Directory site
where user's mailboxes reside for your Exchange deployment. For Exchange features such as the
Availability service and Unified Messaging, you must also have the Unified Messaging, Mailbox, and Hub
Transport server roles installed in the Exchange messaging environment.
Additionally, if you are not providing external access to your Exchange messaging infrastructure, there are several
steps in the Autodiscover deployment process that you will not have to perform.
The following sections describe the scenarios and how to deploy the Autodiscover service in each of these
scenarios.
Configuring the Autodiscover Service to Use Site Affinity for Internal Communication
If you manage a large, distributed organization that has Active Directory sites that are separated by low-bandwidth
network connectivity, we recommend that you use site affinity for the Autodiscover service for intranet-based
traffic. To use site affinity, you specify which Active Directory sites are preferred for clients to connect to a
particular Autodiscover service instance. Specifying which Active Directory sites are preferred is also known as
configuring site scope.
You configure site affinity by using the Set-ClientAccessServer cmdlet. This cmdlet lets you specify the preferred
Active Directory sites for connecting to the Autodiscover service on a specific Client Access server. After you
configure site affinity for the Autodiscover service, the client will connect to the Autodiscover service as you
specified.
The following example uses a topology that includes one forest with three sites:
 US-contoso A contoso site that is located in North America
 Europe-contoso A contoso site that is located in Europe
 APAC-contoso A contoso site that is located in Asia
In this example, each Active Directory site has Client Access servers and Mailbox servers. The US-contoso site is
connected to the Europe-contoso site by using a high-speed connection. The US-contoso site is connected to the
APAC-contoso site by using a low-speed connection. The APAC-contoso site is connected to the Europe-contoso site
by using a high-speed connection.
Based on these connectivity factors, you might want to allow users in the US-contoso and Europe-contoso sites to
use either the Client Access servers in the US-contoso or the Europe-contoso sites, users in the Europe-contoso
site to use any Client Access servers in the organization for the Autodiscover service requests, and users in the
APAC-contoso site to use the Client Access servers in the APAC-contoso or the Europe-contoso site. Finally, the
Client Access servers can be reached by using a common internal namespace across all sites.
You can configure site scope for users in the US-contoso site by configuring the Autodiscover site scope correctly
on the Client Access servers in the US-contoso Active Directory site. To do this use the following command.
Copy Code
Set-ClientAccessServer -Identity "us-cas" -AutodiscoverServiceInternalURI
"https://internal.contoso.com/autodiscover/autodiscover.xml" -
AutoDiscoverSiteScope "us-contoso","europe-contoso"
The previous command ensures the following:
 If an Outlook 2007 client is a member of the US-contoso Active Directory site, it will use the US-CAS SCP
record for its Autodiscover requests. Additionally, the client will not try to use an APAC-CAS server for
Autodiscover requests.
 If an Outlook 2007 client is a member of the Europe-contoso Active Directory site, it can use the US-CAS
SCP record for its Autodiscover requests.
You can configure site scope for users in the APAC-contoso site by configuring the Autodiscover site scope property
on the Client Access servers in the APAC-contoso site. To do this, use the following command.
Copy Code
Set-ClientAccessServer -Identity "apac-cas" -AutodiscoverServiceInternalURI
AutoDiscoverSiteScope "apac-contoso","europe-contoso"
The previous command ensures the following:
 If an Outlook 2007 client is a member of the APAC-contoso Active Directory site, it will use the APAC-CAS
SCP record for its Autodiscover requests. Additionally, the client will not try to use a US-CAS server for
Autodiscover requests.
 If an Outlook 2007 client is a member of the Europe-contoso Active Directory site, it can use the APAC-
CAS SCP record for its Autodiscover requests.
Finally, because the Client Access servers in the Europe-contoso Active Directory site are connected to both the
US-contoso and APAC-contoso sites by using a high-speed connection, you will want to make sure that users in
either of those sites can use the Client Access servers in the Europe-contoso site. To do this, configure the
Autodiscover site scope property as follows.
Copy Code
Set-ClientAccessServer -Identity "europe-cas" -AutodiscoverServiceInternalURI
AutoDiscoverSiteScope "us-contoso", "europe-contoso", "apac-contoso"
The previous command ensures that Outlook 2007 clients that are members of the Europe-contoso Active Directory
site use the Europe-CAS SCP record for Autodiscover service requests. Additionally, the Outlook client can also use
either the US-CAS SCP record or the APAC-CAS SCP record after you run the previous commands.
Therefore, if a user is located in the US-contoso site and tries to locate the Autodiscover service by using
Outlook 2007, the Outlook client can select the SCP record from the list in which the site scope equals "us-
contoso". In this case, the client will either access a US-CAS server or a Europe-CAS server.
If you do not alter the site-scope settings for the Autodiscover service, the Outlook client will only use the Client
Access servers in its local site (US-contoso, Europe-contoso, APAC-contoso). If, on the other hand, you delete the
site-scope settings, Outlook will randomly select an SCP record for Autodiscover requests. This could result in a
poor experience for the end user because the request may go out of the user's Active Directory site and use a low
quality network connection. For example, if you did not run the previous commands, a user in the US-contoso
Active Directory site would potentially use the APAC-CAS server, the Europe-CAS server, or the US-CAS server.
How to Configure the Autodiscover Service to Use Site Affinity

You can use the Set-ClientAccessServer cmdlet in the Exchange Management Shell to configure the Autodiscover
service to use site affinity on a computer that is running Exchange 2007 that has the Client Access server role
installed.
Before You Begin
To perform the following procedure, the account you use must be delegated the Exchange Server Administrator
role and membership in the local Administrators group for the target server.
To use the Exchange Management Shell to configure site affinity for the Autodiscover service
 Run the following command:
Copy Code
Set-ClientAccessServer -Identity "ServerName" -
AutodiscoverServiceInternalURI
"https://internalsitename/autodiscover/autodiscover.xml"
AutoDiscoverSiteScope "SiteName"
For more information about syntax and parameters, see Set-ClientAccessServer.
Configuring the Autodiscover Service for Multiple Forests

You can deploy Microsoft Exchange by using multiple forests. Two of the multiple forest deployment scenarios are
the resource forest topology and the multiple trusted forest topology. The following sections describe how the
Autodiscover service is used in these two deployment scenarios.
Configuring the Autodiscover Service in a Resource Forest Topology
If you use a resource forest topology, user accounts reside in one forest (known as a user account forest) and
Microsoft Exchange is deployed in a separate forest (known as a resource forest).
In this scenario, the following will occur:
1. The Outlook client contacts Active Directory in the user account forest to locate the URL for the
Autodiscover service. Because the service is hosted in the resource forest, you must update
Active Directory in the user account forest to include the information that Active Directory requires to
enable the client to access the resource forest. To do this, you must create an Autodiscover SCP pointer
record in Active Directory in the user account forest. The Autodiscover SCP pointer record includes the
LDAP URL of the resource forest that the client will use to locate the Autodiscover service in the resource
forest.
2. Outlook binds to the target forest by using the LDAP URL and retrieves the SCP records.
3. Depending on your SCP record configuration, the following will occur:
a. If the account forest Active Directory sites are in the resource forest, which requires Microsoft
Identity Lifecycle Manager 2007 synchronization, the Outlook client will retrieve the SCP records
for the Outlook client's Active Directory site.
b. If the SCP records do not have a site scope that matches the Outlook client's site, the Outlook
client will retrieve an SCP record at random. Also, if the Active Directory site topology is not
being replicated between the user account forest and the resource forest, the Outlook client will
retrieve an SCP record at random.
4. The Outlook client connects to the URL that is specified in the SCP record that was obtained and retrieves
the required user profile settings by using the Autodiscover service.
Configuring the Autodiscover Service in a Multiple Trusted Forest Topology
In the multiple trusted forest scenario, the user accounts and Microsoft Exchange are deployed in multiple forests.
Exchange 2007 features such as the Availability service and Unified Messaging rely on the Autodiscover service to
access user accounts across forests. In this scenario, the Autodiscover service must be available to users across
multiple trusted forests. This scenario resembles the resource forest scenario, except that the Autodiscover SCP
object must be configured in all forests. To configure the Autodiscover SCP object in the multiple forest topology,
run the Export-AutoDiscoveryConfig cmdlet from each forest that has the Autodiscover service against each
target forest where Microsoft Exchange is deployed.
How to Configure the Autodiscover Service When You Use Multiple Forests
If your Exchange deployment has two or more trusted forests, you must update Active Directory so that users who
are running Microsoft Office Outlook 2007 in one forest can access the Client Access servers in the remote (or
target) forest to use the Autodiscover service. To do this, you must extend the schema in the user forest by
running Exchange 2007 Setup with the /PrepareAD or /PrepareSchema switch, and then run the Export-
AutodiscoverConfig cmdlet in the resource forest that contains the Client Access servers that provide the
Autodiscover service against the target forests. This will configure the SCP information for the Autodiscover pointer
in Active Directory. Or, you can manually create the root Autodiscover SCP record container in the user forest.
Important:
If you install Exchange 2007 Service Pack 1 (SP1), you will not have to extend the schema or manually
create the Autodiscover SCP record container in the user forest.
Note:
If you do not want to extend the schema in the user forest, you can update DNS in the user forest with a
host record that points to the internal IP address of the Client Access server in the resource forest where
Autodiscover is hosted.
Note:
If you will be manually creating the Autodiscover SCP record container, you must install the Windows
Server 2003 Support Tools from the Windows Server 2003 CD. After the Autodiscover SCP record container
is installed, you can access the Active Directory Service Interfaces (ADSI) Edit tool by going to the Start
menu, clicking Programs, and then clicking Windows Support Tools. Then select Support Tools Help.
Before You Begin
To perform the following procedures, the account you use must be delegated the Exchange Server Administrator
To use ADSI Edit to extend the schema in the user forest

 Run Exchange 2007 Setup on a server in the user forest by using the following command:
Copy Code
Setup.com /prepareschema
 Or, create the "Microsoft Exchange Autodiscover" container in the user account forest by following these
steps:
1. Start ADSI Edit.
2. Expand the Configuration container.
3. Expand CN=Configuration,DC=<root domain>.
4. Expand the CN=Services container.
5. Right-click CN=Services, click New, and then select Object.
6. Under Select a Class, select Container, and then click Next.
7. Next to Value, enter "Microsoft Exchange Autodiscover", and then click Next.
8. Click Finish.
9. Allow Active Directory replication to occur before you continue with the next step.
To use the Exchange Management Shell to configure the Autodiscover service for multiple forests
1. On an Exchange 2007 Client Access server in the resource forest, enter the user name and password for
the account that has the required permissions for the target forest in the variable " $a" by running the
following command:
Copy Code
$a = Get-Credential
2. On an Exchange 2007 Client Access server in the resource forest, run the following command:
Copy Code
Export-AutoDiscoverConfig -DomainController DomainControllerName -
TargetForestDomainController TargetForestDomainControllerName -
TargetForestCredentials $a -MultipleExchangeDeployments $true
Managing the Autodiscover Service
Managing the Autodiscover service for users includes performing tasks such as making sure that users will be able
to use the Autodiscover service after their mailboxes are moved from one forest to another forest.
The following sections describe the common management tasks for the Autodiscover service. Depending on your
deployment, some of these procedures may not have to be performed.
How to Configure the Autodiscover Service for Cross Forest Moves

You can use the Exchange Management Shell to configure your Microsoft Exchange deployment to handle
mailboxes that are moved from one forest to another for the Autodiscover service.
For a cross-forest mailbox move, the two forests must be trusted. For the Autodiscover service to handle this
move, you must configure a mail contact in the original forest where the user's mailbox resided.
When you configure a mail contact, the user will authenticate to the original forest where the mailbox resided, and
the user will receive a redirect that uses the new e-mail address. The client will then try to contact the
Autodiscover service by using the new e-mail address against the new forest.
For example, contoso.com and fourthcoffee.com are separate, trusted forests and the mailbox for a user is
[email protected]. This user originally resided in the forest named contoso.com and was moved to the forest
named fourthcoffee.com.
For this example, you have to set a contact in mail1.contoso.com by using the following command in the Exchange
Management Shell.
Copy Code
New-MailContact -ExternalEmailAddress 'SMTP:[email protected]' -Name
'Kweku Ako Adjei' -Alias 'kwekua' -OrganizationalUnit 'contoso.com/Users' -
FirstName 'Kweku' -Initials '' -LastName 'Ako Adjei'
After you configure the contact, when the user connects to contoso.com and uses the contoso.com credentials, the
following request is sent to the Outlook 2007 client.
<?xml version="1.0" encoding="utf-8" ?>\r\n
<Autodiscover
xmlns="http://schemas.contoso.com/exchange/autodiscover/outlook/requestschema/
2006">\r\n
<Request>\r\n
<EMailAddress>[email protected]</EMailAddress>\r\n
<AcceptableResponseSchema>http://schemas.contoso.com/exchange/autodiscover/
outlook/responseschema/2006a</AcceptableResponseSchema>\r\n
</Request>\r\n
</Autodiscover>
The Outlook 2007 client will receive the following redirect response from contoso.com.
<?xml version="1.0" encoding="utf-8"?>\r\n
<Autodiscover
xmlns="http://schemas.contoso.com/exchange/autodiscover/responseschema/
2006"><Response
xmlns="http://schemas.contoso.com/exchange/autodiscover/outlook/responseschema
/2006a">\r\n
<Account>\r\n
<Action>redirectAddr</Action>\r\n
<RedirectAddr>[email protected]</RedirectAddr>\r\n
</Account>\r\n
</Response></Autodiscover>
The user will then be able to connect to the Autodiscover service by using this new e-mail address in the
mail2.contoso.com forest.
Before You Begin
To perform the following procedure on an Exchange 2007 Client Access server, the account you use must be
delegated the Exchange Server Administrator role and membership in the local Administrators group for the target
server.
To use the Exchange Management Shell to create a new mail contact for the Autodiscover service to handle cross-
forest mailbox moves
Copy Code
New-MailContact -ExternalEmailAddress 'SMTP:[email protected]' -
Name 'Kweku Ako Adjei' -Alias 'kwekua' -OrganizationalUnit
'contoso.com/Users' -FirstName 'Kweku' -Initials '' -LastName 'Ako
Adjei'
How to Configure Exchange Services for the Autodiscover Service

This section explains how to configure Microsoft Exchange services, such as the Availability service, for the
Autodiscover service on a Microsoft Exchange 2007 computer that has the Client Access server role installed.
When you enable Outlook Anywhere, you must also configure external access to Microsoft Exchange services for
the Autodiscover service. This includes the URLs for the Availability service, Exchange Web Services, Unified
Messaging (UM), and the offline address book.
If you do not configure the external URL values, the Autodiscover service information that is provided to the
Microsoft Office Outlook 2007 client may be incorrect for clients that are connecting from outside your network.
They may be able to connect to their Microsoft Exchange mailbox. However, they will be unable to use Exchange
features such as Out of Office functionality, the Availability service, Unified Messaging, or offline address book
downloads.
Generally, the internal URL is configured by Microsoft Exchange Setup and references the internal FQDN of the
Client Access server. However, the external URL values are NULL and must be configured by using the virtual
directory cmdlet for each component.
In this section, you will configure external host name, authentication, and encryption settings for the following Web
services:
 Outlook Anywhere
 Offline address book
 Unified Messaging
 Exchange Web Services
If you performed a custom installation of Exchange 2007 and you will not be using an Exchange service such as
Unified Messaging, you will not have to complete the procedure to configure the external URL for Unified Messaging
for the Autodiscover service later in this section. Additionally, if you are not providing external access to your
Exchange services, you can safely ignore these procedures.
Before You Begin
To perform the following procedures, the account you use must be delegated the Exchange Server Administrator
To use the Exchange Management Shell to configure the external host name for Outlook Anywhere for the
Autodiscover service
Copy Code
Enable-OutlookAnywhere -Server CAS01 -ExternalHostname
"mail.contoso.com" -ExternalAuthenticationMethod "Basic" -SSLOffloading:
$False
To use the Exchange Management Shell to configure the external URL for the offline address book for the
Autodiscover service
Copy Code
Set-OABVirtualDirectory -identity "CAS01\OAB (Default Web Site)" -
externalurl https://mail.contoso.com/OAB -RequireSSL:$true
To use the Exchange Management Shell to configure the external URL for Unified Messaging for the Autodiscover
service
Copy Code
Set-UMVirtualDirectory -identity "CAS01\UnifiedMessaging (Default Web
Site)" -externalurl
https://mail.contoso.com/UnifiedMessaging/Service.asmx -
BasicAuthentication:$True
To use the Exchange Management Shell to configure the external URL for Exchange Web Services for the
Availability service and Out of Office services
Copy Code
Set-WebServicesVirtualDirectory -identity "CAS01\EWS (Default Web Site)"
-externalurl https://mail.contoso.com/EWS/Exchange.asmx -
BasicAuthentication:$True
Autodiscover and ISA Server 2006
When an Exchange 2007 Client Access server is deployed with an advanced firewall server such as ISA Server
2006, you will typically create a Web Publishing rule for each application and use the same Web listener because
listeners in ISA Server 2006 can handle multiple authentication methods. Notice that the rule you create for
Outlook Anywhere has the option to include the Autodiscover virtual directory.
Note:
If Exchange 2007 will be deployed behind an ISA Server computer, see the documentation about how to
configure ISA Server in Publishing Exchange Server 2007 with ISA Server 2006.
Conclusion
This white paper provides the necessary information to enable you to deploy and configure the Autodiscover
service for your users. Use this information to help you define a deployment strategy for the Autodiscover service
to provide your users with the Microsoft Exchange features that you enable

Exchange 2007 Autodiscovery White Paper

Uploaded by

Copyright:

Available Formats

Exchange 2007 Autodiscovery White Paper

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Exchange 2007 Autodiscovery White Paper

Uploaded by

Copyright:

Available Formats

White Paper: Exchange 2007 Autodiscover Service

 How the Autodiscover Service Works with Clients

 How Outlook 2007 and Autodiscover Interoperate

 Autodiscover and Certificates

 Understanding the Exchange Setup Self-Signed Certificate

 Scenario 1: Using a Certificate That Supports Multiple DNS Names

 Scenario 2: Using One Single-Name Certificate

 Scenario 3: Using Two Single-Name Certificates

 Scenario 4: Using the Autodiscover Service with Redirection

 How to Configure the Autodiscover Service for Internet Access

 Scenario 1: How to Use a Certificate That Supports Multiple DNS Names

 Scenario 2: How to Use One Single-Name Certificate

 Scenario 3: How to Use Two Single-Name Certificates

 Optional Deployment Information for a Large-Scale Hosted Environment

 Additional Deployment Scenarios and Considerations for the Autodiscover Service

 How to Configure the Autodiscover Service to Use Site Affinity

 Configuring the Autodiscover Service for Multiple Forests

 Managing the Autodiscover Service

 How to Configure the Autodiscover Service for Cross Forest Moves

 How to Configure Exchange Services for the Autodiscover Service

 Autodiscover and ISA Server 2006

How the Autodiscover Service Works with Clients

 When a new Outlook profile is configured or updated

An Outlook 2007 client connects to the Autodiscover service as follows:

The Autodiscover service process for external access

How Outlook 2007 and Autodiscover Interoperate

 The user’s display name

 Separate connection settings for internal and external connectivity

 The location of the user’s Mailbox server

 Outlook Anywhere server settings

The Autodiscover Service and the Outlook Provider

There are three Outlook provider settings, as follows:

required for Exchange 2007.

How the Autodiscover Service Provides Settings to Outlook 2007

 Every time that the application starts

 At intervals on a background thread

 Any time that the client's connection to an Exchange server fails

Forcing Outlook 2007 to Update the User Profile Settings

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.

Autodiscover and Certificates

 The certificate is current and has not expired.

Understanding the Exchange Setup Self-Signed Certificate

Scenario 1: Using a Certificate That Supports Multiple DNS Names

Obtaining a Unified Communications Certificate

Scenario 3: Using Two Single-Name Certificates

Scenario 4: Using the Autodiscover Service with Redirection

Scenario Pros Cons

Single certificate  Easy to  Higher cost certificate type (Unified

One single-name  Easy to  Requires modification of SCP object and

 Supports all  Requires Outlook 2007 update rollup,

Two single-name  Lower cost than  Requires an additional public IP address

 Both sites are

Single certificate  Can be done by  Requires an additional public IP address

 Ideal for hosters

Single certificate  Smallest up-  Highest total cost of ownership for

How to Configure the Autodiscover Service for Internet Access

 Scenario 1: Using a certificate that supports multiple DNS names

 Scenario 2: Using one single-name certificate