Managing Mailbox quota’s: databases with different settings?
So, a while back I discussed an on-premises Exchange design for a customer. When discussing database distribution in an Exchange 2013 Database Availability Group (DAG), the topic of mailbox quota’s came along. They insisted on having different Database (DB) level quota’s and move mailboxes to other databases when the user requires more storage space.
It’s a tactic I have seen before, especially during Exchange 2003 (Enterprise edition) and Exchange 2007. I can understand why organization adopt this practice, it’s easy to implement and relatively easy to administer. But I prefer a different approach, one that has less technical issues and is simpler from an infrastructural viewpoint.
The problem with quota tiering of DB’s is that it requires mailbox moves when a higher quota is necessary. That generates extra transaction logs, but also generates white spaces in the DB’s with lower quota’s. Luckily transaction logs are purged after a successful full backup, but you have to take the extra necessary space into account. The same goes for white spaces. Yes, it will be re-used for new mail, but it’s still storage you won’t win back immediately, unless you perform a database rebuild. Something I wouldn’t recommend on a regular basis.
Another thing to consider is that the amount of quota sizes is limited to the amount of DB per server. In 2010/2013 Edition Standard that is 5 DB’s, which is hopefully not an issue. What might become an issue is the amount of storage used per database. Microsoft recommends maximum database sizes of 200GB and 2TB, the first size is for an single DB the latter one if the DB is protected within a DAG. Do note that these are recommendations, depending on your situation it could very well be prudent to keep the DB’s smaller due in order to keep restore times in line with you Service Level Agreement. In any case, this will immediately affect the amount of mailboxes that you could keep in a database and it could result that you would have no more in order to keep with this practice with Exchange Standard edition and thus upgrade to Exchange Enterprise Edition which has the ability to mount up to 100 DB’s.
Also, there might be a correlation between mailbox size and mailbox activity; a more active mailbox will probably reach it’s quota more quickly. So, concentrating those mailboxes in the same database might give rise to higher IOPS for that specific database with larger quota mailboxes. Even though the Exchange Server Role Calculator can be used enter up to four different mailbox type usage, but it assumes all mailboxes are randomly spread out all DB’s. I won’t suspect any issues from this, but it is certainly something to take into account.
So, I prefer to set the same default quota setting on all databases. It’s a much more simple approach, especially when using a DAG. I consider the DAG mostly a big data black box and don’t care where the mailbox is located. This way you can profit from the automatic mailbox provisioning introduced in Exchange 2010, which load balances the placement of mailboxes across databases unless excluded. This way all mailbox activity and storage is leveled out over the available databases and thus they should all behave relatively the same. Which I reckon would simplify admin life in the long run, more so than the benefits of having database quota’s.
If there is a need to increase the quota beyond the established default quota value, I would set it on the mailbox directly. Especially with the Exchange Management Shell (EMS), you are much more flexible. You can even schedule a task with a script that checks group memberships or custom attributes (for instance) periodically and adjusts that mailbox quota according to specific requirements. This way you still have an easy or even automatic method increasing a mailbox quota, but without the previously mentioned downsides.