In a recent post I discussed the various factors that must be considered when planning an Exchange database design.

For Exchange Server 2003 and 2007 the layout and naming of databases played an important role in the ease of administration as well as the balancing of database load.  If Help Desk staff randomly chose a database to host a given mailbox it could easily lead to unbalanced servers and result in poor performance of the Exchange back end.

Fortunately Exchange Server 2010 makes this a lot simpler thanks to several improvements and new features.

Database Performance Improvements

An immediate improvement in Exchange 2010 is the database performance, when viewed in the context of disk IOPS (Inputs/Outputs per Second) required to perform certain operations.  Simply put, a given operation in Exchange 2010 (let’s say a user sorting their 10,000 item inbox by name instead of date) generates far less read/write load on the disks that store that mailbox database.

The benefit of this is an increase in the potential mailbox density per database.  You can fit more mailboxes into a single database, and that database can be much bigger than in previous versions of Exchange (up to 2 terabytes instead of prior recommended maximums of 100 gigabytes).

Fewer databases leaves fewer choices for Help Desk administrators when creating new mailboxes, which is a good thing.

Mailbox Load Balancing

A new feature of Exchange Server 2010 is the mailbox provisioning load balancer.  This acts as an automatic distributor of new mailboxes between mailbox databases in the organization.

When a new mailbox is being created by the Help Desk they can choose a specific mailbox database, or simply let the mailbox provisioning load balancer choose one for them.

Here is an example of the load balancer after I created 6 new mailboxes at once (there were 2 pre-existing system mailboxes).  Notice that the distribution is not 100% even.

Count Name
----- ----
    4 Mailbox Database 1
    3 Mailbox Database 2
    1 Mailbox Database 3

Now here are the same databases after I created another 10 mailboxes.  See how the distribution is starting to even out more.

Count Name
----- ----
    8 Mailbox Database 1
    5 Mailbox Database 3
    5 Mailbox Database 2

Finally, I moved all 18 of those mailboxes to the first database, and then created another few hundred mailboxes.

Count Name
----- ----
  146 Mailbox Database 1
  125 Mailbox Database 2
  124 Mailbox Database 3

As you can see the load balancer does a pretty good job of distributing mailbox load.

Online Mailbox Moves

In previous versions of Exchange a mailbox move was disruptive to the end user.  They would be required to restart their Outlook client when the move had occurred to connect them to the new database.

Exchange Server 2010 solves this in two ways – firstly the MAPI connectivity (Outlook clients) has been moved from the Mailbox server role to the Client Access server role.  This means that an Outlook client connects to a single namespace for mailbox access that can remain the same regardless of the backend database the mailbox is actually on.

Secondly the mailbox moves occur online in a non-disruptive manner.  The end user does not need to restart their client to continue working, rather the Client Access server manages the change seamlessly for them.

This improvement means that Exchange administrators can run maintenance scripts any time of the day or night that will automatically assess mailbox distribution across the databases and can then run online moves to rebalance them if necessary.

Summary

Each of these three areas of improvement is significant in themselves.  But taken as a whole they present a much easier database design process for Exchange Server 2010 environments.