Exchange Storage Limits?
July 15th, 2008
So do you use Storage limits on your Exchange Server? If so what are they?
We have imposed fairly conservative limits on our users, not because of space but rather because of DR planning…. We got burned 2 years ago during a Exchange Server crash and there we no limits on the storage… so the reaction was to impose limits to prevent the nightmare of some of the mailboxes from not happening again… Today I am wondering if those limits are “fair”.
So just doing some research, what are your limits and why?
Our warning level is 250MB, prohibit send 300MB and prohibit send and receive 350MB. We also automatically cleanup Deleted Items that are older than 28 days. Most mailboxes stay between 100 – 200MB so the limits help keep the pack rats from storing useless information. Every 1-2 months we have to re-educate a user on how cleanup their mailbox. This usually means showing them how to delete the 10-20 large email messages (usually forwards to their friends that are 5-10MB) sitting in their Sent Items folder.
We have our warnings set at 300MB, but I don’t have any prohibit levels set, the warnings have solved most of the problems and staff clean up their mailboxes when they get the warning. I don’t really have a good reason anymore for the limits other than faster backup speed and DR, I put them in back in the days of Exchanges 15GB store limits, but with Exchange 2003 SP2 and the higher store limits, backup speed would be the only reason to have them in place and to force staff to clean house once and awhile, maybe it’s time for me to rethink this too.
We impose very loose limits for our users.
Issue Warning: 2.0 GB
Prohibit Send: 2.5 GB
Prohibit Receive: 3.0 GB
If everyone was at the cusp of these limits we would be in some major trouble. Luckily there are only a couple out of the 100 or so users that have or will come close to having these limits on their mailboxes enforced. If I just a bunch of time to kill I would split our users into 3 different levels based on their reasonable storage needs. That is on the list of things to do but, unfortunately, it is pretty far down the list.
Our limit is 90 MB, Warnings sent at 75 MB. Send ability stops at 85 MB. File attachments are limited to 5 MB (3 MB internally) We use FTP for the really big stuff and a file transfer service (http://files.second.org) for stuff between 5 MB and 200 MB.
It appears based on other comments, that we are pretty tight.
I think a new philosophy is needed regarding e-mail. The tools/ technology (Exchange in this case) should not dictate what the user’s needs are/ what the business requires. As such, we do not impose storage limits (today), although the PST Unicode format limit is 20GB. Our Exchange DB is broken into 16 storage groups, between 20-50GB each.
Too much time is wasted by the user trying to manage e-mail, clean up e-mail, archive and move e-mail. They have other things to do. The world has changed, and e-mail is now a central personal repository for storing information. A user should be able to store as much as they need to, and be able to easily search the data.
The real problem isn’t the data stored in this case, its the architecture. Exchange’s single file database storage is archaic at best. Microsoft needs to to move to a maildir type format (one file per message – which they won’t do). This would speed things up immensely, AND improve DR capabilities.
As such, we are working on implementing a Courier IMAP system for “primary” unlimited storage, and the Exchange mailbox will be pulled back to 100MB. Exchange will remain in place for it’s groupware features that the users are dependent on (read – Outlook). The Courier based system is a rocket by comparison, on much less hardware.
My point is that IT really should dictate how much a user can store or how to store it, IT should just make sure they meet whatever the user’s needs.
That last sentance is mis-typed:
My point is that IT really should NOT dictate how much a user can store or how to store it.
IT should just make sure they meet whatever the user’s needs.
Phew…
We’re pretty much right in line with Drinnon, having actually been even tighter until about a year ago. We expect to make this a lot more user friendly when we implement email Archiving sometime in the next year.