Troubleshooting Information Store Startup Problems

In Microsoft Exchange Server the information store may become corrupted and may not start. The corruption may be caused by such things as sudden loss of power to a running Microsoft Exchange Server computer or faulty hardware that has written information to disk incorrectly. This article outlines steps to recover from an information store that does not start.

The steps outlined in this article are most effective if circular logging is turned off and the customer has some type of regular backup procedure in place. If circular logging is turned on (which is the setup default) then steps 1, 2, and 6 through 9 are valid (circular logging automatically writes over transaction logs files after the data they contain has been committed to the database). If a backup is NOT available then steps 1, 2, 8, and 9 are valid. For information and strategies on backup and restoration procedures, please see chapter 15 of the Microsoft Exchange Server Administrator's Guide.

To recover an information store that does not start, perform the following steps strictly in order. If you follow these steps in order, you preserve, in descending order, as much data as possible.

1. Check the Windows NT Event Viewer application event log for EDB, MSExchangeIS, MSExchangePriv, MSExchangePub messages. These error messages may give a clear reason for the problems with the information store. Two of the most common error messages that are reported to the application event log are "out of disk space" or an error message that states that the isinteg -patch command needs to be run.
   For more information, click the following article number to view the article in the Microsoft Knowledge Base:
   149238� Information store fails to start with 1011 error
2. Shut down all of the Exchange Server services, and restart the Exchange Server computer. When the information store restarts it automatically tries to recover and return the database to a consistent state.
3. Make a full offline backup (stop all of the Exchange Server services) of the information store. This should include all .edb and .log files
   
   IMPORTANT: The .edb and .log files may be stored on different physical drives. To determine where they are located, look in the registry under the HKEY_LOCAL_MACHINE subtree, under the following subkey:
   
   \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
   
   and look at the DB Log Path parameter. Making a full offline backup is a precautionary measure to capture the existing state of the Exchange Server computer before you perform the following steps. This step is necessary if you reach step 8 or 9 of this procedure.
4. Restore the last full online backup, and make sure that you do NOT click to select the Start Services after Restore check box. Restore any incremental (from the time of the last full online backup through the day before the information store startup problem) online backups of the information store. Only click to select the Start Service after Restore check box when you restore the LAST incremental backup.
   
   IMPORTANT: Do NOT click to select the Erase all existing data check box.
   
   When the information store starts it rolls forward through all of the existing database logs and places the data in the restored information store. This brings the information store back to the point of at which it stopped responding. If this step is successful, there is no loss of data.
   
   IMPORTANT: If you perform step 5 on, you will lose data.
5. If step 4 does not start the information store, then go into the Event Viewer application event log and review the logged messages for the source EDB; there is one message for each log file that it replayed during the restoration in step 4. If one of these EDB messages reports a problem replaying a particular log file, open the Mdbdata folder and remove the corrupted log file and all of the log files that are greater in number. After these log files are moved, try to restart the information store.
   
   For example, if the application event log says that the Edb00012.log file could not be processed or was corrupted and the log files in the Mdbdata folder range in number from Edb000001.log through Edb000025.log, remove from Edb000012.log through Edb0000025.log, and than try to restart the information store. If this step is successful you will only lose the data stored in the removed log files.
6. If step 5 does not work, restore the last full online backup of the information store. Click to select the Start Service After Restore check box. Click to select the Erase all existing data check box. This restores the information store to the point in time that the online backup was taken. Then start the Exchange Server Administrator program and run the DS/IS consistency adjuster on the Advanced tab of the server object properties.
7. If step 6 does not work, repeat step 6 with the next most recent version of either a full offline or full online backup.
8. If step 7 does not work, delete all of the .edb and .log files from the Mdbdata folder and restore a copy of the Priv.edb and Pub.edb databases from the backup of the database when the problem started (step 3). Open the Exchsrvr\bin folder and run Edbutil /d /r /ispriv followed by Edbutil /d /r /ispub. This utility defragments the private and public information stores and tries to fix any database errors that it encounters. After Edbutil.exe has finished running successfully, try to restart the information store. If the information store starts, Microsoft highly recommends that you run the isinteg -fix command against both the private and public information stores to clean up any inconsistencies that may have arisen as a result of the Edbutil utility.
   
   For additional information about the Edbutil and Isinteg utilities, please refer to the Troubleshooting section in Volume 2 of the Microsoft Exchange Server Administrator's Guide or click the article number below to view the article in the Microsoft Knowledge Base:
   
   143233� XSRV Adm: Command Line Parameters for Edbutil.exe
9. If all of the above steps do not work, the information store can be wiped as a last resort. To determine if the problem exists in either the public or private information store, you must wipe them one at a time, starting with the public information store. This process irrevocably deletes all of the user e-mail messages, user folders (wiping the private store, Priv.edb), and public folders (wiping the public store, Pub.edb).
   To wipe the public information store, perform the following steps:
   
   
   1. Either ensure that you have completed step 3 (full backup) or copy the Exchsrvr\Mdbdata folder to another location on the hard disk drive.
   2. In the Exchsrvr\Mdbdata folder, delete all of the Edb*.log files, all of the Res*.log files, the Edb.chk file, and the Pub.edb file.
   3. Now restart the Information Store service. If it starts, you have lost all of the public folder information (new Pub.edb, Res*.log and Edb.chk files are created automatically) and all of the information in the log files. However, you retain all of the user e-mail messages and folders that were stored in the private information store (Priv.edb).
10. If wiping the public information store does not work, perform the following steps:
    
    1. Remove all of the information that exists in the Mdbdata folder.
    2. Bring back a copy of the Pub.edb database from tape or alternate location.
    3. Try to restart the information store. If the service starts, the public folder information is intact. However, all of the user e-mail messages, folders, and information in the logs is lost. The users' mailboxes are recreated the next time that they log on.
11. If all of the steps above do not work, remove all of the information from the Exchsrvr\Mdbdata folder and then restart the Information Store service. This returns the information store to the installation defaults.

You can use the DS/IS consistency adjuster (on the Advanced tab of the server object) to clear up any directory or information store inconsistencies.

The Exchange Server information store was designed to be a recoverable system. It relies on a daily backup procedure and transaction logs to ensure this recoverability. Microsoft HIGHLY recommends that you have a DAILY backup procedure in place and that these backups are verified regularly.