Exchange_2010_Module5_Client Access Server

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