Thinking about Mailbox and Message Size Limits

Published 07-06-2006 10:00 AM 76.9K Views



I regularly meet with customers and discuss their Exchange Server architecture.  Two topics frequently come up so I thought I'd discuss them with everybody and give my perspective on them.


Many customers tell me that they do not impose mailbox and/or message size limits on the vast majority of their user population. This poses a problem because you will never be able to adequately design a storage subsystem or maintain the desired database size limits, let alone meet any service level agreements that may be in place.


Additionally, most of these customers do not have defined, measurable, and actionable Service Level Agreements (SLAs) or Operating Level Agreements (OLAs) in place to manage user expectations (i.e. messaging as a service), and thus cannot measure a real cost/benefit with regards to the user population demands.  Ultimately, the lack of mailbox size limits and message size limits can lead to instability in the messaging architecture.


Oh, and I consider an outrageously large limit (to quiet the restless natives) the same as the lack of mailbox and message size limits.


Mailbox Limits


The following areas or issues may occur in your environment if you do not have a proper quota management policy in place:

-         Denial of Service Attacks - Without a message and mailbox size limits, a hacker (whether internal or external) can easily implement a denial of service attack by sending messages with large attachments, ultimately using all available resources on the Exchange servers, thereby causing system failure.  Implementing message size limits (both internal and external) can reduce the likelihood of this risk.

-         Capacity Planning - The lack of quota management effectively limits any type of future capacity planning (e.g. cannot predict future database growth).  In particular, if you have an SLA that dictates a backup/restore window you may not be able to meet that goal, due to not being able to control the database size metric.

-         Network Utilization - Since the users will have unlimited mailbox sizes, network utilization will increase between client and server if users utilize OSTs or cached mode Outlook clients.

-         Single Instance Storage - Single Instance Storage ratios may continue to decrease if reactionary measures are used to combat the lack of quotas (e.g. continually moving mailboxes around the enterprise to head off low disk space, SLA attainment, etc).

-         Cost Impact - Due to the growth that will likely ensue without a proper quota management implementation, organizations will find that the cost per mailbox will and continue to increase over time.  In addition, most likely additional costs will accrue due to poor management of the solution, in terms of not having proper SLA/OLAs, moving mailboxes to head off capacity disasters, and overloading servers from a performance and capacity standpoint (due to the aforementioned mailbox moves).

-         Performance Impact - A lack of quota management will mean that eventually the storage subsystem will not be able to sustain the I/O throughput required.  As you increase the mailbox sizes, the number of items will increase and for most users this will mean an increase in the number of items in the key folders (Inbox, Sent Items, Calendar, etc); as the number of items increase, the I/O throughput per mailbox will increase (  In addition, since the amount of data increases, users may deploy desktop search programs, and when running in online mode, these search programs utilize Exchange server resources ( 


Also remember that mailbox quotas are only part of the solution:

-         Users should realize that a mailbox is not a file storage area; the users will require some training on email etiquette that is appropriate in their business.  For more information on email etiquette rules, please review

-         Organizations could provide alternate solutions like SharePoint Portal Servers and Windows SharePoint Services where users can save documents and can collaborate around them by sending links via email as opposed to attaching the documents. 

-         Archiving solutions can help, but only with proper planning and design. Also, please note that most archival solutions replace the archived content with a stub reference.  The stub references still have an impact on the messaging view creation process and affect the performance and scalability of the solution.


To resolve the lack of mailbox size quota management in the short-term, organizations should:

-         Identify an appropriate message size limit.

-         Identify appropriate size limits; include warning, prohibit send, and prohibit send/receive.

-         Identify key personnel that require additional storage capacity, above and beyond the limits defined from above. Create separate SLA/OLAs for these sets of users.


To resolve the lack of mailbox size quota management in the long-term, organizations should:

-         Implement defined Service Level Agreements and Operating Level Agreements that measure the messaging solution as a service; e.g. Gold, Silver, Bronze; 99.99% availability, etc that are actionable and measurable.

-         Gain support from the business for the budget and resources to support the defined SLA/OLAs. 

-         Implement the message size limit.

-         Implement the mailbox size limit using mailbox database policies.

-         Move key personnel onto a dedicated database store and use a separate mailbox database policy to control mailbox size.


Message Size Limits


Microsoft has a best practice of a 10MB limit.  Exchange Server 2003 by default sets the global message size limit to 10MB.  The Exchange Product Group implemented this code change due to customer feedback and to help protect against denial of service attacks.


Issues that can arise from a lack of internal message size quota policy:

-         Denial of Service Attacks - Without or with improper message size limits, a hacker (whether internal or external) can easily implement a denial of service attack by sending messages with large attachments, ultimately using all available resources on the Exchange servers, thereby causing system failure.

-         Capacity Planning - Improper quota management effectively limits any type of future capacity planning (e.g. cannot predict future database growth).

-         Backup/Restore Windows - Improper quota management will ultimately impact backup restore windows.  As the database sizes grow, the backup window will increase.  At some point this backup window will interfere with business hours.  The same is true for the restore window.

-         Virus Scanning - Improper quota management will incur performance penalties on virus scanning of the messages.

-         Anti-Spam Measures - Many anti-spam products won't scan the message if they are over a certain size.

-         Network Utilization - Network utilization will increase as messages are sent between Exchange servers and between the Exchange organization and the Surf Control relay devices.


To resolve the lack of message size quota management in the short-term, organizations should:

-         Organizations should monitor and study the contribution of impact related to such large size limits.

-         Organizations should consider alternate products for attachments, so that the overall message size limit can be reduced.  For example, Windows SharePoint Services integrates with Office 2003, thereby allowing attachments to be stored on web sites.

-         Do not implement message size limits on SMTP Virtual Servers as that will also impact public folder replication.  Message Size Limits should only be implemented globally, on connectors, or on the mail-enabled object (


To resolve the lack of mailbox size quota management in the long-term, organizations should:

-         Organizations should implement another mechanism for file transmission and storage.

-         Organizations should reduce the overall message size limit.

-         Define SLA/OLA's and gain support from the business for the budget and resources to meet user demands.

-         Monitor and measure performance to the defined SLA/OLA's.


The Future


Many of you may say "That's great Ross, but the technology doesn't support us.  The users need their data and we can't allow them to delete it because we'll have to restore more, or we can't allow them to go to PST, etc".   


Yes I know, with today's technologies it is hard to implement a solution, but it is doable.  For example, Microsoft IT implements a strict message and mailbox size limit policy, as well as defined measurable SLA/OLAs for the messaging service.  For more information, visit IT Showcase at


But beyond Outlook 2003's capabilities of restricting PST access (you do know you can do that, right?), Exchange 2003 doesn't provide any mechanism (beyond the limited Mailbox Manager Policies) to implement life cycle management or long-term archival (our third-party partners help in this area - 


But fear not, we are making great strides in Exchange 2007 and Outlook 2007 around email life cycle management (in Exchange 2007 it is known as message record management).  In addition, our move to 64-bit, allowed us to make changes to the product to reduce the IOPS/mailbox requirements (see for more information). 


I encourage you all to review the Exchange 2007 Beta 2 demos on Compliance to learn more about what's coming -


With these features, I truly expect customers to finally be able to get a handle on the data that exists within their message stores and to finally be able to implement valid message and mailbox size limits.


- Ross Smith IV

Not applicable
Usually the reason I hear for no mailbox limits is not technical.. it is political. The IT department isn't strong enough to stand up to users who complain about their "small" mailboxes. Even if it is a written policy!
Not applicable
Legal issues are now becoming predominant as well.  Because of a growing number of retention regulations (which not only differ state-to-state but world-wide as well), the shift in limits is increasingly moving from a size-based limit to a time-based limit, which is easier to defend legally.  

This does not mean that there are not still ways to mitigate uncontrolled mail store growth (limiting file attachment size and rigidly enforcing time-based retention limits are two examples) but controlling mail store limits by size alone is increasingly becoming less practical to do.

Great post though as this is currently a hot topic for our team.
Not applicable
The interessting part of the E2007 Story is, that MS is propagating a default Mailbox Size if 2GB!!! I'm sure this will be no problem with the new 64Bit architecture...but how will you backup such a Database in a reasonable time? Even with snapshots...
Not applicable
Michael - Couldn't agree more...that's why many of the Message Records Management features we have in Exchange 2007 will be so handy!

Not applicable

Yes we are advocating larger mailboxes due to the architectural changes we made in ESE and Store as a result of moving to the 64-bit platform.  One of those changes is an increase in the number of storage groups (from 4 in E2K3 to 50).  Also you can have 50 databases per server (we are still keeping hte SG database depth at 5).  So today you might have 20 databases with 250 200MB mailboxes and that potential db size might be 50GB.  Well in Exchange 2007, you can have 50 databases, so you could have 100 mailboxes that have 500MB size limits.  Or you could go higher on the mailbox size limits and reduce the number of users (to ensure your backup strategy is met).  Also remember that we also have the continuous replication strategies which will reduce the need to backup against the production data (you will be able to utilize VSS to backup the replica).

Basically it all comes down to your requirements, SLAs, RTOs and RPOs.  They will still drive the underlying design.
Not applicable
Ross in an early E2K7 presentation I saw they stated there would be up to 50 Storage Groups (not Mail Stores).  If I misheard this then I am now worried.  With a lot of 3rd party backup and recovery tools the Storage Group is the unit of granularity (due to Trans Logs) not the Mail Store.  For example a popular SAN appliance uses the Storage Group for its "instant" recovery target so all stores are affected.  This is not the only such tool that emphasized Storage Groups.  In otherwords 50 mail stores does me no good if I have to affect some significant number of them to recover.  

Can you please correct me or the following website info?

• Performance improvements   Exchange 2007 supports deployment on a 64-bit architecture for improved performance and capacity. Because of the move from a 32-bit architecture to a 64-bit architecture, the Enterprise Edition of Exchange Server 2007 now supports a larger number of storage groups and databases per server. Exchange Server 2007 lets you create as many as 50 storage groups per server. Although a storage group can contain as many as 5 databases, there is a limit of 50 databases per server

Not applicable
Ross my apologizes for misreading your last post..  it pays to read throughly before getting too worried. ;)
Not applicable

I totally disagree with you on just about every point that you list. And my experience is that your conclusions are inconsistent with what actually occurs at customer sites, and I've been doing Exchange and Exchange consulting for over 10 years now.

The statement of not being able to manage an environment without quotas is just wrong. Want an example of how an environment with a ridiculously high limit can work? Take a look at your buddies over at MSN or Google with 2GB FREE mailboxes. I'll guarantee you that they know the details of users and servers more than 99% of the mail installations. You seem to subscribe to the belief that "if you provide it, they will use it" That's absolutely incorrect, otherwise all of these MSN and Google mailboxes will be full, and if I remember rumors correctly, they AVERAGE less than 25MB per user.

For a standard corporate environment, you can pretty well assume that the average usage will be in the 100-200MB per user range (dependent on the type of organization). From that you can easily extrapolate the server sizing needed for an organization. Limits are limits and are very different from averages. Averages are what system sizing should be based on, not limits.

And as part of mailbox etiquette you indicate that users shouldn't use email as a file storage facility and that other solutions such as SharePoint should be utilized. Well, first of all, remember IT is a SUPPORT organization and that IT should SUPPORT what the users need. but more importantly, let's just take the situation where you and me want to do a little business and exchange some files. How long would it take for you to get a SharePoint portal created and accounts for me created and the files uploaded? And then what mechanism is there that would make sure that the site is deleted when we finish corresponding? I know that in probably 99% of the organizations, this isn't only hard, it is impossible for a standard user to request!
Exchange actually provides one of the best solutions for file management that Microsoft currently has. What other solutions allow me to share files with ANYONE on the Internet at ANY TIME with no prior setup? What other application allows me to replicate that data between my server, desktop, and laptop and even access the data with an Internet browser?
Not applicable
First I don’t think comparing an Internet Service Provider users to corporate users is a valid approach.  The usage scenario is completely different.  Did you know that they do not guarantee restore times or SLA's around data availability or recoverability?  Also, we typically see that once a limit is established, end users typically utilize 45-60% of that limit, but of course you will always see a bell curve with maibox sizes.

As for your sizing recommendation, well I will disagree with you there.  If you base things on averages and not the maximum that can possibly occur (it’s very easy to perform a DoS based attack and flood the environment with messages – I have one customer that routinely sees this within their environment because they won’t lock down distribution groups, and they get into a bedlam or “reply all” battle) then you will find at some point you will have to extend your storage.  Let me give you an example, within Microsoft, we designed our storage to support 4000 200MB mailboxes (with a database overhead factor of 1.4) per Exchange server spread across 20 databases.   At any point in time we can say that our database size will never exceed 55GB because we have limits in place and we know what the maximum will be.  If we designed without those limits, we would not be able to achieve our RTO and RPOs for backup and restore.  Also, this configuration has been in place for almost 4 years with zero storage changes.  I have yet to meet a customer that has had zero limits and not had to extend their capacity as a result.  But I have met many that have implemented them and have stories like Microsoft IT's.

Yes I do agree with you regarding teh storage facility comment, and I should have expanded on what I meant as I was really referring to internal communications.  SharePoint and other technologies are viable for intranet and established business partner communications. They aren’t viable for Internet usage, so yes email is usually the best method for transferring data.  By the way, the SharePoint technologies do offer automatic site deletion capability.

Not applicable

Could you comment more about how not having limits can effect performance from a user perspective. We have limts but lots of exceptions to those limits and it is all political. How do I convince my managers that limits will help performance in the long run?
Not applicable
Wouldn't a real SQL-based store (not another enriched version of ESE) the definitive solution? We have been expecting this for years...
Not applicable

There will always be cases where certain individuals either have higher limits or no limits, that's to be expected.  For those individuals you will find that they most likely have a higher I/O demand than their typical end user since they store more data and access more often.  The key thing to remember when dealing with large limits is to distribute the data across folders rather than storing it in a single folder; the more data within a folder the more processing the server (online mode, OWA, etc) or the client (cached mode) has to perform in order to display the data (e.g. user sorts 5000 item folder by subject line).  The time it takes to complete could be perceived by the end user as troublesome.

For those instances when users believe their performance is lacking, I would recommending using ExMON and ExPTA to help diagnose and uncover the potential problems.

Hope this helps.

Not applicable
Ross X,

Always nice to meet another Ross. :)

Regardless of where the data is stored, the same underlying principles would apply.  For example, you would apply the same approach to home directories, SharePoint sites, etc, so that you can provide an available and reliable infrastructure for your end users and maintain your enterprise costs.  

Not applicable
We have numerous mailboxes in our organization larger than 2GB...some of the largest are close to 10GB. ::cringe:: Can anyone beat that? :)

For many years our users were feared into not deleting ANY email other than spam because they thought they might be violating some State law regarding public records (we're a local govt. agency). Any attemps at convincing management to set mailbox limits in the past was met with strong resistance. There was also no attachment size limits for a few years before I arrived. I did convince them to enable message size limits because of DoS vulnerabilities at least (that and people would try and send a 600MB attachment and choke the server).

Now you can imagine that our Exchange Server performance is rather pitiful with such large mailboxes. I've worked to gather data to PROVE to management that the poor performance is due to large mailboxes & number of items per folder. Now that their Outlook performance sucks...guess what? They're beginning to listen!

We've also implemented a 3rd party email archiving solution...which has drastically helped the mailboxes sizes, but now the # of items per folder is the problem because the stubs are still there. I've seen mailboxes with 45,000 and up to 250,000 items in ONE FOLDER. Our next steps are to start deleting the stubs older than 1 year to reduce # of items per folder and enforcing a 200MB mailbox size limit via our archiving solution.

Thanks for posting this great blog. It helps shed some light on what email gluttons we are in our org. They always ask questions like, imagine how many emails Microsoft must get, they don't have these performance problems? It helps when you have a 200MB mailbox compared to a 10GB one!!

-Brian S
Not applicable
I think exchange is a victim of it's own success really - whilst most of the sites I work on have mailbox limits in place for the general populace, all of them have the limits removed for the real core email users (basically making the  limits a moot point).

It's all good and well saying that email should not be used as filestore, but show me a tool that is anywhere near as intuitive for finding information as outlook? add in remote access through OWA, and it's a near perfect situation.

Sharepoint might get useful in the future, but for now, it's just another slow clunky web interface, rather than a fast native client (ie outlook)

Not applicable
Our mailbox limits are based on one thing only - the ability to restore data in a reasonable amount of time.
Not applicable
Ross, I am confused about one point you make, "network utilization will increase between client and server if users utilize OSTs or cached mode Outlook clients."
How can this be?  If I remember correctly, MS said we should implement cached mode to REDUCE communication with the Exchange server.  If a user wants to read a message that they have a copy of in their OST, why do they need to contact the server at all?
After the initial syncing, it seems like further communications should be reduced.
Not applicable
Hey Peter,

There are several reasons that may contribute to an increase in network utilization with cached mode clients:

1.  Download of the OAB.  Depending on the version (v3a or v4) this could be frequent or infrequent.  But still even the deltas will consume bandwidth.
2.  Frequency of full OST synchronization.  This may not be a major thing for most companies (it is within MSFT, I've had to perform a full sync several times due to beta testing Office 2007).
3.  Consolidation scenario.  Consider the case where you have two sites, both with Exchange servers.  User1 in SiteA sends a message to 20 users in SiteB.  Exchange will send a single message to SiteB.  Now consolidate and deploy cached mode.  User1 in SiteA sends a message to 20 users in SiteB.  All SiteB users' mailboxes are either on the same server as User1 (or located on another in SiteA).  Now all 20 users will download that single message to their clients.  That's an increase in traffic.
4.  Monday morning synchronization - basically the day everyone comes back from the weekend and starts synchronization at nearly the same time.

Hope this helps.

Not applicable
I have to agree with the comments made earlier-- Exchange is a victim of its own success.  My organization had 2GB mailboxes three years ago-- users want to store everything in Outlook, and they don't want to hear IT whine that the underlying Exchange database isn't meant to support this.  I need Exchange 2007's database *today*, and next year I need something even more scalable.  If Microsoft wants to own the document management system market now is the time...
Not applicable
Hi Ross,

Thank you for clarifying the MSFT best practice regarding size limits. We were recently contacted for our "secure file transfer appliance" products by a VAR who focuses on Exchange/Outlook implementations and because of the Exchange 2003 (default) limit; they need a complimentary solution that would still allow users to send large files.

The reality is that large attachment/file is common in most business processes today. The "tricky" part of email attachment is that users like to CC and BCC a lot of people but at the same time, unless you work at the few industries where there are specific retention regulations, the "shelve life" for most of these attachments are rather short. So, sending these data as email attachment impacts both the network performance and storage requirements. On the other hand, if you can do an "attachment offload" that is transparent to the end users, suddenly everyone is happy - end users gets to send the files/emails they need  and IT does not have to worry about email infrastructure being under siege.

Regards,  YFJ
Not applicable
Well I couldn't disagree with you more on the Mailbox size issue. You're reasoning may be sound from a technical point of view, but from a user point of view, you're so far offbase it isn't funny anymore. 1GByte of e-mail is minimum from my point of view. I work for a government and handle several dossiers that are high in e-mail volume. One dossier alone generated 80MB in e-mail in 6 months. 3 years of work amounts to 1 Gigabyte. Much of that stuff stays relevant. I can try to archive it away in a document management system or to a central disk, but that costs serious time. A tool like desktop search will allow it to be manageable and searchable. (Will this be included in Outlook 2007?)

If I throw it away I probably break the archiving law and some companies probably SOX. If I archive every e-mail that might become relevant later on even with 30 seconds a day that is easily amounts 10-30 minutes per day. All in all I need my e-mail to be effective. Questions I regularly answer on the basis of mails is:
- Has so and so ever asked a question on this?
- They say that they never agreed to that sentene being included in the paper. Is that true?
- What papers did you use to write the drafts for that project 2 years ago? we're due for the official review
Some of that you can answer with the official archive, but the e-mail box answers it in much more detail.

So Ross, if you really want to give your customers (being the enduser and not the IT-department) what they need, you build Exchange to be capable of managing mailboxes with at least 3GByte of storage per user and max 5 second search times. Don't build a system that limits the user right from the start, let the only thing that limits the user be his budget (and I mean hardware budget, not MS License budget)

For more on my point of view on this and why company wiki's might help out see and
Not applicable
Hi Rudulf,

I don't recall ever saying that you had to have small mailbox limits in this post.  What I did say was that they need to be managed appropriately for the aforementioned reasons.  It is true that ensuring that an organization meets regulartory compliance mandates, means that you have to balance legal, IT, and end user requirements.  That may require larger mailboxes, though with today's products, that means ensuring that you have enough disk I/O, enough disk capacity, mechanisms to perform legal discovery, and archival solutions.  In addition, you need to ensure that you can meet any SLAs that ensure you can provide an accepted level of service to the organization and its end users, as well as, being able to adequately backup and restore that data.

With Exchange 2003, that is a hard feat.  With Exchange 2007 it will be many times easier.  The move to 64-bit and utilizing large amounts of RAM, coupled with architectural changes in the product, will allow organizations to reduce the I/O requirements they had in previous versions of the product.  We've made significant changes to VSS (support restore of VSS backup into recovery storage group, backup of continuous replication model, etc) that will allow customers to implement large mailboxes (our goal is 2GB) and ensure RPO/RTOs are met.  And finally, we actually have a records management solution that works out of the box (see the links I provided above for more info on our records management story).

And yes, Outlook 2007 has been enhanced.  With regards to search, Outlook 2007 in online mode will utilize the revamped search solution that has been incorporated into Exchange 2007.  Outlook 2007 in cached mode will utilize Windows Desktop Search 3.0 for Windows XP, or the built-in search functionality included in Windows Vista.

Not applicable
I am looking for a way to effectively place limits on all user accounts within an exchange mail store.  I am aware of the policies that can be placed and the limits that can be placed within individual AD accounts but I would like a quick an easy way to place a limit, say 50MB higher than all users' current mailbox size. I know that I can place a set limit for all users, but I think a quota should be eased into a mail environment.  Capping current users off at a certain limit a little higher than their current amount would certainly go over better than a set limit for everyone straight off the bat.   Any suggestions would be greatly appreciated.
Not applicable

Very good article. I have a comment about the first issue you state about the Denied of Services Attacks. In Exchange 2000/2003 and I think also 2007 even if you limit the size of the mailbox an internal user could cause the server to stop. It is due a caracteristic of the MAPI Protocol and I see no way to correct it for the next version. If you attach a big file on the message the Exchange log files still get increased. That way a user can get the server down by creating log files. Even if you restrict the message size I can still attach the files and even if I cancel the message the log files still growing. Exchange won't do anything until the categorizer process run and that only occurs after I hit the send button. Regarding that issue I ask you Is it possible to track that? Because I don't even need to try send the message I can cancel it and the log still growing. What kind of information it keeps on the log files? I have seen meny microbegin and micro commint transaction on the log files but I did not find information regarding that. Can you give me some information. I am a Microsoft Exchange Engineer in Brazil

Best Regards

Not applicable
Not applicable


You have three choices:

1.  Use a mailbox store policy and assign limits there.  Then add the mailbox stores to the policy.
2.  Assign limits directly on the mailbox policy.
3.  Assign limits on the user accounts themselves.

Not applicable
I'm a user, with perhaps a bit different perspective on this issue -- although Rudolf above fairly accurately conveyed a lot of the same points.  My organization recently implemented an 85 MB mailbox size limit, and I was identified as having the largest existing mailbox (about 160 MB at the time).  I used to reduce mailbox size periodically by saving large attachments I wanted to my file folder on the shared server.  I felt virtuous after doing so.  However, the same email announcing the 85 MB limit also stated that the shared server hard drive was essentially completely full so users also had to delete files from there -- and I was identified as the user with the larger data store on the shared drive.  The recommendation of our IT staff is to archive emails routinely to a .pst file on our C drive.  While this is fairly transparent while in the office (although I do have to search for emails in two places), this recommendation seems to fly in the face of why one stores things on servers: backup of files and access to them from more than the desktop in your office (such as from home, where I'm able to read office mail remotely).  Not only do desktop hard drives randomly fail, I've come back from vacations before to have my desktop machine replaced in an unannounced upgrade ("Oh, did you have files on that old machine?").

Sorry, but this capacity limit seems like a Microsoft problem to me.  I resent being made to feel like a "bad user" because I find it useful to keep old emails around as a reference, in a secure place I can access from home as well as my own desktop machine in my physical office.  Like Rudolf, I routinely need to dig up and cite emails from weeks or months ago.  Statements like the above, "Users should realize that a mailbox is not a file storage area," are as offputtingly scolding to end users as they are inaccurate (you're saying email is not an essential business tool?).  

In my situation, the 85 MB limit means I can have less than a month of old emails readily on hand.  In four days away from the office, without any emails sent my me, my Exchange store increased by 20 MB.  Many of these emails I could probably safely delete or archive -- but which ones?  I could spend (waste) 20 minutes or more each day on making choices/guesses about this matter, but frankly my ardor to work free overtime on worthy projects diminishes if the tyranny of mailbox size limits requires me to do regularly such a chore.  I will go home at 5 PM, which I doubt is the result my employer intends.  Immediately moving emails to the .pst file on my hard drive (as some "good users" in my office now do) leaves me half crippled when I log on from home -- or any place, if my hard drive fails.

As a user, I do compare the situation to my free Yahoo and GMail accounts, where I can have gigabytes of storage.  If they give that away with high reliability to millions of users, why can't my IT department with 80-100 users provide better service?
Not applicable
I am trying to help a small firm with 250 mailboxes and about 190GB of email. Probably 10% of the users have 2-5GB mailboxes with a mailbox that is 13GB in size.  They just purchased new hardware to move their 2 node cluster to and users are still complaining about client "slowness".

I read you post and it advised limits and quotas, but I am not sure whether these larger boxes are causing the instability.  A manager said a "friend" of his is at an org that hosts 1000 mailboxes with 200GB in size and they don't have issues.  

Can having a "larger" mailbox cause issues for all users?

I used the ExBPA and it helps quickly track down some config issues, but it would be helpful as an IT person to truly understand the problems (if really a problem) of several users having large mailboxes.

Any thoghts?
Not applicable

I would recommend that you use ExPTA to help determeine the cause of "slowness".


PS - I doubt your friend has 1000 200GigaByte mailboxes on a single Exchange server.  The backup/restore/recovery requirements would be astronomical.

Not applicable
Patrick, your question, "why can't my IT department with 80-100 users provide better service?" may need to be reworked a bit. "Why can't management approve a budget big enough to provide 80-100 users better service?" Many times, the problem is simple math: 100GB for mailboxes, 100 employees all wanting 2GB mailboxes. I am in a similar boat right now with our current ex2000 server because it is overallocated on storage space. Right now things are ok, but if everyone suddenly slammed against their storage limits tomorrow the store would go offline.

Thankfully Management here decided it was time to really invest, so we are sitting on new hardware with enough disk storage to cover

(with TOTAL_STORAGE being a number *after* RAID and formatting are complete, and #_USERS being the number of projected employees for 5 years)

Many times it is as frustating for IT staff as it is end users. Please blame those that are _really_ responsible, not those that are just trying to keep the databases online and disk utilization somewhere below 95%.
Not applicable
Question about i/o performance.

Disk Bottleneck Detected

The Microsoft® Exchange Server Analyzer Tool has determined that your disk system is currently running within 20 percent of the expected maximum available throughput. This determination is made by one of the following calculations:
• Measuring disk latencies. The performance counters that indicate latency are LogicalDiskAvg.Disk sec/Read and LogicalDiskAvg. Disk sec/Write.
• Comparing the maximum possible disk I/O per second (IOPS) of your current disk configuration and spindle count against the current IOPS value, as recorded by Performance Monitor (Perfmon).

I need some clarification please.

Perfmon (or the OS for that matter) is not aware of disk configuration ( groups) at the raid controller or disk array. That is, the OS kernel has no idea of what type of “physical” disk he sees, this “physical” disk could be a raid 10, raid 5, raid 3, or raid 50 on the back end and the os will see it as just one physical disk.

That said, I have a server attached to an array via FC, by different means I have confirmed that the disk utilization at the array is always almost nil (3 to 17%) however troubleshooter is complaining about disk performance. (I used different disk performance tools like IOmeter, and I have been able to load the back end disks to 100%)

By changing different parameters (io/interrupt ratio or NumFcpContext for example) I managed to increase disk utilization at the back end from 3-17% to 10-19%, but troubleshooter keeps complaining about disk performance.

Why doesn’t exchange use all the resources available to it?
How would you explain it?
Not applicable
I always bring up the question: "How many of you go home, open up your physical mail and then stick it right back in the mailbox?" Imagine the US Postal service running around replacing shoebox size mailboxes with 50, 100 Gallon  or swimming pool size drums to accomodate the laziness of recipients that don't want to bother sorting out what's legit and what's junk and filing away the really important stuff. You wouldn't do it at home so why at work is it OK?

E-mail is no different. If a user is not sure what they are supposed to keep for 4 years or what other compliance issues need to be met, then they need to learn and be held accountable for how they handle their correspondence. The mailroom guy would never be held accountable for an executive throwing out something he should have kept yet an email admin could easily be fired for the same.

I've found that there is never a solution that everyone likes but explaining the pro's and cons of .pst files, limits, and filing of messages - all user/management training goes a long way. Ultimnately THEY have to sign off on a policy before it's implemented and if they go with a solution that's very liberal, they are aware of the caveats and risks.
Not applicable
Keeping control of your messaging data can often be a frustrating experience. Administrators can often
Version history
Last update:
‎Jul 01 2019 03:15 PM
Updated by: