\[Editor's Note: Do you have something to share with other Windows NT Magazine readers? We want to know about it. Write for Reader to Reader online, and you can tell others about your NT discoveries, comments, problems, solutions, and experiences. Email your contributions (700 words or less) to [email protected] along with your name and phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
Over the past few months, my team has run into a few cases where a restored Exchange Server Information Store (IS) won't start after a recent backup. This problem has occurred with several of our restored servers in different configurations, most recently with a 40GB public folder server. The problem doesn't happen every time we restore an Exchange Server IS, but it happens enough to cause concern, especially with the disparity in our hardware (i.e., a Compaq ProLiant server, standard PCs, an HP NetServer) and software (i.e., Seagate \[now Veritas\] Backup Exec and Microsoft NTBackup).
Here's the situation: Our ISs won't start after a restore using either NTBackup or BackupExec. When we use NTBackup, the options we select include:
- Overwrite All Existing Data: The problem exists regardless of this setting.
- Start Service After Restore: Selected.
The sequence of events contributing to the problem is as follows:
- After the restore completes, Exchange Server 5.5's JET engine, ESE97, begins replaying transaction log files with several occurrences of Event ID 109.
- After Exchange Server finishes playing back the log files, an Event ID 107 appears indicating "The database engine has stopped restoring."
- Following Event ID 107, Event ID 100 appears, indicating "The database engine 05.2448.0002 started."
- Following Event ID 100, Event ID 101 appears, indicating "The database engine stopped."
- Finally, another final occurrence of Event ID 100 appears, indicating "The database engine 05.2448.0002 started" in the Application Log.
All the Event IDs I've identified above are typical during the IS restore process. However, after the second occurrence of Event ID 100, the IS hangs. A hang is evident when no activity occurs in the Application Log or from the store.exe process.
Apparent Cause
The System Attendant appears to lock the edb.log file, the edb.chk file, or both. In addition, the Restore In Progress key appears in the Registry under HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\ Services\MSExchangeIS, preventing the IS from starting.
We've verified the file lock situation by trying to rename the edb.log and edb.chk files when the System Attendant starts shortly after completing the NTBackup restore. These files lock only after the restore and only when the IS is starting. After we stop and restart the System Attendant, the file locks disappear and the IS can start successfully. However, if we select the Start Service After Restore option before beginning the restore process, the IS will hang, forcing us to kill the process.
Workaround
The best option we've found to get a restored IS working is to clear the Start Service After Restore option. After the restore completes, we stop the System Attendant service and restart all Exchange Server services to the IS. The IS will typically start at this point.
What if you select the Start Service After Restore option? To recover, you need to perform the following steps:
- Stop the IS when the hang occurs.
- Remove the Restore In Progress Registry key.
- If the IS doesn't start at this point with the Event ID 148, "Database e:\exchsrvr\MDBDATA\PRIV.EDB and its patch file do not match," run
eseutil /r /is to perform a soft recovery, and run Isinteg -patch
to generate a new patch file.
- Restart the IS.
