Overview of Exchange Server 2010 roles
Exchange Server 2010 has five main roles: Client Access, Mailbox, Hub Transport, Edge Transport, and Unified Messaging. These five roles represent how end users interact with Exchange, how messages are stored, how messages are routed within and outside the organization, and how we can integrate telephony in Exchange. In addition to these five roles, there is also a critical component in any Exchange deployment—Active Directory, which stores the user directory information and Exchange configuration for the organization.
The following diagram shows a general overview of how the roles interact with each other and external systems:
First we'll take a look at each of the Exchange roles and then look at how Active Directory is used.
Client Access Role
The Client Access Role in Exchange Server 2010 functions as the interface between most of Exchange Server's other roles and end user client devices. When a client connects to Exchange Server from an Outlook Client, Web Services Client, POP3, IMAP, or ActiveSync device, they connect to the Client Access Role, which either services the request, redirects the request, or proxies the request to other roles.
In particular, the Client Access Role fulfils the following functions:
- Provides Autodiscover functionality to help auto-configure some clients and devices, and assist clients in discovering which Exchange Servers to connect to
- Serves Outlook Web App to end users, providing a web-based interface to Exchange Server
- Serves web-distributed Free/Busy information through the availability service
- Provides the end-point for downloading Offline Address Book information
- Provides the NSPI endpoint and proxies Active Directory lookups and searches, for facilities such as the Global Address List (GAL)
- Services Exchange Web Services (EWS) requests for custom applications, backend Outlook functions, and dedicated EWS-based clients, such as Mac Mail, Entourage 2008 Web Services Edition, and Outlook 2011
- Acts as the connection point for Outlook Anywhere using the HTTPS-based RPC Proxy services
- Provides the RPC Client Access Service which MAPI-based clients connect to mailboxes through, rather than directly to mailbox servers themselves
- Participates in Client Access Arrays, which allow a pool of servers with the Client Access Role to use a common name for MAPI client access and make use of load-balancing technologies for scalability and high availability of the RPC Client Access Service
- Acts as the interface for services such as federation, remote mailbox moves, and access to cloud-hosted personal archives
- Manages and processes requests for mailbox management, such as mailbox moves and exports
In comparison to earlier versions of Exchange, there is a big difference that cannot be underestimated, and that's the move of the RPC Client Access layer to the Client Access Role as a "middleware" platform. This is often referred to as MAPI on the Middle Tier (MoMT) as a normal Outlook client; using MAPI to connect to the mailbox now connects to this middle tier rather than the backend mailbox database itself.
For smaller environments, especially single-server environments, this makes very little difference. For larger organizations with more than a single server, it's a big benefit, particularly for high-availability—which we'll cover shortly.
In an environment that is providing external access for mobile devices, it is typical to have an external-facing entry point into your Exchange infrastructure. When planning this, you need to bear in mind that Microsoft does not support the Client Access Role within the perimeter network where a firewall exists between the perimeter network and the internal network.
This means for many scenarios you need to implement a solution within the perimeter network that acts as a reverse-proxy back to the Client Access servers located on the internal network. There are a number of options, particularly when considering a highly available solution, but the key point of note is that provision for this should be planned from the outset.
When investigating what you need from a reverse proxy, bear in mind that you don't necessarily need a reverse proxy that can handle the RPC Client Access part of the Client Access Role. Your main consideration for a basic reverse proxy is to handle web-based traffic using the HTTPS protocol, as this is what external clients will use to communicate with Exchange. For a basic Exchange Server deployment this simplifies the requirements and allows the opportunity to use basic reverse proxies ranging from open source solutions, such as Apache Web Server and Squid Proxy Server to solutions from Microsoft, like ISA 2006, Forefront TMG and Forefront UAG Servers.
The traffic flow through a simple Client Access Server is shown in this simplified diagram:
Even with a reverse proxy solution, your mobile device will ultimately connect to the Client Access Role on your Exchange Server, so if you can, it's important to make sure that a server failure, or even routine maintenance will not impact end user access to your Exchange Server 2010 environment.
When designing high availability and load-balancing for your Exchange environment, it's important to understand that you will be providing high availability for two distinct services: the web-based services provided by IIS, and the RPC Client Access service.
This is where the Client Access Array comes into play. A client access array is a logical construct that is defined on a per-Active Directory site basis and is simply a single name that can be used to refer to a number of Client Access Servers. When you create a client access array in Exchange Server 2010, you don't add servers to it through the Exchange interface. The name you define is created as additional DNS record pointing at a single server, or it points to your highly-available, load-balanced environment. It doesn't need to match the name used for your highly-available web services either. From an Outlook client perspective it is the name that once correctly configured, clients will see as their Exchange Server mailbox server name.
The best way to provide high availability for the Client Access Role (both web services and the RPC-based Client Access Array) is to use a dedicated Hardware Load Balancer or a Virtual Load Balancer. These devices from suppliers such as Cisco, F5, Citrix, Barracuda, KEMP technologies and Open Source alternatives, available as a physical black-box or in the case of a Virtual Load Balancer virtual appliance, provide intelligent load balancing and failover capabilities.
Although you can use Windows Network Load Balancing (WNLB) to perform this function in combination with a reverse proxy in the perimeter network, Load Balancers designed for Exchange are application-intelligent and can detect issues with parts of your Client Access infrastructure that WNLB would not. For example, an issue that prevents OWA from working on one of the servers running the Client Access Role wouldn't be detected by WNLB out of the box. Another reason to opt for a Load Balancer is that when you combine the Client Access Role with the Mailbox Role on a server participating in a Database Availability Group, WNLB cannot be used due to conflicts with the failover clustering feature that underpins Database Availability Groups.
In addition, a Load Balancer can sometimes replace the need for a reverse proxy as it can also perform this function, and as you will typically use it for all communication with the Client Access infrastructure you can also consider using SSL offload facilities to take some of the load off the Client Access servers. Finally, remember that Load Balancers can fail too, so consider purchasing a solution that has some resilience built-in.
Finally, if you are combining the Client Access and Mailbox Server Roles in a Database Base Availability Group (DAG) environment, then you are not able to make use of WNLB, and to obtain high availability, a Load Balancer will be a necessity.
The following diagram shows a typical highly-available Client Access infrastructure utilizing a load balancer:
Mailbox Role
The Mailbox Role is the component of Exchange Server that, in particular, hosts Mailbox and Public Folder databases. When comparing the functionality to previous versions of Exchange Server, it is very similar to the Mailbox Role in Exchange Server 2007 or a backend server in Exchange Server 2003, with the major exception being that MAPI-based clients such as Outlook connect to Client Access Servers for Mailbox database access.
In particular, the Mailbox Role fulfils the following functions:
- Hosts Mailbox Databases, which store user mailbox data.
- Hosts and provides client access to Public Folder databases. Although Public Folders are a de-emphasized feature of Exchange Server 2010, they are still present and one-off cases where clients connect directly to the Mailbox Server Role itself.
- Generates Offline Address Books distributing them based on policies to Client Access Servers and where required, to Public Folder Databases.
- Manages and participates in Database Availability Groups, Exchange Server 2010's primary high-availability, and clustering feature.
- Provides indexing and searching facilities to content stored in Exchange Server databases.
- Manages and processes policies for managing mailboxes and mailbox database, such as policies to remove or archive mailbox data and maintain databases through processes such as online defragmentation.
If you're not familiar with the concept of a Mailbox or Public Folder Database, the best way to describe it is as a single, large file on disk optimized for storing lots of structured data in a way that allows for very fast access.
When a message is received by the Mailbox role, its contents are examined and all the relevant fields, such as who the message is from, who the message is addressed to, the message's ID, and of course the content, are added into database tables, similar to an Access or SQL database. This allows for better indexing and retrieval of the data, and just like an SQL database, before any data is written to the database file itself, data is written to a binary transaction log.
The database format that Exchange Server uses is called the Extensible Storage Engine (ESE) and in Exchange Server 2010 it has been optimized for storing large mailboxes on slower disks, such as SATA. To help with performance, the Exchange Server hosting the Mailbox Role utilizes the available RAM in the server to cache a large amount of data, helping significantly with performance.
In previous versions of Exchange Server, Mailbox and Public Folder Databases were logically owned by individual Exchange Servers, and contained within Storage Groups, which themselves could contain multiple Databases with a single set of Transaction Logs. The concept of Storage Groups is no longer used in Exchange Server 2010, and Databases are now logically separate from Exchange Servers, instead using an attribute to define the current server that "owns" the database.
Exchange Server 2010 uses a technology new to this version of the product for clustering and replication of Mailbox Databases, known as Database Availability Groups (DAGs). Exchange Servers that are a member of a DAG use network-based replication to keep copies of Mailbox Databases up-to-date.
Previously, in Exchange Server 2007, the clustering technologies available were bound by Mailbox Database being logically owned by a single server, and therefore even servers utilizing the pre-cursor to DAGs, Cluster Continuous Replication (CCR), had limits on the scalability as only one Exchange Server per CCR Cluster could be active at one time. This limitation also affected the now removed technology also used in Exchange Server 2003, Single Copy Clusters (SCC), where shared storage was used to store a single copy of the Mailbox Databases owned by the server.
In Exchange Server 2010, each Mailbox Database can only be active on a single server at one time. However, the major change is that the clustering is performed on a per-database level rather than a server level. This allows all members of a Database Availability Group to have active databases, and due to the placement of the RPC Client Access Service on the Client Access Server Role, clients do not get disconnected when a database is switched between Exchange Servers hosting Mailbox Databases.
All DAG member servers participate in the cluster itself. However, the underlying cluster configuration is managed by Exchange Server rather than the Administrator themselves. As a majority node set cluster, a DAG requires a majority (over 50 percent) of the DAG member servers to be online for the cluster to be operational. To ensure resilience in the case where there is an even number of DAG member servers, a Windows file share is used to provide an extra cluster "vote". This is known as the File Share Witness, and is typically configured on another Exchange Server, typically a Hub Transport Server.
Additionally, the previous limitation on the number of Mailbox Database copies has been increased; each Mailbox Database can have up to 16 copies in a DAG. This improvement in the number of copies that can be achieved has allowed the Exchange Team to suggest new options for providing cheaper Mailboxes, such as supporting the use of direct-attached storage that doesn't use RAID, known as JBOD, or Just a Bunch Of Disks. JBOD is supported in scenarios where at least three Database copies exist in a DAG.
The following diagram illustrates an example of a scenario where four Exchange Servers hosting the Mailbox Role are participating in a DAG, using four copies per database:
In the diagram above, you will see that each copy of a database has an activation preference. The activation preference is taken into account when a server fails to determine the next server that should make a database active. Typically, the database will be active on the server that has the first database activation preference set, except during a failover or when a server is down for maintenance.
Exchange Server 2010 replicates mailbox databases using a technology that ships the transaction log files to other DAG member nodes that host a copy of the database, known as Continuous Replication. The transaction logs are replayed to the other database copies, which means each copy of each database is independent and not subject to replication of general block-level corruption of the underlying database caused by file system errors. Logs are shipped over the TCP/IP protocol and either shipped as entire log files, or as each transaction has occurred (known as Block Mode). Exchange Server 2010 automatically determines which mode to use and generally when copies are up-to-date, block mode is used. Public Folder Databases are not replicated using the same Continuous Replication technology used by Mailbox Databases.
Instead replication between servers is performed using the same technology Public Folder Databases have used in earlier versions of Exchange, where each Public Folder Database is effectively standalone and replication is performed on a schedule via Hub Transport servers. Therefore, to achieve Public Folder Database resiliency, Databases should be created on a number of Exchange Servers hosting the Mailbox Role, and the Public Folders within should have replicas added to each. In general though, unless you need Public Folders, they are best avoided altogether.
Database Availability Groups can span multiple datacenters to provide resilience and disaster recovery abilities in the case of a total or temporary loss of a data center.
Failover between datacenters is not an automatic process and involves going through a process to "shrink" the cluster before bringing it online at the secondary datacenter, and associated reconfiguration of other services, such as DNS names for Client Access Servers.
When the original primary datacenter is brought back online, it's important to avoid a situation where the original servers attempt to activate their Database copies—the last thing they knew was that they owned the Databases before the failover occurred. This would result in a situation where the Database copies become inconsistent and require a full copy from the active secondary datacenter.
Such a situation, known as split brain, can be avoided through the use of a technology called Datacenter Activation Co-ordination Protocol (DACP) .This technology prevents the DAG member nodes in the original datacenter from activating databases and attempting to take ownership of the cluster though the use of an in-memory flag, the DAC memory bit. When the original servers come back online, they will attempt to contact other Mailbox Servers to check for servers with the DAC memory bit set to 1. If they cannot contact another server, they won't attempt to mount Databases. When they can contact the secondary datacenter with the currently active Databases, they will be able to continue startup with knowledge of the cluster state, mounting Databases without the risk of a "split brain".
Although the Database Availability Group site resilience facilities in Exchange Server 2010 initially sound complicated, with careful planning and understanding of how a switchover and switchback is managed, it is actually fairly straightforward and a worthwhile consideration for building a resilient Exchange Server infrastructure that can withstand a major disaster with little to no data loss and minimal downtime.
Hub Transport Role
The Hub Transport Role deals with the transfer of mail between sender and recipient in Exchange Server 2010. Without the Hub Transport Role, mail goes nowhere. When a message is submitted to Exchange, the Hub Transport deals with determining where the message needs to go and takes responsibility for ensuring as best as it can that the message was delivered successfully.
In particular, the Hub Transport Role fulfils the following functions:
- Mail transfer (using SMTP) between user mailboxes and public folders (even on the same server or mailbox database)
- Mail routing and transfer in and out of the organization, up to the Edge Transport Role or other SMTP gateway
- Routing of mail within the Exchange organization
- Managing mail queues
- Where appropriate, storing copies of mail until it is successfully delivered to its destination using technologies, such as the Transport Dumpster and Shadow Redundancy
- Acts as the mail submission server for clients using SMTP to send mail (such as POP3/IMAP clients)
- Performs business logic on SMTP mail using Hub Transport Rules
Looking deeper into the Hub Transport role, the first thing you will notice is there is configuration at two levels. The first is at the Organization level and this covers the address spaces (or internet domains) that the Hub Transport server is responsible for accepting or relaying mail for, and connectors to manage sending mail outside of the Exchange Organization, known as Send Connectors.
Send Connectors are typically used for sending mail to the Internet and can use the standard DNS-lookup-based method (MX records) for finding the correct mail server to deliver to, or can be configured to use a smart-host to pass the mail on to for eventual delivery.
The second set of configuration takes place on a per-server basis and in particular it's important to understand what Receive Connectors are. The Receive Connector is the configuration for each "listener" that a Hub Transport server uses to accept incoming mail. Like Internet mail servers, this uses the SMTP protocol and has configuration options to determine what TCP/IP port and IP address each Receive Connector listens on for new connections, and settings to determine who or what can connect and what authentication methods should be accepted. By default, Receive Connectors are created to listen on the standard TCP/IP port, 25, for server-to-server communication (such as Mailbox Servers submitting mail for delivery) and a client-focused Receive Connector listening on port 587, a secondary standard TCP/IP port allocated for client SMTP submission. By default, no unauthenticated connections are allowed and mail can only be relayed by authenticated senders.
Beginning with Exchange Server 2007, Active Directory sites are used for routing mail within an Exchange environment. In previous versions of Exchange, mail routing was managed separately to the Active Directory site infrastructure through the use of routing groups and bridgehead servers. Exchange Server 2007 simplifies the management of mail routing by respecting the configured Active Directory site information, but it does mean that the design of Active Directory is important to the Exchange environment.
The following diagram illustrates the mail routing in Exchange 2010:
The Hub Transport Role is one of the easiest roles in Exchange Server to provide high availability for. While the Client Access Role requires session information to be maintained, particularly for services, such as Outlook Web App, each session to the Hub Transport Role is distinct, and subsequent sessions do not require either the client or server to know about previous sessions; quite simply when an SMTP client logs in and sends a message—once it's been accepted at the end of that session, the transaction is complete.
Internally, Exchange Servers are capable of dealing with a failed Hub Transport server with no impact on the end-user experience. And no load balancing for Hub Transport-to-Hub Transport communication is necessary or indeed supported. DNS round-robin can be used for rudimentary balancing of end-user client connections that use SMTP, as can a load balancer; however, compared to the configuration required for a Client Access Server, load balancer configuration is straightforward.
One traditional weakness of the Hub Transport server in a highly available environment is the mail queue database. If a Hub Transport server fails before delivering messages, typically messages can be lost. Exchange Server 2010 improves upon this with a feature called Shadow Redundancy. Within Exchange Server 2010, this feature delays deletion of the submitted message until all the message hops with the Exchange environment have completed. If they fail, the message is re-submitted, meaning no messages are lost if a Hub Transport server fails.
The following diagrams illustrate how this functions, firstly, in normal operation without a failure:
Next, let's look at how shadow redundancy functions when there is a server failure:
Finally, the Hub Transport role contributes to the high availability features of the Mailbox Role, using the feature known as the Transport Dumpster. When a message is delivered to a Mailbox Server, the message will not be deleted permanently from the Hub Transport server until it has been notified that the message has been replicated to all copies of the destination mailbox database. In the event of a "lossy" database failover, any messages that were not replicated in time will be re-submitted to the Mailbox Server hosting the currently active database.
The following diagram illustrates how this re-submission process functions:
Edge Transport Role
The Edge Transport Role in Exchange Server 2010 is the first of the two optional components in an Exchange Server deployment. The Edge Transport Role can only be installed separately from other Exchange Server roles on a server that is not a domain member. The Edge Transport Role is very similar to the Hub Transport role, in that it deals with transport of mail. The major difference is that is it focused on communicating with external clients and is typically situated in your Edge network (also known as a DMZ).
The main functions of the Edge Transport Role are:
- External SMTP facilities for incoming and outgoing messages from the organization
- Message hygiene facilities to junk e-mail through the use of real-time block and by allowing lists and content scanning
- To host a local copy of relevant directory information using Active Directory Lightweight Directory Services (previously known as Active Directory Application Mode, or ADAM), used to store information about known users and user-managed junk e-mail lists
Conceptually, the Edge Transport role is very similar to the Hub Transport Role. The technology used for transporting messages is the same; the key difference is that it's not directly attached to the Active Directory domain. Instead, an Edge synchronization relationship is created to allow Exchange and Active Directory data to be published regularly to the Edge Transport Role.
The Edge Transport Role is the ideal place to use as your first line of defense against spam, malware, and other threats. Basic techniques to cut down spam include the use of Real-time Block Lists (RBLs) from providers such as SpamHaus. Using a combination of the right RBLs can cut down on most common spam. The Edge Role also has the ability to perform content-based scanning to further help with reducing Spam, and by installing Malware scanning tools like Forefront Protection for Exchange you can add on inbound scanning for Malware and Spyware and provide enhanced Spam-filtering before any mail reaches the core Exchange organization.
The techniques for providing high availability for the Edge Transport role are very similar to those used to provide high availability for the Hub Transport Role. Multiple Edge Transport servers can be placed within the organization, ideally at strategic points, such as multiple paths to and from the Internet.
Incoming mail resilience and high availability is built into the SMTP protocol through the use of Mail Exchanger, or MX records. These DNS records are created for each domain and are used to direct inbound mail to the correct mail server. Each entry would typically be the external hostname of each Edge Transport server and a weighted number is specified to determine which one other SMTP server on the Internet should attempt to try first; the lower the number the higher the priority. If you're simply providing resilience and want to provide a degree of load balancing between the two, it's common to give all the Edge Transport servers the same priority.
The following diagram illustrates a highly-available Edge infrastructure across two sites:
The Edge Transport Role isn't your only option when looking to manage your inbound and outbound messaging requirements.
For small environments, especially those with a single server, Administrators can configure the Hub Transport server to accept messages directly from the Internet, enable the Anti-Spam facilities typically provided by the Edge role, and install and configure anti-malware protection. While not an ideal solution, for those on a limited budget, it can be a simple solution.
However, there are many other solutions in the marketplace that will provide the functionality of the Edge Role either as a hosted service, dedicated software, or appliance.
Hosted services such as Forefront Online Protection for Exchange (FOPE), Google Postini, and Symantec Message Labs act as your inbound Mail Exchangers to the outside world and accept and deliver inbound and outbound mail on your Exchange organization's behalf. Messages from these services are typically delivered directly to your Hub Transport servers, which use firewall rules to only allow SMTP connections from your hosted provider's Internet address space.
Dedicated software or appliances are conceptually similar to the Edge Transport servers, in that they run within your datacenter, located in your Edge/DMZ network. Examples of solutions include BarricadeMX, Barracuda, and GFI MailEssentials. However, there are many on the market, including free, open source solutions like MailScanner which can be downloaded and installed at no charge.
Unified Messaging Role
The Unified Messaging Role is the second optional component of Exchange Server 2010. This role provides voice-based access to the Exchange organization—accepting voice mail and delivering it to user mailboxes or allowing voice-based access to Exchange 2010. First introduced in Exchange Server 2007, the Unified Messaging Role is in its second incarnation and integrates smoothly with many third-party IP phone systems.
In particular the Unified Messaging Role provides the following features:
- Voicemail services including transcription of voice messages into text with supported languages
- Voice access to end user mailboxes allowing messages to be read out loud to the end user
- Configurable voicemail routing and call transfer based on user-configured rules, such as the options to provide a different message if the user is out of office or in a meeting
- Directory access for external callers using the Auto Attendant services
- Uses the MP3 codec making playback of voicemail straightforward on iOS devices
As a component of Exchange, the Unified Messaging Role is fairly straightforward to manage and on a per-server level there is little configuration, apart from determining the protocols it will use to listen for IP PBX connections on and installation of language packs for your region.
At an organization level, configuration is a little more complicated and requires understanding of IP telephony technologies to configure correctly. For a successful implementation mapping between users' telephone extensions and mailboxes needs to be performed and a Dial Plan configured to define the relationship between Exchange and the IP PBX, along with rules for number translation, a Session Initiation Protocol (SIP) trunk to carry voice traffic between Exchange and the IP PBX or PSTN gateway.
A highly available Unified Messaging service relies somewhat on the capabilities of your IP PBX or PSTN gateway - by providing multiple Exchange Servers hosting the Unified Messaging Role, you provide the infrastructure that can receive incoming and make outgoing SIP sessions with the associated IP PBX or PSTN gateway.
As each Unified Messaging server is effectively stateless, once it has processed each inbound call or voicemail the balancing of calls is handled by the IP PBX or PSTN gateway and its capabilities to associate multiple servers with a SIP Trunk.
Active Directory
Although not an Exchange role, Active Directory plays one of the most critical roles in Exchange Server. Without Active Directory, your Exchange Server can't do very much at all. In particular, Active Directory provides the following to Exchange:
- User, Contact, and Distribution Group information, including end user directory information, e-mail addressing, and mailbox configuration information, such as what mailbox database a user mailbox is located on.
- Directory information used to generate Offline Address Books and used by clients, through the Client Access Server to look up Global Address List information.
- Nearly all configuration for Exchange Server including information about Mailbox and Public Folder databases, database availability groups, policies, and organization-wide settings such as accepted mailboxes, and basics such as the Exchange Server computer accounts.
- User authorization and authentication services for end-users. Much like all clients log-ons are passed by Exchange Server to Active Directory.
- Administrative permissions, including Active Directory-based permissions and configuration information for Exchange Server's role-based access control.
As you can see, if your Active Directory infrastructure has a problem, Exchange Server has a problem. Therefore if you are building high-availability into Exchange Server, you also need to consider building high-availability into your Active Directory infrastructure.
Before installation of Exchange Server 2010 there are some basic pre-requisites for the Exchange environment; the forest functional level must be at least Windows Server 2003 or higher, and the domain controllers should be Windows Server 2003 SP1 or higher. Naturally, later functional levels and Windows Server operating systems are supported, especially for larger environments. 64-bit domain controllers are recommended due to their ability to cache more information in server memory.
Active Directory is a multi-master directory service, so by installing extra domain controllers in each site and designating appropriate ones as Global Catalog servers, you provide resilience to your environment, including your Exchange Server infrastructure.
In smaller environments it is tempting to install Exchange Server and Active Directory Domain Controller Role onto the same server, and although this is the configuration for a specialized product like Small Business Server 2011, in a generic Exchange Server environment it is not considered best practice. If you install Exchange Server onto an Active Directory domain controller, you cannot choose later on to demote the Domain Controller—to do so you would need to uninstall Exchange Server first.