One of the more interesting factoids about the changes that Microsoft has made to improve the Exchange Information Store is the way that reported mailbox sizes change. Apparently there’s quite a lot of overhead within the database that has never been charged against user mailbox quotas. I assume that the until-now-forgotten overhead includes general debris, forgotten messages, bits of email addresses, and similar crud that accumulates over time. The Exchange developers maintain that they are simply being more accurate in mailbox accounting.
In any case, the Exchange 2013 boasts a brand-new Store process written in managed code (note to self: was the Exchange 2010 Store code unmanageable?). This is deemed to be a very good thing by those in the know, which clearly don’t include me. A separate worker process is now used to control each database and the whole shooting match is coordinated by a management process that keeps the workers in line.
The Exchange 2013 Store remains based on ESE. The bunch who hanker after an SQL-based implementation of Exchange will be sadly disappointed at this news but the rest of us are quite content that ESE remains king of the Exchange heap.
Among the other claimed benefits for the new Store such as yet another reduction in I/O, this approach allows problems that affect mailboxes to be confined to a single database and avoid affecting the other active databases mounted on a server. For instance, if a mailbox contains some corrupt items that are accessed by a client, the knock-on effect is now confined to the database and doesn’t extend across the entire mailbox server. You can’t argue with fault isolation.
Of course, it’s the I/O reduction that gets the headline news, at least when Squeaky Lobster (really Ross Smith IV in a cunning disguise, kind of like Spiderman for Exchange geeks) speaks on the topic. It’s hard to remember when Exchange used to consume the I/O capacity of an entire SAN by simply starting its processes and the rate that the developers have driven I/O improvements over the last three versions is impressive. During his impressive technical keynote at MEC, Ross claimed an overall reduction of 99% in I/O between Exchange 2003 and Exchange 2013. I can’t think of a similar improvement in another product.
But getting back to mailbox quotas, there’s no increase in the physical database file on disk. All that’s affected is the calculation of how much quota a user mailbox has consumed within the database and therefore how much of that quota remains. According to the Exchange 2013 Preview release notes, the actual difference is in the order of 30 to 40% extra, so a mailbox that is reported to hold 100MB of data in Exchange 2010 will be shown as anything between 130MB and 140MB in Exchange 2013. Of course, you might never notice the increase if you have a sufficiently large quota. For instance, if your quota is 10GB and you’re only using 1GB today, seeing an increase to 1.3GB after your mailbox moves to Exchange 2013 won’t cause any concern. Unless you worry about such things, in which case it’s time to consult with a shrink.
A problem might exist for users who teeter on the edge of their quota, those who have to juggle items within their mailboxes today. A good indication of someone who’s on the verge of quota exhaustion is when they are forced to delete messages and then empty the Deleted Items folder before they can receive messages. Users like this will definitely have a problem when their mailboxes are moved as there’s a fair bet that instant quota exhaustion will be a side effect of the migration. That is, if the mailbox move even completes as the Mailbox Replication Service (MRS) will not extend mailbox quota if a move exceeds the available space.
The solution is relatively simple. First, you need to understand the quotas assigned to users now and the percentage that are actually used. There are many PowerShell-based reports available for both Exchange 2007 and Exchange 2010 that you can use, include the popular version written by MVP Paul Cunningham. Next, you should identify users who have or who are approaching quota exhaustion and immediately assign these mailboxes some extra quota. Apart from anything else, this gesture will be much immediately appreciated by the users and that’s always a good thing. Last, consider whether the standard mailbox quotas in use within your organization are appropriate in light of current usage patterns, user expectations, and storage capacity and adjust quotas and warning limits accordingly.
In an era when consumer expectations are set by the 25GB mailboxes available in Gmail and Office 365, I bet you’ll discover a good case for a general increase in mailbox quotas. Users will be happy and more productive and you’ll establish a much better base for an eventual migration to Exchange 2013. And by the time you get to that point, you’ll have forgotten about the small extra overhead that the Exchange Store imposes on mailboxes.
Follow Tony @12Knocksinna
