Client Access Server

This is Microsoft Exchange Server 2010, Module 5: Client Access Servers.

Agenda

Here is the agenda of the topics we’ll be discussing today. First, we’ll go through an
overview of Client Access Server (CAS) functions.

What Client Access Servers Do

This is a brief overview of the Client Access Server’s role in an Exchange Server 2010
environment. As you can see, Client Access Servers handle most of the services that
occur between end users and the Mailbox server or the domain controller.

Store Access Paths: All Roads Go Through the Middle Tier

In Exchange Server 2003, all clients either connected directly to the Mailbox server or
were proxied to the Mailbox server via a front-end server. All data rendering happened
on the Mailbox server, and the Mailbox server was the primary access point for data.
With the introduction of Exchange Server 2007, we consolidated the store access paths;
Internet-based clients like Outlook Web Access, Exchange ActiveSync, Exchange Web
Service, IMAP, and POP had their data rendered through a business logic layer that
exists on the Client Access Server. MAPI and WebDAV clients still had data rendering
performed on the Mailbox server role.

In Exchange 2010 however, all data rendering now happens at the business logic layer in
the middle-tier. In addition, we have deprecated WebDAV connectivity.

Exchange 2010 Middle Tier: What is it?

To facilitate this move to having all data rendering for all clients to be performed by the
Client Access Server infrastructure, we developed two new services, known as the RPC
Client Access Service and the Address Book Services. These services handle two key
scenarios. One, handling mailbox-related data connections and two, handling directory-
related data connections.

In other words, Outlook clients will connect to the Client Access Server infrastructure
instead of to the Mailbox server for data connections, and to the Client Access Server
infrastructure for directory connections instead of the Global Catalog or the Mailbox
server.
Agenda

Next, let’s take a look at the RPC Client Access service.

RPC Client Access Service: The Why

Exchange 2010 introduces a new concept of high availability; database level failover and
switchovers. No longer do you have to failover an entire set of databases to another
server to achieve availability for a single failed database. But in order to achieve this
behavior, we had to obfuscate the server from the clients. Thus why we have the RPC
Client Access Service now on Client Access Server. The mailbox server hosting the active
database is now irrelevant to the client.

Another benefit of having all data rendering and connections go through the Client
Access Server infrastructure is that we can utilize the same code for all clients. We can
now perform the same content body conversions regardless of whether you are MAPI,
IMAP, POP, or Outlook Web App, thus reducing the chance that one client will expose
the data in a different form. We can also ensure that calendar items are dealt with
correctly regardless of client. This also had the benefit of reducing code and client logic
in the Exchange store process.

We’re going to discuss the directory scenarios and scalability during the next few slides.

Data Validation and Compliance

In Exchange 2010, many components have been added at the middle tier layer to enable
new functionality.

There are new calendar validation and compliance features that require acting on items
as they are saved. For example, Calendar Logging, which captures the state of items as
they are saved, for diagnostics and repair, Dumpster, which keeps deleted items around
so that they may be restored, and Retention, which keeps deleted items around per
retention policy.

Exchange 2010 can support these features for all clients without any client changes,
using its own Middle Tier “magic”.

Archive Mailbox Infrastructure

In Exchange 2010, the archive mailbox infrastructure has also been modified.

RPC Client Access “magic” allows us to add a new mailbox type by exercising an existing
client code path. This involves no changes to Outlook connection logic; the archive is
 just another mailbox. In addition, Autodiscover has been enhanced in order to enable
clients to discover the archive Legacy DN.

Client Access: Scaling Mailbox Connections

With Exchange Server 2003, we were limited by kernel memory, and that affected our
scale. With Exchange Server 2007 and a 64-bit operating system, we discovered that the
OS and application had other bottlenecks that prevented our scalability in terms of
connections.

From an inbound connection perspective, we are not limited per se, as each client
connection is made up of a source IP address, source port, destination IP address, and
destination port. This unique combination allows us to scale up the number of inbound
connections.

Where we see a scale limitation is between Client Access Server and mailbox. Prior to
Windows 2008, each outbound connection would only use a single source port
regardless of the destination IP or whether the source port was available for use; in
other words, once the source port was used, it could not be used for any other
outbound connection on the server. Thus we were limited to the maximum number of
Transmission Control Protocol (TCP)/IP connections, which for Exchange Server 2007 is
60,000, and that’s the MaxUserPort TCP setting. We addressed this in Windows 2008 by
allowing the source port to be used once on a per IP address basis. So now as long as we
have additional IP addresses on Client Access Server, we can scale 60,000 outbound
connections per source IP address. However, the corresponding applications had to take
advantage of this new feature. In the case of Outlook Anywhere, the RPC Proxy service
on Windows 2008 was updated to do so. DSProxy, on the other hand, was not, so the
Mailbox server is limited to 60,000 outbound connections to the global catalog servers.

A CAS server is not limited to 60,000 TCP connections. It is limited to 60,000 unique
combinations of source IP, source port, destination IP, and destination port for each IP
defined on the CAS server. This means that a CAS server with a single IP address can
support more than 60,000 TCP connections.

Client Access: Scaling Mailbox Connections

It is 100 RPC connections per RPC Client Access (RPCCA) service per process. Between
RPCCA on the Client Access Server and Outlook clients, everything looks like it does in
Exchange 2007. There is a 1:1 mapping of connections to sessions because when the
connection is dropped, it is expected that the session is gone. This means for each
 connection per session Outlook makes, we have a corresponding connection per session
on the Client Access Server.

In Exchange 2010, we made changes on the server so that it is possible to disconnect a

connection and still persist the session info and state. As a result, between Client Access
Server and Mailbox servers, there is a 1:1 mapping of sessions from what you see from
the clients, but they all re-use a pool of 100 connections to perform actions. If the
sessions are not actively doing something, they wait in a disconnected state until the
client connection is dropped or they need to perform some action.

Address Book Service

With the Address Book Service, Outlook still expects to get a directory referral, but now
we’ll always refer to the Client Access Server array in the user’s site. Having a single
directory endpoint simplifies deployment, as it allows finding a writable domain
controller in complex topologies, allows legacy clients to open archive mailboxes, allows
hidden users to create Outlook profiles, and gets rid of DSProxy, which was overly
complex and a problem area for our customers. The Key Takeaway here is that all of
Outlook’s RPC connections are now handled and terminated by Exchange.

RPC Client Access Service: How Directory Referral Connections Work

This slide shows how directory referral connections work in Exchange 2010. First,
Outlook calls the Address Book server API. Then, the Client Access Server queries Active
Directory Domain Services. Next, the Client Access Server tells Outlook which Client
Access Server or array should be used for directory requests. And finally, Outlook
connects to the appropriate Client Access Server.

The only other "normal" reason legacy clients would connect to an Exchange Server
2010 Client Access Server is if the user has been rolled back from an Exchange 2010
server to something earlier. It is also possible that a user or confused admin created a
profile and pointed it to a cool new Exchange 2010 server. Otherwise legacy mailbox
clients would never connect to a Client Access Server 2010 to ask for directory referral
requests.

Address Book Service: GAL and Address List Segmentation

In prior versions of Exchange, each client computed the user’s Global Address List
differently.

Outlook chooses the GAL based on Active Directory Domain Services ACLs, GAL
membership, and GAL size. Users cannot see a GAL of which they are not a member.
 Client Access Server components use the out-of-box GAL, but name resolution is
performed against the entire Directory. Deleting the out-of-box GAL breaks Outlook
Web Access and cmdlets.

The goals of Exchange 2010 include consistency among clients, flexibility, in which GAL
membership equals a GAL assignment, and to make hidden users work correctly.

GAL Access in Exchange 2010: Unified GAL Selection Algorithm

In Exchange 2010, there is a unified GAL selection algorithm that is used for access,
shown here.

All clients select the user’s GAL through the same code path, whether it uses ACLs or
QueryBaseDNs set. This is more flexible than the current Active Directory Domain
Services NSPI implementation.

Address Book Service: Writing to the Directory

One area that has been a pain point for some of our customers was how Active
Directory Domain Services writes for environments with multiple domains.

So, in environments that deployed multiple domains, there was potential for a client to
be referred to a global catalog that did not own the object that the end user was
attempting to modify. Work we did in Exchange Server 2003 SP2 made it so that the
directory referrals Exchange would prefer, to give a user a global catalog that was in the
same domain as the user, which satisfied delegate and cert mgmt, but distribution
group changes were never guaranteed. In fact, the code that was used to find the right
global catalog was unreliable, and when helping customers troubleshoot issues in this
area, we found that even developers on the team didn’t fully understand it.

The Address Book service, or NSPI interface, specifically detects ModProps RPC or
ModLinkAtt RPC requests and takes the appropriate action if the modification is scoped
to distribution group membership, delegate management, and certificate management.
Assuming the user has the rights to modify these properties, controlled via RBAC, the
Address Book service will utilize the appropriate cmdlet to initiate the change.

Middle Tier Throttling

Here are some notes to keep in mind about middle-tier throttling. First, that if the
resource is doing work on behalf of a user, it is counting against their budget. And
budgets are always being recharged as a function of time. Next, telling Outlook to slow
down differs between Outlook 2003 (and earlier) and Outlook 2007 and 2010, but the
 effect is the same. Throttling is enabled out of the box, but IT admins can customize or
disable completely by assigning a NULL policy. And finally, store already does similar
throttling to protect against high load in Exchange Server 2007.

RPC Client Access Array

The RPC Client Access Array prevents single point of failure for RPC Client Access, and
enables database-level high availability. The requirements for an RPC Client Access Array
include a load balancer: either Windows Network Load Balancer, or small deployments
can use a software load balancer, while larger deployments require a hardware load
balancer. And user affinity is also required; source IP or otherwise for session-based
clients.

Client Access Array + Outlook Anywhere

Outlook Anywhere clients generate two connections spawned by the RPC/HTTP client
component to represent a single RPC connection. This is done because HTTP
connections are half duplex. For example, they either allow you to send information or
receive information, but not both at the same time. In the case of RPC, connections
need to be long lived and full duplex, so the RPC_IN_DATA connection acts as the
sending half duplex connection, while the RPC_OUT_DATA connection acts as the
receiving half duplex connection. Since HTTP requires that each connection be given a
max length, each of these connections is 1 GB "long" and is terminated when this limit is
reached. Each of these connections is tagged with a client session id. When the RPC
server component receives the RPC_IN_DATA and RPC_OUT_DATA with the same client
session id, it knows that for any request received on the RPC_IN_DATA connection, it
must reply back on the RPC_OUT_DATA connection. That is magic.

Scalability/Performance Implications: Handling Increased Processing on CAS

Here are some of the scalability and performance implications for handling increased
processing on the Client Access Server.

Regarding load balancing, it’s important to note that there are some scalability concerns
with software load balancers. Microsoft IT has hit some Windows NLB scalability issues
recently that have resulted in overwhelming our network switches. Also, Intelligence
concerns. Windows NLB doesn’t provide as much intelligence as we’d like when
determining cluster node health (think about the scenario where the server is still
responsive but IIS has crashed). And finally, OCS, which has never tested Windows NLB
and recommends hardware Load balancing.

Agenda
 Next, let’s take a look at Exchange Web Services.

Exchange Web Services

Exchange Web Services has several strengths. First, it’s remotable over the Internet. It
encapsulates Outlook business logic, it contains strongly-typed Personal Information
Manager, or PIM, objects, it has cross-platform interoperability through open web
service standards, and it is both scalable and high-performing.

Autodiscover

Autodiscover is used by Outlook, Entourage, Exchange ActiveSync clients and Exchange

Web Services applications. It auto-configures the client for the end user. So, within a
corporate network, Outlook magically configures itself without requiring any user entry.
From outside the corporate network, the user only enters their e-mail address, user
name and password. Another great feature of Autodiscover is that Outlook
automatically adjusts when Exchange configuration changes or mailboxes are moved.

One of the new features of Autodiscover in Exchange 2010 is a SOAP-based

Autodiscover service with WS-Security and batch request support.

EWS: What’s New in Exchange 2010

So, what’s new in the Exchange 2010 version of Exchange Web Services?

First, there’s a Exchange Web Services Managed API, which is a first class .NET
development for Exchange Web Services that supports Exchange Server 2007 Service
Pack 1 (SP1) and later, and has a built-in Autodiscover client.

There is also now WS-Security authentication, full distribution list or groups support,
time zone enhancements, folder associated items, and user configuration objects.

EWS: Availability Service

This flowchart shows the process that the Exchange Web Services Availability Service
uses. First, Outlook’s Scheduling Assistant calls Exchange Web Services’s
GetUserAvailability method using the URL determined via Autodiscover. Then the user’s
home Client Access Server server determines which mailboxes are local vs. in remote
sites. Third, local free/busy information is retrieved via MAPI RPC from the mailbox. The
original CAS server combines the local and remote results and returns them to Outlook.
And finally, requests for remote sites are proxied to remote Client Access Server servers.

EWS: MailTips Service

 The MailTips service is a feature of Exchange Web Services that will be available with
Outlook 2010 and Outlook Web App 2010 that is designed to make sure your
communications are right the first time and to avoid embarrassing mistakes. First, you
can know if someone is out of office before you send a message; simply look at the OOF
and send your email to the right person from the start.

You can choose to be alerted to important issues like external recipients or large lists of
people that this will be sent to.

You can also know internal rules that will block your message from being sent before
you send it (for example, if there are too many attachments, too big of an attachment, if
the recipient can’t receive the message, or any other custom rules defined by the
system administrator.

EWS: Federated Sharing

Exchange Web Services in Exchange 2010 introduces new APIs to support federated
sharing outside of the organization. This table shows the benefits for both information
workers and IT.

EWS: Message Tracking Service

In the newest version of Exchange Web Services, the Message Tracking Service provides
the ability to trace on the servers how a message went through from start to finish. This
service works across organizations.

Agenda

Next, let’s take a look at the Offline Address Book functionality.

Offline Address Book (OAB)

Exchange 2010 Client Access Server still distributes the Offline Address Book via
Background Intelligent Transfer Service (BITS) over HTTP(s) for Outlook 2007 or later, no
version change!

In Exchange 2010, the Offline Address Book will bring support for a Hierarchical Address
Book (HAB), properties customization, and MailTips for Outlook 2010.

OAB Configuration

Here are some notes for configuring the Offline Address Book in Exchange 2010. First,
Hierarchical Address Book support is accomplished by populating objects with the
organization tree information. For example, departments and sub-departments.
 The list of properties stored in the offline address book or OAB is viewed by: Get-
OfflineAddressBook. The OAB properties list can be customized with Set-
OfflineAddressBook. And you can globally enable Offline Address Book distribution.

Agenda

Now let’s take a look at IMAP and POP improvements in Exchange Server 2010.

POP-IMAP Investments in Exchange 2010

First, IMAP & POP have both improved scalability with lower memory and central
processing unit utilization. Multipurpose Internet Mail Extensions, or MIME, fidelity
improves reproduction of MIME in cases of double-byte character set or DBCS handling,
or signed and encrypted messages. We have added back Delegate Access support.
Duplicate download of messages has been mitigated for most cases. Hidden messages
are no longer retrieved. And in the current release, service discovery support for High
Availability (HA) scenarios will be added.

Agenda

Next, let’s go over some topology scenarios.

Redirection and Proxying Between AD DS Sites

There can be some confusion on the difference between redirection and proxying
between Active Directory Domain Services sites.

Redirection takes place when a Client Access Server in the user’s mailbox AD DS site is
available on the Internet, but the user goes to an Outlook Web Access URL for a Client
Access Server in a different AD DS site. Outlook Web App will show a page telling the
user which Outlook Web App URL they should be using for access to their home AD DS
site. You should use the externalUrl config key to show the Outlook Web App
redirection.

Meanwhile, proxying occurs when no Client Access Server in the user’s mailbox AD DS
site is available on the Internet. The user enters the Outlook Web App URL for a Client
Access Server in a different AD DS site. In this case, Outlook Web Access will proxy the
user requests to the Client Access Server in the mailbox AD DS Site. You should use the
internalUrl configuration key to control Outlook Web App proxy behavior.

Load Balancing and Server Affinity

 Outlook Web Access and Exchange Web Services require server affinity. During a
session, all client requests must go to the same Client Access Server. Other Client Access
Server services do not require client-server affinity.

Meanwhile, your choices for load balancing include client IP-based load balancing,
cookie-based load balancing (which is often seen as a “Poor man’s” solution since it’s
cheap and easy to set up), and finally, Windows Network Load Balancing (NLB). With
Windows NLB, the server affinity fails if the client IP changes during the session.
Windows NLB does not work behind reverse proxies like Internet Security and
Acceleration (ISA) since the client IP is masked by the reverse proxy. ISA 2006 and the
Unified Access Gateway (UAG) can do client IP LB for servers behind it.

Load Balancing and CAS-to-CAS Proxying

Let’s take a quick look at load balancing and CAS-to-CAS proxying. In this scenario, a
service is contacted on a Client Access Server in site A. The service needs to proxy
request to a Client Access Server in site B, which is closer to the targeted mailbox. Site B
has load balanced Client Access Servers , such as NLB or reverse proxy.

In this scenario, the CAS-to-CAS enabled services that are necessary would be:
ActiveSync, Availability, and MailTips.

CAS and Perimeter Networks

Note that you should never deploy a Client Access Server in the Perimeter Network. No
domain member servers should ever be in the perimeter; they have too many access
rights on intranet AD DS servers. The only possible Exception to this rule is an ISA server.

Microsoft

This concludes Microsoft Exchange Server 2010, Module 5: Client Access Servers.