As almost any parent knows, young children have a knack for asking difficult questions. One of my favorite question types is the "relational" question, exemplified by queries such as "How long is 'a while'?" or "How much is 'some'?" Because Microsoft's been touting the ability of Exchange Server 2007 to handle "larger" mailboxes than its predecessors, the question "How big is 'larger'?" has started to pop up more often.
First, a bit of context: Exchange doesn't have a hard limit on the size of individual mailboxes, and it never has. (I dare say it never will, but don't take that as a promise until you hear it from Microsoft.) Exchange does have limits on the size of mailbox databases, which effectively caps the size of individual mailboxes. However, average mailbox size is more often limited by other factors, notably the number of disk I/O operations per second (IOPS) available for mailbox service, the total amount of disk space available, and the number of mailboxes that can be managed on a single server.
These factors are all interrelated, and they all tie in to backup and recovery speeds. Say you want to put 2000 mailboxes on a server. You can back up 20GB per hour on that server, and your service level agreement calls for a maximum of 6 hours of downtime for restores. Because restores take roughly twice as long as backups, your server mailboxes should be limited to about 30MB each:
(3 hours x 20GB per hour) / 2000 mailboxes = 30MB per mailbox
Of course, that's with current disk sizes; in the days when a 20GB disk was big stuff, you might have settled on smaller mailboxes or fewer mailboxes per server.
Now, 250GB and larger disks are becoming commonplace in new server installations. Exchange 2007 promises a large-scale reduction in the number of IOPS required per mailbox, thanks to its 64-bit-powered ability to use large amounts of RAM for the Extensible Storage Engine cache. Microsoft says you can now use much larger mailboxes without a performance penalty. But should you?
Maybe not. Allowing mailboxes to grow without limit can be a bad decision for several reasons:
- Large mailboxes hurt client performance. Microsoft Outlook 2000 and later do a good job of handling large mailboxes; the problem is with the number of items in the mailbox. Compared with older versions, Outlook 2007 does a better job of dealing with high item counts, but that's not necessarily true of other clients, such as Research in Motion's BlackBerry devices.
- Large mailboxes hurt worker productivity. A commenter on the Microsoft Exchange Team Blog used the analogy of storing all your paper mail in your mailbox, instead of sorting through it and acting on or filing the important stuff. Exchange 2007 and Outlook 2007 have vastly better search capabilities than the versions we have now, but allowing unbounded mailbox growth encourages people to keep stuff they don't need just because they can.
- For companies that have retention or compliance requirements, letting employees keep lots and lots of email in their mailboxes instead of in the archive multiplies the problems associated with tracking and retaining necessary messages.
I can already hear teeth clenching among the legions of administrators and users who hate mailbox quotas. It's true that you shouldn't impose arbitrary quotas—if you have a business requirement for large mailboxes, feel free to let them grow. However, just because you can support larger mailboxes on your existing hardware doesn't mean that you must, or even should, until you thoroughly understand the impact on compliance, productivity, and performance.
Many of the technical obstacles that limited the use of large mailboxes in older versions of Exchange, such as slow full-text search and I/O congestion, have been eliminated from Exchange 2007. If those technical limits were getting in the way of your business processes, you'll be able to move forward with allowing larger mailboxes. Just be sure you know what you're getting into.
End of Article
Register
