With Exchange 2010, the underlying functionality of a Client Access server was similar to that of an application server that made extensive use of Web services. These servers needed to be built to handle increased I/O operations, which meant processors, memory, network, and disk I/O were all potential sources of bottlenecks. Because they also performed content conversion, you could improve performance by optimizing disk storage.
As part of the major architecture changes for Exchange 2013, Client Access servers no longer handle all of the client-related messaging tasks in an Exchange implementation, nor do they perform content conversion. Instead, all processing and content conversion is performed on Mailbox servers, and Client Access servers are used only for authentication, proxy services, and limited redirection.
Client Access servers provide access through the Outlook MAPI, Internet Mes- sage Access Protocol version 4 revision 1 (IMAP4), Post Office Protocol version 3 (POP3), and Hypertext Transfer Protocol (HTTP) Internet protocols. By default, when you install a Client Access server, these services are available to both internal and external clients. You can modify the default configuration at any time and specify whether the Client Access server will be accessible to clients outside the organiza- tion. You also can configure the external URLs for each Client Access Server-related service.
Exchange Server 2013 allows access using Microsoft Outlook with Simple Mail Transfer Protocol (SMTP), Outlook Anywhere (RPC over HTTP), Outlook Web App, and Exchange ActiveSync. Internet Message Access Protocol 4 (IMAP4) and Post Office Protocol 3 (POP3) are available as alternatives to standard protocols. IMAP4 is a protocol for reading mail and accessing public and private folders on remote serv- ers. POP3 is a protocol for retrieving mail from remote servers. Client Access servers provide access to free/busy data by using the Availability service, and they enable clients to download automatic configuration settings from the Autodiscover service.
Exchange 2013 uses the Active Directory infrastructure to determine its site membership and the site membership of other servers. The Microsoft Exchange Active Directory Topology service running on an Exchange server is responsible for updating the site attribute of an Exchange server in the directory.
Once a server determines its site membership, the server identifies which domain controllers and global catalogs to use for processing Active Directory queries. Because this information is available in the directory, Exchange servers don’t need to use DNS to resolve a server address to a subnet associated with an Active Directory site.
Exchange 2013 Mailbox servers interact directly with Outlook clients, Client Ac- cess servers, and Active Directory. Mailbox servers use Lightweight Directory Access Protocol (LDAP) to obtain recipient, server, and organization configuration informa- tion from Active Directory. Client Access servers accept connections to Mailbox serv- ers over the local network and over the Internet. Client Access servers send requests from clients to the appropriate Mailbox server and return data from Mailbox servers to clients, including online address book files, free/busy data, calendar schedules, and client profile settings.
Some clients use POP3 or IMAP4 connections to communicate with the Ex- change server. Other clients use SMTP, POP3, or IMAP4 to communicate with the Exchange server. Client Access servers proxy POP3, IMAP4, and SMTP communica- tions between clients and Mailbox servers using POP3, IMAP4, and SMTP redirection respectively.
Outlook Web App, Exchange Active Sync, Exchange Admin Center, and Power- Shell communications are handled in much the same way as communications for standard Outlook clients.
Outlook clients on the corporate network access the Client Access server to send and retrieve messages using either SMTP or Outlook Anywhere (RPC over HTTP), as do clients outside the corporate network. Regardless of whether they are on or out- side the corporate network, Outlook clients access public folder data using Outlook Anywhere. To retrieve a user’s Active Directory information, Client Access servers use LDAP or Name Service Provider Interface (NSPI). By default, communications between Client Access servers and Mailbox servers is encrypted, as are communica- tions with domain controllers and global catalogs.
NOTE In Exchange 2013, RPC connections are made directly to the MAPI RPC con- nection point on the Client Access server and the NSPI endpoint on the Client Access server. HTTP connections are still made to the RPC Proxy component on the Client Ac- cess server. The Client Access server then communicates with the appropriate Mailbox server. For directory information, Outlook communicates with an NSPI endpoint lo- cated on the Client Access server. NSPI communicates with the Active Directory driver, which then communicates with Active Directory.
Each Active Directory site with Mailbox servers should have at least one Client Access server. When there are multiple Client Access servers in a site, these servers are automatically configured in an array. Client Access arrays provide load balancing and failover support for all client access features. Each array has an external domain name, and client requests are directed to this external domain name, allowing for transparent load balancing as well as failover and failback. When a load-balanced resource fails on one server, the remaining servers in the array take over the work- load of the failed server. When the failed server comes back online, the server can automatically rejoin the array, and the load-balancing feature starts to distribute the load to the server automatically. Failover takes only a few seconds in most cases.
The external URLs for CAS-related services should point to the array rather than to individual servers, and the internal URLs should point to individual servers. Because of this, you should set the external URLs for Exchange ActiveSync, Outlook Web applications, Exchange Admin Center, and the Offline Address Book relative to the external domain name for the array. For example, Exchange ActiveSync runs as a web application named Microsoft-Server-ActiveSync. When setting up Exchange ActiveSync URLs on each individual Mailbox server, you should configure the internal URL to point to a specific CAS server, such as https://casserver48.pocket-consultant.com
/Microsoft-Server-ActiveSync, and the external URL to point to a location relative to
the array, such as https://array1.pocket-consultant.com/Microsoft-Server-ActiveSync. In Exchange 2010, Exchange Management Shell had several cmdlets you used to register and manage arrays in Active Directory. Because arrays are now created au- tomatically, Exchange 2013 has only the Get-ClientAccessArray cmdlet for working with arrays. This cmdlet lists information about available or specified Client Access arrays. Its basic syntax is as follows:
Get-ClientAccessArray [-Identity ArrayIdentity] [-DomainController FullyQualifiedName] [-Site SiteId]
Load balancing can be implemented using hardware or software. Windows Server includes the Windows Network Load Balancing service. Network Load Balancing doesn’t use shared resources or clustered storage devices. Instead, each server has a copy of the Client Access services and features that are being load balanced, and local storage typically is used. Generally, users usually don’t know that they’re access- ing a group of servers rather than a single server. The reason for this is that the array appears to be a single server. Clients connect to the array using the array’s external domain name, and this virtual address is mapped automatically to a specific server based on availability. It is important to note that you cannot use Windows Network Load Balancing for establishing a Client Access array if the Client Access servers are co-located on a Mailbox server in a database availability group.