If you do have a good backup information store or brick level read the section mentions, restore with good backup"
Exchange 2000 Information store is not mounting, all exchange services seems to be running however, when attempting to mount the databases, and exchange is reporting some generic error.
Most of the problems I have seen similar to this one are cause by human factor. Running exchange on very old crapy servers and not performing hardware refresh is the result of huge time consuming when it comes to database repair.
The application log on the exchange server is one of the most important places for exchange administrator to go and gather exchange related information, because the exchange specific events will be logged in there.
Here is one of the errors on the problem exchange server
Event Type: Error
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 412
Time: 1:40:37 PM
Information Store (4948) e53f288d-df1b-47ba-9c3b-901e530848a5: Unable to read the header of logfile E:\exchsrvr\mdbdata\E003C9F3.log. Error -530.
For more information, click
The event log and the error description are leading me to corruption on the exchange database and we are deciding to repair the database.Those of you who has experience fixing the database problem with exchange will remember the tool called "ESEUTIL" and normally can be found in the directory, where exchange binaries are installed in the folder called "BIN"
- Open CMD
- Navigate to this directory ( Use windows GUI, to make sure of the exchange installation directory)
- ESEUTIL /? ( if you want to know the available switches)
- ESEUTIL /P (Repairs a corrupt offline database by discarding any pages that cannot be fixed)
- C:\Program Files\Exchsrvr\BIN>eseutil -p E:\exchsrvr\mdbdata\priv1.stm ( this is what I used)
- Now depending upon your server hardware resources, the ESEUTIL will take time to complete
PS: Do not get frustrated with ESEUTIL, the process will take as much as it wants to take, there is not much to do but wait with patience, go get cup of coffee.
Here are the nice guidelines to have a side.
- You run Eseutil /P first.
- Then you run Eseutil /D.
- Then run Isinteg -fix -test alltests.
- Plan on moving the mailboxes from the repaired database to a newly created database. Never trust a repaired database for long term use; will likely cause issues further down the road.
- "Isinteg -s (servername) -fix -test alltests"
IF you encounter problems here some more to try
- Stop all exchange services.
- Delete all *.log files
- Move the "E00.log" and "E00.chk" files to another folder.
- Mount the Information Stores.
Restore with good backup
If you do have your information store level backup and your log files go ahead and restore it from your backup and save the day. If you do only have brick level backup you are still good. (VERITAS or similar products).
Go to ESM, and find out the exchange databases locations, and rename all databases to "old-Priv1.edb" "old-Priv1.stm" and so on. Now mount the databases, exchange will warn you and it will say, if you force me to do this I am going to create brand new mail databases, and everyone will get brand new mailbox, meaning no previous mail data. It is fine go ahead and click okay. Now make sure all mailboxes are accessible and exchange is happy. Go to your backup software and perform brick level restore. This will bring all mail data to last good backup time.
Why we want to do it instead of attempting to repair the database? The Eseutil /P, might consume enormous amount of time, in some situations. Especially if the server you will be running Eseutil from is weak on hardware CPU and memory resources (Crapy server). I have witnessed in some cases the /P took a day to complete.
Also remember Microsoft recommends not keeping a repaired database around too long since it is tent to get corrupted again
MCITP (EMA), MCITP (SA)
MCSE 2003, M+, S+, MCDST
Security+, Project +, Server +