Blog Post

Exchange Team Blog
1 MIN READ

Did you just say you wanted a large mailbox?

The_Exchange_Team's avatar
Jul 01, 2008

So you've heard some folks saying large mailboxes are a good idea. Your users have been screaming for mailboxes with more than 1GB quotas. Your management wants you to be able to recover from outages in minutes, not days. Everyone is telling you to do more with less. Well, with Exchange 2007 you can have your cake and eat it too (so long as you plan for it). Have a look at the rules of the game in the new Planning for Large Mailboxes with Exchange 2007 white paper. This white paper covers the benefits of large mailboxes for both the end user and the administrator, the challenges that large mailboxes bring to an organizations infrastructure, and how Exchange 2007's features can help meet those challenges. Yes, >1GB mailboxes can be delivered to your users without breaking the bank. Check it out here:   http://go.microsoft.com/fwlink/?LinkId=122250 - Tom Di Nardo

Updated Jul 01, 2019
Version 2.0
  • Your whitepaper says:

    "Exchange 2007 now offers the ability to deploy a simple, inexpensive, and fast recovery solution that scales well for use with large mailboxes and also provides high availability. This solution is CCR on direct attached storage."



    And many of your people are mention only benefits with DAS.


    But your on articles:

    "http://searchexchange.techtarget.com/tip/0,289483,sid43_gci1313460,00.html"


    "http://searchexchange.techtarget.com/tip/0,289483,sid43_gci1313923,00.html"



    Speaks for SAN instead of DAS. And somehow in enterprise level the reason to switch from E2003 with SAN to E2007 with DAS are not so clear. And I mean environments where you have multiple servers with 4000 - 8000+ mailboxes per server and 50 SGs in each. But

    still continuing with SAN is more reasonable solution e.g. in management point of view.



    So is there any change to open this technology area more? Have Microsoft IT founded any pitfalls when using DAS for Exc2007?

  • So this is the new world.
    Archiving is bad  and large mailboxes are cool...

    Oh well, what is large?

    My users have 32GB and more.
    All in one mailbox then..

    LOL

    Michael
  • Hi Petri,

    Thanks for your comment. I tried accessing the links that you've posted but they throw a 404 error.

    I am not suggesting that customers should eliminate their existing technology investment in SAN. A move from SAN to DAS would be worth considering as hardware goes to end-of-life. Most customers in the enterprise space replace hardware on a 3-5 year refresh cycle (some maintain longer term maintenance contracts, but they are not the majority from my experience). If you are currently on SAN and are looking at an upcoming hardware refresh, then it is appropriate to evaluate the options that are available to ensure that the choice you make offers the best solution for your particular environment. As I say in the white paper " This solution is effective for either SAN or direct attached storage solutions. We recommend evaluating direct attached storage as a storage option due to its reduced complexity and inexpensive nature."

    This solution is very capable of supporting the workloads you mention on either DAS or SAN. The cost and reduced complexity benefits with DAS are significant and are worth evaluating. This is all about evaluating options and making educated choices about what is the best fit for your organization. In the end, you may decide that SAN meets your specific needs better. There’s nothing wrong with that.

    Tom.
  • Hi Michael,

    Thanks for your comment.

    Ahhh….No. Archiving is not bad. Stub files are bad. Just like PST files are bad. :)

    I know the pain you are dealing with. I’ve had customers with 70+GB mailboxes in the past. In these circumstances the best you can do is explain the issues and help steer things in the right direction. A 32+GB mailbox effectively means you need to be in online mode (unless you are working in a well architected OST scenario which only syncs a small number of folders). As a result, the performance costs to the server tend to be significant. Generally, most customers who have mailboxes like this also have regulatory compliance requirements. As I point out in the paper, that is a valid reason to deploy an archival solution.

    Additionally, I would suggest that many users that have mailboxes like this are misusing the resources they’ve been given. In some of these cases, an additional tactic that should be employed is discussing their usage patterns and exploring other options to see if an alternative solution for them may be a better fit. For illustration, many users like this tend to use their mailboxes as a version control system for large PowerPoint slide-decks and the like. Retaining 50 different versions of their 70MB “How I like to bump off my mailbox quotas” presentation is probably not the best use of your organizations storage infrastructure. Steering that user to a document version control system is probably a better fit.

    Tom.
  • Unfortunately  we are in one of those small organizations that do not impose limits.  It is the nature of our beasts, and luckily, the end user understands the trade off of having a 12 G mailbox.

    I have a question in relation to Storage and I/O.  Our users receive about 900 emails a day.  Most of the 900 emails are sent to a distribution list that the users are members of.  You can imagine how disappiointed I am to see SIS change!  How is a message sent to a distribution list procesessed?  Assume the users are spit between 2 Storage Groups (one database per SG).  Does the message get written once to each log, then to each database, or does it get written once PER USER on the DL?  I would think that would make a significant difference in disk i/o.


  • I have read a ton of information regarding the Jet Engine and increased file capacity in Exchange 2007, but all I am trying to determine right now is what is the maximum size of a mail box in Exchange Server 2007?

    Please let me know.

    Thanks,

    C.