Exchange Server's Client Access: An Introduction

The Client Access server role, which debuted in Microsoft Exchange Server 2007, gets a significant increase in responsibility in Exchange Server 2010: It now handles mailbox access for all client connections. Because of the emphasis that's being placed on the Client Access role, it makes sense to gain a better understanding of the role and how to plan for its deployment. This article is the first of a series that will take an in-depth look at this vital Exchange role. I'll start by helping you understand what the Client Access role does and what you should consider when planning your Client Access server infrastructure. In future articles, I'll walk you through the deployment and configuration of your Client Access servers, show you how to make them resilient against failures, make them more secure, and help you keep them healthy.

Overview of the Client Access Role

The Client Access server role is one of five potential server roles in Exchange. It can be combined on the same server with the Mailbox, Hub Transport, and Unified Messaging roles. However, regardless of the combination of roles, you'll need to ensure that the hardware (processor, memory, hard disks, and network connections) is sized to handle the workloads of each role. I'll explore sizing considerations later in this article.

Also, depending on which roles you group together, you might be limited in which security policies and hardening measures you can apply to the server. For example, if you have the Mailbox role and Client Access role combined on the same server, you make the Mailbox role vulnerable because it will have additional services installed and exposed. Each role has its own set of responsibilities, and the Client Access server doesn't exactly have a light load. Many people think of the Client Access role as only providing the interface for web-based email, but in reality it does much more, particularly in Exchange 2010. But before we dive into Exchange 2010 specifically, I'd like to walk you through the basic functionality that the Client Access server brings to the table.

In Exchange 2007, the Client Access server role was introduced to remove some of the burden from Mailbox servers and to provide a common entry point into the organization for client protocols, including connections from web browsers, mobile phones, or even email clients over the Internet. As a result, resources on the Mailbox server role are freed up so they can be focused on working with the messaging data. Also, your Mailbox servers are more secure because it's less likely that administrators will run services on them that are used by external clients—but hopefully you were doing this part anyway with a reverse proxy server.

To provide these connection points, the Client Access server uses a mixture of Windows services and web virtual directories provided through Microsoft Internet Information Server (IIS). You can see the virtual directories provided by the Client Access server by taking a look in the Connections (left) pane of the IIS Manager tool, which Figure 1 shows. Some of these services probably look familiar, but you might wonder what the others do. Table 1 summarizes the virtual directories that the Exchange 2010 Client Access server runs.

Figure 1: Client Access server virtual directories revealed
in the Connections pane of IIS Manager

Client Access in Exchange 2010

The Exchange 2010 Client Access server brings with it a variety of new features, some improvements to existing features, and some well-needed interface enhancements to make the Exchange administrator's job easier. There are two new virtual directories in the Exchange 2010 Client Access server that build on the existing web-based architecture used in Exchange 2007. First, the Exchange Control Panel (ECP) provides a new interface for browser-based email clients. ECP works in conjunction with Outlook Web App (OWA; formerly Outlook Web Access) to give users more control over their mailbox settings. Users can change their contact information in the Global Address List (GAL) and manage distribution groups they own through ECP. If users have administrative roles assigned through Exchange's implementation of Role Based Access Control (RBAC), they can perform additional management tasks for the Exchange organization, such as performing discovery searches across multiple mailboxes and assigning roles to other users. As Figure 2 shows, these additional capabilities show up as added tabs in the ECP UI.

Figure 2: ECP UI with tabs for access to additional capabilities

The second new virtual directory introduced in the Exchange 2010 Client Access server is Remote PowerShell, which lets you connect to Exchange Management Shell (EMS) from any computer with an SSL connection to the Client Access server. Because this communication happens over HTTPS, you can even use computers outside your network. Although you're running commands from your client, they're actually executed from the Client Access server. Therefore, you can use Remote PowerShell to manage your 64-bit Exchange servers from your 32-bit Windows 7, Windows Vista SP1, and Windows XP SP3 clients.

The only prerequisites for your clients to access Remote PowerShell are that Windows Remote Management (WinRM) 2.0 and Windows PowerShell 2.0 must be installed. These components are provided in the Windows Management Framework. After you download and install the Windows Management Framework on your clients, you don't need to install the Exchange Management tools on them, nor do the clients need to be joined to the domain. You authenticate through Remote PowerShell by creating a session object and specifying the PowerShell web services Uniform Resource Identifier (URI), as the following code shows:

$Session = New-PSSession  -ConfiguratonName Microsoft.Exchange  -ConnectionUri https://contoso-cas01.contoso.com/PowerShell/  -Authentication NegotiateWithImplicitCredentialImport-PSSession $Session

Although the code lines are broken here due to space constraints, you would enter them all on one line. Along with Kerberos authentication (which requires a domain connection), Remote PowerShell supports NTLM, basic and digest authentication, and the Credential Security Support Provider (CredSSP) protocol.

The Client Access server determines which RBAC roles you hold and presents you with only the EMS cmdlets and parameters that your roles allow you to have. For example, if you don't have the Mailbox Import Export role, you won't have access to the Export-Mailbox cmdlet.

In addition to the new virtual directories, Exchange 2010 adds a few new Windows services to the Client Access role that dramatically change how client connectivity works. The most significant of these new Windows services is the RPC Client Access (RPCCA) service, which moves the remote procedure call (RPC) endpoint for clients from the Mailbox server to the Client Access server. Clients talk to the Client Access server by using RPC, and the Client Access server makes the MAPI RPC connection on behalf of the user. The Client Access server uses the Active Manager client component to determine which Mailbox server hosts the user's database, then connects to that database, brokering the flow of MAPI traffic.

Outlook 2010 and Outlook 2007 clients can connect to RPCCA out of the box. However, if you're using Outlook 2003, you'll need to change the encryption setting. You can modify this setting on the Outlook client either by Group Policy or by making the change manually in the Outlook profile. Another option that you have is to turn off the encryption requirement on your Client Access server, although this isn't what I would typically recommend. To make this change, you can run the following command in EMS:

Set-RpcClientAccess  -Server   -EncryptionRequired $false

By moving the MAPI endpoint for internal Outlook clients to the Client Access server, some new features are made possible. Perhaps the most anticipated features are online mailbox moves and an improved failover experience. Database failover is possible only when your Mailbox servers are in a database availability group (DAG). The Exchange Replication Service (MSExchangeRepl) monitors the databases and reports failures to the Active Manager component running on the Mailbox servers in the DAG. When the active copy of the database changes, the MSExchangeRepl updates the Active Manager client component in the RPCCA service.

Because all Outlook clients now connect to the Client Access server directly, mailboxes can move between databases or even between Mailbox servers while the user is logged on and working in Outlook. The Client Access server now handles mailbox moves, and it does so through the Mailbox Replication Service (MRS). The process happens asynchronously, so you can create the move request, then continue working while the Client Access server does the heavy lifting. Online mode and cached mode are both supported for online mailbox moves, but the experience is much better if your clients are running in cached mode. For more information about online mailbox moves, see "Moving Mailboxes the Exchange 2010 Way."

If you move a mailbox to an Exchange 2010 database from an Exchange 2007 SP2 database or another Exchange 2010 database while users are online, there's no profile reconfiguration, no manipulation of DNS records, and no waiting for Active Directory (AD) replication. Because the user is connected to the Client Access server, only that server needs to be aware of the database location on the user's AD account. When the mailbox move request is initiated, the AD attributes are updated and the Client Access server in that site is made aware that a move request is in progress.

To fully enable the transition to RPCCA, another service also had to be moved out to the Client Access server. In Exchange, directory access is provided to clients through the Name Service Provider Interface (NSPI). In Exchange 2007 and earlier, referrals to an NSPI endpoint were provided by the DSProxy component. Exchange 2010 replaces DSProxy with the new Address Book service, which runs on the Client Access server. Moving the Address Book service and the RPCCA service gives you the freedom of no longer connecting to your Mailbox servers directly with Outlook.

Planning Your Client Access Infrastructure

Now that you have a basic understanding of what the Client Access role does, let's take a look at some of the things you should do to adequately plan your Client Access infrastructure. Where to put the servers is likely a question at the top of your mind. The answer to this question is the same in Exchange 2010 as it was in Exchange 2007: Everywhere! Client Access servers talk to Mailbox servers over RPC, so a Client Access server can establish a connection with a Mailbox server only in the same site. Because of this limitation, one of the requirements of Exchange 2010 is to have at least one server hosting the Client Access role in every AD site that includes Mailbox servers. This requirement isn't a problem if you're providing access to users only inside your network. But if you want users outside your network to access their email—through OWA, Outlook Anywhere, POP/IMAP, or ActiveSync—then you'll need to put more consideration into your Client Access server layout.

When deciding which Client Access servers to make Internet-facing, one of the important factors to consider is your external namespace. If you have more than one AD site with an Internet-facing Client Access server, it's difficult to pull off a single-namespace scenario. To understand why, let's look at two important parameters on your virtual directories, the InternalURL and the ExternalURL. The InternalURL contains the URL used by clients on the internal network. The ExternalURL contains the URL that clients use over the Internet. For example, in OWA this might be https://mail.contoso.com/owa. If you have multiple Internet-facing Client Access servers, they'll each have their own ExternalURL defined for their virtual directories.

To illustrate the effect of these settings, let's see what happens when Lincoln, who has a mailbox in the Baltimore site on BAL-MB01, accesses a Client Access server in Seattle (SEA-CAS01). When Lincoln tries to use OWA on SEA-CAS01, the Client Access server realizes that Lincoln's mailbox is in Baltimore. If BAL-CAS01 has anything in the ExternalURL field for OWA, then SEA-CAS01 knows that BAL-CAS01 is Internet-facing and manually redirects Lincoln to use the ExternalURL for BAL-CAS01. However, if BAL-CAS01 doesn't have an ExternalURL, SEA-CAS01 uses the InternalURL defined on BAL-CAS01 to proxy the connection for the user. When proxied, if a user were to open a message in OWA, the request for the message would be passed from the user to SEA-CAS01 to BAL-CAS01 to the Mailbox server hosting the user's mailbox (BAL-MB01). Figure 3 illustrates this process.

Figure 3: A message request proxied through the InternalURL

You can see that when you have multiple Internet-facing Client Access servers, it makes sense for each site to have its own namespace. If they all have the same namespace, the ExternalURL might not resolve correctly to the site that hosts the user's mailbox. The other, more common, option is to have only one site with Internet-facing Client Access servers and have all users access it through a single namespace. If a user's mailbox isn't in that site, the connection is always proxied to the Client Access server that's in the right site.

Sizing the Servers

After you figure out where your Client Access servers should go, you'll need to decide how many to have and on what hardware they should run. I'll be the first to admit that sizing your Client Access servers is more of an art than a science. Unless you have a very simple environment, it's nearly impossible to tell ahead of time how many users will connect to a Client Access server, how frequently they'll connect, and what protocol they'll use. Yet, all of these factors need to go into the equation when deciding how many servers to have. Unfortunately, 10,000 users connecting through OWA doesn't generate the same load as 10,000 users using Outlook Anywhere or ActiveSync. To make it even more difficult, you need to consider many factors outside of the Client Access role that can lead to poor client connectivity experiences, such as TCP/IP connection limitations or a poorly sized AD implementation.

Microsoft has provided some general guidance for figuring out how many Client Access servers you need in "Understanding Exchange Performance." However, these numbers are generalizations and won't necessarily apply to specific implementations. The Microsoft guidelines for Exchange 2010 indicate that when a Client Access server is the only role on a server, you need three CPU cores in your Client Access server for every four CPU cores on your Mailbox servers in the same site. For example, if you have two Mailbox servers in a site with 8 cores each, for a total of 16 cores, you should ensure that the total number of Client Access cores in that site add up to at least 12, which could mean 3 servers with 4 cores each, or even 6 servers with 2 cores each.

For memory in Exchange 2010 Client Access servers, you should have a minimum of 4GB plus 2GB for each CPU core, up to a maximum of 16GB. For example, if you have a Client Access server with 4 CPU cores, you should have 8GB of memory in the server. My recommendation is that you start with these guidelines, but also do the research and testing needed to ensure that your Client Access infrastructure is properly scaled.

What do I mean by doing the research and testing? To start, you need to understand what protocols your clients are using to access the Client Access server. Your client traffic is going to be composed of MAPI, Outlook Anywhere, ActiveSync, EWS, and OWA. If you're currently using Exchange 2007, you can start gathering this data with some simple performance monitoring on your existing Mailbox servers (for MAPI) and Client Access servers (for everything else). There are performance counters available for each of these protocols, and capturing this data over a period of days, weeks, or months can give you a good idea of which protocols clients use to access their mail. The longer you can collect performance data, the more accurate your estimates will be. In addition to Performance Monitor, you can use tools such as the Exchange Server User Monitor, which helps you analyze MAPI traffic.

After you have some internal statistics, you can use the data to determine how to size your servers. You should deploy your server's hardware configuration in a lab environment, then test it by generating the load and protocol mix that you estimated in your research. The 2010 version of Exchange Load Generator is currently in beta, but you can use this tool to simulate the client protocol traffic. With simulation testing, you can determine what your hardware bottlenecks are and decide to scale up the hardware configuration or throw more Client Access servers in your array if necessary.

Ready to Roll

As you can see, the Client Access server role is integral to any Exchange 2010 or Exchange 2007 deployment, and getting the details right will ensure efficient mail transfer. Now that you have a better understanding of the Client Access server and its increased importance in Exchange 2010, you're ready to look at some more specific guidance for deploying the role and getting the most out of it—which I'll address in my next article in this series.