5. RPC Client Access
The introduction of the RPC Client Access layer means that Outlook clients now connect to the Client Access server to access a user's mailbox. It is a requirement to have at least one Client Access server per Active Directory site where a Mailbox server has been installed.
AutoDiscover uses the RPCClientAccessServer setting on the mail database to configure a client to use the Client Access server in the Mailbox server's site. The RPCClientAccessServer
property is automatically set to a randomly selected FQDN of a Client
Access server in the same site as the database if an array has not
already been created. If it has already been created, it will be set to
that instead. Note that this setting is not updated in the event of
changes, such as removing the Client Access server array or installing
additional Client Access servers.
There is not a concept of proxy or redirection for RPC access in Exchange
2010 RTM. Client Access servers will make a direct connection to a
Mailbox server across sites. The only way to prevent this is to change
the RPCClientAccessServer
setting on the database. In Service Pack 1, redirection logic and the
ability to disable cross-site direct connections were added for RPC
Client Access. Redirection is controlled by three properties (in
addition to enabling redirection)—the Home Server property on the
user's directory object, the preferred database site (such as the RPCClientAccessServer
property), and the Active database site. Disabling cross-site
connections forces redirection behavior and the Outlook client will
reconnect to the Client Access server array in the other site.
The default setting for RPC
Client Access is that encryption is required. By default, older Outlook
clients such as Outlook 2003 do not enable encryption. You have two
options when using such clients: either enable encryption on the client
or remove the encryption requirement on the Client Access server. It is
recommended that security be preserved and the Outlook clients have
their settings changed. This, however, may be difficult to do in
organizations that do not have automated processes in place.
To provide for load balancing of the RPC Client Access, Exchange uses the ClientAccessArray concept. As explained earlier, the RPCClientAccessServer setting controls where RPC clients go for service. To allow for load balancing, this property is set to ClientAccessArray
instead of a single host. When an administrator creates the array, it
does not create any form of load balancing itself; it really is just a
logical object representing an array of servers that must be separately
configured to perform load balancing. This can be done using either
hardware- or software-based load balancing. Only one array is allowed
per Active Directory site, and multiple DAGs can utilize the same
Client Access server array.
One option frequently recommended when load balancing RPC services is to restrict the ports
required. Without restrictions in place, a large range of ports need to
be configured, which can overwhelm some load-balancing devices. The
static port for RPC Client Access is configured in the registry using the following key. The key needs to be set on every Client Access server to the value of the port used for TCP connections,
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
Value: TCP/IP Port
Type: DWORD
It is recommended that you set this value to a high port that is not used by any other application, such as 50,000.
This setting does not affect Outlook Anywhere connections because those are hard-coded to use port 6001.
Additionally, the static ports
for the two RPC endpoints for the Exchange Address Book Service are set
in the Microsoft.Exchange.AddressBook.Service.Exe.config file. This
file is located in the bin directory of the Exchange installation path.
The RpcTcpPort
value should be set to the TCP port to be used for connections. Again,
setting this to a port not used by any other application is
recommended, such as 50,001.
Note: Do not change the values for NspiHttpPort and RfrHttpPort—changes may result in delays in Outlook Anywhere connecting to Exchange.
After these two changes are made, and the Microsoft Exchange RPC
Client Access Service and the Microsoft Exchange Active Directory
Topology Service are restarted, Outlook will still connect to the RPC
Endpoint Mapper to be told which port to use for service, but instead
of being provided with a dynamic port, as would be the default, Outlook
uses the two statically configured ports.
|
Greg Taylor
Senior PM – Exchange Product Team, Microsoft Corporation
When considering what names to
put onto certificates and what FQDN's to set the various VDirs and
parameters to, I am sometimes asked which FQDN the Client Access server
array should be set to and whether that name should be on the
certificates used.
Taking those questions
in reverse order (the second question is easier to answer), Outlook
connects to the array using RPC, not SSL. So no, the FQDN you use for
the array does not need to be on any certificate, unless you happen to
be using the same FQDN for other services—EWS, OAB, and so on.
So, what should you call your
array? I think Greg is an excellent name—you should call it that. If
you can't, you should name it something simple and easy to understand
but which only resolves in internal DNS. Why? Let's say you named it mail.fabrikam.com
and that name exists in both internal and external DNS. When you fire
up Outlook at home it will try to connect to mail.fabrikam.com using
RPC, and if it can resolve that name to an IP, it will keep trying and
trying, until it times out and then falls back to trying to connect
over HTTPS (which likely will work, but the delay is a killer if you
are an e-mail addict like me). If, however, you had named it outlook.fabrikam.com, or better still greg.fabrikam.com, and neither of those exist in external DNS, Outlook immediately starts trying to connect over HTTPS.
|
6. Outlook Anywhere
Outlook
Anywhere enables the full Outlook client to access Exchange using HTTPS
by wrapping the RPCs that Outlook usually uses to access a Mailbox
server with HTTPS to enable passage through firewalls. The advantage is
that this design gives users access to their mailboxes over virtually
any network, without special VPN solutions or additional firewall rules
that most companies already enable for Internet access.
Enabling Outlook Anywhere requires several steps, but the important part to understand is that AutoDiscover provides the Outlook Anywhere host name and Web service externalURL
properties to configure the client to connect to Exchange. If you have
more than one Internet facing Active Directory site, it is recommended
that each site have a separate external host name. The AutoDiscover
service will always provide service URLs for the Client Access server closest to the user's Mailbox server. In Figure 13, the Miami datacenter does not have Internet connectivity. In this case, a user with a mailbox in Miami will first access the Client Access server in Denver because it is externally accessible. The Denver Client Access server will make an RPC connection to the RPC Client Access server in Miami, which in turn connects to the Miami mailbox.
Because Outlook Anywhere utilizes the HTTP protocol, its connections are half-duplex. This means two connections are created for a conversation, RPC_DATA_IN and RPC_DATA_OUT, as shown in Figure 14.
Each connection is tagged with a client session ID. The RPC server on
the endpoint uses this client session ID to know that data it receives
via RPC_IN_DATA must be returned using the RPC_DATA_OUT with the same
client session ID.
This mechanism sometimes presented a problem in Exchange Server 2007 when an SSL ID-based load-balancing solution was placed between the Client
Access server and clients. The load balancer does not recognize that
these sets of paired connections need to be sent to the same Client Access server, so often it distributed these connections to all the Client
Access servers in the load-balancing pool. This meant connections were
sometimes split between different Client Access servers and so
bidirectional connectivity was broken.
In Exchange Server
2010—or more precisely, in Exchange Server 2010 running on Windows
Server 2008—this issue is solved by a component called the Load
Balancing Service (LBS). Oddly, LBS has nothing to do with load
balancing itself. What it does is detect when sessions from the same
client have been split across multiple servers configured in an array
and proxy connections between the hosts to ensure that split sessions
no longer cause problems.
6.1. Certificates
A few settings for Outlook Anywhere impact certificate namespaces. Figure 15 shows the Microsoft Exchange Proxy Settings dialog box.
The dialog box
itself has changed slightly through different Outlook client versions.
It is generally accessed through the account settings for Exchange (in
the profile) on the Connection tab. On the Connection tab there is a
section that refers to connecting to Exchange via HTTP, and there is a
button for Exchange Proxy Settings.
The first setting to
understand is the URL used to connect to the proxy (Client Access
server). This is the URL location Outlook will use to connect to
Exchange. The second text box is for the certificate name in the
Microsoft standard form (msstd). This is the subject name Outlook
expects to find on the certificate presented from the Client Access
server when making a connection. This name should not be a SAN because
of incompatibilities in the operating system and with Outlook. (This
became less of an issue after Windows Vista SP1 was released.) The
default configuration on the Client Access server will set these to the same value (the Outlook Anywhere ExternalHostname). For now, let's focus on the mechanisms Outlook Anywhere uses.
|
Andrew Ehrensing
Principal Consultant, Microsoft Consulting Services, US Central Region
When planning for Client Access server sizing, particularly for Outlook Anywhere, it is important
to know how many connections you can expect. This also helps capacity
planning when running connections through a hardware load balancer or
intelligent firewall. To get an accurate client connection count, you
cannot rely on the hidden Outlook connection status dialog box. You
can, however, use Microsoft's TcpView utilityhttp://technet.microsoft.com/en-us/sysinternals/bb897437.aspx)
or a network sniffer. Another good resource can be found in the
whitepaper "Outlook Anywhere Scalability with Outlook 2007, Outlook
2003, and Exchange 2007," available at http://technet.microsoft.com/en-us/library/cc540453(EXCHG.80).aspx.
Even though this whitepaper has not yet been updated for Exchange 2010,
the information it provides good guidance for planning purposes. (
|
