I would like to know how other people are managing the assignment of specific storage limits to users. I have the following class of users/mailboxes: Call center users, very low size limit (40%)Low volume users, users who do not sit at a desk (20%) Normal corporate users, average email volume for a desk based employee (30%)Executive users or high profile users, high volume of email (5%)Service accounts with varying volume (5%) Given these classes or tiers of users/mailboxes I manage storage limits by creating mailbox databases with storage limits set on the databases and if a user ever changes their tier I will move the mailbox to the appropriate database. The one thing I don't like about this layout is that all the low volume users are in one database and the executives (heavy hitters) are in their own database; I would prefer to see a more even distribution. I have been reading to see what other people are doing but I am not finding a lot so that's my reason for coming here and asking the question. I have been thinking of reducing the number of Databases we have but mixing users classes in one or 2 databases and using AD groups with scheduled scripts to manage setting mailbox sizes on each user object. How are you guys handling this? Hand modifying each users? Setting size limits at the database level? Something else? I know some of you probably have the same size limits across the board; I can't do that because I do not have an unlimited storage budget. Thanks in advance for any responses. -Kevin Nelson

Hello Kevin, In most of my client environment we follow the same way as you are creating a database for each set of users and put them in it. No need to worry about it because if you are with DAG maximum database size can be upto 2TB (400 - 500 GB would be easily recoverable from the failure). Maybe you can have multiple databases for high volume users.Kottees : My Blog : Please mark it as an answer if it really helps you.

Hello Kevin, In most of my client environment we follow the same way as you are creating a database for each set of users and put them in it. No need to worry about it because if you are with DAG maximum database size can be upto 2TB (400 - 500 GB would be easily recoverable from the failure). Maybe you can have multiple databases for high volume users.Kottees : My Blog : Please mark it as an answer if it really helps you.

@Kevin. Great question, unfortunately, it depends. Currently, Exchange 2010 is more about balancing hot and cold data in the same DB. In other words, using the MBX calculator, we want you to be balanced with the 4 (or more) tiers of different end users types. In the past, Exchange used to balance information based on DB. Just like your current design. What commonly happens is that the heavy hitters, aka managers and C level staff, are on the same DB and which DB goes down first? So all of them are at your office, not good. If only a few of them are impacted, hopefully the others support you as you fix it. PowerShell is your friend. I too like the ease of moving people via DB, but PS can be leveraged just as easy. In fact, with less impact to your DB structure. If you move the MBX between DB's in a DAG, that's a lot of transaction logs, replications, and time that potentially impacts everyone. Just by using, say a custom attribute, you could easily query any changes to end users. Could even script it like once a week and have the HelpDesk just notify you of the end users per week to modify, via an Excel doc that they update. Sounds easier and less impacting to me to change individual quotas. But again, it all depends on the process you have at your location.

@Kevin. Great question, unfortunately, it depends. Currently, Exchange 2010 is more about balancing hot and cold data in the same DB. In other words, using the MBX calculator, we want you to be balanced with the 4 (or more) tiers of different end users types. In the past, Exchange used to balance information based on DB. Just like your current design. What commonly happens is that the heavy hitters, aka managers and C level staff, are on the same DB and which DB goes down first? So all of them are at your office, not good. If only a few of them are impacted, hopefully the others support you as you fix it. PowerShell is your friend. I too like the ease of moving people via DB, but PS can be leveraged just as easy. In fact, with less impact to your DB structure. If you move the MBX between DB's in a DAG, that's a lot of transaction logs, replications, and time that potentially impacts everyone. Just by using, say a custom attribute, you could easily query any changes to end users. Could even script it like once a week and have the HelpDesk just notify you of the end users per week to modify, via an Excel doc that they update. Sounds easier and less impacting to me to change individual quotas. But again, it all depends on the process you have at your location.