These tools can be run on one database at a time from the command line and can be used to perform a range of database tasks from repair, offline defragmentation, and integrity checks in Exchange Server 5.5, Exchange Server 2000, and Exchange Server 2003. ISInteg corrects database problems at the application level of the database. Eseutil corrects database problems at the ESE level. ISInteg understands the database as a collection of mailboxes and items in them, and can correlate and repair information and relationships between mailboxes, folders, items and attachments

Defragmentation mode: Command line  "eseutil /D ". Defragments the database files. This mode reduces the gross size on disk of the database (.edb) and streaming files (.stm) by discarding most empty pages and ad hoc indexes. When Eseutil defragments a database by eliminating unused storage and compacting the database, Eseutil actually creates a new database that contains all the information from the original database. When defragmentation is complete, the original database is deleted or saved to a user-specified location, and the new version is copied over the original. If the utility encounters a serious logical problem in the database, defragmentation stops. The database must then first be repaired with Eseutil /P before it can be defragmented.
The time length to complete defragmentation depends on how much of the database is empty, and not on the size of the database file. For example, defragmenting a 100 GB database that contains 10 GB of data takes about the same time as defragmenting an 11 GB database that contains 10 GB of data.

When run a defragmentation: There are several situations where it is appropriate to defragment an Exchange database. The following includes a list of those situations:

• There is a significant amount of white space in the database that can be reclaimed and which will not be reused. An example can be when the number of mailboxes in the database has been significantly reduced.
• An event is repeatedly logged in the Application log advising you to defragment the database offline. This may occur rarely when typical online defragmentation is no longer able to efficiently defragment the database.
• When the 16 GB database size limit is reached on the Standard version of Exchange and white space must be reclaimed in order to mount the database. If you are running Exchange Server 2003, then Service Pack 2 (SP2) should be installed to raise the limit to 75 GB.

When NOT run a defragmentation: There are situations where it is not appropriate to defragment an Exchange database. The following includes a list of those situations.

• Eseutil defrag should not be run as any kind of standard maintenance. Exchange runs an automatic online defragmentation nightly that handles the day-to-day maintenance of Exchange. There is no reason to periodically run an offline defragmentation unless special circumstances apply.
• Eseutil defrag cannot not be run when the database is not in a consistent state.

How to run a defragmentation:

• Make sure you have free disk space equal to 110 percent of the end size of the database that you want to process (the end size being the current file size minus the size of the white space in the file).
• Dismount the database before defragmenting as Eseutil performs an offline defragmentation. During the offline defragmentation the dismounted database will be inaccessible to clients.
• ESEUTIL /d "database name" [options]

Repair mode : Command line  "eseutil /P ". Eseutil repairs corrupt database pages in an offline database but discards any that cannot be fixed. In repair mode, the Eseutil utility fixes individual tables but does not adjust the relationships between tables. ISInteg should be used to check logical relationships between tables. For example, a table in the database stores messages for all mailboxes. A separate table is used for each user's Inbox folder. Suppose that a message is lost when using Eseutil to repair the message table. Eseutil will not correlate the message with the reference to it in each Inbox folder, because Eseutil does not understand the cross-table schema of the application. ISInteg is needed to compare the repaired message table with each Inbox folder, and to remove a lost message from the Inbox.

When run a repair:

• Only when you cannot restore a database from backup or when you cannot fully roll transaction logs forward
• An event is repeatedly logged in the Application log advising you to defragment the database offline. This may occur rarely when typical online defragmentation is no longer able to efficiently defragment the database.

When NOT run a repair:

• Do not allow a repaired database to remain in production for an extended period of time.
• Do not use the Eseutil repair option when backup is available.

How to run a repair

• First, Eseutil is run in /P mode to perform a database page-level and table-level repair .
• Second, Eseutil is run in /D mode to fully rebuild indexes and defragment the database.
• Last, ISInteg -fix is then run to repair the database at the application level

Restore mode : Command line  "eseutil /C ". Eseutil displays the Restore.env file and controls hard recovery after restoration from online backup. The term "hard recovery" refers to the process that controls transaction log file replay into a database that has been restored using the legacy online streaming backup application programming interface (API). This process is different from transaction log replay that occurs after a database crash or after restoring a database using the Volume Shadow Copy Service (VSS) backup API

How to run a restore: ESEUTIL /CM “d:\temp\First Storage Group”

• To view the Restore.env ESEUTIL /CM “d:\temp\First Storage Group” .
• To run hard recovery, ESEUTIL /CC “d:\temp\First Storage Group”.

Recovery mode : Command line  "eseutil /R ". Recovery refers to the process of playing transaction log files into a database. There are two kinds of recovery:

How to run Hard recovery

• Hard recovery occurs when transaction log files must be replayed into a restored online backup. In all other recovery scenarios, soft recovery is done. Hard recovery can be done with Eseutil by using the Restore mode (/C).

How to run Soft recovery

• In the default soft recovery scenario, an external event unexpectedly stops an Exchange database, but the database and log files remain intact and in place. When the database is mounted again, Exchange reads the checkpoint file and begins to replay the transaction log that is listed as the checkpoint log. If no checkpoint file exists, replay begins with the oldest log file available in the transaction log folder for the storage group.
  Exchange writes completed transactions to the database files found in the log file that have not already been written and reverses any incomplete transactions. Exchange never begins writing a transaction into the database files until all the operations composing it have been secured to the log files. You do not need to physically undo or back out a transaction in the database if all uncommitted transaction logs present at the time of the unexpected stop are present when replay begins.

Eseutil /R E00.

Integrity mode : Command line  "eseutil /G ". Eseutil verifies the page level and Extensible Storage Engine (ESE) level logical integrity of the database but does not verify database integrity at the Information Store level. It is important to detect specific type of anomalies or inconsistencies in order to take proper steps to fix the database. You should recover the database to Clean Shutdown state before running an integrity check.

How to run Integrity

• ESEUTIL /G priv1.edb

File dump mode : Command line  "eseutil /M ". You can use the /m switch with Eseutil to create a file dump, or formatted output of various database file types that you specify when you run Eseutil

How to run a dump

• ESEUTIL /MH filename.edb to dump database header (default).
• ESEUTIL /MK filename.chk to dump checkpoint file.
• ESEUTIL /ML filename.log to dump log file or set of logs.

Checksum mode : Command line  "eseutil /K ". The Eseutil tool in Microsoft® Exchange Server 2003 includes a /K switch that you can use to verify the page-level integrity of the information store databases. The /K switch can be used to detect file header damage. File header damage may occur in databases, log files, patch files, or checkpoint files. In addition, you can use the Eseutil /K command to verify the checksum integrity of the transaction logs when all the databases in the storage group are dismounted

How to run a checksum

• ESEUTIL /K priv1.edb /E (checksums stm file only)
• ESEUTIL /K priv1.edb /I (checksums edb file only)
• ESEUTIL /K priv1.stm (checksums stm header pages only)

Copy mode : Command line  "eseutil /Y ". The ability of Eseutil to copy large files is a new capability introduced in Exchange Server 2003 that has been imported from ESEFile. The copy file mode is optimized to copy very large files efficiently. You can use the switch to copy a database, streaming file, or log file. However, the mode is not suited as a general purpose copy utility

How to Run a copy

• The following is an example of how to copy the priv1.edb file from server1 to your current location: ESEUTIL /Y \\server1\d$\priv1.edb
• The following is an example of how to copy the priv1.edb file from sever1 to server2 specifying the full path and file names for both source and destination:
  ESEUTIL /Y \\server1\d$\priv1.edb /D\\server2\d$\priv1.edb

Common Eseutil Errors

Error -327 (0xfffffeb9) : JET_errBadPageLink
This error occurs when there is logical corruption in the database. Logical corruption can be caused by a bug in Exchange or by a hard disk crash. A crash can cause the error if write ordering of pages from cache was not preserved, and therefore only some pages from a transaction were updated while other pages were left as older versions.

Error -501 (0xfffffe0b) : JET_errLogFileCorrupt
This error indicates physical damage to a transaction log file. It is similar in its causes and effects to an error -1018 in a database file. You cannot repair or recover a log file after this error occurs.

Error -510 (0xfffffe02) : JET_errLogWriteFail
This error indicates that Exchange was unable to write to the current log file. The log disk may be full, a hardware error may have made the disk inaccessible or another process may have locked the log file.

Error -514 (0xfffffdfe) : JET_errBadLogVersion
This error occurs when trying to replay a log file that was generated with a different version of Exchange. This error may occur after upgrading to a major version of Exchange, and occasionally may happen after a service pack or hotfix upgrade that alters the database schema or internals. Service packs that can trigger this error include Exchange 2000 Server Service Pack 1 (SP1) or Service Pack 2 (SP2), Exchange Server 2003 SP1, and Exchange Server 5.5 Service Pack 4 (SP4).

Error -515 (0xfffffdfd) : JET_errInvalidLogSequence
This error indicates that a log file is missing or does not match the other log files. This can happen if the log signature does not match, if the creation time does not dovetail with other logs in the sequence or if another problem is detected which indicates this log was not part of the original sequence. This error is seen most often because a log file is missing. It may also be seen in circumstances where multiple restorations of a database have left you with multiple log streams for that database, and you have tried to blend the log streams.

Error -519 (0xfffffdf9) : JET_errLogSequenceEnd
Exchange Server 2003 and earlier versions support log file sequences of up to 1,000,000 log files per storage group before the log sequence must be reset to one. Database behavior, after this limit is reached, varies by Exchange version. For more information about resolving this error for Exchange 2000 and Exchange 2003, see the Microsoft Knowledge Base article 830408, "Exchange database stores remain mounted although all transaction logs that are available to a storage group have been used."

Error -530 (0xfffffdee) : JET_errBadLogSignature
This error indicates a signature mismatch. The signature is actually "good" but it does not match other log files in the sequence or does not match the log signature recorded in the database. This could be because log files from different sequences have been found or that a database has crashed and the logs needed to recover it are no longer present.

Error -531 (0xfffffded) : JET_errBadDbSignature
This error is similar to error -530. Both databases and log files have signatures that identify and match them to each other. It is not necessary in all cases that the signatures match, but when a signature mismatch affects recovery, either error -531, -530 or both will be seen. In some cases, recovery can complete successfully after Error -531, but its presence indicates that transaction log data was not able to be applied to the database.

Error -532 (0xfffffdec) : JET_errBadCheckpointSignature
This error indicates that the checkpoint file does not match the transaction log files. Removing the checkpoint file will correct this error. It will also cause Exchange to re-scan every transaction log to determine whether it is needed for recovery. If there are thousands of log files, this may take several minutes or more.

Error -533 (0xfffffdeb) : JET_errCheckpointCorrupt
This error indicates that a corrupt checkpoint file has been deleted. In most versions of Exchange, a corrupt checkpoint file will be automatically deleted and re-created. A corrupt checkpoint file may be deleted because it cannot be used.

Error -537 (0xfffffde7) : JET_errBadSLVSignature
This error indicates that the current .edb file and .stm file do not match each other. An Exchange 2000 Server database or Exchange Server 2003 database consists of two files--the .edb MAPI database file and the .stm streaming database file. These files must be kept synchronized with each other, and they cannot be used with other databases.

Error -540 (0xfffffde4) : JET_errDatabaseStreamingFileMismatch
For more information, see Error -537

Error -543 (0xfffffde1) : JET_errRequiredLogFilesMissing
This error indicates that log files are missing. An Exchange database that has been shut down correctly is in a Clean Shutdown space and has detached from its log files. The database is now independent of the log files. All existing log files could be deleted and the database could be restarted with a new or different set of log files.
Note: Deleting log files for a Clean Shutdown database will affect the validity and roll forward capabilities of previous backups.
If a database has not been shut down correctly, it is still attached to one or more of the log files. These log files are required to bring the database to a consistent state. If these log files cannot be made available, the database must be restored from backup or repaired before it can be started again.

Error -544 (0xfffffde0) : JET_errSoftRecoveryOnBackupDatabase
This error indicates that in place of hard recovery, a soft recovery was performed on the database. If a database is restored from a streaming online backup, it is in a special state that requires "hard recovery," as contrasted to "soft recovery" which runs after an ordinary database crash. Hard recovery is run by triggering transaction log replay within the backup application or by running Eseutil /CC after database and transaction log files have been restored. For more information about running hard recovery, see Eseutil /C Restore Mode.

Error -548 (0xfffffddc) : JET_errLogSequenceEndDatabasesConsistent
This error may accompany error -519, and indicates that no more transaction log files can be generated in this sequence, but databases are all in Clean Shutdown mode. This means it is safe to remove transaction log files and reset the log sequence. For more information about resolving this error for Exchange 2000 and Exchange 2003, see the Microsoft Knowledge Base article 830408, "Exchange database stores remain mounted although all transaction logs that are available to a storage group have been used."

Error -549 (0xfffffddb) : JET_errStreamingDataNotLogged
This error occurs when circular logging is enabled and data placed in the streaming database (.stm file) is not logged. Circular logging causes log files to be deleted soon after their data has been written to the database file. This reduces disk space requirements for transaction logging, but also prevents rolling the database forward from a backup. By default, circular logging is disabled, and the online backup process is relied on to remove excess transaction logs that are no longer required for rolling the database forward. If you change circular logging settings, you should immediately perform a full backup.

Error -550 (0xfffffdda) : JET_errDatabaseInconsistent
This error will occur if transaction log files are missing or not all data from the log files could be applied to the database. If a database is unexpectedly stopped, it will be in Dirty Shutdown state. (The state of a database can be viewed by reading the database header while the database is stopped. For more information, see section on Eseutil /M File Dump Mode). A database in Dirty Shutdown state is still attached to its transaction log files and must have required log files applied to it before it can be started. To correct this error, you must apply all required log files, restore the database, or repair the database.

Error -551 (0xfffffdd9) : JET_errConsistentTimeMismatch
This error is closely related to error -1216 (JET_errAttachedDatabaseMismatch). It is typically caused by restoring raw copies of one database's files while other databases in the storage group are in a Dirty Shutdown state. For more information about resolving the error for Exchange Server 2000, see the Microsoft Knowledge base article 296843 "How to recover an Exchange 2000 Server database after error -1216.

Error -552 (0xfffffdd8) : JET_errDatabasePatchFileMismatch
This error can occur in versions of Exchange prior to Exchange 2000 Server Service Pack 2 (SP2) after restoring from a streaming online backup. The patch file is a file used in transaction log replay for older versions of Exchange. Optimizations in Service Pack 2 for Exchange 2000 allow hard recovery to proceed without patch data.

Error -1216 (0xfffffb40) : JET_errAttachedDatabaseMismatch
This error is closely related to error -551 (JET_errConsistentTimeMismatch). It typically occurs after a simultaneous crash of all databases in a storage group if one of the databases is no longer available (for example, because its disk has been destroyed). For more information about resolving the error for Exchange 2000 Server, see the Microsoft Knowledge base article 296843 "How to recover an Exchange 2000 Server database after error -1216."

Error -1206 : JET_errDatabaseCorrupted
This is a generic error and does not necessarily indicate a severe problem. The error will trigger at the end of an integrity check where problems of mild to medium severity have been found. Scan the .integ.raw file for the word ERROR to get detailed information about issues found in the database. For more information, see the Events & Errors Message Center. For more information on resolving the error for Exchange 2000 Server Standard Edition, see Microsoft Knowledge Base article, 313704 "XADM: Running an Integrity Check on the Srs.EDB Database Always Returns a JET_errDatabaseCorrupted Error Message."

Error -939586631 (Unknown Error) : Unknown Error
This error occurs when you try to run Eseutil /CC with an incorrect path to the Restore.env file. The mailbox store will fail to mount as a result of this error. You can resolve the issue by running Eseutil /CC with the correct path of the Restore.env file. If the issue persists, you can run Eseutil /P followed by Eseutil /D, and then try running Eseutil /CC again to recover the database. For more information about running Eseutil /CC, see How to Run Eseutil /C (Restore) in Different Scenarios.

For More Information : Microsoft Knowledge Base article 266361

General recomendation:

1) Check integrity. ESEUTIL /G priv1.edb

2) Repair if necessary. ESEUTIL /P e:\exchsrvr\mdbdata\priv1.edb

3) After Eseutil /P completes successfully, defrag the database. ESEUTIL /D e:\exchsrvr\mdbdata\priv1.edb

4) After Eseutil /D is completed successfully is highly recommended run ISINTEG –fix -test alltests