Exchange 2010 - to split or not to split

Hello, I have a fairly large customer whos users do not delete the trash folder in their Outlook.  Consequently, their Exchange datastore grows by leaps and bounds.  With this growth, they continue to run out of room on their virtual disk that is setup on a SAN.  We need to constantly increase the size of the disk to accommodate.  This is a fine solution short term but we will not be able to sustain this growth.  

Currently, the company houses a Vmware Esxi environment with two hosts attached to a SAN.  The Exchange store database is currently at 477GB.  The virtual disk that this resides on currently is a total of 730GB.  The SAN has only 230GB of space left.

1.  How big should we allow the Exchange store to get?  What is recommended with 2010?  Exchange has locked up twice in the past two weeks and I'm not sure if it could be related to the size of the database.

2.  I'd like to ideally push my client to Office 365 as I feel that it would be a great solution for them.  Unfortunately, the internal IT user wants me to split the database up so that the higher up management team's emails reside on one Store and all other users reside on another.  This solution will allow us to be able to restore quicker in the event of a failure but does not address the space issue.  Is splitting the stores up recommended?  What are the pro's and con's to doing this?

Again, Office 365 is what I would like to see them get to but the internal IT person is "old school" and is hesitant to put anything to a "cloud" solution.  The things that I want to avoid are:

1.  Supportability.  I dont' want the splitting of the exchange stores to cause a "cluster ****" on the environment so that my team and I spend endless amounts of time supporting.  Easy solution is better for us as it is more manageable
2.  I dont want the time invested to split the databases up and migrate email to that to overshadow what an Office 365 migration would cost the company.  In the end, if we do go the route of splitting the scopes the company is STILL on Exchange 2010 which is now 4+ years old.  I would like to point them to 365 as they will be on an updated platform.  I would hate to think that the money cost to them for splitting the scopes would be higher then 365 and in the end they are still on old technology.

The company currently houses approximately 100 employees - which is a large company for us.  We are a VAR and outsourced IT company for local businesses.

Thank you for your recommendations and if you have questions for all means ask away!
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Adam FarageSr. Enterprise ArchitectCommented:
So.. I will try my best to answer this without turning this into a 2 hour lecture :)

How big should we allow the Exchange store to get

If its a single mailbox server deployment, I believe the recommended maximum size is 500GB (keep me honest experts, I could be wrong). The reason for this is not because of the maximum recommended size of the database (which is 2TB) but the MTR (meantime to recovery) in the event that database needs to be restored. A lot of things factor into this (disk speed, database size, ect) but the main thing to remember is if I am recovering from tape / backup, then its going to take a while the larger it gets. If you were running a DAG, the MTR is reduced because you have multiple copies and you can do other things with it such as page patching / database patching and failover (page / database patching in Exchange 2010+ is when I take the database / log files and "patch them" onto a node that is screwed - due to database portability it works but there are some steps that go along with it).

Exchange has locked up twice in the past two weeks and I'm not sure if it could be related to the size of the database

Now if you reached the point where less than 1% of the total volume was available I can see this being an issue (as the database would dismount to protect itself) but I am leaning towards one of the two items below:

- the IOPS you are providing through the LUN that is hosting the database is not adequate for what you are hosting
- you have a high item count within some of the mailboxes (thus degrading performance)

There are two ways to look into this, and justify adding additional spindles to the LUN on the SAN that is hosting the database, or simply moving to O365...

Resize the environment:
- Run the mailbox report from Paul Cunningham to get the average mailbox size currently. Keep that report handy since you will need it in a bit
- Run the MessageStats script from Neil Johnson to find the average send / receive count and message size
- Google "Exchange Role Calculator" for the version you need and then import the numbers from these two in there, along with fill in the blanks for your organization. I have done this literally 40+ times in the past two years, so feel free to ask questions.

One of the taps within there should be storage, which will give you the IOPS required. That is what you need to look into and see if your current storage solution can meet these IOPS now along with in the future depending on the amount you grow.

Moving onto my second point here (high item count) in Exchange 2010 the item count for the default folders should never go above 100,000 items (for Exchange 2010 SP3, in Exchange 2007 its 20,000 items). If this does you can see adverse performance effects such as ESE B+ deadlocks and other horrible things. You can find this information out by running this script here.

Thanks for the wall of text Adam, but whats the point?

The point here is you need to look at the overall architecture of the environment, see if you have the IOPS required along with reducing the total number of items within the default folders. I would also recommend keeping databases below 500GB (or at 500GB) due to the longer MTR when going over that. If you cannot dedicate the IOPS required for the database role, either rearchitect the solution or think about moving to O365.

Happy holidays, and let me know if this makes sense or if you have any questions.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DSTechTeamAuthor Commented:
It makes perfect sense Adam!  Thank you for your input.

Adam FarageSr. Enterprise ArchitectCommented:
Noo problem. Enjoy the new years!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.