In part 1 of this series I wrote about scaling Transport servers, and in part 2 I wrote about scaling Client Access servers.  In this third and final post in the series I will look at scaling of Mailbox servers.

Mailbox Servers

The role of the Mailbox server for Exchange Server 2007 is to host the mailbox and public folder databases for the organization.  In other words this is where all of the email, calendar, and other Exchange data is stored.

The Mailbox server accepts direct MAPI connections from Microsoft Outlook clients, but also receives other connections such as Outlook Web Access and ActiveSync via the Client Access server.

As the backend of the Exchange system the Mailbox server is usually located on the most powerful hardware and is often configured for high availability.  Because of the direct client access to the Mailbox server any performance problem is likely to be noticed immediately by end users, unlike say the Hub Transport server that may deliver mail slowly during periods of poor performance but this may actually go unnoticed by the users.

As an organization sends and receives email throughout the day the Mailbox server processes these transactions in its databases.  This means that careful attention needs to be paid to the disk performance of the Mailbox server, but attention also needs to be given to the processor and memory.

Processor Scaling

A Mailbox server can function with a single processor core but it is recommended to start with at least 4 cores.  For average email users a ratio of 1 core per 1000 users is appropriate, but for heavy users this decreases to 1 core per 750 users.

Because a Mailbox server may also be configured with one of the Exchange Server 2007 database replication features, or may host other roles as well, some additional factors should be considered.  When LCR is used the ration of processor cores to mailbox users decreases by 20% (ie 1:800 for average users).  Also, if multiple roles are deployed on the server the ratio also decreases by 20%.

As you can see combining LCR with a multi-role server will increase the processor requirements for a given number of users by a significant amount. Continue reading Scaling Up vs Scaling Out Exchange Server 2007 Roles Part 3 – Mailbox Servers

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”. Continue reading Designing an Exchange Server Database Layout

Back in Part 2 of this series I demonstrated how to backup the Exchange Server 2007 Mailbox Server role, and then how to use that backup to restore an entire mailbox database in the event of a disaster.  In this part of the series I will demonstrate how to use that same backup to recover individual mailbox items.

Mailbox Item Recovery for Exchange Server 2007

The backup utility that is provided with Windows Server 2003 is capable of backing up and restoring entire mailbox databases for Exchange Server 2007.  However it is not natively capable of restoring an individual mailbox item (such as a single email) should the need arise.

Some third party Exchange backup products do provide this functionality however this comes at a cost.  Fortunately all they are doing is providing a simple interface for a built-in feature of Exchange Server 2007 to perform the restore.

For businesses on a budget or anyone who simply chooses to use the built-in backup utility for backing up their Exchange servers you can still recover individual items thanks to Recovery Storage Groups.

What is a Recovery Storage Group?

A Recovery Storage Group is an Exchange Server 2007 feature that allows the administrator to create an “invisible” storage group that can be used to restore a mailbox database and extract data from it without affecting the production database that is being accessed by end users.

The Recovery Storage Group is only used for restore and recovery operations.  It is never connected to by an end user using Outlook or other mail protocols, and the mailboxes contained within it are not associated with any Active Directory user accounts.

Restoring Mailbox Items using the Recovery Storage Group

In this example the user “John Smith” has deleted an email from the inbox that was received last week.  The Mailbox server is backed up every night and so the email administrator knows that the item is likely contained within one of the previous nights’ backups. Continue reading Exchange Server 2007 Backup and Recovery Part 5 – Recovering Individual Mailbox Items