ESEUTIL and ISINTEG are Exchange Server built-in tools that can help recover corrupt PRIV, PRIV1, Pub, and Pub1 edb and stm database files. It is important that prior to running ANY Microsoft Utilities to back up your latest copies of your Information Store files to another partition, network drive or external hard drive.
If you are using Microsoft phone support, they will not tell you to back up your Information Stores! Before letting anyone touch your server back up your database files!
ESEUTIL Disaster Recovery Options
When your Exchange Server has failed, whether from a dirty shutdown, IS reaching the 16GB limit, or even the partition or hard drive running out of space, you are faced with a disaster recovery scenario. There are several steps that must be taken in a particular order for any chance at Exchange Recovery.
Please back up your databases prior to running any utilities.
The first step that must be taken is ESEUTIL with a p switch. Below are the most common ESEUTIL command line switches:
- Defragmentation: ESEUTIL /d <database name> [options]
- Recovery: ESEUTIL /r [options]
- Integrity: ESEUTIL /g <database name [options]
- File Dump: ESEUTIL /m[mode-modifier] <filename>
- Repair: ESEUTIL /p <database name [options]
- Restore: ESEUTIL /c[mode-modifier] <path name> [options]
- Checksum: ESEUTIL /k <database name> [options]
As you can see with the list a p switch is the repair. It goes through 3 different tests prior to completion. If you don’t make it through these steps it is time to restore from backup. If you don’t have a backup, you will need to call 727-251-2058 after hours or 866-438-6932 from 9 to 5 EST for Exchange Server Disaster Recovery Support. More than likely you will need data recovery.
If the /p does go through its steps without error you will need to remove ALL log files out of your Information Stores folder (usually MDBDATA) examples are edb.log or edb1234.log. At this point you are ready to run a defrag.
ESEUTIL Offline Defrag /d Switch
While it is true most administrators of Exchange schedule regular defrags, you absolutely must run one during Exchange Data Recovery. The length of time that the defrag takes depends on the amount of garbage or “white space” within the edb and your hardware. The older and slower your box, the longer it will take!
Offline defrag creates a new database by copying all records and tables from the old database into the new database. Because ESEUTIL is creating a temp during the defrag and an actual copy when it is done, you must have at least 125% free space on the partition where your MDBDATA Information Stores directory is, or you will have to use a T/ switch and choose a temporary space on a network drive for the temp.edb file. Since the edb that you are defragging ends up getting deleted, the temp edb will need to go back over the network and this adds even more time to the disaster recovery.
Note: After the defrag is done, ESEUTIL considers the new edb to be a different edb from the original, and its log files cannot be replayed into the new database which is why the old log files within the MDBDATA were removed.
If you are fortunate enough to make it through these steps, the next Microsoft utility that you need is ISINTEG.
ISINTEG Information Store Integrity Check For Exchange Disaster Recovery
Now that ESEUTIL has done it’s thing you are ready to move on to ISINTEG. It is also located in the BIN folder, but it has different switches. The one you need for Exchange Disaster Recovery is:
ISINTEG -PRI -FIX -TEST ALLTESTS It might take a few times for this to come back without any errors, Microsoft actually warns not to run it more than 3 times, but I have heard people running it as many as 20 or 30! Needless to say they needed data recovery! Keep the ISINTEG to a minimum of 3 times just to be on the safe side.
You will have to repeat these steps on the PUB as well. It is OK to run all the ESEUTIL command on both the PUB and PRIV then run all of the ISINTEG afterwards, the important thing is to follow the order of /p, /d, BEFORE running ISINTEG!
While it is true that these utilities can deal with moderate corruption, they are not going to recover from any type of jet engine error. If you are having jet errors you will certainly need exchange server data recovery.
Another type of Exchange Recovery is here:
Before running any utilities COPY YOUR EDB FILE!
Data Recovery Steps: These commands can bring all edb’s to a consistent state.
- Syntax: ESEUTIL /r (3 character logfile base name)[options]
- Options: zero or more of the following switches, separated by a space:
- /l<path> – location of log files (default: current directory)
- /s<path> – location of system files (e.g., checkpoint file) (default: current directory)
- /i – ignore mismatched/missing database attachments
- /o – suppress logo
Hopefully you have good backups and will never need to perform these types of Exchange Recovery.