Recommended Mailbox Size Limits

Published Mar 14 2005 09:38 AM 146K Views

IMPORTANT: This article provides guidance for Exchange 2003. For guidance on more recent versions of the Exchange product, please see the following resources:

Many times I've been asked to give a guideline on how large a mailbox can be before performance degrades, or on the recommended size for a mailbox.  Unfortunately, this question is like asking "How many cookies are enough?"  There may be a lot of implied information, but the question itself is vague.   For example, I personally think there are never enough cookies, while my brother won’t eat more than one.  Nonetheless, I have been asked to forge ahead, declaring my assumptions, and stating my conclusions. 
First, there are no inherent size limits on individual mailboxes.  The main factors that limit mailbox size, practically speaking, are available disk space, backup and restore times, Service Level Agreements, and Outlook performance.  By Outlook performance I’m referring to the latencies experienced by the end user.  In this blog, I'll just talk about the limitation due to Outlook performance.
It's item count, not size, that matters

First, it's not the size of the mailbox that impacts performance - it is the number of items in the folder or folders that are being accessed on the server.  In particular, performance is largely influenced by the number of items in the most commonly used folders: Calendar, Contacts, Inbox, and Sent Item folder. 

Having a large number of items in a folder will mean than operations in that folder will take longer.  Operations that depend on the number of items in the folder include adding a new column to the view, sorting on a new column, finds and searches.   Many Outlook plug-ins do sorts or searches as they are running, and these requests may overlap with other Outlook MAPI requests, resulting in a poor user experience.
If you are running in Cached-Mode, (the default mode for Outlook 2003), then client performance can be an issue.  One thing you should do is keep your OST files (the local data cache) free of fragments.  There is a nice little tool called CONTIG on for this purpose ( 
All user pain is subjective

Setting a limit depends somewhat on your users’ tolerance for pain.  Are they comfortable with slow Outlook operations, or do they expect a snappy response?  How much wait are your users willing to tolerate?   The number of items in these key folders has a large impact on the delays for many common actions, and this is one factor that the user can control.   Publishing guidelines for your users may help them control their own experience.
Not all users are created equal

In addition to the number of items in the key folders, there are other factors that impact the Outlook experience, such as the number of other MAPI applications or Outlook plug-ins running on the user’s machine.  All MAPI requests contend for attention in emsmdb32.dll; if you have a lot of plug-ins making requests, Outlook will run slower.  Furthermore, the complexity of the action will have an impact.  For example, marking all items in a folder as read is going to take a lot longer than marking one item.  Other actions that inherently may take a long time include getting free-busy information for a lot of users on a meeting request, or doing a search across multiple folders.  If your users are frequently doing complex actions, have lots of plug-ins, or have high use of the contacts and calendar folder, you may want to recommend that they keep limit the number of items in their critical path folders.
Not all servers are created equal

If you're running on really old hardware, you may experience poor performance at a lower number of items than if you're running on the latest-and-greatest.  This is a big area and I’m just not going to go into this any further here... Ok, I lied; I have to add one more thing:  disk latencies.  For optimal user experience, make sure disk latencies are small (eg, 20ms or less), even during peak server usage (see my earlier disk blogs).
Here’s an example to show how disk latency can add up.  When getting a view, the requests for the data are done in individual, serialized requests from the disk, not bulk operations.  So for example, if a plug-in is getting a view of 1000 items, then the Exchange store will probably make about 200 separate requests for data (assuming about 5 messages are retrieved per request).  At 20 ms, that’s a guaranteed 4 second delay just from the disk subsystem alone!   Imagine if your disk latency was 50ms or 100ms? To make matters worse, if you have multiple plug-ins making similar requests, you may find that your Outlook client is frequently blocked.  Help yourself (and the other users) by keeping disk I/O latency low.
The Bottom Line:

I usually recommend no more than about 2500 - 5000 messages in any of the critical path folders.  The critical path folders are the Calendar, Contacts, Inbox, and Sent Item folder. Ideally, keep the Inbox, Contacts and Calendar to 1000 or less.  Other folders, particularly custom folders created by the user, can handle having larger numbers of items without having a broad impact on the user experience (20,000 items in my "Cookie Recipes" folder?  No problem - except when I need to find that recipe from last Christmas!). 
If getting word out to the users to reduce folder item counts is impractical, administrators have another option.   Administrators can use the Mailbox Manager tool to control the size of critical mailbox folders.  Unfortunately, Mailbox Manager does not evaluate the mailboxes based on message count within a folder— instead it processes messages by age and/or size of message.  Regardless, if your organization allows the use of it, it can help prevent mail folders - and user-frustration - from getting out of control.

- Nicole Allen

Not applicable
Prob a dumb question, but how do you keep the calendar items down?
Not applicable
What sort of plug-ins generate lots of server requests? Do the standard ones like Delegate Access, Deleted Item Recovery, etc. have any impact?
Not applicable
I've heard from someone else about the 'critical mailbox folders' and they should be left and no sub folders created in them. Myself, I believe subfolders in the Inbox are easier to manage, is this part of your strategy in keeping the items down in the inbox?
Not applicable
The worst offender I have ever seen - a 100 user company with no size limits, 30 users with more than 1GiB mailboxes, and one user with 9GiB! No amount of pleading can convince them to set up limits. Ah, well...
Not applicable
Nicole -

Can i just say GOD BLESS YOU? as an RRE, i am on site all the time - Literally. Of the most common issues we deal with, disk subsystem perf and mailbox related questions (perf and size) are amongst some of the most popular / inquired about. Your BLOG on DISK and finally on mailbox size is invaluable - I did and will continue to send customers to them all the time.
Not applicable
Thanks for the info, I was not aware that count mattered more than size, but end-user Outlook performance is only one issue. What about the ability to do store maintenance and backups? Are there reccomended limits for .edb files? Basically, we are trying to set a policy, but we have nothing but our subjective experience with no "best practices" to help us out.
Not applicable
Great info Nicole (thanks!). To expand on this further, if a user has sub-folders created under their inbox, would those also affect performance and count towards the total message count? Are we better off telling our users to create new root folders to store item long term. <br> <br>Thanks
Not applicable
Creating subfolders under the inbox will have essentially the same performance impact as creating them anywhere else - it's a great strategy - go for it!

One thing I didn't mention in the blog...and will mention here, even though it's unrelated to your question: It's also a good idea to keep the number of items in your task folder down. This is generally the case, and thus the task folder is often overlooked. Nonetheless, a large number of items in the task folder will slow down many common operations (including switching to the calendar view).
Not applicable
It's hard to get better feedback than that - Thank you!
Not applicable
Shucks, I'm blushing. Thanks for the feedback!
Not applicable
And lets not forget that pesky "Journal" folder! Ive seen those glue up many a mailbox.
Not applicable
The best way is to allow Outlook’s Auto-Archive to do the work for you.

You can modify the Calendar auto-archive properties. Select the "Folder" icon in the nav pane (so that you can see the Calendar folder in the list of folders), right click on the Calendar, select properties, select the auto-archive tab, select Archive this folder using these settings: Clean out items older than X months. (you choose X).

This will clean your calendar of old meetings.

The alternative is to delete them by hand.
Not applicable
The standard plugins are pay-to-play - that means they generate RPCs when you use them, and have low or no impact on other mail actions.

On the other hand, PDA Sync utilities, thread compression (when it is running), client-side virus scanners, client-side rules that run a script and some client-side content indexing plug-ins all tend to require a lot of RPCs.

Delegate access will increase mailflow, but shouldn’t have a large impact on RPCs; the impact should be proportional to the usage.
Not applicable
is there a limit to the # of Contacts in Outlook? i suspect but can't prove that i'm losing old contacts as i add new ones!

do you think the losses may be related to syncing w/ my Palm based Kyocera PDA/ phone?
Not applicable
Based on the questions that we got on another post, it seemed appropriate to address the &quot;Requesting...
Not applicable
Based on the questions that we got on another post, it seemed appropriate to address the &quot;Requesting...
Not applicable
Based on the questions that we got on another post, it seemed appropriate to address the &quot;Requesting...
Not applicable
Kevin&amp;rsquo;s Webcast Resources:
Exchange Server 2003 &amp;ndash; Tips, Tricks, and Shortcuts
Here are...
Not applicable

This is the final blog in my series about Exchange 2007 storage. In this blog I will...
Not applicable
Keeping control of your messaging data can often be a frustrating experience. Administrators can often
Version history
Last update:
‎Mar 14 2005 09:38 AM
Updated by: