Windows 7 / Getting Started

---

Exchange Mailbox Services Configuration

Much of the configuration that is done for the Mailbox server role is done during the hardware configuration and installation of the Mailbox role. After the Mailbox role is installed, creating and configuring databases usually completes most of what needs to be done. After the deployment is completed, management of mailboxes and public folders is usually the extent to which the Mailbox server is managed. When you install Exchange, you need to consider a number of important things.

One of the biggest considerations is where Exchange should be installed and how the disks should be configured for the databases. As best practice it is always good to have the operating system and the system page file configured on separate RAID1 or RAID10 disks.

As with Exchange Server 2007, each database needs to be located on the same path on each server that will host a copy. When deploying a DAG with more than 22 different databases, managing drive letters might be a challenge. Rather than assigning each drive a new letter, they should be assigned mount points on a RAID-protected volume. Following this best practice will allow more than 24 disks to be used and provide flexibility to remount a replacement disks to that mount point quickly in case of a failure. If the disk that hosts the mount points fails, the mount points will also become unavailable. Protecting the mount point host volume with RAID will ensure that a single disk failure will not cause all of the databases to go offline.

This tutorial has covered a number of the storage improvements that have been made in Exchange Server 2010. These changes affect all aspects of design and should cause experienced Exchange administrators to reconsider a lot of the accepted assumptions that have become rote. One of these is the need to ensure that the transaction logs and the database must be on separate physical disks. With the lower I/O requirements and database write smoothing, this no longer becomes a problem with disk contention. There are still reasons that it might be good to split the transaction logs and databases on separate volumes or disks. One such reason is to not allow growing transaction logs to run the disk out of space and cause the database to go offline. In a stand-alone deployment it is still important to store the transaction logs on separate disks from the database so that in the event of a disk failure, both the transaction logs and the database are not lost. In a high-availability deployment, multiple copies of the data already exist on other servers.

Determining the Number of Mailboxes for Each Server

A number of factors go into deciding the number and size of mailboxes that should be placed on a single server and how to configure the number of mailboxes that should be placed in each database. The final decision will weigh several key factors, such as the size, relative importance, and, most important, the service level agreement (SLA) required for the mailboxes.

Although 10,000 mailboxes provided to university students with a maximum quota size of 25 MB at no cost may take up more space than 250 executives with a maximum quota of 10 GB, the former mailboxes are arguably far less important. Weigh this relative importance against the number of mailboxes that can be recovered within the SLA. When it comes down to it, database size is often governed by your redundancy design.

Determining Where to Host Mailboxes

A number of best practices are defined for placing mailbox servers and mailboxes on these servers. As you define the location of each of your user populations, the network connectivity, server and storage capabilities, and skill sets available at each site, where to place the servers may become clearer.

The Litware deployment is a distributed environment with Exchange mailbox and other services pushed out to the remote sites. This has several advantages, especially if the users at the remote offices primarily communicate with each other. Because users primarily communicate with each other, the majority of the e-mail messages stay within the site and do not need to traverse the network. The side benefit of this is that in the event of network issues where the remote site loses connectivity back to one of the corporate sites, the local users can continue to send and receive e-mail. The downside of this configuration is that support for the remote servers can be challenging especially if physical access is needed to repair the hardware.

The Fabrikam deployment uses a more centralized deployment. The benefit of this type of deployment is that mailbox services are concentrated in locations that have appropriate network connectivity and support staff to handle monitoring and maintenance of the hardware and software. The best practice for determining where to host mailboxes depends on what fits the business requirements, network requirements, and administrative requirements. The principle should always be to keep the design as simple as possible while still achieving the goals. You need to ask several key questions when determining where to host mailboxes:

• Is there adequate and redundant bandwidth available between the clients and the Exchange servers?
• If the Exchange servers will be hosted at a remote location, how will backups, hardware maintenance, and monitoring be accomplished?
• Does the remote site have adequate power, cooling, and network connectivity?