I probably get asked this a dozen times a quarter….
“Chris/Dude/TechNet Guy/Geek/Hey….You!/Presenter/Microsoft Guy/#$%&*^&! how do I EASILY and SIMPLY migrate my Exchange data from one server to another?”
The reasons why the server data has to be moved range from, “there has been or will be an hardware failure” to “I just don’t like the color of the case the Exchange server is in so I bought a new one and decided to reinstall” (no….really). We have a number of articles on how to migrate Exchange from version to version, server to server, etc. But we don’t have any *good*, simple, easy articles on moving data from one server to another. I think the best article we have is this one — “How to move Exchange 2000 to a new server and keep the server name”. An Exchange 2003 version of the article is here. The only problem with this article is that it implies that you have to keep the server name the same on the two servers for it to work. And that just isn’t the case. However, the Organization Name *is* very important. I will explain later.
Now for a rant……I happen to think that technology should make our lives simpler and easier. Yet when I look around at how complex systems have become and how much aggravation and stress *I* go through when the simplest concepts and administrative tasks require gargantuan effort or a degree in physics to accomplish. I can only imagine what YOU – the true IT Pros – go through on a daily basis. It just doesn’t need to be nor is it that difficult in many cases.
So let’s address the simplest (and very safe!) method of moving your Exchange data from one server to another in the same organization with or without keeping the same server name. (By the way….I just performed this exact process last week when rebuilding my home domain…it works!)
WARNING! DANGER WILL ROBINSON! WARNING! (Imagine me flailing my arms, if you will…..)
Some caveats….this applies to moving Exchange 2000 to Exchange 2000 or Exchange 2003 to Exchange 2003. A similar process works for Exchange 5.5 and earlier but the interface is different so different steps. But let’s face it, if you are still running Exchange 5.5……you are in the Stone Age…..you NEED to update to Exchange 2003. This post also applies ONLY to going from STD —> STD or ENT —> ENT. It may be possible to go STD —> ENT with this process but I have never attempted it. You can NOT go ENT —> STD without a more complex migration strategy than this, period.
Also, I am not going to go down the road of security at all. Security is very important but I would like to keep this article shorter than the Encyclopedia Britannica so if there is a glaring security item I will point it out, otherwise reference the Exchange Tech Center for Exchange security info.
Short Version for Techies
Take PRODUCTION Exchange server offline (disconnect clients)
Make an offline backup of PRODUCTION Exchange server
Install new Exchange Server using same OrgName
Dismount databases on NEW server
Delete *.* from the \MDBDATA directory on NEW Server
Copy the data from the \MDBDATA directory on the PRODUCTION server to the \MDBDATA directory on the NEW server
Mark DB’s as able to be overwritten by restore on NEW server
Mount the DB’s on NEW server
Reconnect Users to Mailboxes on NEW server
Put NEW server into production
Keep old server around for a while (or at least a FULL backup) for a while just in case
Long Version for n00bz
On the existing server, you need to do an offline FILE LEVEL backup of the Exchange Databases. While this needs to be done as late in the process as possible to maintain uptime and capture as much (if not all) of the email on the server, I mention it now because making this file level backup means taking the Exchange databases offline which means planned downtime. For a large corporation this could mean months of planning. For a small business, you might be able to do this at the drop of a hat. Plan for your environment.
Making a File Level Backup of Exchange
On the PRODUCTION Exchange server you have to take the databases offline.
First, identify where the Exchange log files are being stored. Open the System Manager —> OrgName (Exchange) —> Servers —> ServerName —> First Storage Group (or the group you are dealing with) —> Properties *** Note the location of the Transaction Logs ***.
Second, identify the location of the Exchange Databases. Open the System Manager —> OrgName (Exchange) —> Servers —> ServerName —> First Storage Group —> Mailbox Store —> Properties and also Public Store —> Properties
*** Note the locations of the PRIVx/PUBx files. Be sure to locate the .EDB and .STM locations. ***
Now that we have found where the data files are we have to make copies of the files. Since the Exchange databases are constantly being updated and modified while the services are running and users are connected, we need to take the databases offline so changes can’t be made. There are two ways to do this, 1) Dismount the databases in the System Manager or, 2) Stop the Exchange Information Store (IS) Service. I personally like stop the IS though essentially there is no difference.
Once the DB’s are offline, you can use the same methods as above to find out where the files are located. Make copies of ALL the .EDB/.STM/.LOG files from the locations above. You should place them on a share that is accessible to the NEW server or burn a copy to DVD or place on tape. Whatever is easiest for you to get the data onto the new server.
You now have a backup of the PRODUCTION server data files!! BUT! As you can see from the length of the remaining steps you may wish to perform the above steps just before we get to the “Restoring Data to New Server” section below or else your users might get a little miffed.
Install the NEW Exchange Server — Build the new server and get the O/S all patched up. Once you have made the O/S configurations you would like, install Exchange Server 2003 as per the deployment tools. You can read about the deployment tools here —
http://support.microsoft.com/kb/812593/en-us
When you install the NEW Exchange Server, it is very important that you install it with the same Organization Name (OrgName) as the existing PRODUCTION server. To locate the current OrgName, open the Exchange System Manager on the PRODUCTION server. In the upper left of the management console tree, you will see “Organization Name (Exchange)” where “Organization Name” is the OrgName. You will need to use this same name when installing Exchange on the NEW server or you will not be able to easily migrate the databases.
Patch the NEW Exchange Server — Once the NEW Exchange is installed, you will need to update it to the same Exchange Service Pack Level as the PRODUCTION Exchange Server. To identify the service pack level, again, go to the Exchange Service Manager, expand OrgName(Exchange) à Servers à ServerName à Properties. You will see a version name and Service Pack level. Install this same Service pack level to the NEW Exchange Server.
Once this is completed, give the NEW server a reboot for good measure and then verify that all the Exchange services are running and that the default Private and Public databases mounted.
Dismount DB’s on NEW Exchange Server — On the NEW server, dismount the existing databases by going to Exchange System Manager à OrgName (Exchange) à Servers à ServerName à FirstStorageGroup (or whatever yours is named). Here you will see the Mailbox Store (where email is stored) and the Public Folder Store (where public folder data is stored). Right click each and select “Dismount Store”. Say yes to each one.
You have now dismounted the databases on the new server. We no longer need the data for these DB’s so we are now going to delete the associated data files. By default, Exchange stores all of its DB and Log files in c:\program files\exchsrvr\mdbdata. You should see a bunch of .LOG files and the Priv and Pub .edb/.stm files. You can safely delete these on the NEW server as they have never been used and we can easily recreate them if needed. Delete ALL of the data in the MDBDATA directory.
Copy Data from PRODUCTION to NEW Exchange Server — Now, copy or restore the files from the offline backup of the PRODUCTION server we performed earlier.
Mark DB’s as restorable — Once the data has finished copying, you have to mark the DB’s being restorable or else you will see errors when you try to mount the DB’s. Open System Manager — > OrgName (Exchange) —> Servers —> ServerName —> Private Store —> Properties —> Database Tab —> Check “This database can be overwritten by a restore” —> Apply —> Okay. Repeat for the Public Store.
Mount the New DB’s — You can now mount each of the databases — System Manager — > OrgName (Exchange) —> Servers —> ServerName —> Private Store. Rt-Click —> Mount Store. As long as you don’t have any errors, repeat for the Public Store.
Connect Mailboxes to Users — This information is actually well documented. If you are running Exchange 2000, refer to “How to recover a delete mailbox in Exchange”. For Exchange 2003, use the Mailbox Recovery Center.
Recommended Additional Resources —
White Paper – Disaster Recovery for Exchange Server 2000
Webcast – Recovery Storage Groups and Disaster Recovery for Exchange 2003
Cheers!