Chapter 2: Deploying Microsoft Exchange Server 2007

Before you deploy Exchange Server 2007, you should carefully plan the messaging architecture. As part of your implementation planning, you need to look closely at the roles your Exchange servers will perform and modify the hardware accordingly to meet the requirements of these roles on a per-server basis. Exchange Server is no longer the simple messaging server that it once was. It is now a complex messaging platform with many components that work together to provide a comprehensive solution for routing, delivering, and accessing e-mails, voice mails, faxes, contacts, and calendar information.

Exchange Server Messaging Roles

With Exchange Server Setup, you can deploy servers with specific roles throughout the enterprise. Prior to setup and configuration, you need to decide how you will use Exchange Server 2007, what roles you will deploy, and where you will locate those roles. Afterward, you can plan for your deployment and then roll out Exchange Server.

Understanding Exchange Server Messaging Roles

As discussed in Chapter 1, "Exchange Server Administration Overview," Exchange Server 2007 implementations have three layers in their architecture: a network layer, an Active Directory layer, and a 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. Using Microsoft Outlook, as discussed in Chapter 3, "Managing Microsoft Exchange Server 2007 Clients," local users can connect directly to the Mailbox server and check their messages. The Mailbox Server role is the only role that you can cluster.

• Client Access Server A middle-tier server that accepts connections to Exchange Server from a variety of different clients. This server hosts the protocols used by clients when checking messages remotely or over the Internet. Using Outlook Anywhere, Outlook Web Access or Exchange ActiveSync, as discussed in Chapter 4, "Managing Mobile Messaging Users," 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 2007, 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.

• Hub Transport Server Previously called a bridgehead server, this is 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 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 (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. In a nonclustered environment, you can combine all of the roles except the Edge Transport Server role on a single server. Because of this, 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.

Deploying Mailbox Servers: The Essentials

For Mailbox servers, the underlying functionality 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 storage groups, and each storage group can have one or more storage databases associated with it.

To provide failure protection, you can configure the Mailbox server role as a cluster resource, allowing the messaging workload of a failed server to automatically shift to another server in a cluster. Exchange Server 2007 has several enhancements that may change the way you use clustering for messaging servers, including:

• Continuous replication With continuous replication, Exchange Server 2007 uses its built-in asynchronous replication technology to create copies of storage groups and then keep the copies up-to-date using transaction log shipping and replay. In a nonclustered environment, you can use local continuous replication to create local copies of storage groups. In a clustered environment, you can use cluster continuous replication to make sure logs on an active node are copied to a passive node.

• Single-copy clusters With single-copy clusters, all Mailbox servers in a cluster use shared storage, allowing multiple servers to manage a single copy of your storage groups. As Mailbox servers now have their own network identity, not the identity of the cluster node, failover is smoother than with previous versions of Exchange and allows a clustered mailbox to be logically disconnected from the failed node and placed under the control of a new host node.

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 1,000 mailboxes that you allow to store up to 2 GB each, you'll need to ensure there are at least 2 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 performed and the greater the potential delay. To improve performance, you can organize mailboxes into multiple storage groups and store the related database and transaction log files on separate disk drives.

I/O performance in Exchange Server 2007 running on 64-bit archtecture is improved substantially over Exhange Server 2003 running on 32-bit architecture. On Mailbox servers, 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 substystem.

Real World Due to 64-bit architecture and new cache optimizations for the Extensible Storage Engine, Exchange Server 2007 can perform read and write operations with up to 1,024 kilobytes (KB) of data versus 64 KB of data previously. This increases the ability to read and write larger I/O and means fewer I/O operations are necessary to service requests for data. To further improve database read and write performance during I/O operations, the streaming database file and installable file system have been removed and the database page size has been increased from 4 KB to 8 KB. Removing the streaming database file and installable file system reduces overhead associated with maintaining a database. Using 8-KB database pages increases the likelihood that messages can be stored in a single database page, which also reduces the overhead associated with maintaining a database. Further, each storage group has its own transaction log, making the database file and its associated transaction log the basic unit of backup and restore operations. See Chapter 5, "Exchange Administration Essentials," for more information on data storage. See Chapter 18, "Backing Up and Restoring Microsoft Exchange Server 2007," for information on backup and recovery.

Deploying Client Access Servers: The Essentials

Client Access servers handle many of the stateless 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. Unlike Mailbox servers, Client Access 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 Client Access servers are primarily limited to protocol logging, content conversion, and paging operations. As content conversion is performed in the TMP folder, you can improve performance by ensuring this folder is not on the same physical disk as the paging file and operating system.

Note 

Client Access servers require three Internet Information services (IIS) 6.0 components: Enable Network Com+ Access, IIS Admin Service, and the world wide web service. You can install these IIS components through the Add Or Remove Programs utility in control panel.

Client Access servers provide access through the Internet Message Access Protocol 4 (IMAP4), Post Office Protocol version 3 (POP3), and Hypertext Transfer Protocol (HTTP) Internet protocols. Exchange Server 2007 allows remote access using Outlook Anywhere, Outlook Web Access, and Exchange ActiveSync. To allow full configuration for remote access, you must install the World Wide Web Service, ASP.NET, and the RPC over HTTP Proxy Windows networking component prior to installing Exchange Server 2007. For more information on remote access to Exchange Server 2007, see Chapter 4, "Managing Mobile Messaging Users."

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 local area network (LAN), and you must deploy a Unified Messaging server running Exchange Server 2007. Once deployed, the job of the Unified Messaging server is to provide 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 Microsoft Speech service, Microsoft Windows Media Encoder, and Microsoft Windows Media Audio Voice Code.

Note 

Unified messaging servers require Microsoft Core XML Services (MSXML) 6.0 or later. MSXML 6.0 supports the XML 1.0 and XML Schema 1.0 W3C Recommendations, and compatibility with System XML 2.0. The MSXML 6.0 SDK is available as a free download from the Microsoft Web site.

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 access routing details and dial plans, which include auto-attendant and mail policy settings.

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 the organization from spam and viruses. The key difference is in the placement of 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 used, you place a server with the Edge Transport role 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 domain name system (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 it is routed. This database has an associated transaction log in which changes are first committed. For optimal performance, you should place the database and the transaction log on separate disks.

Transport servers perform protocol logging, message tracking, and content conversion. Protocol logging allows you to verify whether a protocol is performing as expected and whether there are any issues that need attention. Message tracking creates logs that track messages sent and received. Incoming mail from the Internet is converted to Messaging Application Programming Interface (MAPI) prior to being delivered. As content conversion is performed in the TMP folder, you can improve performance by ensuring that the TMP folder is not on the same physical disk as the paging file and operating system.