Restoring .edb files onto a new server!

[woodmar]

I am trying to duplicate my current exchange installation onto a new server, or basically, I want to “restore” the exchange databases on a freshly installed system.

Here are the steps I’ve followed so far:

1. Installed Windows NT 4.0 Server on a new hardware platform. (SP6 high enc, etc)
2. Installed Exchange 5.5 Enterprise with SP3. (that’s what I’m currently running)
3. Created partitions matching the source system.
4. Ran the optimizer to move the database files onto the appropriate drives.
5. Restore the PRIV.EDB, PUB.EDB, DIR.EDB and transaction logs onto the new system.
6. Ran a number of eseutil’s and isinteg tools, including isinteg –patch and eseutil /p, /r and /p

For some reason, the exchange services will not start after a restore… I am really stuck and now and the documentation on this specific problem is minimal.
The latest problem is the DS_E_COMMUNICATIONS problem and I know that the error comes from not being able to communicate with the services..!

Has anyone experienced this problem before, or does anyone have some good docs on restoring exchange databases?

Thanks a million!

 

[Andyleates]

Does the server have the same name?

Andy Leates MCSE CCNA MCP+I

 

[woodmar]

Thanks for replying...

At first I named the server (NetBios name) differently, then I changed it back to the original name. I reinstalled exchange after renaming it and the problem persists.

When I use the original (newly installed) edb files the server starts up without problems but as soon as I replace them the services fail.

Cheers

 

[yfclub]

Hi! I had the same problem some time ago. What happened was that I misspelled the folder name. So, when I used the new database it worked, because it was using the new path name, but when I tried to use the old DB it didn't start.

You may be using a different drive letter or something like it - it MUST be same way as the original.

Regards,
Hawk

 

[woodmar]

Hawk,

Thanks for your reply... I'm afraid that it's not as simple as that. I've made sure all paths and filenames are EXACTLY the same. Besides, I'm overwriting the new db files with the old ones, so the location remain the same.

Cheers,
Martin

 

[yfclub]

I understood that you are overwriting the db files - this is what I did too. What happens is that the path name, drive letter, server name, etc are written into the db file and when Exchange DS starts it reads all these information and if it's not the same, DS crashes.

This is a method of security - weak, but it's a method.

Hawk

 

[woodmar]

Ok, so let me just get it absolutely clear...

1. The server name (netbios) must be the same.
2. The db path must be the same. (e:\exchsrve\mdbdata)
3. The name of the db must be the same (priv.edb, pub.edb)
4. The installation path of exchange must be the same...

What am I missing..???

Cheers,

 

[es959]

This is usually a given, but make certain you are starting the services not with the System account but with the account you used to install the Exchange Server. This is a documented issue that I have seen. Sounds simple, but overlooked sometimes.

 

[Harrisonblade]

When building the Exchange server back up from a disater or if you simply want to transfer the data to a more powerfull box the server name the site name need to be the same. The drives do not need to be the same the logs files can be stored anywher you like the data base can be placed on a different drive letter. The site name and the server name must be completly identical.

 

[yfclub]

Harrisonblade,
I had to rebuild about 10 Exchange servers, one problem that I had recently is this:

The old installation had all db files here: e:\exchsrvr\dbdata

I made a new installation using:
e:\exchsrv\dbdata (without the letter "r" in exchsrvr)

When I started the server with the new db, I had no errors or warnings, but when I replaced the new dbs by the old ones, rebuild them and tried to start the server, DS could start because it said that the DB couldn't be found. When I discovered that I forgot to put the letter "r" in the path name and corrected it, the server started with no problems... what do you say about it???? The path doesn't matter? Yes, it does and it remains into the db files.
This is my experience and reading at Microsoft FAQ website, I may be wrong...

Regards,
Hawk

 

[yfclub]

Please, take a look here:

http://support.microsoft.com/default.aspx?scid=kb;en-us;185078

I'll search for more and place it here.

The importante is: path matteres!

Hawk

 

[Harrisonblade]

I have seen the same article. I have restored a DB to an E: drive when previously on D: but it is impossible to restore a DB to a server with a different server name site name or Organisation name. I do not disagree with the article directly however any article I have found has said that the site org and server name must be the same. The path in my experiance can be worked around. I do not wish to get into a shouting matchj on who knows more that who I am only going on personal experiance.

 

[Harrisonblade]

I have seen the same article. I have restored a DB to an E: drive when previously on D: but it is impossible to restore a DB to a server with a different server name site name or Organisation name. I do not disagree with the article directly however any article I have found has said that the site org and server name must be the same. The path in my experiance can be worked around. I do not wish to get into a shouting match on who knows more that who I am only going on personal experiance.

 

[woodmar]

Thanks for your replies - I'll give it a shot and let you know... My PRIV.EDB is 68GB, so it takes a bit of time to restore, repair etc.

Cheers

 

[bigdog92]

like the guys said above path matters a lot. When i did this the first time i messed up one path. Also make sure no log files are in the directors when you go to patch with isinteg. Just create a temp folder if you want and move them into it. I would also make sure your using the service account to start up any services.

 

[fuego007]

Check out my FAQ on this subject. If the original server is still available and has not been touched, you can simply find the point in the FAQ where you need to start over. I think this will solve your problem.

http://www.tek-tips.com/faqs.cfm?spid=10&sfid=3512

 

[woodmar]

Sorry, still no luck! - fuego007, I followed your FAQ and I think you've made a small mistake.

You say; to run the isinteg -patch tool whilst all the services are stopped. I am pretty positive that you need the "Directory" service running in order to complete the isinteg -patch..! If not, I receive a DS_E_COMMUNICATION_ERROR..!

I could be wrong..?

I'll keep trying

 

[bigdog92]

you are correct woodmar you need the directory service and the system attendant on for this to work. Also, if you are restoring from offline backup i would degragment the database and use that to patch. this would mean the use of eseutil /d priv.edb (or wahtever your priv is called). then taking all the log files out and just using the log files that the defragmentation creates.

 

[justin2000]

woodmar,

follow fuego007's FAQ to the letter, the only difference is before you do the isinteg -patch, start the System Attendant and the Directory Service.

I would recommend not to run the eseutil /d before trying to start it - you don't need to at all - a IS the size of 68gb, will take ages to go, and it's totally unnecessary.

 

[woodmar]

Ok, I finally managed to get this thing working..!

Here is what to do:

1. Build a new server with the same name as the original.
2. Take the original offline
3. Add the new server to the network
4. Restore the databases from backup (I used Veritas NetBackup with Exchange agent)
5. Reboot and run isinteg -patch
6. Install Exchange 5.5. SP4
7. Run isinteg -patch again
8. Reboot server and Viola!

The key to make this work is the installation of SP4.
I was looking into lots of MS documentation and checking out several forums. Everyone was telling me to "match all the settings" such as file patch, server name and service pack. I therefore assumed that I should apply the same service pack to the new server.

That, however, did not work well and by chance, after restoring the databases I came across two documents from MS, basically saying that there were errors in SP3 and that isinteg -patch would not work unless certain files were updated.
So, if you're in the same situation, have a look at these and update the files if necessary. - Good Luck!

http://support.microsoft.com/defaul...port/kb/articles/Q248/8/38.asp&NoWebContent=1

http://support.microsoft.com/defaul...port/kb/articles/q154/0/32.asp&NoWebContent=1

Cheers,

Martin