1. Understanding Exchange Server messaging roles
On-premises implementations of Exchange Server have three layers in
their architecture: a network layer, directory layer, and messaging
layer. The messaging layer is where you define and deploy the Exchange
Server roles. The Exchange servers at the core of the messaging layer
can operate in the following roles:
-
Mailbox Server
. A back-end server that hosts mailboxes, public
folders, and related messaging data, such as address lists, resource
scheduling, and meeting items.
-
Client Access Server
. A middle-tier server that accepts connections to
Exchange Server from a variety of clients. This server hosts the
protocols used by all clients when checking messages. On the local
network, Outlook MAPI clients are connected directly to the Client
Access server to check mail using SMTP. Remote users can check their
mail over the Internet by using Outlook Anywhere, Outlook Web App,
Exchange ActiveSync, POP3, or IMAP4.
-
Legacy Edge Transport Server
. An additional mail routing server that routes mail
into and out of the Exchange organization. This server is designed to
be deployed in an organization’s perimeter network and is used to
establish a secure boundary between the organization and the Internet.
This server accepts mail coming into the organization from the Internet
and from trusted servers in external organizations, processes the mail
to protect against some types of spam messages and viruses, and routes
all accepted messages to a Mailbox server inside the organization.
At the time of this writing, Exchange 2013 supports the Mailbox
Server and Client Access Server roles. If you want to use Edge
Transports, you must deploy these transports on servers running either
Exchange 2007 or Exchange 2010. Two other server roles available for
Exchange 2010, Unified Messaging and Hub Transport, are now implemented
as services running on Exchange 2013 Mailbox servers:
-
Unified Messaging service
. A middle-tier service that integrates a private
branch exchange (PBX) system with Exchange Server 2013, allowing voice
messages and faxes to be stored with email in a user’s mailbox. Unified
messaging supports call answering with automated greetings and message
recording, fax receiving, and dial-in access. With dial-in access,
users can use Outlook Voice Access to check voice mail, email, and
calendar information; to review or dial contacts; and to configure
preferences and personal options. To receive faxes, you need an
integrated solution from a Microsoft partner.
-
Transport service
. A mail
routing service that handles mail flow, routing, and delivery within
the Exchange organization. This service processes all mail that is sent
inside the organization before it is delivered to a mailbox in the
organization or routed to users outside the organization. Processing
ensures that senders and recipients are resolved and filtered as
appropriate, content is filtered and has its format converted if
necessary, and attachments are screened. To meet any regulatory or
organizational compliance requirements, the Mailbox server can also
record, or journal, messages and add disclaimers to them.
The Mailbox and Client Access roles are the building blocks of on-premises Exchange organizations. Table 1
provides an overview of the basic processor configurations I recommend
for these roles. Processors can have multiple cores. Following the
configurations shown in the table, I recommend that you build Client
Access servers for scaling out and Mailbox servers for scaling up. If
you deploy legacy Edge Transport servers, they should be built for
scaling out as well.
Table 1. Recommended configurations for Exchange Server roles
|
SERVER ROLE
|
MINIMUM PROCESSORS
|
RECOMMENDED PROCESSORS
|
BUILD FOR
|
|
Legacy Edge Transport |
1 |
4 |
Scale out |
|
Client Access |
1–2 |
2–4 |
Scale out |
|
Mailbox |
1–2 |
4–8 |
Scale up |
|
Multiple server roles |
2 |
4–8 |
Scale up |
Because you can combine the Mailbox and Client Access roles on a
single server, one of the most basic Exchange organizations you can
create is one that includes a single Exchange server that provides the
Mailbox Server and Client Access Server roles. These roles are the
minimum required for routing and delivering messages to both local and
remote messaging clients. For added security and protection, you can
deploy the legacy Edge Transport server role in a perimeter network on
one or more separate servers. As part of site planning, keep in mind
every Active Directory site that has a Mailbox server must also have a
Client Access server.
Although a basic implementation of Exchange Server might include
only one server, you’ll likely find investing in multiple servers is
more effective in terms of time, money, and resources. Why? High
availability is integrated into the core architecture of Exchange
Server 2013 and can be easily enabled.
With the Mailbox Server role, you can configure automatic failover
by making the Mailbox servers members of the same database availability
group. Each Mailbox server in the group can then have a copy of the
mailbox databases from the other Mailbox servers in the group. Each
mailbox database can have up to 16 copies, and this means you can have
up to 16 Mailbox servers in a database availability group as well.
Client Access servers in Exchange 2013 are lightweight, stateless
proxy servers. They provide the proxy and redirection logic for client
protocols. For load balancing and failover redundancy, you previously
needed to configure Client Access arrays and there typically was a
specific affinity between the client and the Client Access server.
Because of the client-server affinity, Microsoft recommended using
application layer–based load balancing solutions, which ensured that
requests from a connected client went through the same Client Access
server endpoint.
With Exchange 2013, no configuration of Client Access arrays is
needed. Client Access servers that are in the same Active Directory
site are automatically added to an array for that site. Further, no
specific affinity is required between the client and the Client Access
server. This allows any available Client Access server to proxy a
client’s request. If a server proxying a connection fails, the client
connection is simply proxied by the next available Client Access
server. This is possible because proxy and redirection logic for client
protocols is built in.
Client Access servers running on Exchange 2013 also support layer 4
load balancing which distributes requests at the transport layer. In
this case, the client connects to Exchange using a single virtual IP
address, and a load balancer selects a server to receive the request.
Because there is no affinity required, the load balancer doesn’t have
to ensure that all requests from a client go to the same server. Not
only does this simplify the load balancer’s job and greatly reduce the
processing overhead, it allows administrators to add or remove servers
at any time. It also means very basic load balancing techniques, such
as round robin and least connection, can be used. Although load
balancing round robin can be configured in DNS, you also can configure
this and other load balancing options using Windows Network Load
Balancing. However, because servers in database availability groups are
already using clustering technology, they can’t also use Windows
Network Load Balancing. Thus, when you deploy Mailbox servers in
availability groups and want to use Windows Network Load Balancing to
load balance client access, the Mailbox Server and Client Access Server
roles must be running on separate servers.
For site resilience, you can deploy two Active Directory sites in
separate geographic locations and then synchronize data between the two
sites. With Exchange 2010, you had to perform a switchover from one
site to the other if you lost all of your Client Access servers, the
virtual IP for the array, or multiple servers in a database
availability group. This is not required for Exchange 2013. If you lose
a Client Access server array in one site, failover to the other site
can happen at the client level automatically. Clients can be
automatically redirected to a second site that has operating Client
Access servers, and those servers act as proxies to the user’s Mailbox
server in the original site.
