Share via

Understanding RPC Client Access

  • Article

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

In Microsoft Exchange Server 2007, the Client Access server role was introduced to handle incoming client connections to Exchange mailboxes. Although the majority of types of client connections were made to the Client Access server, Microsoft Office Outlook still connected directly to the Mailbox server when it was running internally with the MAPI protocol.

A new service was introduced with Exchange Server 2010 to allow these MAPI connections to be handled by the Client Access server. The RPC Client Access service provides data access through a single, common path of the Client Access server, with the exception of public folder requests, which are still made directly to the Mailbox server. This change applies business logic to clients more consistently, and provides a better client experience when failover occurs.

Contents

RPC Client Access Service and the Address Book Service

Advantages of the RPC Client Access Service

The Client Access Array

Configuring the RPC Client Access Service and the Address Book Service

RPC Client Access Service and the Address Book Service

In addition to moving processing of incoming Outlook Mailbox connections to the Client Access server, in Exchange 2010, directory access is also handled by the Client Access server. For more information about directory access, see Understanding the Address Book Service.

Microsoft Outlook still connects directly to the Mailbox server to access Public Folder databases. If a client tries to connect to a Mailbox server for public folder access, the RPC Client Access service (MsExchangeRpc) answers the RPC endpoint. If the endpoint is on a server that has the Mailbox server role installed, the RPC Client Access service will only allow public folder logons and will provide a referral to a Client Access server or a Client Access server array. If the endpoint is on a Client Access server or Client Access server array, it will allow only Private folder logons and will provide a referral to a Mailbox server for public folder access.

Differences in client connectivity between Exchange 2007 and Exchange 2010

Advantages of the RPC Client Access Service

There are a number of advantages to the RPC Client Access service. Clients encounter less downtime during a mailbox failover, because all connections are made through the Client Access servers. When failover occurred in Exchange 2007, Outlook clients would be disconnected from the Mailbox server for a period of time that depended on their network configuration. In Exchange 2010, if a single Client Access server in a Client Access server array fails, the client will immediately be redirected to another Client Access server in the array. If a Mailbox server that is part of a Database Availability Group (DAG) fails, the client is disconnected for only the amount of time it takes for a failover database to be mounted.

A load-balanced array of Client Access servers lets you spread the traffic load over all Client Access servers in the array equally.

Other problems resolved by this new architecture include the following:

  • Some issues with messages displaying differently on different clients.

  • Problems uploading certificates to the global address list.

  • The inability to create profiles for hidden users.

  • Inconsistent application of business logic to clients.

  • Public folders connecting to the RPC Client Access service on the Mailbox server, rather than the Client Access server.

Additionally, the DSProxy service has been removed and the new Address Book service is responsible for updating certificates and distribution list membership and maintaining delegate information for Outlook clients.

MAPI Client Connections

In Exchange 2007, Outlook and other MAPI clients communicated with the Client Access server for HTTPS connections such as Exchange Web Services (including the Availability service and Out of Office settings), and Offline Address Book downloads, but communicated directly with the MAPI RPC component on the Mailbox server and the NSPI endpoint on Global Catalog servers for Directory Service inquiries.

In Exchange 2010, these connections are made to the MAPI RPC connection point on the Client Access server or the Client Access server array.

The Address Book Service

In previous versions of Exchange, DSProxy, a referral service that told Outlook clients where to find the Name Service Provider Interface (NSPI) endpoint, was responsible for directing Outlook to a global catalog server. DSProxy was located on the Mailbox server. DSProxy has been eliminated in Exchange 2010 and replaced with the Address Book service.

Currently, when an Outlook client makes a request of the Client Access server, it results in one of two possible actions.

  • If the user's mailbox is on an Exchange 2010 Mailbox server, then either the request is handled by a Client Access server in the current Active Directory site, or if the user’s mailbox is in a different Active Directory site, the request is proxied to the destination Active Directory site.

  • If the user's mailbox is on a legacy Exchange Mailbox server, the directory request is referred to the user's Mailbox server. Legacy Mailbox servers can't communicate directly with Exchange 2010 Client Access servers for directory information.

The Address Book service also provides information about writable domain controllers as well as global address list access. For more information about the Address Book service, see Understanding the Address Book Service.

The Client Access Server Array

In addition to the RPC Client Access service, Exchange 2010 introduced a new logical structure to the Exchange organization: the Client Access server array. When a Client Access server array is defined in an Active Directory site, it serves as a single contact point for all client connections within that Active Directory site. A Client Access server array can include one or many Client Access servers.

Architecture of the Client Access server array.

Each Active Directory site can have a single Client Access server array. A Client Access server array doesn’t provide load balancing. A separate load balancing solution is still needed. For more information about load balancing, see Understanding Load Balancing in Exchange 2010.

We recommend that you create a Client Access server array even if you only have a single Client Access server within your organization. When a Client Access server array is created, clients connect through the virtual name of the Client Access server array rather than directly to the fully-qualified domain name (FQDN) of your single Client Access server. If a single Client Access server needs to be replaced within an Active Directory site or a second Client Access server is added, no profile updates are necessary on the clients.

After a Client Access server array is defined within an Active Directory site, all Client Access servers within that Active Directory site are automatically part of the Client Access server array.

Configuring the RPC Client Access Service and the Address Book Service

To configure the RPC Client Access service and the Address Book service, you must perform the following steps.

  1. Create a Client Access array

  2. Configure load balancing

  3. Configure IP ports

  4. Configure RPC encryption settings

  5. Configure your Mailbox databases

  6. Ensure low latency and sufficient network speed

Create a Client Access Array

You can create a Client Access array within your Active Directory site by using the following command.

New-ClientAccessArray -Name name -Site site_name -FQDN internal_only_CAS_Array_FQDN

Note

After the Client Access array has been created, you'll also need to create the address in DNS and associate it with the virtual IP address used for the Client Access array.

It's important that the (FQDN) specified in the command be only resolvable internally. If the name is also resolvable externally, these external clients will attempt to connect to the array via a TCP connection instead of HTTPS.

Configure Load Balancing

Load balancing is recommended for high availability, failover, and for spreading the traffic load over multiple servers to help performance. When you choose a load balancing solution, consider the following:

  • Windows Network Load Balancing isn't supported on Windows failover cluster servers.

  • You can't use a Client Access array across multiple Active Directory sites. Instead, create two Client Access arrays and load balance separately within the sites.

  • Hardware load balancers typically monitor return traffic, port availability, or service availability to ensure that servers that can't answer client requests aren't given network connections.

  • Some load balancing solutions, such as ISA 2006 or TMG 2010, can't do RPC load balancing or monitor RPC services. These solutions aren't recommended unless all clients are connecting via Outlook Anywhere and all traffic is encapsulated inside HTTP.

For more information about load balancing, see Understanding Load Balancing in Exchange 2010.

Configure IP Ports

An IP port is an opening through which information can pass from the originating computer to the destination computer. By default, the dynamic port range for outgoing connections on Windows Server 2008 R2 is 49152 to 65535. Exchange 2010 Client Access changes this range to 6005 through 65535. The range was expanded to provide sufficient scaling for large deployments. This is a large range of ports to balance through your firewall between the client and the Client Access servers or Client Access array.

By fixing the MAPI and directory endpoints, you can greatly reduce the number of ports that need to be load balanced. The MAPI endpoint can be statically configured in the registry and the directory endpoint can be fixed in a configuration file.

To fix the MAPI endpoint, use the following setting in the registry.

HKLM\SYSTEM\CurrentControlSet\ Services\MSExchangeRPC\ParametersSystem\TCP/IP Port [DWORD] is the value for the IP port to use.

To fix the directory services endpoint, edit the RpcTcpPort value in the registry.

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeAB\Parameters\RpcTcpPort [String] is the value for the IP port to use.

Note

We don't recommend that you change the default value of the Outlook Anywhere ports.

Configure RPC Encryption Settings

In the RTM version of Exchange 2010, the RPC endpoint is encrypted by default. However, Outlook 2003 doesn’t enforce encrypted MAPI connections. When you upgrade your organization to the RTM version of Exchange 2010, your clients running Outlook 2007 or later versions will automatically be compatible with the change to RPC Client Access, since they support RPC encryption by default. Outlook 2003 doesn’t use RPC encryption, however, and RPC Client Access requires it by default. If you haven't turned off RPC encryption, which we don’t recommend, your users will need to configure Outlook 2003 for RPC encryption or you'll need to use a Group Policy to force Outlook 2003 to use RPC encryption.

Symptoms of this problem include the following error messages:

  • Cannot start Microsoft Office Outlook. Unable to open the Office window. The set of folders could not be opened.

  • Unable to open your default e-mail folders. The information store could not be opened.

If your users are using Cached Exchange Mode, Office won't display an error, but will start in disconnected mode.

By default, Exchange 2010 Service Pack 1 (SP1) doesn't encrypt the RPC endpoint. If you've completed the installation of Exchange 2010 SP1 in your organization, Outlook 2003 clients will be able to connect to the Exchange server without further configuration.

For more information about this issue, including workarounds, see Outlook Connection Issues with Exchange 2010 Mailboxes.

Configure Outlook 2003 to Use RPC Encryption

To configure Outlook 2003 to use RPC encryption, use the following steps.

  1. Click Tools > E-Mail Accounts > View or Change an Existing Account.

  2. Select the account and click More Settings.

  3. Select the Security tab.

  4. Select Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server.

  5. Click OK.

Configure Your Mailbox Database

Each Mailbox database contains an RPCClientAccessServer value. This value is established when the database is created and it determines the Client Access server or Client Access array that the clients with mailboxes on that Mailbox server will use. This value also determines the location of the RPC end point. For Outlook 2007 and Outlook 2010 clients, this value is obtained from the Autodiscover service.

The default value of the RPCClientAccessServer is determined by the following rules:

  • If you have configured a Client Access Server array within your Active Directory site, the address of that array will be used.

  • If an array does not exist within the Active Directory site and if you have both the Client Access server role and the Mailbox server role on the same physical server, the value of RPCClientAccessServer property for a particular Mailbox server will be the same as the Mailbox server.

  • Otherwise, the value of the RPCClientAccessServer property for a particular Mailbox server will be set to a random Client Access server within the Active Directory site.

    Note

    We don't recommend that you install all the server roles on a single computer that's also a domain controller. Although this configuration is supported, it's not recommended.

  • If you created a Mailbox database before the creation of a Client Access array or the installed a Client Access server within the Active Directory site, you’ll need to reconfigure the value of the RPCClientAccessServer property. If no Client Access server exists in the Active Directory site when the Mailbox database is created, the value of the RPCClientAccessServer property will be set to the FQDN of the Mailbox server. To configure the value of the RPCClientAccessServer property, use the following command.

    Set-MailboxDatabase <name> -RPCClientAccessServer <internal_only_CAS_Array_FQDN>

Latency and Bandwidth Requirements

For users running Outlook without Cached Exchange Mode, high latency times between the client and the server directly affect how frequently Outlook is unresponsive. In general, a latency of greater than 200 milliseconds (ms) to the home Mailbox server will result in poor client performance.

Because latency between the Client Access server and the mailbox should be less than 10 ms, we recommend that the value of the RPCClientAccessServer property always be configured to a Client Access array in the active Mailbox database site.

Note

Changing the value of the RPCClientAccessServer property will force all clients to reconnect.

Configuring the Address Book Service

The Address Book service is configured through the Microsoft.Exchange.AddressBook.Service.config file. This file allows you to configure the following:

  • The number of concurrent connections per user (the default limit is 50).

  • Disable or enable logging.

  • The location, size, and retention period for the log files.

To enable logging, use the following value:

< add key="ProtocolLoggingEnabled" value="true" />

 © 2010 Microsoft Corporation. All rights reserved.