Up
until Exchange Server 2003, all roles were installed on one server and
administrators were unable to select which features were available. It
was possible to designate an Exchange 2000 or Exchange 2003 server as a
so called "front-end server", but this server was just like an ordinary
Exchange server acting as a protocol proxy. It still had a Mailbox
Database and a Public Folder database installed by default.
Exchange Server 2007
introduced the concept of "server roles" and this concept is maintained
in Exchange Server 2010. The following server roles, each with a
specific function, are available in Exchange Server 2010:
Mailbox Server (MB) role
Client Access Server (CAS) role
Hub Transport Server (HT) role
Edge Transport Server (Edge) role
Unified Messaging Server (UM) role.
These server roles can be
installed on dedicated hardware, where each machine has its own role,
but they can also be combined. A typical server installation, for
example in the setup program, combines the Mailbox, Client Access and
Hub Transport Server role. The Management Tools are always installed
during installation, irrespective of which server role is installed.
By contrast, the Edge Transport Server role cannot be combined with any
other role. In fact, the Edge Transport Server role cannot even be part
of the (internal) domain, since it is designed to be installed in the
network's Demilitarized Zone (DMZ).
There are multiple reasons for separating Exchange Server into multiple server roles:
Enhanced scalability
– since one server can be dedicated for one server role, the
scalability profits are huge. This specific server can be configured and
optimized for one particular Role, resulting in a high performance
server.
Improved security
– one dedicated server can be hardened for security using the Security
Configuration Wizard (SCW). Since only one Server Role is used on a
particular server, all other functions and ports are disabled, resulting
in a more secure system.
Simplified deployment and administration – a dedicated server is easier to configure, easier to secure and easier to administer.
I will explain each server role in detail, in the following sections.
1.6.1 Mailbox Server role
The Mailbox Server role is
the heart of your Exchange Server 2010 environment. This is where the
Mailbox Database and Public Folder Database are installed. The sole
purpose of the Mailbox Server role is to host Mailboxes and Public
Folders; nothing more. In previous versions of Exchange Server,
including Exchange Server 2007, Outlook clients using MAPI still
connected directly to the Mailbox Server Role, but with Exchange Server
2010 this is no longer the case. MAPI clients now connect to a service
called "RPC Client Access," running on the Client Access Server. (The
original code name of RPC Client Access was "MAPI on the Middle Tier" or
MoMT.)
The Mailbox Server Role does
not route any messages, it only stores messages in mailboxes. For
routing messages, the Hub Transport Server role is needed. This latter
role is responsible for routing all messages, even between mailboxes
that are on the same server, and even between mailboxes that are in the
same mailbox database.
For accessing mailboxes, a
Client Access Server is also always needed; it is just not possible to
access any mailbox without a Client Access Server.
As I mentioned, Storage Groups
no longer exist in Exchange Server 2010, but mailboxes are still stored
in databases, just like in Exchange Server 2007. Although rumors have
been circulating for more than ten years that the database engine used
in Exchange Server will be replaced by a SQL Server engine, it has not
happened yet. Just as in earlier versions of Exchange Server, the
Extensible Storage Engine (ESE) is still being used, although major
changes have been made to the database and the database schema.
By default, the first database on a server will be installed in the directory:
The
<<identifier>> is a unique number to make sure that the
Mailbox Database name is unique within the Exchange organization.
It is best practice, from both a
performance and a recovery perspective, to place the database and the
accompanying log files on a dedicated disk. This disk can be on a Fiber
Channel SAN, on an iSCSI SAN, or on a Direct Attached Storage (DAS)
solution. Whilst it was a design goal to limit the amount of disk I/O to
a level where both the database and the log files could be installed on
a 1TB SATA disk, this is only an option if Database Copies are
configured and you have at least two copies of the Mailbox Database, in
order to avoid a single point of failure.
