Mailbox Limits
As a seasoned Exchange administrator you have most likely heard from someone that "Storage is cheap, why must you put a limit on my mailbox rather than just adding more disks?" For a number of really important reasons, adding disk alone is not the answer. The primary reason is to meet SLAs. Without established mailbox limits, an SLA violation could occur in a number of ways. For instance, if none of the 5,000 mailboxes on a mailbox server had limits imposed, any single mailbox could consume all of the disks on a server in a matter of minutes. Although this could happen as the result of a malicious act, it can also be unintentional in a case where an Outlook rule or outside service continues to send e-mail messages to a mailbox, causing it to grow larger until the underlying storage fills up. With the improved performance and faster server hardware, these sorts of actions can happen in a matter of just a few minutes.
The other way mailbox limits play into achieving an SLA and controlling the size of databases has to do with achieving expected backup and recovery times. To recover the data in a database within the agreed-upon SLA, the databases must be under a specific size. For example, if you can restore 150 GB of data from your backup solution in three hours, and you have a four-hour SLA to restore the data, you do not want to allow the database to grow larger than 150 GB; otherwise, anytime a restore is required, the SLA will be violated. The easiest way to implement and maintain control over the size of the databases is to establish limits on the mailboxes and thereby not allow them to cause the database to grow beyond the size that prevent SLAs from being met.
This really means there is no hard and fast rule on how big mailboxes should be-just that a maximum size should be set. The best practice is to set a limit that in aggregate is less than the available disk space. That way if all mailboxes on the server reach the limit, the server will still have space to continue operating. That said, this may not be completely feasible, nor is it probable that all users will use their entire quota at the same time, unless there is malicious intent. In this case it is important to weigh the risks and costs involved.
Configuring Deleted Item Recovery Quotas
Configuring the deleted item recovery setting needs to be done after the business needs are captured and understood. However, a couple of settings should be configured to ensure that malicious users cannot cause Denial of Service attacks by placing large amounts of data into the dumpster and running the server out of space. To do this the RecoverableItemsQuota and RecoverableItemsWarningQuota settings should be set per database. However, the settings can also be done per mailbox. These settings are similar to mailbox quotas except that they apply to items in the dumpster:
- RecoverableItemsQuota The default limit is 30 GB; however, this can be set as needed. When the limit is reached all soft deletes will fail and an event log entry will be made the first time it occurs and once daily if the condition continues.
- RecoverableItemsWarningQuota The default limit is 20 GB; however, this can be set as needed. When the limit is reached, an event log alert will be made and will continue once daily afterward if the condition continues. The oldest items in the dumpster will be deleted to make room for new dumpster data.
In this tutorial:
- Mailbox Services in Exchange Server
- Exchange Server Mailbox Services
- Exchange Mailbox Services Architecture
- The Exchange Services
- Deleted Item Recovery and Dumpster 2.0
- Discontinuation of Storage Groups
- Increased Database Page Size
- I/O Operations
- Online Archive
- Exchange Mailbox Services Configuration
- Database Maintenance
- Mailbox Limits
- Poison Mailbox Detection and Correction
- Client Configuration
- Configuring Public Folders
- Configuring Public Folders for Site Redundancy