How you manage and configure server roles has a huge impact on the efficiency of your Exchange Server infrastructure.
Excerpted from “Exchange 2010 - A Practical Approach,” published by Red Gate Books (2009).
A lot has changed with server roles and Exchange Server. Up until Exchange Server 2003, you had to install all roles on one server. You couldn’t select which features would be available. You could designate an Exchange 2000 or Exchange 2003 server as a so-called “front-end server,” but this worked 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.” Exchange Server 2010 greatly expands on this concept. Exchange Server 2010 has the following server roles, each with a specific function:
You can install these server roles on dedicated hardware, where each machine has its own role. You can also combine roles on a single server. A typical server installation, for example, combines the Mailbox, Client Access and Hub Transport Server roles. Management Tools are always installed during installation, regardless of which server role is installed.
By contrast, you can’t combine the Edge Transport Server role with any other role. In fact, you can’t even have the Edge Transport Server role be part of the internal domain, because it’s designed to be installed in the network perimeter. There are many reasons for separating Exchange Server into multiple server roles:
Following is a detailed look at each server role.
The Mailbox Server role is the heart of your Exchange Server 2010 environment. This is where you install the Mailbox Database and Public Folder Database. The sole purpose of the Mailbox Server role is to host Mailboxes and Public Folders—nothing more.
In earlier versions of Exchange Server, including Exchange Server 2007, Outlook clients using MAPI still connected directly to the Mailbox Server Role. This is no longer the case with Exchange Server 2010. MAPI clients now connect to a service called “RPC Client Access,” running on the Client Access Server.
The Mailbox Server Role doesn’t route any messages. It only stores messages in mailboxes. The Hub Transport Server role handles all message routing, even between mailboxes on the same server or in the same mailbox database. A Client Access Server is always needed for accessing mailboxes. You’d need IIS on a Mailbox Server role to implement the role-based access control model (RBAC), even if no client is accessing the Mailbox Server directly.
Storage Groups no longer exist in Exchange Server 2010, but mailboxes are still stored in databases, just like in Exchange Server 2007. Just as in earlier versions of Exchange Server, it still uses the Extensible Storage Engine (ESE), although there have been major changes made to the database and the database schema. By default, the first database on a server will be installed in the directory: C:\Program Files\ Microsoft\Exchange Server\V14\Mailbox\Mailbox Database <<identifier>>
The <<identifier>> is a unique number to make sure that the Mailbox Database name is unique within the Exchange organization.
It’s a best practice, from both a performance and a recovery perspective, to place the database and accompanying log files on a dedicated disk. This disk can be on a Fibre Channel storage-area network (SAN), iSCSI SAN or direct-attached storage (DAS) solution. It was a design goal to limit the amount of disk I/O to a level where you could install both the database and the log files on a 1TB SATA disk, but this is only an option if you’ve configured Database Copies and have at least two copies of the Mailbox Database, to avoid a single point of failure.
The Client Access Server role offers all available protocols access to mailboxes. In Exchange Server 2003, Microsoft introduced the concept of “front-end” and “back-end” servers. The Client Access Server role is comparable to an Exchange Server 2003 front-end server.
All clients connect to the Client Access Server. After authentication, requests are proxied to the appropriate Mailbox Server. Communication between the client and the Client Access Server is via the normal protocols (HTTP, IMAP4, POP3 and MAPI). Communication between the Client Access Server and the Mailbox Server is via Remote Procedure Calls (RPCs).
The Exchange Server 2010 Client Access Server provides the following functionality:
The Client Access Server doesn’t offer SMTP Services. The Hub Transport Server handles all SMTP Services. You need at least one Client Access Server for each Mailbox Server in an Active Directory site, as well as a fast connection between the Client Access Server and the Mailbox Server. The Client Access Server also needs a fast connection to a Global Catalog Server.
You should deploy the Client Access Server on the internal network—not in the network perimeter. In order to access a Client Access Server from the Internet, you need to install a Microsoft Internet Security and Acceleration (ISA) Server in the perimeter network. You should then “publish” all necessary Exchange services to the Internet on this ISA Server.
The Hub Transport Server role is responsible for routing messaging, not only between the Internet and your Exchange infrastructure, but also between your Exchange servers. Messages are always routed with the Hub Transport Server role, even if the source and destination mailbox are on the same server or the source and the destination mailbox are in the same Mailbox Database. For example, the Hub Transport Server routes messages as follows:
Step 1. Someone sends a message to the Hub Transport Server.
Step 2. If the recipient is on the same server as the sender, the message is sent back.
Step 3. When the recipient is on another mailbox server, the message is routed to the appropriate Hub Transport Server.
Step 4. The second Hub Transport Server then delivers the message to the recipient’s Mailbox Server.
Compliance is the primary reason for routing all messages through the Hub Transport Server. You can track all messages flowing through the Exchange organization and take appropriate action if needed to satisfy legal requirements, Health Insurance Portability and Accountability Act (HIPAA), Sarbanes-Oxley and so on. On the Hub Transport Server, you can configure the following agents for compliance purposes:
Because a Mailbox Server doesn’t deliver any messages, every Mailbox Server within an Active Directory site also requires a Hub Transport Server. The Hub Transport Server also needs a fast connection to a Global Catalog server for querying Active Directory. This Global Catalog server should be in the same Active Directory site as the Hub Transport Server.
When a message is going to an external recipient, the message is sent from the Hub Transport Server out over the Internet. This may be via an Exchange Server 2010 Edge Transport Server in the perimeter network, but the Hub Transport Server can also deliver messages directly to the Internet.
You can also configure the Hub Transport Server to handle anti-spam and antivirus functions. Anti-spam services are disabled on a Hub Transport Server by default, as this service is intended to run on an Edge Transport Server in the perimeter network. Microsoft supplies a script on every Hub Transport Server to enable anti-spam services.
You can use Microsoft Forefront for Exchange for antivirus capabilities. Using this on the Hub Transport Server will scan inbound and outbound SMTP traffic. On the Mailbox Server, it will scan the contents of a Mailbox Database, which provides a double layer of security.
The Edge Transport Server role was introduced with Exchange Server 2007, and provides an extra layer of message hygiene. It’s typically installed as an SMTP gateway in the network perimeter. External messages are first delivered to the Edge Transport Server role. After going through anti-spam and antivirus filters, it forwards those messages to a Hub Transport Server on the internal network.
The Edge Transport Server can also provide the following services:
The Edge Transport Server is installed in the network perimeter. It can’t be a member of an internal Active Directory and Exchange Server 2010 organization. The Edge Transport Server uses the Active Directory Lightweight Directory Services (AD LDS) to store all information.
In earlier versions of Windows, this service was called Active Directory Application Mode (ADAM). The AD LDS stores basic information regarding the Exchange infrastructure, such as recipients and the Hub Transport Server to which the Edge Transport Server is sending its messages. It uses a synchronization feature called EdgeSync to keep the AD LDS database up-to-date. This pushes information from the Hub Transport Server to the Edge Transport Server at regular intervals.
The Exchange Server 2010 Unified Messaging Server role combines the mailbox database, voice messages and e-mail messages into one store. With the Unified Messaging Server role, you can access all messages in the mailbox using either a telephone or a computer. You can use an IP-based system or a “classical” analog PBX phone system although, in the latter case, you’ll need a special Unified Messaging IP Gateway to connect the two.
The Unified Messaging Server role provides the following features:
The Unified Messaging service installed on the Unified Messaging Server role works closely with the Microsoft Exchange Speech Engine Service. The Speech Engine Service provides Dual Tone Multi Frequency (DTMF), also referred to as touch-tone, Automatic Speech Recognition, and Text-to-Speech service responsible for reading mailbox items and voice menus.
You should have the Unified Messaging Server role installed in an Active Directory site together with a Hub Transport Server. The latter server is responsible for routing messaging to the Mailbox Servers. It also should have a fast connection to a Global Catalog server. If possible, you should also install the Mailbox Server role as close as possible to the Unified Messaging Server role, preferably in the same site and with a decent network connection.
The high-availability, management and compliancy features make Exchange Server 2010 a compelling choice. In fact, the new features in Exchange Server 2010 will generally result in less complexity, which is always preferable.
Jaap Wesselius is the founder of DM Consultants, a company with a strong focus on messaging and collaboration solutions. After working at Microsoft for eight years, Wesselius decided to commit more of his time to the Exchange community in the Netherlands, resulting in an Exchange Server MVP award in 2007. He’s also a regular contributor at the Dutch Unified Communications User Group and a regular author for Simple-Talk.
Learn more about “Exchange 2010 - A Practical Approach” at red-gate.com.