All clients connect to the Client Access Server and, after authentication, the requests

are provide to the appropriate Mailbox Server. Communication between the client and
the Client Access Server is via the normal protocols (HTTP, IMAP4, POP3 and MAPI),
and communication between the Client Access Server and the Mailbox Server is via
Remote Procedure Calls (RPC).
There are seven client types:
Client

Protocol

Outlook

MAPI over RPC

Outlook Voice Access

RTP

Outlook Web App

HTTP/HTTPS

Exchange ActiveSync

HTTP/HTTPS

Outlook Anywhere

MAPI over RPC over HTTP/HTTPS

POP Client

POP3 (receive) / SMTP (send)

(Post Office Protocol)

IMAP Client

IMAP4 (receive) / SMTP (send)

As indicated before, the CAS is used for the following clients and services:
. Outlook MAPI
. Outlook Anywhere
. Availability service
. Autodiscover service
. Outlook Web App (OWA)
. ActiveSync
. POP3 and IMAP
The following functionality is provided by the Exchange Server 2010 Client Access
Server:
HTTP for Outlook Web App.
Outlook Anywhere (formerly known as RPC/HTTP) for Outlook 2003, Outlook 2007
and Outlook 2010.
ActiveSync for (Windows Mobile) PDAs.
Internet protocols POP3 and IMAP4.
MAPI on the Middle Tier (MoMT).

 Availability Service, Autodiscover and Exchange Web Services. These services are
offered to Outlook 2007 clients and provide free/busy information, automatic
configuration of the Outlook 2007 and Outlook 2010 client, the Offl ine Address Book
downloads and Out-of-Office functionality.
In Exchange Server 2010, Outlook MAPI clients connect to the CAS role servers.
This provides a consistent connection point and a single point to manage client access,
performance, and compliance.
This is by far the most common access client because most Outlook clients in a
companys internal network are Outlook MAPI clients. Outlook MAPI is also sometimes
referred to as Outlook RPC because RPC is the connection protocol.
Outlook Anywhere is the Exchange Server 2010 name for the original RPC over HTTP
feature in Exchange Server 2003.
For security, the Outlook Anywhere protocol is always implemented with Secure
Sockets Layer (SSL) to secure the transport, so it is actually RPC over HTTPS. This
ensures that the confidentiality and integrity of the Outlook Anywhere traffic is protected.
Outlook Anywhere is enabled by default in Exchange Server 2010
In Exchange Server 2010, the Availability service is web-based and is accessed via a
uniform resource locator (URL). The service can be load-balanced with Network Load
Balancing (NLB) and can provide free/busy information in trusted cross-forest
topologies.
It does the following tasks for the Outlook and OWA clients:
. Retrieve current free/busy information for Exchange Server 2010 mailboxes
. Retrieve current free/busy information from other Exchange Server 2010 organizations
. Retrieve published free/busy information from public folders for mailboxes on servers
that have versions of Exchange Server that are earlier than Exchange Server 2007
. View attendee working hours
. Show meeting time suggestions
The Availability service is installed by default on each CAS. Interestingly, there are no
Exchange Management Console options for the Availability service. All interaction with
the service is through the Exchange Management Shell.

The Exchange Server 2010 Autodiscover feature automatically generates a profile

from the users email address and password.
The Autodiscover service provides the following information to the clients:
. The users display name
. Separate connection settings for internal and external connectivity
. The location of the users mailbox server
. The URLs for various Outlook features
. Outlook Anywhere server settings
The Outlook Web App (OWA) is the full-featured Exchange Server 2010 web-based
client.
It is a component of the CAS server role. This client enables a user with a web browser
to access the Exchange Server 2010 infrastructure from the intranet or the Internet.
In addition to the email, calendaring, tasks, notes, and file access features, Exchange
Server 2010 includes a number of new features for the OWA client. These new features
include the following:
. Conversation View
. Presence and IM
. UM Voice Mail
. Calendar Sharing
. SMS Message Synchronization
. Improved Searching and Filtering
. Favorites Folders
. Message Delivery Reports
. Mail Tips Information
. Rights Management
. Group Management
The Exchange Control Panel (ECP) is hosted on the CAS server role and is an
exciting new tool in Exchange Server 2010. The ECP is a browser-based Management
client for end users, administrators, and specialists.
The ECP is AJAX-based, is deployed as a part of the Client Access server role, and
shares some code with OWA. However, the two are separate applications and sites.

Exchange ActiveSync is a synchronization protocol that allows mobile devices to

synchronize the users Exchange Server mailbox, including email, calendar, contacts,
and tasks.
ActiveSync supports the following devices:
. Windows Mobile 6.x and 5.0
. Pocket PC 2003
. Pocket PC 2002
The Exchange Server 2010 ActiveSync has a number of new features and improved
features over the Exchange Server 2003 version, including the following:
. Support for HTML messages
. Support for follow-up flags
. Support for fast message retrieval
. Meeting attendee information
. Enhanced Exchange Search
. Windows SharePoint Services and Universal Naming Convention (UNC) document
access
. PIN reset
. Autodiscover for over-the-air provisioning
. Support for Out of Office configuration
. Support for tasks synchronization
. Support for Direct Push
Exchange Server 2010 ActiveSync also has a number of new security features,
including the following:
. Exchange ActiveSync mailbox policies
. Device password policies
. Remote Device Wipe
The ActiveSync Remote Wipe function deletes the data off the device. Applications
and other program data remain on the system, only the data is removed. To
administratively remote wipe a device:

The Exchange Management Console can be used to wipe a device. This would typically
be done by an administrator after a device has been lost.
Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) are
legacy messaging protocols that are used mostly by home users and some third-party
applications.
Exchange Server 2010 supports them for backward compatibility and the services are
disabled by default. To use these protocols, the services must be started on the CAS.
The Exchange Server 2010 Unified Messaging Server role combines the mailbox
database and both voice messages and e-mail messages into one store. Using the
Unified Messaging Server role it is possible to access all messages in the mailbox using
either a telephone or a computer.
The Unified Messaging Server role provides users with the following features:
Call Answering this feature acts as an answering machine.
Subscriber Access sometimes referred to as Outlook Voice Access.
Auto Attendant using the Auto Attendant, it is possible to create a custom menu in
the Unified Messaging system using voice prompts
Dual Tone Multi Frequency (DTMF) also referred to as the touchtone Automatic
Speech Recognition.
Text-to-Speech service thats responsible for reading mailbox items and reading the
voice menus.
The Unified Messaging Server role should be installed in an Active Directory site
together with a Hub Transport Server, since this latter server is responsible for routing
messaging to the Mailbox Servers. It also should have a fast connection to a Global
Catalog server.
If possible, the Mailbox Server role should be installed as close as possible to the
Unified Messaging Server role, preferably in the same site and with a decent network
connection.

Introduction
Microsoft Exchange 2010 includes a service, introduced in Exchange 2007, called the
Autodiscover service. The Autodiscover service configures and maintains server settings for
client computers that are running Microsoft Outlook and many mobile devices. An important
function of the Autodiscover service is to provide access to features for clients that are connected
to your 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 clients to automatically connect to features. For more
information about how to configure features, see How to configure Exchange services for the
Autodiscover service later in this white paper.
How the Autodiscover service works with clients
When you install the Client Access server role on a computer that is running Exchange 2010, 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
clients in the following circumstances:
-

When a new Outlook profile is configured or updated

When a client periodically checks for changes to the Web Services URLs
When underlying network connection changes occur in your messaging environment

Additionally, a new service connection point (SCP) 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
FQDN for the Client Access server. The keywords attribute specifies the sites to which this SCP
record is associated. By default, this attribute specifies the site to which the Client Access server
belongs. When a domain-connected client connects to the directory service, the Exchange 2010
client authenticates to 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 client authenticates to 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 features.
An Outlook 2007 or Outlook 2010 client connects to the Autodiscover service as follows:
-

Outlook sends a Lightweight Directory Access Protocol (LDAP) query to Active

Directory looking for all available SCP objects. Specifically, Outlook initializes the
LDAP connection using the ldap_init() function and passes a NULL value for the

hostname. When a particular global catalog server name (or domain name) is not
specified, the operation searches for a global catalog server in the domain, based on the
membership of the computer that is initializing the operation.
Outlook sorts and enumerates the returned results based on the client's site by using the
keyword attribute of the SCP record. One of two lists is created, an in-site list or an outof-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 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.
Tip:
In environments where Outlook 2007 is deployed in remote sites that do not have Exchange
2010 Mailbox and Client Access servers, you can use site affinity to configure the SCP objects
for Outlook clients to use SCP objects that are physically closer. For more information, see
Configuring the Autodiscover service to use site affinity later in this white paper.

Outlook first tries to connect to each Autodiscover URL that it 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.
The Autodiscover service queries Active Directory to obtain the connection settings and
URLs for the Exchange services that have been configured.
The Autodiscover service returns an HTTPS response with an XML file that includes the
connection settings and URLs for the available Exchange services.
Outlook uses the appropriate configuration information and connection settings to
connect to your Exchange messaging environment.

For more information about SCP objects, see Publishing with Service Connection Points.
When Outlook 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 the right side of the users email
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/autodiscove
r.xml

https://autodiscover.contoso.com/autodiscove
r/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.
There is another option related to DNS that is made possible with an Outlook 2007 software
update and with Outlook 2010. With this update to Outlook 2007, or with Outlook 2010, the
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
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 or have to administer a second website.
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.
How Outlook and Autodiscover interoperate
The Autodiscover service makes it easier to configure and manage deployment of Outlook
clients. Versions of Exchange Server prior to Exchange 2007, and versions of Outlook prior to
Outlook 2007, required that you configure all user profiles manually. Extra work was required to
manage these profiles if changes occurred to the messaging environment. Otherwise, the clients
could stop functioning correctly.
The Autodiscover service uses a user's email address and domain account to automatically
configure the user's profile. By using the email address and domain account, the Autodiscover
service can provide the following information to the client:

The users display name

Separate connection settings for internal and

external connectivity

The location of the users Mailbox server

The URLs for various 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 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 2010
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 App 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

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 and Outlook 2010 automatically connect 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 that use the Autodiscover service: the
Outlook layer and the MAPI layer. The Outlook layer begins operating when you open Outlook
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 tries to contact an Exchange 2010 server.
If Outlook does not connect to the Autodiscover service, the Outlook layer will reconnect every
five 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 six hours to update the user's profile settings. The
MAPI layer also connects to the Autodiscover service if the user creates a new Outlook profile.
Forcing Outlook to update the user profile settings
Under most circumstances, Outlook 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 Exchange Server 2010 is deployed in the messaging environment of the Contoso company,
the IT administrator for Contoso upgrades the users to Outlook 2010. 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 2010. After enabling Outlook Anywhere, the administrator checks the
Outlook profile settings on an Outlook 2010 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 2010. 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 2010 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 users profile settings, use the
following steps:
1. Open Outlook 2010.
2. 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.

Tip:
For domain-connected clients, Outlook 2007 and Outlook 2010 are designed to ignore the first
validity check in the previous list. This design enables Outlook 2007 and Outlook 2010 to
function without any certificate warnings when Outlook uses the self-signed certificate that is
installed by Exchange Setup.
Understanding the Exchange self-signed certificate
When you install the Client Access server role, Exchange 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 certificates 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.
Tip:
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 clients to work
immediately after Exchange Setup has 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 clients can
immediately start to use Exchange 2010 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 an FQDN that maps to the external DNS
namespace those clients will be connecting to, for example, mail.contoso.com.
Tip:
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 clients connect to the Autodiscover service by using SSL, this introduces a new
challenge. Outlook 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 App or Exchange ActiveSync that 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 Autodiscover from the Internet
If you are providing external access to Autodiscover 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
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 messaging environment, the client locates the
Autodiscover service on the Internet by using the right side of the user's email 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-addressdomain>/autodiscover/autodiscover.xml

https://autodiscover.<smtp-addressdomain>/autodiscover/autodiscover.xml

For example, if the user's e-mail address is kwekua@contoso.com, 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. You should choose a method 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. However, using a Unified Communications
certificate may increase the cost, as this kind of certificate can be more expensive than the
single-name certificates that you already may own.

Tip:
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 ISA Server team blog article: Certificates with Multiple SAN Entries May
Break ISA Server Web Publishing and Microsoft Knowledge Base article 841664, Clients may
receive an "Error Code 500 Internal Server Error" error message when they try to visit a Web
site that you publish by using ISA Server 2006 or ISA Server 2004.
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.
You could also 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 a server that is running Exchange 2007 or Exchange 2010: "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 2010 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 2010. If this describes your situation, there are alternative solutions you can
implement to address these types of scenarios that will ultimately give you the same level of
functionality. One option is to obtain a second certificate and install it on a second website that
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 websites and public IP addresses.
The Default Web Site will host your primary Exchange features and services such as Outlook
Web App and Exchange ActiveSync while the second website will be used to host the
Autodiscover service.
Scenario 4: Using the Autodiscover service with redirection
If you cannot, or do not want to use Scenario 2: Using one single-name certificate and the
Autodiscover SRV record described earlier in this white paper, this kind of deployment scenario
may be the ideal solution to use in situations such as a hosted Exchange 2010 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 website 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 that 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 with
clients 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 website 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.
Tip:
Similar to using two single-name certificates, this solution also requires a second public IP
address that must be assigned to the second website.

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
total cost of ownership depending on your environment. The following table illustrates the pros
and cons associated with each solution.
Scenario

Pros

Single certificate
that supports
multiple DNS
names

One single-name
certificate and
website

Supports all client

connections
Microsoftrecommended best
practice

Easy to implement

Supports all client

connections

Least expensive

Ideal for hosters if

DNS provider
supports SRV
records

Two single-name
certificates and
websites

Single certificate

Easy to implement

Cons

Lower cost than

using Unified
Communications
certificate

Both sites are

secured with SSL

Can be done by

Higher cost certificate type (Unified

Communications certificate)

Requires additional configuration if used

together with either ISA Server 2004 or
ISA Server 2006

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 or Outlook
2010

DNS provider may not support

Autodiscover SRV record

Requires an additional public IP address

Complex to set up and maintain

Requires an additional public IP address

using your existing

certificate

No additional cost

Ideal for hosters if

DNS provider does
not support SRV
records

Smallest upfront
cost

with redirect

Single certificate
generated by
using Windows
Certificate
Services

Supports all client

connections

Somewhat complex to set up

Highest total cost of ownership for

administrators and end users

Important:
Whichever solution you implement to replace the default self-signed certificate, your internal
Outlook 2007 and Outlook 2010 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.
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 a server that is running Exchange Server 2007 or Exchange Server 2010: "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 lists the 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

website**

No

No

Yes

Yes

# of certificates

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 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.
The following procedures describe how to create a certificate request for submission to a thirdparty CA and when to use your own internal PKI by using Windows Certificate Services.

Step 1: Create the certificate request

Youll need to create the certificate request for submission to your third-party certification
authority (CA). On the Client Access server, open the Exchange Management Shell and enter the
following code.
Copy
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"

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"

Tip:
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 Server computers.
After you request the certificate, see "Step 2: Install the Certificate" later in this section.
In Exchange 2007, the New-ExchangeCertificate cmdlet allowed you to save the certificate
request to a file that you specified using the Path parameter. In Exchange 2010, you must either
copy the output of the New-ExchangeCertificate cmdlet or use the following syntax to send the
data to a file.
Copy
$Data = 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"

Then run the following cmdlet to save the information stored in the Data variable to a file.
Copy
Set-Content -path "C:\Docs\MyCertRequest.req" -Value $Data

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

To create a certificate request internally by using Windows Certificate Services, use the
following steps:
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.
Tip:
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
New-ExchangeCertificate
-GenerateRequest -DomainName
mail.contoso.com,
autodiscover.contoso.com
-PrivateKeyExportable:$True

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 App, Exchange ActiveSync, and Outlook
Anywhere. See the previous note regarding how to save the certificate request to a file.
Tip:
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
New-ExchangeCertificate
-GenerateRequest -DomainName
mail.contoso.com,
autodiscover.contoso.com,
machinename,
machinename.contoso.local
-PrivateKeyExportable:$True

4. On your Client Access server, open Internet

Explorer and enter the URL to connect to the
Certificate Services administration webpage
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 click Submit a
certificate request by using a base-64encoded CMC or PKCS #10 file.
6. Copy the contents of the certreq.txt file that
you saved in step 3 or the output of the New
ExchangeCertificate cmdlet in the Saved
Request field.
7. Click Web Server under Certificate
Template and click Submit.
8. Click Download certificate and then save the
CER file to Drive C, that is c:\certnet.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.
Tip:
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 website.

To install and enable an SSL certificate, open the Exchange Management Shell on the Client
Access server and run the following command.
Copy
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path
c:\certnew.cer.-Encoding byte -ReadCount 0)) -Password:(GetCredential).password
| Enable-ExchangeCertificate -Services iis

Step 3: (Optional) Administer and use root certificates for end users
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 domainconnected 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.
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 or Windows 7, 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, use the following steps:
1. Open Internet Explorer on a domainconnected computer, and then enter the URL
to connect to the Certificate Services
administration webpage.
2. Select the Download a CA certificate,
certificate chain or CRL option, and then
select Download a CA certificate.
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 email, an FTP site, or other method.
To install the SSL certificate on your Outlook 2007 and Outlook 2010 clients, use the following
steps:
1. Copy the root certificate to the desktop.

2. Select the root certificate and open it.

3. In the Certificate dialog box, on the General
tab, click Install Certificate.
4. In the Certificate Import Wizard, click Next.
5. Click Place all certificates in the following
store and then click Browse.
6. In the Select Certificate Store window, click
Trusted Root Certification Authorities and
then click OK.
7. Click Next and then click Finish.
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
App, 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 and Outlook 2010 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.

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 a default website
The procedures in the following section assume that you already have obtained a valid thirdparty 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: Use an existing SSL certificate
The following procedures describe how to use an existing SSL certificate that you have already
implemented for a version of Exchange prior to Exchange Server 2007. Instructions for
exporting a certificate on Exchange 2007 are also provided. To use an existing SSL certificate
from a version of Exchange prior to Exchange 2007, use the following steps.
1. In IIS Manager, open the properties of the
Default Web Site, and then click the
Directory Security tab.
2. Click Server Certificate.
3. In 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 click Next, then click
Next again and click Finish.
6. Import the certificate to the Personal Store by
using the following steps:

1. In the Certificates snap-in for MMC,

expand the top-level Certificates
(Local Computer).
2. Open the options menu of the
Personal node, 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 for Mark this Key as
Exportable.
5. Click Place all certificates in the
following store, click Personal
Certificate Store, click Next, and
then click Finish.
7. Determine the Thumbprint attribute of the
imported certificate. To do this, open the
Exchange Management Shell and run the
following command.
Copy
Get-ExchangeCertificate | fl

8. Locate the certificate that you just imported,

copy the certificates thumbprint, and then
run the following command.
Copy
Enable-ExchangeCertificate
-Thumbprint
<thumbprint_of_new_certificate>
-Services iis

To use an existing SSL Certificate from Exchange 2007, use the following steps:

1. On the Client Access server, open the

Exchange Management Shell and then run the
following command. This will return a list of
all existing certificates. You will then need to
copy the thumbprint value of the certificate
you need.
Copy
Get-ExchangeCertificate -DomainName
mail1.contoso.com

2. Using the thumbprint you obtained in step 1,

export the certificate to a file. The thumbprint
value shown is provided for example
purposes only.
Copy
Export-ExchangeCertificate
-Thumbprint
5113ae0233a72fccb75b1d0198628675333d0
10e -BinaryEncoded:$true -Path
c:\certificates\export.pfx -Password:
(Get-Credential).password

Option 2: Use a new single-name certificate

You can use the Exchange Management Shell on your Client Access server to install and enable
your new third-party certificate with the following code.
Copy

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path

c:\certificates\ExportedCert.pfx -Encoding byte -ReadCount 0)) -Password:(GetCredential).password | 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 2010 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. In the Exchange Management Shell, run the
following command.
Copy
Set-ClientAccessServer -identity <servername> -AutodiscoverServiceInternalUri
https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Important:

You must repeat this step for every Client Access server that is installed in your Exchange
messaging infrastructure.
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: Implement 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 and Outlook 2010 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. Outlook 2010 includes this 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 websites 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 website.
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. Outlook 2010 contains this functionality, so no update is required for Outlook
2010 clients.
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 websites 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 or the use of Outlook 2010 for all of your clients. 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 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 of 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 website.
Step 1: Add 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. Use the following steps.
1. On the Exchange 2010 Client Access server,
open the properties of your network adapter.
2. Click 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 and click Add.
Step 2: Create the 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 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 steps are used 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.
1. Open DNS Manager and expand the Forward
Lookup Zones container.
2. Open the context menu for 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.
Tip:
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 website
The procedures in the following section assume that you already have obtained a valid thirdparty 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: Use an existing SSL certificate
The following procedures describe how to use an existing SSL certificate that you have already
implemented for a version of Exchange prior to Exchange Server 2007. Instructions for
exporting a certificate on Exchange 2007 are also provided. Using IIS Manager on your earlier
version of Exchange, export the existing certificate in PFX format by following these steps.
1. In IIS Manager, open the context menu for
the Default Web Site, click Properties, and
then click the Directory Security tab.

2. Click Server Certificate.

3. In 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 click Next, then click
Next again and click Finish.
6. Import the certificate to the Personal Store by
using the following steps.
1. In the Certificates snap-in for MMC,
expand the top-level Certificates
(Local Computer).
2. Open the context menu for the
Personal node, 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 for Mark this Key as
Exportable.
5. Click Place all certificates in the
following store, click Personal
Certificate Store, click Next, and
then click Finish.
7. Determine the Thumbprint attribute of the
imported certificate. To do this, open the
Exchange Management Shell and run the
following command.
Copy
Get-ExchangeCertificate | fl

8. Locate the certificate that you just imported,

copy the certificates thumbprint, and then
run the following command.
Copy
Enable-ExchangeCertificate
-Thumbprint
<thumbprint_of_new_certificate>
-Services iis

To use an existing SSL certificate from Exchange 2007, use the following steps.
1. On the Client Access server, open the
Exchange Management Shell and then run the
following command. This will return a list of
all existing certificates. You will then need to
copy the thumbprint value of the certificate
you need.
Copy
Get-ExchangeCertificate -DomainName
mail1.contoso.com

2. Using the thumbprint you obtained in step 1,

export the certificate to a file. The
Thumbprint value shown is provided for
example purposes only.
Copy
Export-ExchangeCertificate
-Thumbprint
5113ae0233a72fccb75b1d0198628675333d0
10e -BinaryEncoded:$true -Path
c:\certificates\export.pfx -Password:
(Get-Credential).password

Option 2: Use a new single-name certificate

You can use the Exchange Management Shell on your Client Access server to install and enable
your new third-party certificate with the following code.
Copy

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path

c:\certificates\ExportedCert.pfx -Encoding byte -ReadCount 0)) -Password:(GetCredential).password | Enable-ExchangeCertificate -Services iis

Step 4: Configure the Default Web Site

The next step in this process is to configure the Default Web Site by using IIS Manager. Use the
following steps.
1. In IIS Manager, expand Web Sites, open the
context menu for 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, then Edit, and change the
IP assignment for port 443 to the Primary IP
address.
Step 5: Configure the Autodiscover website
The next step in this process is to configure the Autodiscover website by using IIS Manager. Use
the following steps.
1. In IIS Manager, open the context menu for
the Web Sites node, click New, and then
click Web Site.
2. When the Web Site Creation Wizard
launches, click Next.
3. On the Web Site Description page, in the
Description field, enter a name for your
website and 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 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: Install a certificate to the Autodiscover website
The following procedure in this section assumes that you have already obtained a valid thirdparty certificate with the common name users will be using to connect to the Autodiscover
service, for example, autodiscover.contoso.com. Because the Enable-ExchangeCertificate
cmdlet only works for certificates installed on the Default Web Site, you must use IIS Manager
to install this certificate on the Autodiscover website. To use the Exchange Management Shell
and IIS Manager to install and enable a third party certificate, use the following steps.
1. In the Exchange Management Shell, enter the
following command to import the second
certificate into the Personal Certificate store
on the server.
Copy
Import-ExchangeCertificate -FileData
([Byte[]]$(Get-Content -Path
c:\certificates\ExportedCert.pfx
-Encoding byte -ReadCount 0))
-Password:(Get-Credential).password

2. In IIS Manager, expand Web Sites, from the

context menu of the Autodiscover Web Site,
click Properties.
3. On the Directory Security tab, click Server
Certificate.
4. When the Web Server Certificate Wizard
opens, click Next.
5. On the Server Certificate page, click 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 website 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 website in IIS, you will use the Exchange
Management Shell to create a new Autodiscover virtual directory by running the following
command. The name of the website is case-sensitive.
Copy
New-AutodiscoverVirtualDirectory -WebSite "Autodiscover Web Site"

Step 8: Modify the SCP object

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 2010 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. Use the following command.
Copy
Set-ClientAccessServer -identity <servername> -AutodiscoverServiceInternalUri
https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Important:
You must repeat this step for every Client Access server in your Exchange messaging
infrastructure.
Step 9: 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.
Summary of Scenario 3
After you configure Exchange to use two single-name certificates and websites, domainconnected 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 website. Because each website 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 website
The following section describes how to configure the Autodiscover service when you use one
single-name certificate with an SSL website in addition to a second website responsible for
redirecting incoming requests over port 80 to the Autodiscover virtual directory set to accept
requests over port 443.
Tip:
If you are a large-scale hoster and unable to implement Scenario 2, review the optional
information that appears after the following steps.
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: Add a second IP address to your network adapter
To add a second IP address to your network adapter, use the following steps.
1. On the Exchange 2010 Client Access server,
open the properties of your network adapter.
2. Click 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 add
an additional host record for the Autodiscover service so that Outlook 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.
1. Open DNS Manager and expand the Forward
Lookup Zones container.

2. Open the context menu for your DNS zone,

for example, contoso.com, and then click
New Host (A).
3. Enter "autodiscover" and the second IP
address that 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 that is assigned to the Default
Web Site.
Step 3: Configure the Default Web Site
Use the following steps to configure the default website.
1. In IIS Manager, open the context menu for
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 steps are used to create a new Autodiscover directory structure that will be used
by the Autodiscover redirect website that you create in the next step.
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 website
Use the following steps to create the Autodiscover redirect website.
1. In IIS Manager, open the context menu for
the Web Sites node, and then click New Web
Site.
2. In the New Web Site Wizard, in the
Description box, enter the name of the
website, 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 website and select
the Autodiscover virtual directory under the
website.
6. In the right pane, open the context menu for
the autodiscover.xml file, and then click
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 App, Exchange ActiveSync, and
Outlook Anywhere, for example,
https://mail.contoso.com/autodiscover/autodis
cover.xml.
Step 6: Modify the service connection point object

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 2010 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.
To use the Exchange Management Shell to change the internal URL for the Autodiscover service,
run the following code.
Copy
Set-ClientAccessServer -AutodiscoverServiceInternalUri
https://mail.contoso.com/autodiscover/autodiscover.xml

Step 7: Configure the Web 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.
Optional deployment information for a large-scale hosted environment
For large-scale hosted environments, using a single redirect website 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 websites 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). You may also host the Autodiscover service on a dedicated web server if you
want.
In this scenario, you create separate websites, each with its corresponding DNS entries for each
hosted email 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.
To configure this kind of scenario, in IIS Manager, configure redirection for each of your sites by
modifying each websites autodiscover.xml file so that it points to
https://mail.contoso.com/autodiscover/autodiscover.xml.
Tip:
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/autodiscove
r.xml

https://autodiscover.contoso.com/autodiscove
r/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 email. When this occurs, a warning message is displayed in Outlook that says: Allow
this website to configure server settings?
Outlook lets users turn off the option for this warning message to continue to appear. We
recommend that you instruct users to turn off the warning message on their clients. Or, you can
suppress the Autodiscover redirect warning for HTTP and SRV redirections. To do this, see
Microsoft Knowledge Base article 956528, You cannot suppress the Autodiscover redirect
warning in Outlook 2007.
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 deployments. For the
Autodiscover service to function correctly, you must make sure that your organization meets the
following requirements:

You must have at least one Client Access

server installed in each Active Directory site
where users mailboxes reside for your
deployment. For 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 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 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 sites are preferred for clients to
connect to a particular Autodiscover service instance. Specifying which 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 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 Europecontoso 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 site. To do this, use the
following command.
Copy

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 client is a member of the UScontoso 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 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

Set-ClientAccessServer -Identity "apac-cas" -AutodiscoverServiceInternalURI

"https://internal.contoso.com/autodiscover/autodiscover.xml"
-AutoDiscoverSiteScope "apac-contoso","europe-contoso"

The previous command ensures the following:

If an Outlook 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 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 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 with the following command.
Copy
Set-ClientAccessServer -Identity "europe-cas" -AutodiscoverServiceInternalURI
"https://internal.contoso.com/autodiscover/autodiscover.xml"
-AutoDiscoverSiteScope "us-contoso", "europe-contoso", "apac-contoso"

The previous command ensures that Outlook 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, 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 access either 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.
Configuring 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
2010 that has the Client Access server role installed. Run the following command.
Copy
Set-ClientAccessServer -Identity "ServerName" -AutodiscoverServiceInternalURI
"https://internalsitename/autodiscover/autodiscover.xml" AutoDiscoverSiteScope
"SiteName"

Configuring the Autodiscover service for multiple forests

You can deploy 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 are deployed in a separate forest (known as a resource forest).
In this scenario, the following will occur:
1. The Outlook client contacts the user account
forest to locate the URL for the Autodiscover
service. Because the service is hosted in the
resource forest, you must update the user
account forest to include the information that
is required to enable the client to access the
resource forest. To do this, you must create an

Autodiscover SCP pointer record 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:
1. 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.
2. 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.
Tip:
To synchronize Active Directory sites between forests, see "Synchronizing Sites and Subnets" in
Multiple Forest Considerations in Windows 2000 and Windows Server 2003.
Configuring the Autodiscover service in a multiple trusted forest topology
In the multiple trusted forest scenario, the user accounts are deployed in multiple forests.
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 ExportAutoDiscoveryConfig cmdlet from each forest that has the Autodiscover service against each
target forest where is deployed.
How to configure the Autodiscover service when you use multiple forests
If your deployment has two or more trusted forests, you must update so that users who are
running 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 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
Exchange 2010. Or, you can manually create the root Autodiscover SCP record container in the
user forest.
To use the Exchange Management Shell to configure the Autodiscover service for multiple
forests, use the following steps.
1. On a 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
$a = Get-Credential

2. On a Client Access server in the resource

forest, run the following command:
Copy
Export-AutoDiscoverConfig
-DomainController <FQDN>
-TargetForestDomainController
<String> -TargetForestCredential $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 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 email address. The client
will then try to contact the Autodiscover service by using the new email address against the new
forest.
For example, contoso.com and fourthcoffee.com are separate, trusted forests and the mailbox for
a user is kwekua@contoso.com. 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 Shell.
Copy
New-MailContact -ExternalEmailAddress 'SMTP:kwekua@fourthcoffee.com' -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 client.
The client will receive the following redirect response from contoso.com.
The user will then be able to connect to the Autodiscover service by using this new email address
in the mail2.contoso.com forest.
To use the Exchange Management Shell to create a new mail contact for the Autodiscover
service to handle cross-forest mailbox moves, run the following command.
Copy
New-MailContact -ExternalEmailAddress 'SMTP:kwekua@fourthcoffee.com' -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 services, such as the Availability service, for the
Autodiscover service on a computer that has the Client Access server role installed.When you
enable Outlook Anywhere, you must also configure external access to services for the
Autodiscover service. This includes the URLs for the Availability service, 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 client may be incorrect for clients that are connecting from outside your network.
They may be able to connect to their mailbox. However, they will be unable to use features such
as Out of Office functionality, the Availability service, Unified Messaging, or offline address
book downloads.
Generally, the internal URL is configured by 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

Web Services

If you performed a custom installation of Exchange 2010 and you will not be using an 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 services, you can safely ignore these procedures.
Important:
The following procedures assume that you are using a Unified Communications certificate that
supports multiple DNS names, as discussed in Scenario 1: Using a certificate that supports
multiple DNS names earlier in this white paper. If you have configured the Autodiscover service
by following Scenario 2: Using one single-name certificate and the Autodiscover SRV record or
Scenario 3: Using two single-name certificates, you must also modify the internal URL of each
Exchange service so that the FQDN in the URL references the common name of the certificate
on the Default Web Site. For example, you must set the internal URL to
https://mail.contoso.com/ews/exchange.asmx.
To use the Exchange Management Shell to configure the external host name for Outlook
Anywhere for the Autodiscover service, run the following command.
Copy
Enable-OutlookAnywhere -Server CAS01 -ExternalHostname "mail.contoso.com"
-DefaultAuthenticationMethod "Basic" -SSLOffloading:$False

To use the Exchange Management Shell to configure the external URL for the offline address
book for the Autodiscover service, run the following command:
Copy

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, run the following command:
Copy

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, run the following command:
Copy

Set-WebServicesVirtualDirectory -identity "CAS01\EWS (Default Web Site)"

-externalurl https://mail.contoso.com/EWS/Exchange.asmx -BasicAuthentication:
$True

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.