Deploying Exchange Server 2010 : Exchange Server Messaging Roles

1. Understanding Exchange Server Messaging Roles

Exchange Server 2010 implementations 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. Remote users can check their mail over the Internet by using Outlook Anywhere, Outlook Web App, Exchange ActiveSync, POP3, or IMAP4,remote users can connect to the Client Access server and check their messages.

• Unified Messaging Server A middle-tier server that integrates a private branch exchange (PBX) system with Exchange Server 2010, allowing voice messages and faxes to be stored with e-mail 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, e-mail, 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.

• Hub Transport Server A mail routing server that handles mail flow, routing, and delivery within the Exchange organization. This server 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 Hub Transport server can also record, or journal, messages and add disclaimers to them.

• 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 Hub Transport server inside the organization.

These five roles are the building blocks of Exchange organizations. Table 1 provides an overview of the supported processor core configurations for these roles. Processors can be single core, dual core, or multiple core. Following the configurations shown in the table, a dedicated Mailbox server has a recommended maximum number of processor cores of 12, but a server with the Mailbox and other roles combined has a recommended maximum of 16. Note that although Exchange Server 2010 can support this number of processor cores, it might make more sense to scale out to multiple servers rather than to scale up the processor cores on a single server.

Because you can combine all of the roles except the Edge Transport server role 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, Client Access server, and Hub Transport server roles. These three 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 Edge Transport server role in a perimeter network on one or more separate servers.

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 2010.

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 group as well.

With the Client Access role, you can enable load balancing and failover support by making Client Access servers members of the same Client Access array. Each Client Access server in the array will then be able to support all client access features, including Outlook MAPI, POP3, IMAP4, Outlook Anywhere, Outlook Web App, and Exchange ActiveSync. You can use Client Access arrays to build groups of up to 32 load-balanced servers, starting with as few a two servers and incrementally scaling as demand increases. Servers that are members of an array cannot also have the Mailbox role. If you are using the Network Load Balancing service, Microsoft recommends no more than eight load-balanced servers.

Because of the built-in, high-availability features, the hardware you use with Exchange Server 2010 might be very different from the hardware you use with earlier releases of Exchange Server. Consider the following scenario:

City Power & Light is running Exchange Server 2007 throughout its organization. The company has clustered Mailbox servers running on two nodes; it's using separate servers for client access, hub transport, and unified messaging; and it has two Edge Transport servers. Clustered Mailbox servers are connected to a storage area network (SAN). Half the disks in the SAN are configured for primary data, and the other half of the disks are configured for backups. The SAN uses RAID 0+1 and RAID 5. Other Exchange servers in the organization use internal drives—RAID 1 for their boot and system volumes, and RAID 5 for their Exchange-related volumes. Backups are rotated regularly to off-site storage.

When planning its Exchange Server 2010 environment, the company decided it no longer needed clustering hardware. It also decided that it no longer needed to dedicate half the storage space on its SAN to backups or use RAID. Instead of using clustering, the company plans on configuring three Mailbox servers as part of the same database availability group. The mailbox database copies available to each server will act as the company's on-site data backup. As a safeguard against logical corruption that replicates across the databases in the DAG, the company decided that one database copy would be lagged behind the others by 72 hours. Because the company isn't using RAID on many SAN disks, there are many more data disks available for storage. Mailbox database failover is automatic for members of the database availability group.

Because the company no longer needs to have dedicated Mailbox servers and is able to combine any roles (except Edge Transport), it decided to run the Hub Transport and Unified Messaging roles on its Mailbox servers as well. To take advantage of load balancing for client access, the company decided to set up three Client Access servers in a load-balanced array. The company will retain both Edge Transport servers as well.

This highly available configuration makes the IT team members confident that they can achieve 99.5 percent or higher uptime for Exchange services, a marked improvement over previous service-level commitments. Higher availability also allows the IT team to streamline many of its processes, especially when it comes to recovery, server backup, and data backup. Still, the team has decided that it will continue to regularly rotate backups to off-site storage.

2. Deploying Mailbox Servers: The Essentials

The underlying functionality of a Mailbox server is similar to that of a database server. Every mailbox-enabled recipient defined in the organization has a mailbox that is used to store messaging data. Groups of related mailboxes are organized using databases, and each database can have one or more database copies associated with it.

With Exchange Server 2007, you needed dedicated hardware for clustered Mailbox servers, those servers could not run other roles, and failover occurred at the server level. Microsoft re-engineered Exchange Server 2010 to provide continuous availability while eliminating these restrictions. This means:

• You do not need dedicated clustering hardware for highly available Mailbox servers. Key components of Windows clustering are managed automatically by Exchange Server.

• You do not need to use Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), or Standby Continuous Replication (SCR). LCR has been discontinued. Key features of CCR and SCR have been combined, enhanced, and made available through database availability groups.

• You can combine multiple Exchange roles on highly available Mailbox servers. This means you can create a fully redundant Exchange organization using only two Exchange servers. In this case, each server would have the Mailbox, Client Access, and Hub Transport roles. You would also need a witness server for the DAG, which doesn't have to be an Exchange server.

The underlying technology built into database availability groups is the key ingredient that makes high availability possible. The related framework ensures failover clustering occurs in the background and doesn't normally require administrator intervention. As a result, Exchange Server 2010 doesn't need or use a cluster resource dynamic-link library (DLL) and uses only a small portion of the Windows clustering components, including heartbeat capabilities and the cluster database.

Database availability groups use continuous replication to achieve high availability. With continuous replication, Exchange Server 2010 uses its built-in asynchronous replication technology to create copies of mailbox databases and then keep the copies up to date using transaction log shipping and replay. Any server in a group can host a copy of a mailbox database from any other server in the group. When a server is added to a group, the server works with other servers in the group to provide automatic recovery from failures that affect mailbox databases, including server failure, database corruption, disk failure, and network connectivity failure.

When you create a database availability group, Exchange adds an object to Active Directory representing the group. This object stores information about the group, including details about servers that are members of the group. When you add the first server to the group, a failover cluster is created automatically and the heartbeat is initiated. As you add member servers to the group, the heartbeat components and the cluster database are used to track and manage information about the group and its member servers, including server status, database mount status, replication status, and mount location.

Because Exchange Server 2010 databases are represented at the organization level, they are effectively disconnected from the servers on which they are stored, which makes it easier to move databases from one server to another. However, it also means you can work with databases in new ways and that there are also new requirements when working with databases. Keep the following in mind when working with databases in Exchange Server 2010:

• Storage group functionality has been moved to the database level. This means you'll work with databases in new ways.

• Database names must be unique throughout your Exchange organization. This means you cannot name two databases identically even if they are on two different Mailbox servers.

• Every mailbox database, except copies, have a different globally unique identifier (GUID). Copies of a database have the same GUID.

• Mailbox servers that are part of the same database availability group do not need to and cannot use shared storage. However, the full paths for all database copies must be identical on host Mailbox servers.

• Although a Mailbox server in a DAG can have a public folder database, public folder databases cannot be part of database availability groups, and you cannot create copies of public folder databases.

For a successful deployment of a Mailbox server, the storage subsystem must meet the storage capacity requirements and must be able to perform the expected number of input/output (I/O) operations per second. Storage capacity requirements are determined by the number of mailboxes hosted on a server and the total storage size allowed per mailbox. For example, if a server hosts 2,500 mailboxes that you allow to store up to 2 gigabytes (GB) each, you need to ensure there are at least 5 terabytes (TB) of storage capacity above and beyond the storage needs of the operating system and Exchange itself.

I/O performance of the storage subsystem is measured in relation to the latency (delay) for each read/write operation to be performed. The more mailboxes you store on a specific drive or drive array, the more read/write operations there are performed and the greater the potential delay. To improve performance, you can use multiple mailbox databases. You might also want to store databases with their transaction log files on separate disk drives, such that database A and related logs are on disk 1, database B and related logs are on disk 2, and so on. In some scenarios, you might want the databases and logs to be on separate disks.

I/O performance in Exchange Server 2010 running on 64-bit architecture is improved substantially over 32-bit architecture. On Mailbox servers, a 64-bit architecture enables a database cache size of up to approximately 90 percent of total random access memory (RAM). A larger cache increases the probability that data requested by a client will be serviced out of memory instead of by the storage subsystem.

Note:

REAL WORLD Because of 64-bit architecture and cache optimizations for the Extensible Storage Engine (ESE), Exchange Server 2010 performs significantly better than Exchange Server 2003. Exchange Server 2010 can perform read and write operations with up to 1,024 kilobytes (KB) of data vs. 64 KB of data with Exchange Server 2003. This increases the ability to read and write larger I/O and means fewer I/O operations are necessary to service requests for data.

The streaming database file and installable file system have been removed and the database page size has been increased to 32 KB. Removing the streaming database file and installable file system reduces the overhead associated with maintaining a database. The page size is the minimum size for reading and writing to the database and is also the unit size for database caching. By using 32-KB database pages and caching these larger pages in memory, Exchange Server 2010 reduces the frequency of reads and writes. Exchange Server 2010 also makes data in the database more sequential, which increases the likelihood that related data will be grouped together. Further, each database has its own transaction log, making the database file and its associated transaction log the basic unit of backup and restore operations. Exchange Server 2010 performs substantially better than Exchange Server 2007. The store schema has been flattened to remove the dependency of mailbox databases to the server object. The schema also has been optimized by refactoring the tables used to store information and reducing the store's reliance on the secondary indices. As a result, the secondary indices no longer cause performance issues during peak usage or index maintenance periods.

Before you install the Mailbox role on a server running the Windows Server 2008 operating system, you must do the following:

3. Deploying Client Access Servers: The Essentials

Client Access servers handle all of the client-related messaging tasks in an Exchange implementation, and the underlying functionality is similar to that of an application server that makes extensive use of Web services. Because all local and remote clients now connect to Client Access servers to check mail, Client Access servers now perform many more I/O operations than on Exchange Server 2007. This means that in addition to processors, memory, network, and disk I/O are all potential sources of bottlenecks. It also means I/O operations on Client Access servers are no longer primarily limited to protocol logging, content conversion, and paging operations. Because content conversion is performed in the TMP folder, you can improve performance by ensuring that this folder is not on the same physical disk as the paging file and operating system.

Client Access servers provide access through the Outlook MAPI, Internet Message Access Protocol version 4 revision 1 (IMAP4), Post Office Protocol version 3 (POP3), and Hypertext Transfer Protocol (HTTP) Internet protocols. Exchange Server 2010 allows local access using Outlook MAPI and remote access using Outlook Anywhere, Outlook Web App, and Exchange ActiveSync. IMAP4 and POP3 are available as alternatives to standard protocols. Client Access servers provide access to free/busy data by using the Availability service, and they enable clients to download automatic configuration settings from the Autodiscover service.

Note:

REAL WORLD In Exchange 2010, RPC connections are made directly to the MAPI RPC connection point on the Client Access server and the NSPI endpoint on the Client Access server. HTTP connections are still made to the RPC Proxy component on the Client Access server. The Client Access server then communicates with the appropriate Mailbox server. For directory information, Outlook communicates with a Name Service Provider Interface (NSPI) endpoint located on the Client Access server. NSPI replaces the DSProxy and communicates with the Active Directory driver, which then communicates with Active Directory.

If one Client Access server in a Client Access server array fails, the client immediately reconnects to another Client Access server in the array. If a mailbox server fails, the client is disconnected for about 30 seconds. Each mailbox server can handle up to 250,000 RPC connections.

Client Access servers accept connections to your Exchange 2010 server over the local network and over the Internet. Some clients, such as Windows Live Mail, use POP3 or IMAP4 connections to communicate with the Exchange server. Other clients, such as e-mail software on mobile phones, use ActiveSync, POP3, or IMAP4 to communicate with the Exchange server. You must install the Client Access server role in every Exchange organization.

Client Access arrays provide load balancing and failover support for all client access features. Servers in an array cannot also have the Mailbox role and must be members of the same Active Directory site. Each array you establish has an external domain name, and client requests are directed to this external domain name, allowing for transparent load balancing as well as failover and failback. When a load-balanced resource fails on one server, the remaining servers in the array take over the workload of the failed server. When the failed server comes back online, the server can automatically rejoin the array, and the load-balancing feature starts to distribute the load to the server automatically. Failover takes only a few seconds in most cases.

When you use Client Access arrays, the external URLs for CAS-related services should point to the array rather than to individual servers, and the internal URLs should point to individual servers. Because of this, you should set the external URLs for Exchange ActiveSync, Outlook Web applications, Exchange Control Panel, and the Offline Address Book relative to the external domain name for the array. For example, Exchange ActiveSync runs as a Web application named Microsoft-Server-ActiveSync. When setting up Exchange ActiveSync URLs on each individual mailbox server, you should configure the internal URL to point to a specific CAS server, such as https://casserver48.cpandl.com/Microsoft-Server-ActiveSync, and the external URL to point to a location relative to the array, such as https://array1.cpandl.com/Microsoft-Server-ActiveSync.

During setup of Exchange Server for a Client Access server, you have the opportunity to specify whether the Client Access server will be accessible to clients outside the organization. If you select the related check box and specify the external domain name for your CAS array, the external URLs for CAS-related services will be configured to point to locations relative to the array automatically. Otherwise, you'll need to manually configure the external URLs for each CAS-related service.

The Exchange Management Shell has several cmdlets you can use to register arrays in Active Directory and in this way tell Exchange about load-balanced arrays you've set up for Client Access servers. These cmdlets include the following:

• Get-ClientAccessArray Lists information about available or specified Client Access arrays.

  Get-ClientAccessArray [-Identity ArrayIdentity]
  [-DomainController FullyQualifiedName] [-Site SiteId]

  
  

• New-ClientAccessArray Creates an object in Active Directory that represents a load-balanced array of CAS servers in a specific Active Directory site

  New-ClientAccessArray -Name ArrayName -Fqdn ExternalArrayName
  -Site SiteId [-DomainController FullyQualifiedName]

  
  

• Set-ClientAccessArray Specifies information about a named Client Access array.

  Set-ClientAccessArray -Identity ArrayIdentity [-Name Name]
  [-Fqdn ExternalArrayName] [-Site SiteId] [-DomainController
  FullyQualifiedName]

  
  

• Remove-ClientAccessArray Removes a Client Access array from Active Directory.

  Remove-ClientAccessArray -Identity ArrayIdentity
  [-DomainController FullyQualifiedName]

  
  

Load balancing can be implemented using hardware or software. Windows Server includes the Network Load Balancing service. Network Load Balancing doesn't use shared resources or clustered storage devices. Instead, each server has a copy of the Client Access services and features that are being load balanced and local storage typically is used. Generally, users usually don't know that they're accessing a group of servers rather than a single server. The reason for this is that the array appears to be a single server. Clients connect to the array using the array's external domain name, and this virtual address is mapped automatically to a specific server based on availability. It is important to note that you cannot use NLB for establishing a Client Access array if the Client Access servers are co-located on a Mailbox server in a database availability group.

Before you install the Client Access role on a server running the Windows Server 2008 operating system, you must complete the following steps:

4. Deploying Unified Messaging Servers: The Essentials

Unified messaging allows you to integrate voice mail, fax, and e-mail functionality so that the related data can be stored in a user's Exchange mailbox. To implement unified messaging, your organization must have a PBX that is connected to the LAN, and you must deploy a Unified Messaging server running Exchange Server 2010. After it is deployed, the Unified Messaging server has the job of providing call answering, fax receiving, subscriber access, and auto-attendant features that allow access to content over the telephone and storage of content received from the PBX.

Although some current PBXs, referred to as IP-PBXs, are Internet Protocol–capable, all other PBXs require a separate Internet Protocol/Voice over Internet Protocol (IP/VoIP) gateway to connect to the LAN. After you connect a PBX to the LAN, you can link it to Exchange by deploying and appropriately configuring the Unified Messaging server role. Prior to installing the Unified Messaging server role, you must install the Microsoft Speech service, Microsoft Windows Media Encoder, and Microsoft Windows Media Audio Voice Code as part of the Desktop Experience feature.

Similar to Client Access servers, Unified Messaging servers don't perform a great deal of I/O operations, and the primary potential bottlenecks for these servers are the processors, memory, and network. I/O operations on Unified Messaging servers are primarily limited to accessing routing details and dial plans, which include auto-attendant and mail policy settings.

Before you install the Unified Messaging role on a server running the Windows Server 2008 operating system, you must complete the following steps:

5. Deploying Transport Servers: The Essentials

The Hub Transport and Edge Transport roles are similar. You use both for messaging routing, and both have a similar set of filters to protect an organization from spam and viruses. The key difference is in where you place servers with these roles. You place a server with the Hub Transport role in the internal network and configure it as a member of the organizational domain. If you use a server with the Edge Transport role, you place it in the organization's perimeter network and you do not configure it as a member of the organizational domain.

For computers with the Hub Transport or Edge Transport role, the server cannot have the Simple Mail Transfer Protocol (SMTP) or Network News Transfer Protocol (NNTP) service installed. Although you install Edge Transport servers outside the Active Directory forest, you must have a DNS suffix configured and you must be able to perform name resolution from the Edge Transport server to any Hub Transport servers.

Tip:

Transport servers store all incoming mail in a database file called mail.que until the transport server verifies that all of the next hops for that message have been completed. This database has an associated transaction log in which changes are first committed. If you are using an Exchange Server's internal drives for storage in a high-volume environment in which one million or more messages are persisted, you should consider placing the database and the transaction log on separate disks for optimal performance. With SANs, it might not be immediately apparent whether disks are physically separate. This is because the volumes you see are logical references to a portion of the storage subsystem. In this case, you might be able to use the Storage Manager For SANs console or a similar tool to help you select logical unit numbers (LUNs) that are on physically separate disks.

Note:

MORE INFO Transport servers have many different queues for messages. These queues are all stored in a single ESE database called mail.que. By default, this database is located in %ExchangeInstallPath%\TransportRoles\data\Queue. Thanks to shadow redundancy, the deletion of a message in the database is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting back successful delivery, the message is resubmitted for delivery to that next hop.

Both Hub and Edge Transport servers perform protocol logging and message tracking. Only Hub transports perform content conversion. Protocol logging allows you to verify whether a protocol is performing as expected and whether any issues need attention. Message tracking creates logs that track messages sent and received. Incoming mail from the Internet is converted to Summary Transport Neutral Encoding Format (STNEF) prior to being delivered. STNEF messages are always MIME-encoded and always have a Content-Transfer-Encoding value of Binary. Because content conversion is performed in the temp folder, you can improve performance by ensuring that the temp folder is not on the same physical disk as the paging file and operating system.

Before you install the Hub Transport role on a server running the Windows Server 2008 operating system, you must complete the following steps:

Before you install the Edge Transport role on a server running the Windows Server 2008 operating system, you must complete these steps: