Planning for Client Access Servers
[This is pre-release documentation and subject to change in future releases. This topic's current status is: Writing.]
Applies to: Exchange Server 2010 Beta* *Topic Last Modified: 2009-02-18
This topic provides an overview of planning considerations for deploying the Client Access server role on a computer that's running Microsoft Exchange Server 2010. The Client Access server role supports the Outlook Web Access, Outlook Anywhere, and Microsoft Exchange ActiveSync client applications, in addition to the Post Office Protocol version 3 (POP3) and Internet Message Access Protocol version 4rev1 (IMAP4) protocols. The Client Access server role also hosts several key services, such as the Autodiscover service and Exchange Web Services.
You must have the Client Access server role installed in every Active Directory site within your organization that contains an Exchange 2010 server that has the Mailbox server role installed. If your organization has only one Active Directory site, the Client Access server role must be installed on at least one computer within your Exchange organization.
You can install the Client Access server role on an Exchange 2010 computer that's running any other server roles except for the Edge Transport server role. You can't install the Client Access server role on a computer that's installed in a cluster. Installation of a Client Access server in a perimeter network isn't supported.
Overview of the Client Access Server Role Features
The Client Access server role manages client access to your Exchange 2010 server. The following client applications require the Client Access server role:
Exchange ActiveSync Users can establish a partnership between their Exchange server and their mobile device by using Exchange ActiveSync. Users can synchronize e-mail messages, contacts, tasks, and calendar data.
Exchange ActiveSync can synchronize messages in all the mail folders that are stored on the Exchange Server server, except for the Drafts and Outbox folders.
Outlook Web Access Users can access their Exchange mailbox data from a Web browser by using Outlook Web Access. The virtual directories for Outlook Web Access are stored on the Client Access server.
Outlook Web Access isn't supported with Pocket Internet Explorer on a mobile device.
Outlook Web Access in Exchange 2010 is accessed by using the URL https://servername/owa. To access public folders through Outlook Web Access in Exchange 2010, use the URL https://servername/public. Outlook Web Access for earlier versions of Exchange is accessed through the URLs https://servername/exchange, https://servername/exchweb, and https://servername/public. If your users have mailboxes on an Exchange 2000 or Exchange 2003 server, they must use these legacy URLs.
Microsoft Office Outlook Although Office Outlook 2007 accesses Microsoft Exchange messaging data directly on the Mailbox server, it relies on the Client Access server role for such services as the Autodiscover service and the Availability service.
Outlook Anywhere Outlook can connect to your Exchange mailbox over the Internet without using a VPN connection to your internal network if you've enabled Outlook Anywhere. Outlook Anywhere was formerly known as RPC over HTTP.
POP3 and IMAP4 Clients If your users connect to Exchange 2010 using a POP3 or IMAP4 client, their connections will pass through the Client Access server. When Exchange 2010 is installed, all required services for POP3 and IMAP4 are installed. But they're disabled. To use POP3 or IMAP4 to connect to Exchange 2010, you must enable either the POP3 service or the IMAP4 service.
In addition to providing a connection point for client applications, the Client Access server role provides support for the following services:
- Autodiscover service Exchange 2010 includes a new Microsoft Exchange service named the Autodiscover service. The Autodiscover service configures client computers that are running Outlook 2007. The Autodiscover service can also configure supported mobile devices. The Autodiscover service provides access to Microsoft Exchange features for Outlook 2007 clients connected to your Exchange messaging environment. The Autodiscover service must be deployed and configured correctly for Outlook 2007 clients to automatically connect to Microsoft Exchange features, such as the offline address book, the Availability service, and Unified Messaging (UM). Additionally, these Exchange features must be configured correctly to provide external access for Outlook 2007 clients. For more information, see Configure Exchange Services for the Autodiscover Service.
- Exchange Web Services Exchange Web Services provides the functionality to enable client applications to communicate with the Exchange server. Exchange Web Services provides access to much of the same data made available through Outlook. Exchange Web Services clients can integrate Outlook data into line-of-business (LOB) applications. LOB applications that use Exchange Web Services can use the Autodiscover service to obtain profile settings for a particular client.
Understanding the Differences Between a Front End Server and a Client Access Server
Earlier versions of Microsoft Exchange supported a front-end server inside an organization. A computer that's running the Exchange 2010 Client Access server role is very different from an Exchange 2003 front-end server. In earlier versions of Microsoft Exchange, the front-end server accepted requests from clients and sent them to the appropriate back-end server for processing. This provided increased capacity for the number of concurrent client sessions in an organization and decreased the load on the back-end server that housed the mailboxes. A front-end server was frequently located in a perimeter network between the external and internal firewalls. One of the primary advantages to a front-end server was the ability to expose a single, consistent namespace when multiple back-end servers were present. Without a front-end server, Outlook Web Access users would have to know the name of the server that stored their mailbox. By including a front-end server, users could access a single URL for Outlook Web Access. The front-end server would proxy the user's request to the appropriate back-end server.
In Exchange 2007, the Client Access server role was designed specifically to optimize the performance of the Mailbox server role by handling much of the processing that previously occurred on back-end servers. Business logic processes, such as Exchange ActiveSync mailbox policies and Outlook Web Access segmentation, are now performed on the Client Access server instead of the Mailbox server. Because the Mailbox server role relies on the Client Access server role to handle incoming client connections, each Active Directory site that has a Mailbox server must also have a Client Access server. Both roles can run on one physical computer. If you have multiple Active Directory sites and want a single external URL for Outlook Web Access or Exchange ActiveSync, you must configure your Client Access servers for proxying.
An Exchange 2010 computer that's running the Client Access server role uses the Exchange RPC protocol to connect to the Mailbox server that it services. You must use a high-bandwidth and low-latency connection between the Client Access server and the Mailbox server. The minimum recommended bandwidth is 100 Mbps, but 1-Gpbs connections should be considered for enterprise datacenters.
Planning Considerations for Exchange ActiveSync
Exchange ActiveSync is a Microsoft Exchange synchronization protocol that's optimized to work together with high-latency and low-bandwidth networks. Exchange ActiveSync is based on HTTP and XML and lets devices such as browser-enabled cellular telephones or Windows Mobile phones access an organization's information on an Exchange server. Exchange ActiveSync enables mobile device users to access their e-mail, calendar, contacts, and tasks, and to continue to be able to access this information while they're working offline.
Exchange ActiveSync can synchronize e-mail messages, calendar items, contacts, and tasks. You can't use Exchange ActiveSync to synchronize notes in Outlook.
When you deploy Exchange ActiveSync, consider the following issues:
Exchange ActiveSync devices There are several devices that support Exchange ActiveSync. These devices include Windows Mobile phones and other third-party devices. For more information about the devices that support Exchange ActiveSync, see Exchange ActiveSync Devices and Compatible Features.
Device data plans Exchange ActiveSync uses a process that is known as Direct Push to keep messaging data synchronized with mobile phones. With Direct Push, data is exchanged over cellular connections. If your users' data plans charge by the minute or the megabyte, the monthly cost can quickly escalate. To use Direct Push with Exchange ActiveSync, your users should have an unlimited data plan with their cellular carrier.
Direct Push doesn't work over a Wi-Fi Internet connection, such as an 802.11b connection. Direct Push works only over a cellular data connection.
Exchange ActiveSync security You should have a security plan in place when you deploy Exchange ActiveSync. We strongly recommend that you use Secure Sockets Layer (SSL) with Exchange ActiveSync. By default, when you install Exchange 2007, Exchange ActiveSync is enabled for your users. The Exchange ActiveSync virtual directory is configured to use Basic authentication with SSL. You can configure the Exchange ActiveSync virtual directory to use Integrated Windows authentication or certificate-based authentication.
In addition to configuring authentication, we recommend that you deploy Exchange ActiveSync mailbox policies to control many settings for your mobile users and their devices. You can require a password, allow or block attachment downloads, require device encryption, specify the maximum number of failed passwords, and enable password recovery. For more information about Exchange ActiveSync mailbox policies, see Understanding Exchange ActiveSync Mailbox Policies.
**Migrating from Exchange Server 2003 to Exchange Server 2007 **If you are migrating from Exchange Server 2003 to Exchange 2007, we recommend that you first upgrade your front-end servers to the Client Access server role. You must enable Integrated Windows authentication on the Exchange Server 2003 back-end server for Exchange ActiveSync to function correctly. After you migrate all front-end servers to Exchange 2007, you can migrate your back-end servers to Exchange 2007 Mailbox servers.
Planning Considerations for Outlook Web Access
Outlook Web Access uses an Internet browser to provide access to Exchange information. Outlook Web Access has a powerful, intuitive interface that resembles Outlook 2007 without the need to install Outlook 2007 on the computer. When you deploy your Exchange messaging infrastructure for Internet-based external access, users can use any computer in any location that has an Internet browser that supports HTML 3.2 and European Computer Manufacturers Association (ECMA) formats. Such browsers include Internet Explorer, Mozilla Firefox 1.8, Opera 7.54, and Safari 1.2.
Outlook Web Access supports most of the features found in Outlook 2007. By default, all client features are enabled. For more information about the client features that are available in Outlook Web Access, see Client Features in Outlook Web Access.
You may want to limit the features available to users through Outlook Web Access, depending on your organization's security and information management needs. For information about how to enable and disable features by using the Exchange Management Console and the Exchange Management Shell, see Managing Outlook Web Access.
Outlook Web Access for Exchange 2010 offers several enhancements in security. You can configure SSL on the Outlook Web Access virtual directory in addition to standard and forms-based authentication. You can configure the following authentication methods for Outlook Web Access by using the Exchange Management Console or the Exchange Management Shell:
Standard authentication methods Standard authentication methods include Integrated Windows authentication, Digest authentication, and Basic authentication. For more information about how to configure standard authentication methods for Outlook Web Access, see Configuring Standard Authentication Methods for Outlook Web Access.
If you configure multiple authentication methods, Internet Information Services (IIS) uses the most secure method first. IIS then searches the list of available authentication protocols, starting with the most secure, until it finds an authentication method that is supported by both the client and the server.
By default, when you install the Client Access server role on an Exchange 2010 server, four Outlook Web Access virtual directories are created in the default IIS Web site on the Exchange server. By default, these virtual directories and the default Web site are configured to require SSL. For more information about how to configure SSL for Outlook Web Access, see Configure Outlook Web Access Virtual Directories to Use SSL.
If you want to use SSL to help secure additional Outlook Web Access virtual directories or Web sites, you must do so manually. To configure a site to use SSL, you must obtain a certificate and configure the Web site or virtual directory to require SSL by using that certificate.
Planning Considerations for Outlook Anywhere
Outlook Anywhere enables users who are running Exchange 2010, Outlook 2007 or Outlook 2003 to connect to your Microsoft Exchange messaging infrastructure from the Internet using the Outlook Anywhere networking technology.
After you install the Client Access server role on an Exchange 2010 server, you can enable Outlook Anywhere for your organization by using the Enable Outlook Anywhere wizard on any Client Access server in your organization. We recommend that you enable at least one Client Access server for Outlook Anywhere access in each site that you manage.
Before you plan your Outlook Anywhere deployment, make sure you've read the following topics:
Planning Considerations for POP3 and IMAP4
Exchange 2010 provides support for clients that use the POP3 and IMAP4 protocols. However, by default, the POP3 and IMAP4 services aren't started in Exchange 2010. To use these protocols, you must first start the POP3 and IMAP4 services on the Client Access server.
There is no user interface in the Exchange Management Console for POP3 and IMAP4. To manage these protocols, you must use the Exchange Management Shell.
When you deploy Client Access servers to support POP3 and IMAP4 clients, there are physical limitations and security limitations if you use earlier versions of Microsoft Exchange, such as Exchange Server 2003. The main physical limitation in deploying POP3 and IMAP4 is that cross-site communication between Client Access servers and Mailbox servers in separate Active Directory sites isn't supported. You must make sure that clients are connecting to the Client Access server located in the same site as the Mailbox server that contains their mailbox.
Planning Considerations for Exchange 2010 Web Services
An Exchange 2010 Client Access server supports two Web services: Exchange Web Services and the Autodiscover service.
Exchange Web Services provides access to:
- Free/busy information, meeting suggestions, and Out of Office functionality.
- Calendar, e-mail, contact, folder, and task items in a user's mailbox.
- Notifications about events that occur in a user's mailbox.
- Synchronization features to synchronize clients with the associated mailbox.
- Ambiguous name resolution.
- Distribution list expansion.
The Autodiscover service enables clients such as Outlook, custom applications, and some mobile devices to obtain settings for many services such as the Availability service, Unified Messaging, and the offline address book (OAB). Clients try to connect to the Autodiscover service through the following two URLs that are based on the user's SMTP address:
Outlook submits an XML request that includes the user's e-mail address. The Autodiscover service returns configuration information about the user in addition to the URLs and settings that are used to connect to different services. Exchange Web Services also provides a developer API for customers and partners to write their own custom applications. These custom applications can then interact with Exchange mailbox data.
Security Planning for Client Access Servers
There are many things to consider when you plan a secure messaging environment. Factors such as e-mail attachments and access to internal and external corporate data make it important to consider multiple security precautions before you deploy your messaging environment. We recommend that you use SSL encryption for all Client Access features, including Outlook Web Access and Outlook Anywhere. Additionally, we recommend that you select an authentication method such as Integrated Windows authentication, instead of Basic authentication. Basic authentication transmits user names and passwords in clear text. Choosing an alternative authentication method improves the security of your communications. You can customize each Client Access feature to use different security mechanisms.
One method to help you make your messaging environment more secure is to deploy an advanced firewall server solution such as Microsoft Internet Security and Acceleration (ISA) Server 2006. ISA Server 2006 helps provide an additional level of security and can also enhance client functionality through new features that are designed for Exchange 2010 and ISA Server 2006.