With Exchange Server 2010, Microsoft Corp. made significant changes to the database structure that underlies the...
email application. These changes have a significant impact on planning for Exchange Server's data storage requirements. Learn Microsoft Exchange 2010 archiving best practices in this tip.
An important factor to consider that may impact your Exchange Server storage planning is whether you plan to implement user archive mailboxes, a new and optional feature in Exchange 2010. User archive mailboxes are secondary mailboxes that can be used for long-term retention of messages. What makes archive mailboxes different from other Exchange archiving methods is that unlike a more traditional archive (such as a journal mailbox), the user retains ownership of the items in the archive mailbox. As such, each user's archives are readily accessible.
Archive mailboxes are designed to take the place of PST files. But unlike PST files, archive mailboxes are stored within a mailbox database on the Exchange Server where they can be managed and regulated by the Exchange administrator.
In the original RTM release of Exchange 2010, user archive mailboxes were in the same mailbox database as users' primary mailboxes. In SP1, Microsoft provided the option of relocating user archive mailboxes to a separate mailbox database that allows the archives to be offloaded so they don't impact the primary mailbox storage.
Microsoft generally recommends placing the archive mailboxes on a low-end mailbox server that uses inexpensive direct-attached storage (such as a SATA array). Remember, if a mailbox database contains only archive mailboxes then it won't be subject to the same I/O load as a mailbox database that's used to store the user's primary mailboxes. Another advantage to using low-cost storage for user archive mailboxes is that doing so makes it practical to set a high mailbox capacity quota on the archive mailboxes.
Can Exchange Server 2010 archiving and e-discovery replace third-party products?
Prior to the release of Exchange Server 2010, an entire industry emerged around creating archiving and e-discovery products for Exchange Server. Now that Exchange 2010 offers native support for user archives and has built in e-discovery capabilities, it seems only natural to consider whether these new features can replace third-party products.
Exchange 2010's archiving features may be sufficient for some smaller organizations, but they're not enterprise-ready. The archiving and e-discovery features both have limitations you won't encounter with most third-party tools.
For example, Exchange 2010's archive mailboxes aren't a true archiving solution. Archive mailboxes let users offload important messages to a secondary mailbox that's not subject to strict retention policies or storage quotas. But if you want to do true archiving at the organizational level you still must use Exchange's journaling feature. The journal works, but third-party archivers provide much better control over message archival, retention and disposal.
The situation's the same for Exchange 2010's multi-mailbox e-discovery search feature. Multi-mailbox search has some major limitations. For example, it can only be used with Exchange 2010 mailboxes, so you'll still need a third-party product to search legacy Exchange mailboxes or PSTs.
Multi-mailbox search also lacks some of the rich reporting options and export capabilities commonly found in specialized e-discovery products.
Another consideration to take into account is the journal mailbox. If you use journaling to archive messages at the hub transport level then all the archived messages are placed into the journal mailbox.
I've never come across any Microsoft best practices for the placement of journal mailboxes, but I like to put the journal mailbox in its own mailbox database. This is because the journaling process tends to be very I/O intensive and placing the journal mailbox in a dedicated mailbox database ensures its I/O doesn't degrade the performance of the other mailbox databases. If all messages are journaled, locating the journal mailbox within the same store as the user mailboxes will double the I/O requirements because Exchange 2010 doesn't use single-instance storage. In other words, journaling causes an extra copy of each message to be created within the mailbox store.
If you were to create the journal mailbox in the same database as the user mailboxes, it would have a major impact on the replication process.
Another advantage to locating the journal mailbox in a separate mailbox database is that it makes it easy to manage storage quotas and message retention based on mailbox function. You can create one set of policies for user mailboxes and another set of requirements for the journal mailbox.
The last type of mailbox you should consider when planning for Exchange 2010 storage is the discovery mailbox. The discovery mailbox is only used when a multi-mailbox search (e-discovery) is performed. The search results are stored in the discovery mailbox.
By default, the discovery mailbox is assigned a 50 GB quota. This sounds large, but it may be too small for performing e-discovery in a large organization.
When it comes to choosing a storage location for a discovery mailbox, capacity is generally more important than performance. While the e-discovery process is I/O intensive, the I/O load is split between the database containing the user mailboxes and the database holding the discovery mailbox.
If e-discovery isn't a priority, then you may consider not even bothering to create a discovery mailbox until you need it. If that's not an option, your best bet is to place the mailbox in a dedicated mailbox database that lives on a low-cost storage system with plenty of free disk space.
More planning required
Clearly, there are a number of considerations that must be taken into account when planning an Exchange Server storage architecture. Even though Exchange 2010 isn't as I/O intensive as its predecessors, I/O performance should still be a major consideration in the design process. Other important considerations include capacity and fault tolerance.
About this author: Brien M. Posey is a seven-time Microsoft MVP for his work with Exchange Server, Windows Server, Internet Information Server (IIS) and File Systems/Storage. He has served as CIO for a nationwide chain of hospitals and was once a network administrator for the Department of Defense at Fort Knox.
This article was previously published in Storage magazine.