Exchange
Server 2010 was designed to be resilient and be able to adapt to a wide
variety of deployment scenarios. Part of this design revolves around
the concept that individual servers can play one or more roles for an
organization. Each of these roles provides for specific functionality
that is commonly performed by Exchange servers, such as mailbox server
or Client Access server (formerly referred to as an OWA server).
Central to the
understanding of Exchange Server 2010 and how to design and architect it
is the understanding of these individual roles. During the design
process, understanding server roles is central to proper server
placement.
The individual server roles in Exchange Server 2010 are as follows:
Each of these roles is described in more detail in the subsequent sections.
Planning for the Mailbox Server Role
The
Mailbox server role is the central role in an Exchange Server topology
as it is the server that stores the actual mailboxes of the user.
Therefore, mailbox servers are often the most critical for an
organization, and are given the most attention.
With the Enterprise
Edition of Exchange Server, a mailbox server can hold anywhere from 1 to
50 databases on it. Each of the databases are theoretically unlimited
in size, although it is wise to keep an individual database limited to
100GB or less for performance and recovery scenarios.
Note
In large organizations,
a single server or a cluster of servers is often dedicated to
individual server roles. That said, a single server can also be assigned
other roles, such as the Client Access server role, in the interest of
consolidating the number of servers deployed. The only limitation to
this is the Edge server role, which must exist by itself and cannot be
installed on a server that holds other roles.
Planning for the Client Access Server Role
The Client Access
server role in Exchange Server is the role that controls access to
mailboxes from all clients, including the full version of Outlook. It is
the component that controls access to mailboxes via the following
mechanisms:
MAPI on the Middle Tier (MoMT)—Standard Outlook method of access
Outlook Web App (OWA)
Exchange ActiveSync
Outlook Anywhere (formerly RPC over HTTP)
Post Office Protocol 3 (POP3)
Internet Message Access Protocol (IMAP4)
In addition, CAS systems also handle the following two special services in an Exchange Server topology:
Autodiscover service—
The Autodiscover service allows clients to determine their
synchronization settings (such as mailbox server and so on) by entering
in their SMTP address and their credentials. It is supported across
standard OWA connections.
Availability service—
The Availability service is the replacement for Free/Busy functionality
in Exchange Server 2000/2003. It is responsible for making a user’s
calendar availability visible to other users making meeting requests.
Client access
servers in Exchange Server 2010 are the only way that clients can access
their mailbox in Exchange Server 2010, which differs from previous
versions of Exchange Server that required direct access to mailbox
servers. By separating client traffic to a load-balanced array
of CAS servers, Exchange Server architects have more flexibility in
design and failover; using concepts such as DAG becomes easier and more
efficient.
Planning for the Edge Transport Role
The Edge Transport role
was introduced with Exchange Server 2007 and is enhanced in Exchange
Server 2007. Edge Transport servers are standalone, workgroup members
that are meant to reside in the demilitarized zone (DMZ) of a firewall.
They do not require access to any internal resources, except for a
one-way synchronization of specific configuration information from
Active Directory via a process called EdgeSync.
Edge Transport servers
hold a small instance of Active Directory Lightweight Domain Services
(AD LDS), which is used to store specific configuration information,
such as the location of Hub Transport servers within the topology. AD
LDS can be thought of as a scaled-down version of a separate Active
Directory forest that runs as a service on a machine.
The Edge Transport role is
the role that provides for spam and virus filtering, as Microsoft has
moved the emphasis on this type of protection to incoming and outgoing
messages. Essentially, this role is a method in which Microsoft intends
to capture some of the market taken by SMTP relay systems and virus
scanners, which have traditionally been taken by third-party products
provided by virus-scanning companies and UNIX SendMail hosts.
In large organizations,
redundancy can be built in to Edge Transport services through simple DNS
round-robin, Windows Network Load Balancing, or with the use of a
third-party hardware load balancer.
Planning for the Hub Transport Role
The Hub Transport role
is a server role that is responsible for the distribution of mail
messages within an Exchange Server organization. There must be at least
one Hub Transport role defined for each Active Directory site that
contains a mailbox server.
Note
The Hub Transport role
can be added to a server running any other role, with only one
exception. It cannot be added to a server that is an Edge Transport
server.
Several special considerations exist for Hub Transport servers as follows:
Multiple Hub Transport servers can be established in a site to provide for redundancy and load balancing.
Exchange
Server 2010 built-in protection features (antivirus and antispam) are
not enabled by default on Hub Transport servers. Instead, they are
enabled on Edge Transport servers. If needed, they can be enabled on a
Hub Transport server by running a Management Shell script.
Messaging
policy and compliance features are enabled on Hub Transport servers and
can be used to add disclaimers, control attachment sizes, encrypt
messages, and block specific content.
Planning for the Unified Messaging Role
The
Unified Messaging role in Exchange Server 2010 was originally
introduced with Exchange Server 2007 but has come of age in this latest
version. This role enables voice mail to be fully integrated into a
user’s mailbox.
The Unified Messaging
role can be installed on multiple servers, although it is recommended
that it only be installed when the infrastructure to support it exists
in the organization. As Exchange Server 2010 progresses, this role will
become more important.
Understanding a Sample Deployment Scenario
A better understanding
of Exchange Server roles can be achieved by looking at sample
deployment scenarios that utilize these roles. For example, Figure 1 illustrates a large enterprise deployment of Exchange Server that takes advantage of all the unique server roles.
In this design, the following key deployment features are illustrated:
DAGs distributed across multiple mailbox servers, with at least three copies of each mailbox database across the organization.
Dedicated Hub Transport servers distribute mail between the two major sites in San Francisco and Zurich.
Medium-sized sites such as Kiev and Lisbon make use of combined CAS/Mailbox/Hub Transport server systems.
Client access servers are set up in the two main sites, to provide for client access mechanisms in those sites.
Edge Transport servers process inbound and outbound mail in the DMZ locations in San Francisco and Zurich.
Unified
Messaging servers exist in the main hub sites and are provided as a
service for users in those locations. The servers are directly connected
to PBX systems in those locations.
Smaller
sites such as Minneapolis, Odessa, and Singapore have their mailboxes
hosted in the two hub locations and use the client access servers with
Outlook Anywhere to access their mailboxes remotely.
