Storage Group design on Exchange 2007 sp1...which way to go?
For my organization I currently have 460 users split between two storage groups, named Sg1 and Sg2. Both databases are stored on one lun on my san and the log files are on their own lun as well. The first storage group contains those users that have the letters A-L inas their first initial of their firstname and the other storage group has users from M-Z. I am going to be inheriting another 1200 users in my email system from various other organization at my university. I am trying to find the right storage design. I used the Microsoft Exchange 2007 calculator and it suggested creating another 5 storage groups with 240 usersper storage group. I was also thinking abou three other designs:1. I will be bringing in about 9 different organizations, such as accounting, human resources, police dept. etc, etc. I was thing of having one storage group per organization which added to my own organization would leave 11 storage groups. The thing about this design is that it makes more storage groups than I want as it addbit more complexity to the mix.2. I can add another 5 storage groups as MS calculatorsays and divide up the storage groups by first initial of first name, so SG3 would be A-F, SG4 would be H-K, etc.3. Create a smaller number of storage groups by taking two departments per storage group, so Accounting and Human Resources would be in one, etc.Any one have any tips?Thanks,Alex
September 30th, 2009 9:27pm

Why not just add another 5 storage groups as per the calculator, and then spread everyone completely randomly across all databases? That way, if you do have any type of failure, it doesn't affect any type of user, department, etc. The calculator has specified that number of databases based on current best practices and to ensure that theoverall maximum database size doesn't exceed the recommended limits - this in turn includes factors such as deleted item retention and so on.Neil Hobson, Exchange MVP
Free Windows Admin Tool Kit Click here and download it now
September 30th, 2009 9:38pm

Neil,I like that idea very much. One question I have is that if I put users randomly into SGs then when Microsoft says I need to 240 users per storage group, then some SGs will have more users than others?
September 30th, 2009 10:30pm

I guess if I did do it by name it would still be more "random"than placing a specific department in an SG.
Free Windows Admin Tool Kit Click here and download it now
September 30th, 2009 10:32pm

The 240 users per database will be the storage calculator's estimate of the maximum number of users you could have on a single database without exceeding the recommended maximum database size. In other words, you wouldn't have to have 240 in every database.Neil Hobson, Exchange MVP
September 30th, 2009 10:58pm

Thanks Neil. Do you think the approach of having a user in aparticular SG based on their first name initial is still a viable thing? Would you recommend that I start mixing up the two SGs I currently have where I base SG membership on first name initial and then when I add the new 1200 users I continue to mix up users in the SGs?Thanks,Alex
Free Windows Admin Tool Kit Click here and download it now
September 30th, 2009 11:22pm

There's no right or wrong answer, it's down to your administration requirements but also it's recommended not to exceed the maximum database sizes recommended by Microsoft (it's technically possible to exceed them, but probably best all round to keep databases reasonably small). Therefore, moving users around databases to balance database sizes is a good approach. The majority of customers I work with do seem to go for the random approach, but there are many examples where users have been grouped by username, department, etc, etc.Neil Hobson, Exchange MVP
October 1st, 2009 11:14am

Thanks Neil! I like your approach and think that is what will work for me in the long run.alex
Free Windows Admin Tool Kit Click here and download it now
October 1st, 2009 6:29pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics