While there are many resources on the subject out there, I find I’m always looking/trying to remember the right syntax for restoring (as often a client blows up their Exchange Servers or do not have proper backups in place and need me to bring them ‘back from the dead’). So, you may get different mileage out of this resource than I will (selfish maybe, but this is mostly for my own use 🙂 but I have provided lots of reference links here as well.
Author’s Note: These steps will take as long as they take, to perform. Repair takes a long time, Defrag can take even longer. And then you still need to run the ISINTEG tool as many times as it takes, until it no longer shows errors/fixes required. So, how do you prevent this from taking so long? Don’t let your databases get too large. A 200GB Database will take DAYS to get through this process. Exchange 2007 now tries to cap you at 50GB per database (thus you should be shooting to stay around 35GB or under as a rule of thumb IMHO) so that you are encourage to create more/many databases, instead of lumping everyone in the same one. So, once you get your stuff repaired, work on distributing those users amongst more storage groups and databases…
So, here are the steps I follow at their simplest/most technical along with a few useful resource links. Note, that the assumption here is that this is for a single Exchange Server environment (not that much will change in a larger environment but I making some assumptions here for brevity).
Note: If your Exchange Server was totally nuked, you may wish/need to do the following as well:
Create a new Windows Server with the same name, in the same domain
-
Install Exchange using setup and the /disasterrecovery switch, if it is Exchange 2003
-
Install Exchange using setup and the /M:recoverserver switch, if it is Exchange 2007
Now, on to the recovery steps (run these commands from within the directory in which your databases exist). In this case, the Exchange 2003 databases are in G:ExchsrvrMDBDATA)
Recovery Steps
-
ESEUTIL /MH to check for dirty shutdown
- “c:program filesexchsrvrbineseutil.exe” /mh priv1.edb
- If the state is ‘Dirty Shutdown’, you’ll need to move on to repair efforts. If this is a recovery effort to a new server or your logs are bogus, make sure your MDBData folders, etc. only have the necessary EDB/STM files and no logfiles (move ’em elsewhere)
-
ESEUTIL /P to repair (this takes a while)
- “c:program filesexchsrvrbineseutil.exe” /P priv1.edb
-
ESEUTIL /G to defrag (this takes even longer)
- “c:program filesexchsrvrbineseutil.exe” /D priv1.edb
Repeat steps above for all of the databases you have (including your PUB as well).
- Start Exchange Information Store
- ISINTEG -s SERVERNAME -FIX -test allfoldertests (run until no errors or fixes, then replace -pri with -pub)
- Perform another ESEUTIL /MH to check for clean shutdown
One interesting thing of note. ESEUTIL is a database modification/fixing tool. It doesn’t care that it is Exchange (or know really, it just recognizes a database in need of help). Isinteg is the utility that you use after ESEUTIL to make Exchange like what it sees, after the repair.
Reference Links
- ISINTEG Reference: http://support.microsoft.com/kb/182081
- ESEUTIL Reference: http://msexchangeteam.com/archive/2004/06/18/159413.aspx
- Exchange 2003 Disaster Recovery Switch: http://www.petri.co.il/exchange_disasterecovery_switch.htm
- Exchange 2007 Recover Server Switch: http://www.msexchange.org/tutorials/Recovering-Exchange-2007-Server-RecoverServer-switch.html
- Using ESEUTIL and ISINTEG together: http://www.msexchange.org/tutorials/Exchange-ISINTEG-ESEUTIL.html
One response to “Exchange Database Repair Steps for Exchange 2003, 2007, etc.”