Move Exchange DB to New Server? 2

[BJGAdmin]

I am upgrading to a better Exchange server machine.  I want to transfer my existing database to it.  I have read MS Article #Q155216, but that article assumes you have other domain controllers in your domain.  My Exchange server is PDC in a single-server domain.<br><br>In addition, that article instructs you to install the same connectors and service packs on the new machine that you have on the original one.  I was hoping to use this transfer as an opportunity to abandon some of the useless connectors I have on my current server (MS Mail, Schedule +) and upgrade to the latest service pack (I am on Exchange SP2 and NT SP4).<br><br>I was under the impression that you could do a restore of the Exchange mailboxes and public folders on any new machine from the PRIV.EDB and PUB.EDB files, as long as you used the original server NetBIOS name and account service name and password.  Do you also need to have the same connectors and service pack installed?<br><br>Am I asking too much here?  It would be really nice to address all these pesky issues with one big move, especially since I could rollback at any time by just turning my original machine back on!<br><br>Thanks for the input.<br><br><br>--  Aaron Cutchin

 

[lardum]

It is possible to move PRIV.EDB and PUB.EDB, even without the service account and password. If you also want the DIR.EDB you need to have the exact service account (exact SID) since this information is stored in DIR.EDB.<br><br>Regarding PRIV.EDB you need to run ISINTEG -PATCH to make it work in a new server, but as you said you need the same Exchange Service Pack since SP's usually change the database engine into a&nbsp;&nbsp;new fresh one. There is also a good idea to have the same Windows NT SP since the index files are handled by NT, but if you are lucky it will rebuild the index files att startup of the Information Store.<br>If you will restore the PRIV.EDB and PUB.EDB only you don't have to use the exact Computer Name. There are also tricks about getting this information out from DIR.EDB.<br><br>Regards<br><br>Lars<br>

 

[BJGAdmin]

Thank you for the information.<br><br>What about connectors?  We originally migrated the Exchange mailboxes from an MSMail server, so the MS Mail Connector is installed on the current server.  We no longer have any MS Mail server, and never will again, so I would like to exclude it from the new server.  Do I need to install it in order to "ISINTEG -PATCH" the priv.edb file?  Same for the CCMail and Schedule+ connectors.<br><br>Also, what will DIR.EDB carry over to the new machine?  The GAL and groups?<br><br>Thanks again for your assistance.<br><br><br>--  Aaron Cutchin<br>--  LAN Admin, BJG

 

[moryak]

Once you get the IS up and running, having the original dir.edb in place is not critical. With the services started, you can run the consistency adjuster. It's under the advanced tab in the server properties window. This will synchronize your Information Store with the Directory.

 

[Wibble]

you may want to run a directory export to a CSV if you're going for the consistency adjuster, as alot of details will be missing, as well as permissions, DL's etc. You can the import back in and append the details<br><br>Basically this scenario is no different than having a server purely for mailbox recovery. You would just copy the PRIV.EDB across to the virgin system (this machine must have the same service packs installed)<br><br>If the database is consistent, you will not have to worry about log files but will have to run isinteg to generate the GUID's. (best to run this, only do this if the system tells you to!!)<br><br>hope this helps

 

[BJGAdmin]

Thank you all very much for your replies.&nbsp;&nbsp;They are very helpful.<br><br>I still have one question, though.&nbsp;&nbsp;It is apparent that whatever machine you will import PRIV and PUB to must have the same SERVICE PACKS as the original server, but does it also need to have the same CONNECTORS installed?&nbsp;&nbsp;I.e., does it need to have MS Mail Connector, Schedule + Free/Busy Connector, CCMail Connector, etc.?<br><br>Thanks again!<br><br>--&nbsp;&nbsp;Aaron Cutchin<br>--&nbsp;&nbsp;LAN Admin, BJG<br>--&nbsp;&nbsp;<A HREF="mailto:admin@bjg.com">admin@bjg.com</A><br>

 

[lardum]

No, not if you are only restoring the PRIV and PUB since the connector information is stored in the DIR.EDB.<br><br>Regards<br><br>Lars<br>

 

[Kuria]

If you think you might run into a problem because of the connectors, put them in the new server and once you ave got it up and running, remove the connectors.

 

[BJGAdmin]

Problem is, you have to reinstall Exchange to remove the connectors.&nbsp;&nbsp;What problems and issues does this present?<br><br>--&nbsp;&nbsp;Aaron<br>

 

[MdB]

It sounds as though you're dealing with a relatively small data store, as I did recently. I put the new NT4 server on the network as a BDC, used Exmerge to export individual mailboxes from the old server to the new, then promoted the BDC to a PDC. Worked pretty well. Some problems with shifts in smtp addresses in the GAL. Still haven't figured out what caused that but it was easy to fix.

 

[dan]

If you are upgrading the hardware, I would suggest you install a second server in the site with the new configuration; then move the mailboxes and public folders to it. Once you create a new IMC, you will need to delete the old one.&nbsp;&nbsp;(One IMC services both servers)<br>When you are finished, turn off the old box.&nbsp;&nbsp;<br>This also has the following advantages:<br>-your data base is defragged as well.<br>-you have no down time.<br>Dan

 

[BJGAdmin]

I considered this, but ultimately decided against it because it is more hazardous than the &quot;duplicate server&quot; method.&nbsp;&nbsp;If you experience problems at any point along the way, you have compromised both the original database and the new one.&nbsp;&nbsp;With the other method, essentially &quot;down old server, build new one with same name, copy database&quot;, you have much more down time, and have to do it when users are off, but you have NO risk.&nbsp;&nbsp;You can always just abandon the new server and start up the old one.<br><br>From my perspective, avoiding risk is well worth working in the evening.<br> <p>Aaron Cutchin<br><a href=mailto:admin@bjg.com>admin@bjg.com</a><br><a href= > </a><br>

 

[kieronridge]

We have just spent the last few months setting up a disaster recovery plan. Basically if you get the disaster recovery white papers all theinfo you need is in there. But you do have to build the server as much identical to the other one as possible. i.e connectors. If you wanna get rid of old connectors build them in first then restore then remove them once the server is up and running. As ofr your Exchnage server being your PDC, your gonna have to back up the SAM. The whole restoring business can be a bit messy. Beware, ensure you have everything backed up and leave the other server in a state where you can bring it online again if need be.

 

[lbrochmann]

We did the same opreation a few weeks ago.

Procedure :

1. Install the new server in the same site and organisation.
2. Reconfigure all services on new server
3. move Mailboxes from old to new
4. Reconfigure Public Folder location
5. Start services on new server
6. Change PdC and BDC roles
7. New Exchange server ready
8. Move out old server from domain

It worked very fine hope this helps.

laurent

 

[Zelandakh]

I would have to agree with Laurent with a minor proviso - back up the old server first!

Problems arise from copying the data files over to new servers. Suggest that you do the following:

1. Install the new server in the same site and org.
2. Install relevant services and connectors on new server identical to old one.
3. Ensure that backup worked on old server. Stop all Exchange Services on old server. Manually copy priv, pub and dir in same folders. Also make copies of the trans logs.
4. Start services again.
5. Use Move Mailboxes wizard.
6. Reconfig Public folders if applicable.
7. Start services on new server.
8. Test logons for some randomly chosen users (suggest using Senior Management too just to be safe!).
9. Change DC if applicable.
10. Down the old server or stop the server service.
11. Wait a week to iron out the kinks so you have a roll back opportunity.
12. Sell old hardware and celebrate.