Exchange stores

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

I have a quick question. Is it possible to have multiple exchange stores in exchange 2010? We current have one Storage group and 3 Mailbox store groups beneath (on Exchange 2003). Speaking to some consultants we got mixed results... some say yes others say no...

 

That's what I am trying to figure out... the way we have it setup now is we have one storage group with 3 mailbox stores within that storage group. We have about 400 mailboxes within all three mailbox stores, so with the migratioin to 2010 I am trying to device if I do the same or not... one of the things I want to take advantage of as well is Single instance Storage... I was thinking of having one Storage Group with one Mailbox store that contains all the mailboxes which is 400.

Based on the amount of mailboxes we have, do you think it's a good approach?

 

Also in case you will want to use Mailbox recovery in DPM 2010, keep in mind that DPM needs to restore whole database to be able to get the mailbox out, so again, lenghty process.

 

We're still an E2K3 shop. I've got two Storage Groups, with four DBs on each. That way, I can spread the load, any corruption should only affect a small subset of users and I can run different policies per store - dependent on corporate requirements (mailbox size, deleted item retention period etc). Since we're on a SAN, I can also chuck SGs on different LUNs, depending on the need to keep peak performance for VIPs.

Sparky - I've never heard any decent reason why you shouldn't run more than one store per SG - though I've sometimes heard people say they don't do this (and, of course, would never dreeeeam of doing so) without explaining it. If you have a link to anything at YouHadMeAtEHLO or somewhere similar which gives a definitive reason for this I'd love to read up on it

PS: Prof - there's no such thing as the old 'SG - DB' architecture in 2010. It's been replaced by 'mailbox databases' - I believe this was to remove the reliability on the 'Server' object in Exchange (but could be wrong - it's aeons since I did anything on E2K10 (it was still in beta when I faffed around with it) since we're not looking at migrating away from 2003 any time soon.

 

I completely agree with you 100% about keeping all mailboxes in one mailbox store... This should definitely be split up!

 

Thanks Luke, I'll keep that in mind... I don't think I'll be using DPM any time soon as I just setup offsite backups!

 

Thanks for the input Zeb!

I'll say one thing, today I've learned more about exchange 2003 then I did in my 4 years here. I feel pretty comfortable with it now and here's what myself and my colleague found.

We've been having serious DB issues over the last week, hence my other post about DB maintenance... this is most likely due to DB corruptions that could be do to size or maybe other factors, but mostly I am guessing it has to do with size. Having 1 400gb DB for one of the stores is not a great way of managing, fortunately that's going to change soon.

We've created 4 more mailbox stores to add to the three we've already had to make a total of 7 mailbox stores. Tonight I will begin to move all the mailboxes from our 400GB DB which is store 1 to the other 4 mailboxes stores we've created. Once done, we'll delete the current problematic DB.

This is also done in preparation to the migration of Exchange 2010.

I am no Exchange expert so we'll have a consultant helping us out with the migration but that will be some serious project.

Anyways, thanks for the help guys! always appreciated!

 

Let me ask you a few quick questions - before you go to the pain of dismounting the stores and defragging them.

First up, is your online maintenance window set during the same time as your backup? In other words, are you running Backup Exec\Legato\whatever you use for backup during the times Exchange is running it's online defrag & cleanup? Check this out - it will slow your backup down brutally, crush your disks and stop online maint from completing - which leads to serious Exchange perf issues over time if the situation persists.

Secondly - check to see the amount of whitespace you have in your store. A large amount can cause significant issues, since the engine has to do a lot more work to process messages.

Thirdly - do you have a journalling mailbox or something similar set up? Have you ever used pfdavadmin to get a count of the folders in your user mailboxes? A user with a system folder with an enormous amount of mail can also end up killing Exchange performance over time. I consulted for a law firm once a while back - they had a mailbox on it's own separate database that kept copies of all correspondence received from clients - no-one ever looked at it - and I mean EVER - and when I ran pfdavadmin against it, it had 130,000-odd messages in the inbox. Archived that sucker off and hey presto - instant Exchange performance boost.

No charge for this, BTW - if you call an Exchange consultant in they'll charge you a day's consulting rate for these little nuggets

PS: One more thing - be careful when getting rid of the initial (i.e. Exchange-created) storage group - you'll need to perform a very specific procedure when moving the System Attendant mailbox. It involves faffing around with ADSIEdit - not a problem if you have experience using it, but not for the faint-hearted if you don't!

 

1. We did have the issue initially with online maintenance and backups coinciding and we changed that right away.

2. Will do... but if we do have a large amount of white space, I would still need to do a ESEUTIL on it, no? to get rid of white space...

3. I believe this is our main problem... we have some users with thousands of mail items and I know for a fact that this is part of the reason what's slowing down our exchange server, we're working on a way to eliminate that. Put it this way, office politics doesn't make it as easy as just archiving to a PST file... I wish it was!

4. I will definitely pay close attention... but I also noticed that each mailbox store creates it's own system attendant mailbox, which btw I am not touching when moving mailboxes from the first mailbox store.