This Summary (a little late, sorry) describes how to restore an Exchange
5.5 Information Store from a Windows NT host to a restore host with either
Windows NT or Windows 2000 running.
I add the hints of Calvin Thomas that helped a lot.
And I add what we think happens when the restored IS starts again. Any
comments are very welcome as this is merely a theory as far as we
understand Exange Server.
setup:
- Have an Exchange Server 5.5, Service Pack 4 on Windows NT 4, SP 6a,
referred to as the Productive Server.
- Have an online backup of the Exchange Server; Networker version is 6.1.1,
BSO Exchange, Service Pack 5
- Have a restore host with Windows NT 4, SP6a (scenario 1) or Windows 2000,
SP 3 (scenario 2)
goal:
Restore the information store to the restore host, where the computer name
of the restore host is different from the productive server as they reside
in the same domain.
Exchange Server configuration of the restore host:
- install Exchange Server 5.5, same service pack level as on the productive
server
- install it with the same domainaccount as on the productive server; at
the end, the Exchange Server service account should be the same
- install a NEW organization with the SAME NAME as on the productive
server; do NOT join the existing organization
- give the site the same name as on the productive server
- be sure that the DIRECTORY NAMES of organization and site match those of
the productive server; they might differ from the DISPLAY names
- run exchange optimizer and configure all database paths as on the
productive server
Networker:
- install Networker Client and BSO Exchange on the restore host with the
same patchlevel as on the productive server (I don't know if this is
crucial)
- configure a client resource for the restore host and make sure backup of
data and Exchange server works
- make sure the account that will do the directed recover of the IS is
listed in the remote access field of the client resource of the productive
server
Restore of the IS:
- make sure the System Attendant service is running on the restore host;
all other Exchenge services should be down (although a running Directory
service does not matter)
- start a directed recover of ONLY the information store (MSEXCH:IS) from
the productive server to the restore host; do NOT restore the Directory as
this stores the computer name and won't start after restore; tell Networker
not to start the IS service after the restore; tell Networker to delete all
database files before recovery
- if you use a command line, it should look like this:
nsrxchsv -s <Networker Server> -c <Productive Server> -t mm/dd/yy -e -v
MSEXCH:IS
where mm/dd/yy denotes the desired browse date
IMPORTANT: BEFORE YOU START THE IS-SERVICE:
- DELETE or rename edb.chk in the working directory of the IS;
this is the most important file to delete before starting the IS service;
edb.chk is NOT deleted by the option to delete all files before recovery
(or by the -e option if you use the command line) and it is NOT part of the
backup
If the resore host is Windows NT 4:
- start the IS service; this may take a long time; presumably the time it
takes depends on the number of logfiles of your restored backup (see our
theory below); on a 1.6GHz Pentium with 1GB RAM it took 20 minutes to start
a 6.5GB information store with 3 logfiles
If the restore host is Windows 2000:
- run isinteg -patch against the IS ant THEN start the IS service; in our
case, isinteg took a long time whereas the IS service started rather quickly
The following applies for both operating systems again
- after the IS is running start Exchange Server Administrator an run the
DS/IS consistency checker; check "IS: Synchronize with the Directory..."
and "Filter: All inconsistencies"
### What we think happens when IS service starts and why deleting edb.chk
is so important ###
The restored IS is in an inconsistent state after recovery as it was an
online backup; there are transactions in the logfiles that are not yet
stored in the IS database ("committed"); edb.chk keeps track of which
transactions are committed and which are not, therefore it is not part of
the backup as the committing of transactions proceeds during the backup.
If you do not delete or rename the file before starting th IS service, the
service assumes a wrong checkpoint because edb.chk refers to the originally
installed IS and its logfiles of the restore hosts Exchange Server, which
is of cource meaningless regarding the RESTORED IS and its logfiles; the
result is confusion, distortion, the collaps of the universe etc.
If there is no edb.chk, when starting the IS service, a new edb.chk will be
created: we assume, that what happens, is that the starting service scans
every single logfile and checks for each transaction, if it is present in
the IS database, i.e. if it may be considered as committed; this takes its
time and this is why we think the time it takes grows with the number of
logfiles that have to be scanned (and it should grow with the size
of the database, too)
If we are totally wrong, please let me know.
### Comment on Windows 2000 ###
There are rumors that the database structure of the Exchange Server depends
on the operating system and on the service pack level, which could make
necessary a more sophisticated treatment of the restored IS before it will
start; I can only state that in the described setting, the recovery worked.
### This is what Calvin Thomas wrote ###
I have recovered several exchange backups recently using NTbackup,
ArcServit, and Networker (offline) backups.
Do not let the services try to restart after the restore. Even better,
restore to another location.
Here is what worked for me on Exchange Server 5.5. SP3, and SP4 both.
1. Install exchange on the recovery machine. Machine name doesn't "have" to
be the same, but I recommend it to save time troubleshooting problems
further on.
2. Make SURE the organization name and site names are identical.
Punctuation, and capitalization matter here.
3. Run the exchange optimizer. Make sure all pathways to all parts of
exchange are identical to original server.
4. Install identical service pack of original server.
5. Verify that exchange starts. Setup and test a mailbox.
6. Shutdown exchange.
7. Move subdirectory exchsrvr\mdbdata somewhere else, and create a new empty
exchsrvr\mdbdata directory.
At this point it diverges slightly depending on if you are doing a live
recovery, or an offline recovery.
8. If offline recovery, copy the recovered IS.priv file into
exchsrvr\mdbdata directory. Keep a copy so you don't have to recover it
several times.
8. If online recovery, run the software to recover the IS. DO NOT LET THE
SERVICES RESTART AFTER THE RECOVERY. Make a copy of the exchsrvr\mdbdata
directory.
9. Start all exchange services in order.
10. If IS starts fine. Run the Directory consistency checker to create the
mailboxes in the directory so you have access to the e-mails.
11. If IS doesn't start try this.
12. c:\exchsrvr\isinteg -patch
13. Go back to 10.
14. Next try eseutil /r /IS. Then go back to 12;
15. Last try eseutil /p /IS then go back to 12.
Between steps, I recommend you rename your data directory (exchsrvr\mdbdata)
to something else and put the original (that you renamed in step 7 above)
back.
Restart exchange and verify it still comes up. If it doesn't, remove
exchange, and reinstall it as in steps 1-5 above.
SOMETIMES, exchange will no longer come up at all after some failed
restarts. The first time it doesn't restart, you may have damaged the
installation enough that it will never work until you remove and reinstall
it.
Using W2K, you almost have to set up a mini domain, and a seperate domain
controller. One warning. If you set up your exchange server with the same
name as the original, do not ever allow this domain controller to sync up
with the domain controllers on the main domain. I did this for 2-3 minutes,
and my domain controller promptly changed the IP address of the main mail
server in active directory!!!!
I did this using a desktop machine, W2K Advanced Server Eval, 2 - 120GB IDE
drives , and a second machine as a W2K domain controller (if you need to
rename your machine it can't be a domain controller). I copied exchange
server 5.5 setup, SP3, and SP4 to hard drive and ran them from there. I
could remove and reinstall exchange SP3, or 4 in about 10 minutes.
###
Hope this summary is of interest.
Ingo Roschmann
Visionet GmbH
--
Note: To sign off this list, send a "signoff" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
