How do I move an Exch 2010 SP1 database to another server?
I have an Exchange 2010 SP1 mailbox database in a DAG that is on 2 servers in domain1. I want to move the entire database over to another DAG, same exchange org/instance, on 2 servers in domain2. In my research I've seen something called database portability but in reading I'm not sure if this is the best option. It may be, I'm just not sure. What are my options? What's the best way to accomplish this goal?
May 13th, 2011 12:55pm

Why not just move the maiboxes with the built-in Exchange tools?
Free Windows Admin Tool Kit Click here and download it now
May 13th, 2011 12:59pm

You can achive with database portability or as Andy says move mailboxes with built in tools. If you go with Andy's option then there's no downtime whereas with database portability there will be some, as you have to set the mailboxes to use the new server and wait for replication. If you go with Andy's suggestion, then make sure that you ahve enough space for your transactions logs, or stage the moves and at least perform a full/incre backup to flush the logs, prefer full. Sukh
May 13th, 2011 1:16pm

I want to preserve the entire DB the way it is, same name and settings. If my goal is to move the entire DB then it makes sense for the move to happen at the DB level. In order to do what you're suggesting I would have to create a new DB with a different name and change all the settings to match the current one, then perform a local move request for every single mailbox in the DB. This will eat up resources on both servers, slow them down, and fill up the log files partition on the destination server, and probably eat up some bandwidth. This also adds more of a chance for errors to occur. I would like for the move to occur on the DB level. Assuming this is possible, this should simplify things. My initial thoughts before doing any research on the topic was to dismount the DB, copy it over to the new server and remount it there. Not sure of how viable this is. I've been working on other portions of this overall project. This is only a small part of a bigger transition. Haven't had time to do some serious research into these 2 options I've found. James B MCSE, Security+, ITIL
Free Windows Admin Tool Kit Click here and download it now
May 13th, 2011 1:50pm

You can always rename the database afterwards back to the original name if desired. As for the settings, there arent that many that cant be easily mimicked on the new store. Moving mailboxes is trivial. Not sure how that would "slow" the servers down. And you can easily handle the transaction log growth by either doing backups and setting the destination store to use circular logging during the mailbox moves. If you want to go the database portability route, see: http://technet.microsoft.com/en-us/library/dd876926.aspx By the way, how big is the store you want to move?
May 13th, 2011 2:13pm

The database I'm trying to move is only used for retention of former employees mailboxes. It's almost 50 GB. I've recently moved a lot of mailboxes, large chunks at a time, using the "local move request" method you're suggesting and the servers involved took a noticeable hit on resources. The exchange store service was using a lot of memory and some decent processor power too. Using the circular logging workaround isn't an option as it leaves us no recovery options in the case of any problems. They like to play it overly cautious around here. I found that article a week or so ago but I've only just finally had a chance to read it. It looks like database portability is probably what I'm looking for if there are not other DB level solutions. I'm a little questionable on the copying everything over part though. If the DB is in a clean shutdown then I should only have to move the EDB file right? Also, are settings moved since you're technically creating a new DB? Any advice or lessons learned from anybody out there with experience in using this method? ThanksJames B MCSE, Security+, ITIL
Free Windows Admin Tool Kit Click here and download it now
May 13th, 2011 5:36pm

1. 50GB is not big at all in my experience so, if we consider this, then you can move mailboxes. Not sure about the specifics on your env, i.e SLA/RTO, 24/7 etc..but you can stage the moves during non-business hours. If it's 24/7 then you can still stage/schedule the move during non-peak usage. Again, get some metrics on network bandwidth & latency. 2. As mentioned above you can use backups (full), this depends on how much space you have on the destination. 3. Move the DB after verifying DB statuc headers. Yes. 4. It doesn't take much to dump the settings of an existing DB and set on the new DB, shouldn't take more that 15-30 mins. 5. Not sure what your timescales are here either, but you have the options above. Sukh
May 14th, 2011 8:12am

Since these are different domains, you wont be able to simply move the server membership between them so your only real options here are mailbox moves, database portability or restoring. Personally, I would still go the move mailbox route. 50GB is small. How much transaction log space do you have on the destination server? If you concerned about server performance, move them in small chunks. It doesnt sound like there are that many mailboxes involved here. As for databse portability, I have never used it for this scenario, but have tested it in the lab and its pretty straight-forward. Yes, if the database shutodown is clean, you are good. As far as mimicking database settings, that takes but a few seconds to set the limits, deleted item retention, default public folder etc, ( that is what you referring to yes?) Those dont travel with the database, you have to set them on the new store since you are "restoring" it to the new one. And, the display name of the store wont be the same as the current one, but you can rename later.
Free Windows Admin Tool Kit Click here and download it now
May 14th, 2011 8:36am

Hi James, When you use database portability: If the DB is in a clean shutdown then I should only have to move the EDB file right? It is recommend to move the database files(.edb file, log files, and Exchange search catalog). Move the database files (.edb file, log files, and Exchange Search catalog) to the appropriate location. The database files need to be present and in the correct location for recovery operations to succeed. are settings moved since you're technically creating a new DB? This is just as Andy said, Those don’t travel with the database, you have to set them on the new store since you are "restoring" it to the new one. Thanks, Evan Liu TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
May 16th, 2011 9:20am

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

Other recent topics Other recent topics