The limits of unlimited mailboxes

Introduction

Exchange 2007 and 2010 dramatically improved the ability for IT departments to provide mailboxes as large as 10GB or more for users. There is tremendous value for information workers in having a large mailbox, particularly with respect to productivity. Whether that means a 10GB, 20GB or larger mailbox, many organizations will want to impose size limits on some or all of their users.

Providing a healthy messaging service requires more than just a solid technology platform; it also requires excellent execution of operations and rigorous capacity management. Capacity management is a critical part of messaging operations and mailbox quotas directly affect the storage requirements of a messaging capacity plan. To ensure the capacity plan remains relevant, the Exchange system can be used to enforce mailbox size quotas.

There have been and are some organizations that try to provide their users with mailboxes of unlimited size. When departments try to do this, it affects the availability, reliability, and manageability of the messaging service. Of course, as mailboxes grow in size, one option is to continue adding storage to accommodate them. But providing unlimited storage requires unlimited space for that storage, and unlimited power and cooling, and of course, unlimited money. I’m not aware of any organization that is capable of providing even one of these things, let alone all of them.

Even if that organization existed and they went down this path, that implies growing Exchange databases beyond the recommended maximum size of 2TB. That in turn would affect the reliability of the system, because databases larger than 2TB can become unmanageable for a variety of reasons (NTFS fragmentation issues, database maintenance never completing, excessive database reseed times, reliability of copying that large of a dataset over the network, etc.).

If that organization instead stays within the 2 TB database limit, that implies deploying additional databases. When extrapolated, this implies eventually adding servers to scale out, especially after reaching the 100 database per server limit. Not to mention the additional storage that would be required to host copies of these databases on multiple servers.

Best Practices

One of the most important metrics to understand when sizing mailbox servers is the storage size limit (mailbox quotas) that’s in effect in your organization. Knowing the amount of data that a user is allowed to store in their mailbox allows you to determine how many mailboxes can be housed on the server. Although mailbox quotas can change in response to changing organizational requirements, having a goal for the mailbox storage quota is necessary to determine your needed mailbox database capacity.

If a limit isn’t set for mailbox storage quotas, you’ll find it difficult to estimate database capacity. Keep in mind, I’m not recommending small mailbox quotas or that all users must have the same quota, but rather that quotas should be in place. It can be a high limit, and it can be different for every user, but there must be controls in place to prevent runaway storage growth on the system.

Managing a lot of different mailbox quotas can be an administration headache so it is best to standardize on four or less mailbox quota sizes, which will enable you to make use of the Exchange 2010 Mailbox Server Role Requirements Calculator for capacity planning. Quotas can be set at the database level, which allows all users in that database to inherit the quota, or they can be set at an individual user level, which overrules the mailbox database quota setting. I don’t like to dedicate specific databases for different quotas, because this makes capacity planning difficult and can cause the database to be very dissimilar in sizes, which does not suit a JBOD storage model, particularly as we move into more symmetrical DAG designs with Exchange 2013. One of the strengths of the JBOD model is the simplicity of design, i.e., one disk hosts one database. It is better to mix those different mailbox quotas for users in with all the other databases so that the load in terms of storage and performance is spread evenly across all mailbox databases.

To quickly assign the same mailbox quota to a number of users that is different from the default mailbox database quota, I recommend placing all those users in a security group and use the following example PowerShell script:

(Get-Group VIP-Users).members | set-mailbox -IssueWarningQuota 9108MB -ProhibitSendQuota 9728MB -ProhibitSendReceiveQuota 10240MB -UseDatabaseQuotaDefaults $false

This PowerShell script returns all the members of the “VIP-Users” group and assigns the mailboxes of those users an individual quota, which is no longer inherited from the mailbox database parameters, with the following three thresholds:

  1. The first threshold “IssueWarningQuota”, triggers a friendly warning message, sent on a daily basis, when the user’s mailbox is larger than 9GB. It does not stop the user from using their e-mail.
  2. The second threshold “ProhibitSendQuota”, prevents the user from sending any more e-mails when the mailbox size is larger than 9.5GB.
  3. The last threshold “ProhibitSendReceiveQuota”, stops the user from sending and receiving e-mails when the mailbox size is larger than 10GB.

Implement Quotas Now

While some companies only start implementing quotas after experiencing an outage caused by running out of space, or after realizing that they can’t keep on throwing money at the problem, you don’t have to wait. You can implement mailbox quotas now.  I recommend implementing quotas in stages:

  1. Start by creating the capacity plan using the Exchange 2010 Mailbox Server Role Requirements Calculator that suits the requirements and budget of the business.
  2. Communicate to users that quotas will implemented in the future. In my experience it helps to tell them sooner rather than later. They’ll want to know, among other things, the size of the mailbox quota and when it will be implemented.
  3. Equip users with training to manage their mailbox sizes by showing them how to determine their mailbox size, and how to permanently delete e-mail messages that are no longer needed.
  4. Start to implement the “IssueWarningQuota” message, which will only warn users that will be affected by the new mailbox quotas in the future. This message can be customized and even contain a reference to an Intranet training site that you can create to assist them in the cleanup.
  5. Implement the “ProhibitSendQuota”, and consider a custom “ProhibitSendReceiveQuota” per-user based on their current mailbox size. For example if a user’s mailbox is currently 14GB make his quota 15GB to start applying control over the storage requirements.
  6. Start reducing the custom “ProhibitSendReceive” quotas to the desired quotas week-by-week until all mailbox sizes are less than their desired mailbox quota.

Lastly, most mailbox size requirements would grow over time and a size that is appropriate today may not be in a few years’ time. Ask yourself: how would I meet my business, availability, compliance and retention requirements if I implement a mailbox size that is 10 times bigger than I currently have? As long as you plan for this up front, the sky could be the limit!

Credits:

Thank you to Scott Schnoll for your assistance with this article. You are a legend.

Martin Coetzer

I practice the art of consulting by fusing the needs of clients with technology to create collaboration solutions.

martincoetzer has 11 posts and counting.See all posts by martincoetzer

Pin It on Pinterest