I am knee deep in an Exchange migration currently of about 850 users from an Exchange 2007 environment to an Exchange 2010 environment. The mailbox databases are connected to a SAN via fiber and from the testing I've done so far I figure I can get about 24GB of mailboxes moved a night.

I have about a million questions with regard to this migration but right now but I think the most important is the following:

Is there a standard best practice for moving mailboxes?

  • Should I spread users out across all the mailbox databases?
  • Should I fill them up to say 70GB one at a time?
  • Move a chunk of users to a mailbox every night?
  • What’s the best way to keep track of how full databases are, where users are, etc.
  • Is there a good way to spread users out automatically or should I just do it by best judgment?

Obviously I’ve never done a move like this so I guess I’m just wondering how I should approach this. Thanks.


I just realized that I should post my database structure, I think it may help show what I'm doing. Here are some pieces I forgot to mention:

  • I have a DAG set up for 3 Exchange mailbox servers. Two on-site and one off-site
  • I have 28 databases cut up across the 2 on-site mailboxes (14 and 14) with the third as a fail over.
  • Currently about 2 TB of mail to migrate so we have a little bit of breathing room on these servers
  • I've been working on a 2010 deployment as well, how did you decide on 14 databases per site? Are users just put into a random one at their site? – benjarrell Apr 17 '12 at 16:40
  • @benjarrell The decision came by looking at the total size of our Exchange 2007 environment and dividing that into 100GB databases. I don't have a link but I believe that is the recommended max mailbox database from Microsoft. From that we built in a few extra databases for growth, etc. – jmreicha Apr 17 '12 at 18:29
  • @jmreicha 100GB maximum per database? Where did you get this number from? Exchange 2010 recommends not going larger than 2TB per database.. – pauska Apr 19 '12 at 14:33
  • @pauska Isn't the 2TB recommendation only for DB's set up to replicate? – jmreicha Apr 19 '12 at 15:29
  • @jmreicha No it's the general maximum size recommended. I do not think DAG have any limits on it, just that a complete resync of 2TB is going to be painful.. – pauska Apr 19 '12 at 15:41

I'd certainly suggest moving chunks of users out of their core hours (at night, as you say). Make sure the mailbox quotas on the new store are big enough!

As for how you load databases, I'd suggest you think about downtime to restore, say, 70gb of data vs. the tolerance of people in that database. You might group people in terms of the tier of service they want, or department, whatever works best for you. All I'd suggest is that whatever you do, you should structure it somehow and you should be consistent.

| improve this answer | |
  • Updated original question. Does that help deciding one way or another how I should approach? – jmreicha Apr 17 '12 at 16:18
  • The decision on how you should approach it is yours, and something that should have been decided before you installed Exchange at all. Its not something any of us can tell you what to do really, just to help you decide for yourself. So... why 14 databases per server? Why 3 servers? Why is one of them off site? What SLA (formal or not)do you have with the users of this service? How do you want to organise the users? by "service tier"? By importance (e.g. in the event of a DR, all the managers are in 1 DB so you can restore that one first) or by department? Location? All are valid choices. – Rob Moir Apr 17 '12 at 16:52
  • Sorry, to clarify, I'm not asking anyone to decide and I appreciate the insight and suggestions. The decision to go with 28 databases is so that we have enough room to accommodate all users from the old Exchange servers evenly in the new. And we will be spreading users out randomly amongs the databases. So I have a plan, I am just looking for some help on how to go about executing it I guess. I apologize, I should have made this clear to begin with. I can update my original question again if that will help. – jmreicha Apr 17 '12 at 18:27

I found an informative article going over the different types of Exchange mailbox distributions and information on how to balance them.

To paraphrase a lot of what is said, there are basically 5 ways to migrate Exchange to a new environment.

  1. Group users according to job function
  2. Group users according to quota limits per mailbox
  3. Distribute databases according to username
  4. Distribute uses across each database evenly independent of type and usage
  5. Randomly distribute users across each database

I believe it will be useful to use approach 5 because we designed our databases with resiliency in mind and so there is less of a need to worry about database failures. Another thing that will be beneficial using this approach is that there will be a somewhat uniform growth in database size since the databases are randomly populated. Database management in the future may be easier because of this as well.

I found this built in method of distributing mailboxes in Exchange 2010, which is exactly what I was looking for. So now I guess the question becomes when to migrate users instead of how.

| improve this answer | |
  • One answer and several comments in under 24 hours is certainly not dead :-) – pauska Apr 19 '12 at 14:34
  • I was just anxious to find an answer I suppose – jmreicha Apr 19 '12 at 14:45
  • The random approach does work, and it has its advantages but it has disadvantages too: if you have to do a DR for whatever reason (and it can happen even with redundancy), it becomes difficult to answer a boss who says "You must restore all the executives first" or "Sales is the lifeblood of the company, restore them before you do anyone else..". – Rob Moir Apr 19 '12 at 16:49
  • Never thought about that, it is a good point. I wonder if hybrid approach may be better. – jmreicha Apr 19 '12 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.