کد:
http://msexchangeteam.com/archive/2010/05/20/454964.aspx
In Exchange 2007, we introduced five server roles that performed distinct functions within the Exchange organization. One role in particular - the Client Access server role - introduced a variety of new Web services, including the Availability service, the Autodiscover service and Calendar Concierge services.
In Exchange 2010, we have the same five server roles. However, there are some significant architectural changes and some shift in responsibilities. In this blog, I focus on the Client Access server role and go into detail about some of its architectural changes.
Perhaps the most significant change is that, in Exchange 2010, two new services on CAS called the RPC Client Access and Address Book services establish the RPC endpoint for MAPI, NSPI and RFR client access. This new functionality replaces the RPC endpoints in the Information Store. The RPC endpoint in the Information Store has not been removed in Exchange 2010, but it has been modified to only accept requests from CAS servers.
The RPC endpoint for public folder database access remains on the Mailbox server, however, Outlook clients now communicate directly with the RPC Client Access service on the Mailbox Server for public folder database access, and not with the Information Store.
Background
In Exchange 2003, all clients either connect directly to the Information Store for data access and data rendering, or through front-end servers that proxy communications to the Information Store for data access.
In Exchange 2007, we started to consolidate data access paths, so that most clients (for example, OWA, Exchange Web Services, POP and IMAP), all went through a common business logic layer known as the Exchange middle tier. The middle tier is a library that is built into all of the server roles. Clients that went through this common business logic layer were able to take advantage of consistent business logic for their operations. At this point, MAPI clients (such as Outlook) and WebDAV clients (such as Entourage 2004) still connected directly to the Information Store.
In Exchange 2010, new managed-code RPC end-points were introduced in the CAS role that sit on top of the core business logic layer shared by the other internal Exchange server roles. In addition, WebDAV has been removed. This of course means that applications that use WebDAV need to be updated or migrated to versions that support Exchange Web Services.
Below is a comparison of the data access paths in Exchange 2007 and Exchange 2010:


Exchange 2010 Middle Tier
In order to facilitate this move to the middle tier, two new services were created that run on the Client Access Server role: the RPC Client Access service and the Address Book service.
The RPC Client Access service handles all data connections for mailboxes and the Address Book Service handles all data connections for access to Active Directory. One notable exception is public folders. For public folder connections, clients connect to the RPC Client Access service on the Mailbox role, and not the Information Store.
RPC Client Access service
In Exchange 2007 and earlier, MAPI clients connect directly to the Mailbox server. This meant when failover of a clustered mailbox server occurred, clients were disconnected from their MAPI and directory endpoints. In Exchange 2010, we have abstracted the client connection away from the Mailbox server. Thus, when a mailbox database switchover or failover occurs, clients remain connected to their MAPI and directory endpoints. This provides a more seamless experience for Outlook clients.
Achieving seamless switchovers and failovers was one of the main motivators for moving these endpoints to the CAS role. By abstracting the client connection away from the Information Store, when some kind of failure occurs to the database containing a user's mailbox, Outlook doesn't necessarily need to reconnect or restart. Another huge benefit is the ability for all clients to use the same code and logic to access the store and for content and body conversion. This means that whether the client is coming through IMAP, MAPI or if someone's making a Web-based connection using OWA, we no longer have to be concerned about the business logic manipulating data into a format that other clients might not be able to read. This is done to mitigate issues like MIME to MAPI conversion. Additionally, this simplifies the Information Store process by making it leaner.
RPC Client Access Array
When a Client Access server communicates with the Mailbox server, it makes sense to view it as the Client Access server communicating with the Mailbox database via the Mailbox server that hosts the database. This is especially evident in a load-balanced array of Client Access servers and/or where your environment is configured to use Database Availability Groups that are associated with a Client Access server or Client Access server array. In a non-load balanced environment, the mailbox database is associated with only a single Client Access server. In a load-balanced environment, the Mailbox database is associated with the load balanced array of multiple Client Access servers. When you start adding two or more Client Access servers, you take advantage of the RPC Client Access Array feature.
By default, before a Client Access array is configured, all databases are associated with a Client Access server in the environment and the Outlook clients communicate directly with the Client Access server until the association with the database is updated to be the Client Access array.
In order for the clients to utilize a CAS array, by default, a CAS array should be created ahead of time. Below is an overview of these steps:

  • Create a Client Access array utilizing a unique FQDN.
  • Add the Client Access servers within the AD site to a load balanced array and in DNS associate the unique FQDN to the Virtual IP of the load-balanced array.
  • Configure the databases to utilize the CAS array.

New-ClientAccessArray –FQDN <RPCClientAccess ArrayName> –Site <SiteName>
The New-ClientAccessArray cmdlet is used to create a new Client Access array. This creates an object that represents a load balanced array of Client Access servers within a single Active Directory site as shown below.

The networkAddress attribute corresponds to the FQDN of the array.
From this point on, any new mailbox database that are created in the environment (in this same site) will be associated with this array. The database creation process pulls the value of the networkAddress attribute from the Array object in Active Directory and assigns it to the database's RPCClientAccessServer attribute.
Associating the CAS Array with a Mailbox Database
Each mailbox database object has an attribute called RpcClientAccessServer. The information contained in this attribute is what point's clients to the MAPI end-point they should be using. If you have more than one database, you will see multiple listings and the RpcClientAccessServer value could be different servers.
Use the following command to associate a database with a Client Access server or Client Access array:
Set-MailboxDatabase <Database_name> -RpcClientAccessServer <ClientAccess ServerName or ClientAccess-ArrayName>
This command changes the legacyExchangeDN attribute of the Mailbox Database. The value is stored in the following location:
CN=Mailbox Database ##########,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,D C=com
After changing the value stored in this attribute, the client knows the location of the RPC endpoint for the array.
Note: Before the Set-MailboxDatabase cmdlet is executed, the attribute is set to one of the Client Access servers in the environment in the same site.
To determine the end point that clients will use for access to this database, Exchange first checks if there is a CAS array in the local site. If there is, it will use the array; the RPCClientAcessServer attribute would be set to the FQDN of the array.
If an array does not exist, Exchange will determine if the server hosting the database is also a CAS. If it is a CAS, Exchange will use it. If the server hosting the mailbox database is not also a CAS, Exchange will pick a random CAS from the site containing the user's mailbox.
In order to find the MAPI endpoint for mailboxes, Exchange queries AD for the HomeMDB value of the user, as well as the name of the user's mailbox database. The legacyExchangeDN for the user's mailbox database is also retrieved. This value is the endpoint that Autodiscover will give to the client, and that the client should use to connect to the user's mailbox.
RPC Client Access in a High Availability Scenario
In an environment with a DAG and an NLB CAS Array, Active Manager always keeps track of which database is active. Active Manager reports this information to servers in the CAS array. Because of this, the Outlook client does not have to keep track of this and continues to only communicate with the Client Access array. In case of a failure at the mailbox and/or at CAS level, the client should regain data access within 30 seconds.


Address Book Service
Prior to Exchange 2010, Exchange Server included a referral service that told Outlook clients where to find the Name Service Provider Interface (NSPI) endpoint. This referral usually pointed Outlook to a Global Catalog server (although Outlook Anywhere connections would leverage the mailbox servers as a proxy for Global Catalog functions). This functionality was provided by a component called Directory Services Proxy (DSProxy). Outlook expects to find this referral service on the same server that it is using for MAPI access.
When Outlook contacts the Client Access server, two possible actions happen:

  • If the user's mailbox is on an Exchange 2010 Mailbox server, then either:
    • If the user's mailbox is in the same site as the Client Access server, the local Client Access server or local CAS array is used; or
    • If the user's mailbox is in a different site, the request is referred to a Client Access server in the remote site or a remote CAS array.

  • If the user's mailbox has been moved back to a legacy Exchange Mailbox server, the directory request is referred to the user's mailbox server. Existing legacy mailboxes don't talk to Exchange 2010 CAS servers for directory information.

Note: If a mailbox is moved back to 2003/2007, CAS will redirect the client to the legacy Mailbox server which will provide a referral to a Global Catalog server. Otherwise, all legacy mailboxes are unchanged
This also acts as a simplified solution for finding a writable domain controller and a unified solution for GAL access.
A representation of the directory access path in Exchange 2010 is shown below:

RPC Encryption Settings

By default, Exchange 2010 requires encryption for RPC client access. This means that by default, Outlook 2003 clients will not be able to connect to Exchange. To enable connectivity, we recommend enabling encryption for Outlook 2003, and not disabling encryption on the server.
For more information about this issue, including workarounds, see Outlook Connection Issues with Exchange 2010 Mailboxes
In addition to the RPC encryption requirement, UDP notification support was removed from Exchange2010. As a result, Outlook 2003 clients in Online Mode can only use polling notifications. This will result in a slight delay in updates to item status (30 seconds on average, with up to a one-minute delay) when changes are made to items in a mailbox accessed by Outlook 2003. There are two workarounds for this issue:

  • Use Outlook 2003 in Cached Exchange Mode; or
  • Adjust the polling interval on the Client Access server. This will impact the performance of the Client Access server.

For more information about this issue, see
In Outlook 2003, e-mail messages take a long time to send and receive when you use an Exchange 2010 mailbox and
Common Client Access Considerations for Outlook 2003 and Exchange 2010
Benefits of RPC Client Access

The goal in Exchange 2010 was to make the store leaner and really more of a data store than a factory for the client business logic. We've been able to move quite a bit of business logic out of the store by removing many of the legacy APIs. We've also moved processing of inbox rules out of the store and into the transport stack. We've moved quite a bit of calendar logic out of the store to the Microsoft Exchange Mailbox Assistants. And, we removed support for ExCDO, epoxy and item level security descriptors.
Another area that hugely benefits from moving RPC endpoints to the middle tier is scalability for mailbox connections. In Exchange 2007, we were effectively limited to 60K connections per mailbox server due to limitations in the TCP/IP stack in Windows, where there was a fixed number of source ports regardless of the number of IP addresses. In Windows 2008, those limitations were removed, and Windows now supported one source port per IP address. However, we couldn't actually take advantage of that change because DSProxy was not updated to use the new feature. This means the Mailbox server is limited to 60k outbound TCP connections to the Global Catalog servers. The store process is hard-coded to only support 65,535 RPC context handles. All told, this limited us to 15,000 active mailboxes before even considering the message profile of these mailboxes and their effect on CPU scalability.
The landscape changed significantly in Exchange 2010 with the introduction of the RPC client access service. Between Outlook clients and the CAS servers, we still have a one-to-one mapping of connections to client sessions. In addition we are able to disconnect idle client sessions, and free up the connection CAS used to talk to the Mailbox role for the idle clients. Now we are able to share a pool of 100 connections among all clients, and when we disconnect those clients they just hang around in a disconnected state until they need to perform some action again or until the client drops the connection.
A representation of improved backend scalability in Exchange 2010 is shown below:

For more information, review: Outlook Anywhere Scalability with Outlook 2007, Outlook 2003, and Exchange 2007
We were also able to introduce logic to the Address Book service that helped enable archive mailboxes, we made improvements in compliance features (for example copy on write for dumpster), and we provided unified GAL capabilities and a writeable GAL.
Many thanks to Scott Schnoll, Victor Wang, Robin Thomas, Ross Smith IV and Vandy Rodrigues for their review and contributions!




- Nagesh Mahadev





موضوعات مشابه: