I’m working with a customer at the moment who has a few problems with their Exchange Server environment.  Most of the problems stem from explosive growth in staff numbers without all of the right standards and procedures in place to ensure that the Exchange system would scale upwards and continue delivering the required KPIs.

One of the problems is an unbalanced distribution of mailboxes across the various mailbox databases on the Exchange servers.  The reason for this is quite simple – each of the mailbox databases is given a name along a standard, but this name gives no indication as to which mailboxes should be placed on it.  In fact there is no system in place to determine where a given mailbox should reside.

As a result of this whenever a new mailbox is created it is placed at random onto one of the mailbox databases.  After a few years of this practice we can see that some databases have just a few dozen mailboxes in them, whereas others have thousands of mailboxes in them.

Unbalanced Database Problems

An unbalanced distribution of mailboxes such as this can cause some serious problems, such as:

• Excessive I/O load on some databases and their back-end storage
• Databases well in excess of recommended maximum sizes
• Long backup and recovery times for the larger databases
• Long maintenance times on the larger databases

A more efficient database layout needs to be designed and implemented to resolve these issues.

Design Considerations

Designing a database layout for an Exchange system takes some careful planning and consideration of the characteristics of the business and network environments.  There is no ‘one size fits all’ approach to this.  As I discussed the matter with my colleagues, these are some of the factors we took into consideration:

• Geographical location of the mailbox servers
• Limitations of the Exchange Server product version in terms of maximum allowed databases
• Mailbox storage quotas, for example VIPs have 2Gb limits but staff have 500Mb limits
• Current size and likely growth of the business in terms of staff numbers
• Maximum recommended database sizes from Microsoft
• Maximum practical database sizes to achieve backup and recovery timeframes
• Naming convention that makes it simple for IT admins to select a mailbox database for new mailboxes

The first consideration is an easy one.  It goes without saying that if mailbox servers are dispersed among the major geographical locations of the business then mailboxes should be placed on the closest server to the user.  So for example, North America users will be placed on server located on that continent, and the database naming convention will include an indicator such as “NAM” or “NAM-East”.Similarly, any limitations of the Exchange Server product version (e.g. Exchange 2007 Standard allows only 5 databases, whereas Enterprise allows 50) create obvious constraints when planning a database layout.

Placing VIPs on their own databases configured with different storage quotas is another common step.  A naming convention can support this as well, for example “NAM-East-VIP” and “NAM-East-Staff” indicate which North America/East users should go where.

Some of the elements need to be considered together.  If the business is expected to grow 25% in the next 3 years, then you may want to allow 25% headroom when projecting your database sizes so that in 3 years time they are still less than the recommended maximum size from Microsoft.  You also should consider your projected database sizes in light of your backup and recovery targets.  It is no good to be under the recommended maximum if that size is still too large to allow a recovery from backup tape in less than the required timeframe.

Three Design Approaches

When it comes to breaking down groups of users in a given geographical area into smaller sub-groups to reduce individual database sizes my colleagues and I discussed three approaches:

1. Division/Department – this method simply allocates databases to different business units and names them accordingly, for example “NAM-East-Staff-Sales” or “NAM-East-Staff-Engineering”.  This makes it easy to place a mailbox, but can lead to imbalances if Sales has 50 staff and Engineering has 300 staff.
2. Surname – this method allocates databases to staff whose surnames start with a given letter or letters, for example “NAM-East-Staff_A-C” or “NAM-East-Staff_D-F”.  Again this makes it easy to place a mailbox, but obviously there are some letters of the alphabet that have more surnames than others.  The answer to this is to break down or group together letters as necessary, for example “NAM-East-Staff_Aa-Ah” might have as many mailboxes as “NAM-East-Staff_X-Z”.
3. Numbers – this method allocates a mailbox to a database when it is created based on which database currently has the fewest mailboxes.  Usually this is accomplished by way of a script that checks each database to determine which has the least mailboxes, and places the new mailbox there.  While this would usually ensure an even balance of mailboxes it means developing a script and training IT admins to use it during mailbox creation.

The Bottom Line

As I wrote earlier there is no ‘one size fits all’ approach to designing an Exchange Server database layout.  Any of the above methods can work successfully as long as it is the correct method for the environment in question.  The best way to determine this is to consider each of the factors mentioned earlier.  Above all else you should ensure that the system that you implement can be easily understood by the IT admins who will be operating it on a daily basis.  If you can’t easily answer the simple question “Where does this mailbox go?” then your design may be flawed and need reconsidering.