3. Deploying Client Access servers: The essentials
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 Message 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 organization. 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 servers. 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 Access servers, and Active Directory. Mailbox servers
use Lightweight Directory Access Protocol (LDAP) to obtain recipient,
server, and organization configuration information from Active
Directory. Client Access servers accept connections to Mailbox servers
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
Exchange server. Other clients use SMTP, POP3, or IMAP4 to communicate
with the Exchange server. Client Access servers proxy POP3, IMAP4, and
SMTP communications between clients and Mailbox servers using POP3,
IMAP4, and SMTP redirection respectively.
Outlook Web App,
Exchange Active Sync, Exchange Admin Center, and PowerShell
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 outside 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 communications with domain controllers and global
catalogs.
Note
In Exchange 2013, RPC connections are made directly to the MAPI RPC
connection 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 Access server. The Client Access server
then communicates with the appropriate Mailbox server. For directory
information, Outlook communicates with an NSPI endpoint located 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 workload 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.
In Exchange 2010, Exchange Management Shell had several cmdlets you
used to register and manage arrays in Active Directory. Because arrays
are now created automatically, 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 accessing 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.
