Windows 2003 EseUtil

Microsoft Exchange Server Database Utility
Guid
Microsoft Corporation
Published: December 12, 2006
Author: Exchange Server Documentation Team
Abstract
When a database is corrupted or damaged, data can be restored from backup or repaired
using Eseutil. Eseutil is a command line utility that works with Extensible Storage Engine
(ESE), database (.edb) files, streaming (.stm) files, and log (.log) files associated with an
Information Store, in a given Storage Group.
Comments? Send feedback to exchdocs@microsoft.com.

Contents
Exchange Server Database Utility Guide.................................................................................7
ISInteg................................................................................................................................. 11
For More Information........................................................................................................... 11
Eseutil /D Defragmentation Mode...........................................................................................12

How Does Eseutil Defrag Work?.........................................................................................12
How Long Does it Take to Defragment a Database?..........................................................13
When to Run Eseutil /D?..................................................................................................... 13
When not to Run Eseutil /D?............................................................................................... 14
How to Run Eseutil /D (Defragmentation)...............................................................................15

Before You Begin................................................................................................................ 15
Procedure........................................................................................................................... 15
Eseutil /P Repair Mode........................................................................................................... 17

Placing a Repaired Database Back Into Production............................................................18
Eseutil /P Best Practice....................................................................................................... 18
Previous Exchange Versions.............................................................................................. 19
How to Run Eseutil /P (Repair) in Different Scenarios............................................................20

Before you begin................................................................................................................. 20
Procedure........................................................................................................................... 20
Post-Repair Considerations................................................................................................ 22
Command line reference..................................................................................................... 22
Eseutil /C Restore Mode......................................................................................................... 23

How to Run Eseutil /C (Restore) in Different Scenarios.........................................................24

Before You Begin................................................................................................................ 25
Procedure........................................................................................................................... 25
Controlling Transaction Log File Replay..............................................................................26
Command line syntax.......................................................................................................... 27
Eseutil /R Recovery Mode...................................................................................................... 28

Hard Recovery.................................................................................................................... 28
Soft Recovery..................................................................................................................... 28
Version Differences............................................................................................................. 29
How to Run Eseutil /R in Recovery Mode...............................................................................32

Command Line Syntax for Running Eseutil /R....................................................................32
Command Line Syntax for More Complex Recovery Scenarios.........................................32
Eseutil /G Integrity Mode........................................................................................................ 36

Other Exchange Versions................................................................................................... 36
How to Run Eseutil /G in Integrity Mode.................................................................................36

Procedure........................................................................................................................... 37
Eseutil /M File Dump Mode.................................................................................................... 39

How to Run Eseutil /M in File Dump Mode.............................................................................40

How to Run Eseutil /M......................................................................................................... 41
Eseutil /K Checksum Mode.................................................................................................... 44

Previous Exchange Versions.............................................................................................. 45
How to Run Eseutil /K in Checksum Mode.............................................................................45

Before You Begin................................................................................................................ 46
Procedure........................................................................................................................... 46
Command line syntax.......................................................................................................... 47
Eseutil /Y Copy File Mode...................................................................................................... 48

How to Run Eseutil /Y in Copy File Mode...............................................................................49

Procedure........................................................................................................................... 49
Command Line Syntax........................................................................................................ 50
Database Recovery Strategies............................................................................................... 50

Understanding Database Structure.....................................................................................51
Understanding Database Recovery Strategies...................................................................51
Reference for Common Eseutil Errors....................................................................................53
Error Codes, Descriptions................................................................................................... 54
Copyright................................................................................................................................ 67
5
Exchange Server Database Utility Guide

When a database is corrupt or damaged, data can be restored from backup or repaired using
Eseutil. Eseutil is a command line utility that works with Extensible Storage Engine (ESE),
database (.edb) files, streaming (.stm) files, and log (.log) files associated with an Information
Store, in a given Storage Group. Eseutil is located in the C:\Program Files\Exchsrvr\Bin
folder in Exchange Server 2000 and in Exchange Server 2003. The tool 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. The most common Eseutil switches are
listed in the table below.
Note:
Download Microsoft Exchange Server Database Utility Guide to print or read offline.
Eseutil Repair, mode can be used to repair a corrupt or damaged database while recovery
and restore modes can be used to replay transaction log files into a database. The file header
dump modes can be used to correlate database and transaction log files and to determine
other information about them. The checksum mode can be used to verify the file integrity of a
database. The copy file mode is useful for very rapid copying of large files. The
defragmentation mode can be used to compact a database offline, reducing the size of the
database files by removing empty space.
Topics in this guide give you an understanding of the Eseutil repair tool, tell you about
scenarios where you can use the tool, discuss the different modes giving instructions on how
to run Eseutil in those modes, and provide help with troubleshooting common Eseutil errors.
For more information about common Eseutil errors, see Reference for Common Eseutil
Errors.
6
Eseutil Mode Switch Description
Defragmentation /D Eseutil 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.
For more information, see

these topics:
 Eseutil /D
Defragmentation Mode
 How to Run Eseutil /D

(Defragmentation)
Repair /P Eseutil repairs corrupt

database pages in an offline
database but discards any
that can't 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.

these topics:
 Eseutil /P Repair Mode
 How to Run Eseutil /P

(Repair) in Different
Scenarios
7
Restore /C Eseutil displays the

Restore.env file and controls
hard recovery after
restoration from online
backup.

these topics:
 Eseutil /C Restore Mode
 How to Run Eseutil /C

(Restore) in Different
Scenarios
Recovery /R Eseutil replays transaction log

files or rolls them forward to
restore a database to internal
consistency or to bring an
older copy of a database up
to date.

these topics:
 Eseutil /R Recovery Mode
 How to Run Eseutil /R in

Recovery Mode
Integrity /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.

these topics:
 Eseutil /G Integrity Mode
 How to Run Eseutil /G in

Integrity Mode
8
File Dump /M Eseutil displays headers of

database files, transaction log
files, and checkpoint files. The
mode also displays database
space allocation and
metadata.

these topics:
 Eseutil /M File Dump

Mode
 How to Run Eseutil /M in

File Dump Mode
Checksum /K Eseutil verifies checksums on

all pages in the database and
streaming files.

these topics:
 Eseutil /K Checksum
Mode
 How to Run Eseutil /K in

Checksum Mode
Copy File /Y Eseutil performs a fast copy

of very large files.

these topics:
 Eseutil /Y Copy File Mode
 How to Run Eseutil /Y in

Copy File Mode
ISInteg
The ISInteg utility is most often used after an Eseutil repair operation. It can also be used
when an event or error warrants it. Several Microsoft Knowledge Base articles recommend
the use of ISInteg for resolving specific issues.
9
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.
ISInteg was originally created as a utility for internal use by testers in the Exchange
development group, and was released publicly because of its general usefulness. It can
perform multiple independent and interrelated tests of the database, and can fix
discrepancies found. ISInteg cannot comprehensively correct all possible problems in the
database, but it is often very successful. Over time, ISInteg has been incrementally improved
to make it more robust and useful.
For More Information

For more information about database recovery strategies, see Database Recovery
Strategies.
For more information about common Eseutil errors, see Reference for Common Eseutil
Errors.
For more information about the ISInteg utility, see the Microsoft Knowledge Base article
182081 "Description of the Isinteg utility" (http://go.microsoft.com/fwlink/?
linkid=3052&kbid=182081).
For more information about repairing Exchange databases and disaster recovery, see the
Exchange Server 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?
LinkId=47570).
For more information about understanding Extensible Storage Engine (ESE) file types, see
Extensible Storage Engine Files (http://go.microsoft.com/fwlink/?LinkId=68167).
Eseutil /D Defragmentation Mode

Eseutil's /D switch can be used to defragment and compact a database offline. The
defragmentation option makes used storage contiguous, eliminates unused storage, and
compacts the database thereby reducing the database's size. For instructions about how to
use the Eseutil /D syntax, see How to Run Eseutil /D (Defragmentation).
Eseutil's /D switch can be used to defragment and compact a database. During typical
operations, database files never shrink below their current size. As space in the database is
freed by deletion of items, existing pages are reused where possible. Typically, a Microsoft®
Exchange Server database will grow for several months after it is put in service, but
eventually the database size stabilizes.
10
Under typical conditions, performing an offline defragmentation will not permanently recover
significant disk space. The file will usually grow again to its previous un-defragmented size.
Special circumstances, such as moving many mailboxes out of the database, may make it
worthwhile to defragment the database offline. By default, during typical operation, the
database is logically defragmented nightly. This does not reduce the size of the file on disk,
but does make the database perform efficiently.
Note:
You can use the Eseutil utility to defragment the information store and directory in
Microsoft Exchange Server 5.5 and to defragment the information store in Microsoft
Exchange 2000 and newer versions.
How Does Eseutil Defrag Work?

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.
When an offline defragmentation is performed, Exchange makes temporary copies of the

database file (.edb file) and the streaming database file (.stm file). Tables from the .edb file
are preserved and copied into the temporary database, but empty pages and indexes are
discarded. Because this causes physical page numbers in the database to be changed,
pages are not copied unaltered; the page links between them are all updated, and all pages
left in the database undergo integrity checks. All pages in the .stm file that has information on
them are preserved in the temporary .stm file, and references to the pages are updated in the
.edb file.
How Long Does it Take to Defragment a

Database?
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.
By default, after defragmentation is completed, the temporary database automatically

becomes the new production database, and the original production database is deleted. The
time that defragmentation takes can be significantly reduced if you have as much free space
on the same logical drives as the size of the original database files. In this case, the
11
temporary database can be put on the same logical drive, and the final copy will complete
almost instantly.
We do not recommend that you use a network drive to hold the temporary database. When
you use a network drive for the temporary database, defragmentation will take longer, and
any transient or permanent network error will end the process. Because defragmentation
cannot be resumed, you would have to start over from the beginning.
Note:
You only need as much extra logical drive disk space as the final size of the files after
defragmentation. Although it is impossible to exactly predict how much disk space will
be reclaimed, you should leave a recommended 110% of free disk drive space to be
safe. For more information about how to determine the amount of disk space for
defragmentation, see the Microsoft Knowledge Base article 195914, "Determining
database free space with Exchange 5.5 Service Pack 1 and later versions of
Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=195914).
When to Run Eseutil /D?

There are several situations where it is appropriate to run Eseutil /D 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. For more information about increasing the database size limit, see Microsoft
Knowledge Base article 828070, "Exchange Server 2003 mailbox store does not mount
when the mailbox store database reaches the 16 GB limit"
(http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).
Note:
After defragmenting the database using Eseutil, we recommend that you perform a
full backup of the database. A full backup is needed because the database
defragmentation creates new database files which have new database signatures.
Log file replay after the restore depends on database signatures to match the
expected values recorded in transaction log files. Any database backups that are
taken before the defragmentation will contain database files that have signatures
12
different from the new defragmented database. If an older database is restored, the
new transaction logs which are bound to the new defragmented database files will
not replay.
When not to Run Eseutil /D?

There are situations where it is not appropriate to run Eseutil /D 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.
Note:
As a rule, unless you expect more than 20 percent of available space to be
recovered, defragmentation will likely not cause permanent shrinkage of the
database files.

For more information, see the following topics in the Exchange Server Database Utility Guide:
 Eseutil /M File Dump Mode
 Eseutil /K Checksum Mode
 Database Recovery Strategies
 Reference for Common Eseutil Errors

13
How to Run Eseutil /D (Defragmentation)

This section explains how the Eseutil command can be used to defragment, and or compact
Exchange database files offline for all versions of Exchange. For more information about
understanding Eseutil /D, see Eseutil /D Defragmentation Mode.
Before You Begin

Before you defragment a database using Eseutil, note the following:
1. 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).
2. Dismount the database before defragmenting as Eseutil performs an offline

defragmentation. During the offline defragmentation the dismounted database will be
inaccessible to clients.
Procedure
How to defragment an Exchange 2000 or Exchange 2003 database
1. In Exchange System Manager, right-click the database that you want to
defragment, and then click Dismount Store.
2. At the command prompt, change to the Exchsrvr\Bin folder, and then type the
Eseutil /d command, a database switch, and any options that you want to use. For
example, the following command (all on one command line) runs the standard
defragmentation utility on a mailbox database:
C:\program files\exchsrvr\bin> Eseutil /d
c:\progra~1\exchsrvr\mdbdata\priv1.edb
Use the following database switch to run Eseutil defragmentation on a specific

database:
Eseutil /d <database_name> [options]
How to defragment the Exchange Server 5.5 database

1. Stop the service that controls the database you wish to defragment by using the
Services applet in Control Panel.
 For the Exchange Directory database, stop the Microsoft Exchange Directory
service.
14
 For the Exchange Mailbox or Public Folder databases, stop the Microsoft
Exchange Information Store service.
2. At the command prompt, change to the Winnt\System32 folder, and then type the
Eseutil /d command, a database switch, and any options that you want to use.
For example, the following command runs the standard defragmentation utility on the
directory and saves the copy in the user-defined file:
C:\winnt\system32> Eseutil /d /ds /tc:\dbback\tempdfrg.edb /p
Use one of the following database switches to run Eseutil on a specific database.
Option Description
----------------------------------------
/ds Directory
/ispriv Private information store
/ispub Public information store
Use one or more of the following options to specify the operations that you want to
perform on the database.
Command line reference

This is the command line reference that can be seen by typing Eseutil ./? at the command
prompt in the Exchsrvr\Bin folder, and the selecting D for defragmentation
DEFRAGMENTATION/COMPACTION:
DESCRIPTION: Performs off-line compaction of a database.
SYNTAX: ESEUTIL /d <database name> [options]
PARAMETERS: <database name> - filename of database to compact
OPTIONS: zero or more of the following switches, separated by a space:
/s<file> - set streaming file name (default: NONE)
/t<db> - set temp. database name (default: TEMPDFRG*.EDB)
/f<file> - set temp. streaming file name
(default: TEMPDFRG*.STM)
/i - do not defragment streaming file
/p - preserve temporary database (ie. don't instate)
/b<db> - make backup copy under the specified name
/8 - set 8k database page size (default: auto-detect)
/o - suppress logo
NOTES: 1) If instating is disabled (ie. /p), the original database
is preserved uncompacted, and the temporary database will
contain the defragmented version of the database.

15
Eseutil /P Repair Mode

The Eseutil repair mode corrects database problems at the page and Extensible Storage
Engine (ESE) table levels but not at the application level. After repairing a database using
Eseutil, ISInteg should be run to repair the database at an application level. To understand
what database page level, ESE table levels, and application levels mean, see Database
Recovery Strategies. For more information about syntax and instructions for using Eseutil /P,
see How to Run Eseutil /P (Repair) in Different Scenarios.
During repair, it may be necessary to discard rows from tables or even entire tables. After
completing the ESE-level repairs, it is necessary to perform an application-level repair to
correct problems that may now exist at the application level because of missing data. The
Information Store Integrity (ISInteg) utility can be used to perform this Exchange application-
level analysis and repair. The following example explains how Eseutil repair works.
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.
In short, Eseutil looks at each Exchange database page and table and ensures consistency
and integrity within each table. ISInteg, recommended to be run after Eseutil, repairs a
database at the application level and ensures the integrity of the relationships between
tables.
Repairing databases involves the following three stages, in this order:
1. Eseutil is run in /P mode to perform a database page-level and table-level repair
2. Eseutil is run in /D mode to fully rebuild indexes and defragment the database
16
3. ISInteg is then run to repair the database at the application level
Note:
A successful repair does not necessarily mean that a database will always be
useable. The loss of system metadata may leave a database unmountable or empty.
When a database is not repairable, you can restore data from backup or create a
new database.
Placing a Repaired Database Back Into

Production
It is a judgment call whether to leave a repaired database permanently in production. The
policy of many administrators is to use repaired databases only for data salvage.
Administrators move mailboxes as soon as possible to another database, or merge the data
from a repaired database into a known good database.
Both Eseutil and ISInteg generate detailed repair log files that list the errors found and
corrected. For more information about causes and consequences of specific errors, you can
search the Microsoft Knowledge Base and see the topic on Reference for Common Eseutil
Errors. Information from these areas can help you decide whether you wish to accept the
risks of leaving a repaired database in production.
Eseutil /P Best Practice

Use Eseutil /P when you cannot restore a database from backup or when you cannot fully roll
transaction logs forward.
Note:
If you cannot roll forward transaction log files, a hybrid strategy is best to follow. You
can restore a working version of the database from backup, repair the damaged
database in the recovery storage group, and merge the two databases.
Microsoft recommends that you follow these best practices when repairing a database:
 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.
 Do not use Eseutil repair mode to expunge a -1018 error. For more information about
error -1018, see Microsoft Knowledge Base article 812531, "Support WebCast: Microsoft
Exchange: Understanding and Resolving Error -1018" (http://go.microsoft.com/fwlink/?
linkid=3052&kbid=812531).
17
Previous Exchange Versions

The table below explains how the Eseutil repair mode works in different versions of
Exchange:
Exchange 200x By default, detailed logging of the repair

process is stored in a plain text file called
database.integ.raw. This log will tell you
exactly which tables were repaired and what
problems required their repair.
Exchange 5.5 It was necessary to specify verbose logging

with the /V switch to see similar detail.

 Eseutil /D Defragmentation Mode
How to Run Eseutil /P (Repair) in Different

Scenarios
The Eseutil syntax and behaviors described in this section apply to Exchange Server 2003
Service Pack 2 (SP2), and give instructions for running the Eseutil repair on your database.
The Eseutil repair mode corrects corrupted or damaged databases at the page and table
levels, but not at the application level. A repair may complete successfully, leaving all
database tables consistent, but with the database so severely damaged that it cannot be
mounted. For more information about the Eseutil repair mode, see Eseutil /P Repair Mode.
18
Before you begin

Consider the following points before running the Eseutil repair mode on your database:
 There must be sufficient disk space on the local logical drive for the temporary repair
database. Keeping 20 percent of the size of the database files being repaired is
suggested, although the size of the temporary file will vary widely depending on the
nature of the repairs made. If sufficient space is unavailable, you may redirect temporary
files to a different drive, as described below.
 The streaming database (.stm file) must be in the same folder as the Messaging
Application Programming Interface (MAPI) database (.edb file), or you must set a
command line switch to identify the path for the streaming database, as described below.
Procedure
To run Eseutil /P
 The basic command line syntax for repairing a database with Eseutil is:
ESEUTIL /P database_filename.edb
Note:
With Exchange Server 5.5, you need to run /V to see the verbose logging
that is default with Exchange 2000 Server and later versions.
You may encounter these scenarios when running Eseutil repair against your database:
 Database and streaming files don't match
 Streaming file is missing
Database and Streaming Files Don’t Match

Some hard crashes may leave the database and streaming databases out of synch with each
other, or you may have obtained a streaming database that is out of date with the database
file. By default, repair will check for this problem at the beginning, and exit to give you a
chance to obtain the correct file if it is available.
You can force repair to continue past this problem, but if the streaming file is one that does
not actually belong with the database, this will not salvage data from it. Instead, all data will
be deleted from the streaming file. Force a mismatch to be ignored only when you are very
confident that the streaming and database files belong together, and that they are close to
being in synch with each other.
19
The streaming database is composed entirely of raw user data. All logical structure and
ownership information about the data is in the MAPI database (.edb file). All data in the .stm
file that does not match the pointers in the .edb file will be lost during a repair.
Follow these steps for running Eseutil /P to ignore a streaming file mismatch:
To ignore streaming file mismatch

 To ignore a streaming file mismatch, add the /I switch to the Eseutil command line.
For example:
ESEUTIL /P priv1.edb /I
Streaming File is Missing

If the streaming database has been destroyed, or is missing, you can still successfully
complete a repair, but with the loss of all data in that file. If the majority of your users are
MAPI clients (Microsoft® Office Outlook® users), the data loss involved may be negligible. If
most users connect via Post Office Protocol version 3 (POP3) or Internet Message Access
Protocol version 4 (IMAP4), the data loss is likely to be catastrophic.
Follow this step to run Eseutil /P when a database streaming file is missing or when repair is
unable to finish with the current streaming file:
To create a new streaming file

 To create a new streaming file, use the /CREATESTM switch. For example:
ESEUTIL /P PRIV1.EDB /CREATESTM
Post-Repair Considerations
Remember the following points after you have run Eseutil /P to repair your database:
 Perform a full backup of the database as soon as possible after a repair. Repair
invalidates previous backups. This does not mean that previous backups cannot be
restored or are completely worthless. It means that repair makes it impossible to
completely roll the database forward from a previous backup. If you restore a previous
backup, transaction log file replay will end at the point at which the repair was done. Any
changes to the database subsequent to the repair cannot be put back into a restored
database. Therefore it is critical that you perform a full backup of the database as soon as
possible after a repair.
 Remember that you must run defrag (Esetuil /D) and ISInteg -fix to finish repair. Only if
you intend to use the repaired database for salvage and then discard it can you skip
20
these extra steps. Skipping them means that you may salvage less data than if you
completed them, but it can also mean saving several hours of recovery time.
Important:
You must perform a full backup of the database, run defrag, and run ISInteg before
placing a repaired database back in production. Microsoft IT's best practice is to
move a mailbox as soon as it is feasible rather than to leave a repaired database
indefinitely in production. For more information, see Eseutil /P Repair Mode.

prompt in the Exchsrvr\Bin folder, and the selecting P for repair.
REPAIR:
DESCRIPTION: Repairs a corrupted or damaged database.
SYNTAX: ESEUTIL /p <database name> [options]
PARAMETERS: <database name> - filename of database to repair
/t<db> - set temp. database name
(default: TEMPREPAIR*.EDB)
/f<name> - set prefix to use for name of report files
(default: <database>.integ.raw)
/i - bypass the database and streaming file mismatch error
/g - run integrity check before repairing
/createstm - create empty streaming file if the file is missing
/8 - set 8k database page size (default: auto-detected)
/o - suppress logo
NOTES: 1) Repair does not run database recovery. If a database
is in a "Dirty Shutdown" state it is strongly
recommended that before proceeding with repair,
recovery is first run to properly complete database
operations for the previous shutdown.
2) The /i option ignores the signature mismatch error in
the check phase if the database and streaming file do
not match each other. The database and streaming file
will receive new signatures in the repair phase. Without
using this option, repair will terminate immediately
once the database and streaming file mismatch error occur
3) The /g option pauses the utility for user input before
repair is performed if corruption is detected. This optio
overrides /createstm and /o options.
4) The /createstm option is irreversible. Once you
start the repair process a new streaming file will
be created. Any streaming file that existed before
the repair will no longer work with this database.
21

Eseutil /C Restore Mode

The Eseutil restore mode allows you to run hard recovery on a database restored from online
backup, and to view the Restore.env file. The Restore.env file is created during restoration of
an online backup, and it controls the hard recovery process. For more information about
running Eseutil /C, see How to Run Eseutil /C (Restore) in Different Scenarios.
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.
Backup applications that implement the Exchange legacy streaming online backup API
provide a setting in the user interface to start hard recovery after the last backup set has been
restored. In Microsoft® Windows NT® NTBackup, it is called “Last Backup Set.”
If you fail to trigger hard recovery from the backup application, you must run hard recovery
manually from the command line with Eseutil before a restored database can be mounted.
Note:
If you run the Eseutil restore commands from where the Restore.env file exists, the
command syntax is very simple. Otherwise, you must add path information to the
switches. Therefore, it is strongly recommended that you run these commands from
the Restore.env location.
22

For more information about database recovery, see Recovering an Exchange Database
(http://go.microsoft.com/fwlink/?LinkId=67227).
How to Run Eseutil /C (Restore) in Different

Scenarios
This section explains the command line syntax and transaction log file replay for running a
hard recovery using Eseutil restore on your database. The Eseutil restore mode allows you to
run hard recovery on a database restored from online backup, and to view the Restore.env
file. The Restore.env file is created when restoring a database from online backup, and it
controls the hard recovery process. For more information about Eseutil /C, see Eseutil /C
Restore Mode.
Before You Begin

Important:
The Eseutil /CC command may not work with Exchange 2000 Server running on a
cluster server, and you may receive the following error message: Error returned
from a callback function call (0x8004010F). Operation terminated with error
-107 (JET_errInternalError, Fatal internal error).
For more information about this error, see Microsoft Knowledge Base article 266689, "The
"eseutil /cc" command does not work on cluster server."
23
Procedure
To run Eseutil /C
 To view the Restore.env file use this basic command line syntax:
ESEUTIL /CM “d:\temp\First Storage Group”
Note:
If you run the command from the directory where Restore.env exists, it is not
necessary to specify any path information. If you specify path information, do
not append Restore.env to the end of the path.
 To run hard recovery, execute the following command line syntax:
ESEUTIL /CC “d:\temp\First Storage Group”
Note:
If you run the command from the directory where Restore.env exists, it is not
necessary to specify any path information. If you specify path information, do
not append Restore.env to the end of the path.
For more information about running Eseutil /CC, see "How to Run Eseutil /cc"
(http://go.microsoft.com/fwlink/?LinkId=67228).
 To force a non-victimized database to be recovered, you can run the following

command as if the database has been victimized, as in the example below:
ESEUTIL /CC /T
Note:
Do not use any parameters with the /T switch. Use of the /T switch will cause
all transaction logs in the Restore.env location to be replayed, whether they
are listed in the Restore.env file or not. No logs in the running folder will be
replayed.
Controlling Transaction Log File Replay.

Transaction log file replay behavior using Eseutil /CC depends on whether the database has
been victimized or not.
Note:
If you are unsure about the victimization status of a database, copy log files into both
the temporary and running folders. This will ensure that one log copy or the other will
be considered for replay.
24
If a database has NOT been victimized, transaction logs will be replayed as follows:
 The sequence of log files listed in the Restore.env file will be replayed first.
 If additional log files exist in the Restore.env location, they will not be replayed under any
circumstances.
 If additional matching log files exist in the running storage group log folder and they are in
contiguous sequence with the files listed in Restore.env, they will be replayed.
 If additional log files exist in the running storage group log folder and they do not match
or are not in contiguous sequence and circular logging has been disabled, then an error
will occur and hard recovery will fail. To resolve such errors, matching and contiguous log
files must be located, or you can use Eseutil /CC /T switches to ignore log files in the
running folder and to replay only log files listed in the Restore.env file.
 If circular logging is currently enabled or was enabled at the time the backup was made,
then only log files listed in Restore.env will be replayed.
 If no log files exist in the running storage group log folder, then recovery will complete
successfully using only the log file(s) listed in Restore.env.
If a database has been victimized, transaction logs will be replayed as follows:

 If additional log files exist in the Restore.env location, and they match and are contiguous
with the logs listed in Restore.env, then they will also be replayed.
 Additional log files in the running storage group log folder will not be replayed.
If a database has been restored to a Recovery Storage Group (RSG), transaction logs
will be replayed as follows:
 Any other databases in the RSG must be dismounted before beginning any transaction
log file replay.
 If additional matching log files exist in the running log folder for the RSG, and they are in
contiguous sequence with the files listed in Restore.env, they will be replayed.
 If additional log files exist in the Restore.env location, they will not be replayed under any
circumstances.
Important After hard recovery succeeds, all files in the temporary directory (where
Restore.env was created) are deleted. Never place your only copy of a log file in the
Restore.env temporary folder.
25
Command line syntax

prompt in the Exchsrvr\Bin folder, and then selecting C for restore.
RESTORE:
DESCRIPTION: Restore information and completion.
SYNTAX: ESEUTIL /c[mode-modifier] <path name> [options]
PARAMETERS: [mode-modifier] - a letter designating the type of operation
to be done
m - dump Restore.Env
c - start recovery for a Restore.Env
<path name> - directory of the restore
(Restore.Env location)
/t[instance] - name of the instance containing the log
files to play forward, or if [instance] is
not specified, don't play forward any log
files unless they are in the restore
directory (default: use instance specified
by Restore.Env)
/f<path name> - directory containing the log files to play
forward (note: doesn't work with /t)
/k - preserves the log files used for recovery
/8 - set 8k database page size (default: 4k)
/o - suppress logo



26
Eseutil /R Recovery Mode

Recovery refers to the process of playing transaction log files into a database. There are two
kinds of recovery:
 Hard recovery: A transaction log replay process that occurs after restoring a database
from an online backup.
 Soft recovery: A transaction log replay process that occurs when a database is re-
mounted after an unexpected stop, or when transaction logs are replayed into an offline
file backup copy of a database.
For more information about hard and soft recoveries, see "Transaction Log File Replay: Soft
Recovery and Hard Recovery in Exchange Server 2003" (http://go.microsoft.com/fwlink/?
linkid=68147).
For more information about instructions for running Eseutil in recovery mode, see How to Run
Eseutil /R in Recovery Mode.
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).
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.
Important:
A fundamental assumption of the soft recovery process is that no database or log
files have been moved, deleted, or destroyed by the failure—or by the administrator
after the failure.
27
Version Differences
Eseutil is always being improved, and added to from version to version. There are currently
three major versions of Eseutil /R for each of the 3 major exchange versions as follows:
 Exchange Server version 5.5
 Exchange 2000 Server
 Exchange Server 2003
Exchange Server 5.5

The command line syntax for soft recovery with Eseutil in Microsoft® Exchange 2000 Server
and Microsoft® Exchange Server 2003 is different from that used in Exchange 5.5. The rules
and best practices for performing manual soft recovery with Eseutil have also changed.
 In Exchange 5.5, there is almost never a good reason to perform soft recovery with
Eseutil. Each time the Information Store starts, soft recovery is run automatically, and
correctly. In Exchange 5.5, the Eseutil soft recovery function was intended mostly for test
environments where you might wish to recover a database on a server that did not have
Exchange installed.
 There is a major risk in running Eseutil /R in Exchange 5.5: After restoring an online
backup, running soft recovery instead will usually corrupt the database. An online backup
needs hard recovery, not soft recovery.
 Only if the following two conditions are both met is it safe to run soft recovery instead of
hard recovery in Exchange 5.5 and previous versions:
 The database paths have not changed since the backup was done.
 The .pat files from the online backup set are exactly 8 K in size (meaning, that they
are composed of only two header pages, and have no actual database pages in
them).
In all other circumstances, running soft recovery instead of hard recovery will corrupt the
database in proportion to the size of the .pat files.
Note:
If you divide the byte size of a .pat file by 4096, and subtract two, that is the
number of logically corrupt pages that will be in the database after improperly
running soft recovery.
Exchange 2000 Server

In Exchange 2000, safeguards were implemented that always prevent soft recovery from
running when hard recovery is needed.
28
There is another risk in running soft recovery with Eseutil. This risk still exists in Exchange
2000 or Exchange 2003: If you improperly specify paths to log files, to the checkpoint file or to
database files, recovery may alter the database or log files and prevent recovery from being
done again.
If existing transaction log files are not found by Eseutil when it tries to run recovery, it will
create a new transaction log file, and try to attach the database to it. If the database is
Inconsistent or in Dirty Shutdown state, the database will not be made startable. If the
database is in a Consistent state, it will be attached and then detached from the new log file.
In either case, you risk making changes to the database or adding log files to the server that
will result in the database becoming unstartable or that will confuse further recovery
troubleshooting.
Note:
Just because recovery with Eseutil reports success does not mean that the database
recovered is in a mountable state. Recovery succeeds whenever all available
transaction log data that is currently available has been applied to the database files.
Recovery success says nothing about whether the available data was sufficient to
restore the databases to consistency.
In Exchange 5.5, you were almost always better off placing files in appropriate locations and
then starting the Information Store to accomplish recovery. In Exchange 2003, there are two
improvements to the Eseutil recovery functionality that provide important advantages over
mounting a database to run recovery on it:
 Eseutil can force recovery to complete even if there is a missing database. This capability
is also available in Exchange 2000.
 If a storage group is unexpectedly stopped, all databases running at the time will be
Inconsistent in a Dirty Shutdown state. Suppose that the reason the storage group
stopped was that a database drive suddenly failed, and the drive is inaccessible. In this
case, you are missing one of the databases.
 If you run recovery while the database is missing, it is possible that you will alter the state
of the transaction logs so that if the drive becomes accessible again, recovery will not
complete successfully with that one database.
Note:
If you restore the database from backup, recovery will be able to complete
successfully—this scenario only applies to recovering a database that was
attached to the current log at the time of the sudden stop.
 If you know that the lost database will not be recovered, you can recover the rest of the
databases in the storage group without first restoring the missing database from backup
by using the Eseutil /I (ignore) switch.
29
Before using this switch to run recovery on the rest of the storage group, you should first
make a backup of all transaction log files, including the current log (Enn.log). By keeping a
copy of the current log and all the other logs, you will still be able to recover the missing
database if it unexpectedly becomes available. Once you recover the rest of the databases,
and thus write more information into Enn.log, you may not be able to recover the missing
database using that log file.
Exchange Server 2003

Eseutil recovery can recover a database that has been moved to a different path location.
This capability is available only in Exchange 2003.
Hard recovery has always been able to finish successfully, even if Exchange databases have
been moved to different path locations since a backup was done. But until Exchange 2003,
soft recovery could only work if the database files were in the same drive path as that defined
in the transaction log files to be replayed.
In Exchange 2003, the /D switch was added to Recovery mode to allow override of the
database path hard coded in the transaction log files. This new capability is very useful when
restoring offline copies of databases to Recovery Storage Groups, or when recovering a
“missing” database as described in the scenario above.
You can now copy a database and a group of transaction logs into any folder you desire, and
successfully run soft recovery. Once the database is consistent, you can then move it to any
other path desired, and attach it to a different log stream.


30
How to Run Eseutil /R in Recovery Mode

Recovery refers to the process of playing transaction log files into a database. There are two
kinds of recovery: Hard and Soft recovery. Hard recovery can be done with Eseutil by using
the Restore mode (/C). For more information about understanding Eseutil recovery, see
Eseutil /R Recovery Mode.
Command Line Syntax for Running Eseutil /R

To Run Eseutil /R
 The basic command line syntax to run soft recovery with Eseutil is:
ESEUTIL /R Enn
 For example:
ESEUTIL /R E00
Note:
The Enn specifies the log file prefix of the transaction logs you intend to play
into the database. This command line will work only when run from the folder
in which the transaction log files exist, and only when the databases to be
recovered are in their original path locations. The log prefix specifier is a
required parameter for Eseutil /R.
Command Line Syntax for More Complex

Recovery Scenarios
Transaction log files are not in the current folder
As a general rule, you should always run Eseutil /R from the folder where the transaction log
files to be replayed exist. This is because the default soft recovery process looks in the
transaction log files to find the path to the databases. If you run recovery from a folder where
no log files exist, a new transaction log file will be generated, and this log file will not know
where the databases are. If you wish to run recovery from outside the transaction logs folder,
add this switch to the command:
/Lpath_to_logfiles
For example:
ESEUTIL /R E00 /Ld:\exchsrvr\logfiles
31
Controlling the checkpoint file

In most cases where you manually run soft recovery, you will want to either delete or hide the
checkpoint file, because you will typically wish to replay all available transaction logs rather
than start from the middle of an available sequence.
If you are running recovery from a folder where a valid checkpoint file exists, and you do not
wish to have that file affect recovery, you must define a different path for a checkpoint file to
be created during recovery. This might be required after restoring an offline backup into a
storage group where databases are running
If you are running recovery from a different folder, and wish to use the checkpoint file to
control recovery, you must point to the path for the checkpoint file.
If you wish to control the use of the checkpoint file during recovery, add this switch to the
recovery command:
/Spath_to_or_away_from_current_checkpoint
For example:
ESEUTIL /R E00 /Sd:\
Recovering a storage group with a missing database

If a storage group is unexpectedly stopped, and one of the Inconsistent databases is
removed or unavailable, you will be unable to mount any of the databases in the storage
group until you restore the missing database or until you run manual recovery with the /I
switch.
Important:
Before recovering while ignoring the missing database, you should make a backup
copy of all transaction log files, including the current log file (Enn.log). Once Enn.log
has been changed by recovering the other databases, it may not be useable for
recovering the missing database if it is once again made available.
Recovering a database “out of place”

This method of recovery completely isolates the recovery process from the running storage
group. It is also the way you should recover an offline backup in a Recovery Storage Group, if
you intend to play any log files into the backup.
To prepare to do this, you should move the database files (.edb and .stm) and all transaction
logs you intend to play into a single temporary folder.
To run Eseutil out of place

 From this folder, you can run the following command:
ESEUTIL /R Enn /I /D
32
 For example:
ESEUTIL /R E00 /I /D
The /I switch may or may not be necessary, depending on whether there are Clean Shutdown
records in the transaction logs for other databases that were attached to the logs. Using the
switch in this circumstance is recommended so that you do not have to start recovery again if
there is a “hanging attachment” somewhere in a log file.
The behavior of the /D switch deserves more explanation. If the /D switch is not present at all,
then the database paths recorded in the transaction log files will be used to locate the
databases. This is the only behavior available in Eseutil for Exchange 2000 and previous
versions. If the /D switch is used without a path, then the current directory will be used as the
path for the database files. If the /D switch is immediately followed (with no intervening space)
by a file path, then that path will be used to locate the database files. For more information
about using the /D switch to resolve issues with transaction logs while moving an Exchange
database, see Issues with Transaction Log Files When Moving an Exchange Mailbox
Database.
Because of the possibility of typing errors, it is strongly recommended that you eliminate the
need for using paths with Eseutil switches by running Eseutil from a folder where all data files
already exist.
After recovery finishes and the database files are in Clean Shutdown state, they may be
moved into place in the appropriate storage group, and attached to the log files there by
mounting the databases.
Note:
It will usually be necessary to mark the checkbox for “This database can be
overwritten by a restore” on the database object properties in Exchange System
Manager before the database will mount.

This is the command line reference that can be seen by typing eseutil ./? at the command
prompt in the Exchsrvr\Bin folder, and the selecting R for restore.
RECOVERY:
DESCRIPTION: Performs recovery, bringing all databases to a
clean-shutdown state.
SYNTAX: ESEUTIL /r <3-character logfile base name> [options]
/l<path> - location of log files
(default: current directory)
/s<path> - location of system files (eg. checkpoint file)
(default: current directory)
/i - ignore mismatched/missing database attachments
/t - on successful recovery, truncate log files
33
/u[log] - stop recovery when the Undo phase is reached

with the option
to stop when a certain log generation is
recovered.
[log] is the log generation number and if not
specified
the replay will go to the end of the existing
logs.
/d[path] - location of database files, or current directory
if [path] not specified (default: directory
originally logged in log files)
/n<path1[:path2]> - new location of database file and optional old
location
if the database file location changed.
Can be specified for each database file.
If a certain database is not in the list,it
won't get recovered.
To allow recovery in the original location
for all other database, use /n*.
(not valid with /d switch, not valid with
/b switch)
/8 - set 8k database page size (default: 4k)
/o - suppress logo

Eseutil /G Integrity Mode

Eseutil /G integrity mode, is a reliable way to verify whether or not an Exchange Server
database contains specific inconsistencies. Using this tool to test database integrity is a safe
approach because the check is performed in a read-only mode. It is important to detect
34
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.
For more information about doing an integrity check using Eseutil, see How to Run Eseutil /G
in Integrity Mode.
Other Exchange Versions

In Exchange Server version 5.5, when the Exchange Database Engine (ESE) encounters a
read verification failure (Error -1018 (JET_errReadVerifyFailure)) during an Eseutil integrity
check, the engine will not perform retry operations. If ESE tries to read the page after the
initial failure, then the length of time to run the Eseutil function dramatically increases. In
Exchange Server 5.5 Service Pack 2 (SP2), the ESE will try to successfully read the page up
to a maximum of 16 times.

How to Run Eseutil /G in Integrity Mode

The integrity check in Eseutil is basically a test run of the repair function. Problems that repair
would address will be reported in the <database>.integ.raw file. The .raw file logs results for
all tables in the database, not just ones that have problems. For more information about the
Eseutil integrity mode, see Eseutil /G Integrity Mode.
Note:
An integrity check may end prematurely if damage to the database is of such a
nature that parts of the database must be repaired before other parts can be
35
checked. The fact that an integrity check ends before it finishes does not necessarily
mean that repair is unlikely to succeed. Although you can perform an integrity check
after a dirty shutdown, we do not recommend this. You should recover the database
to Clean Shutdown state before you run an integrity check if you can do so.
Procedure
To run Eseutil /G
 The basic command line syntax to run an integrity check with Eseutil is:
ESEUTIL /G database_filename.edb
For example:
ESEUTIL /G priv1.edb
Note:
There must be disk space available to the equivalent of 25 percent of
combined size of the Exchange database (.edb) and streaming database
(.stm) files. The streaming database must be in the same folder as the .edb
file.
You may be faced with the following scenarios when you run an Eseutil /G integrity check on
the database:
 Insufficient local drive space for temporary database
 Ignoring streaming database mismatches
Insufficient Local Drive Space for Temporary Database

Many of the integrity checks involve reconstructing indexes and other data inside a temporary
database. Afterward, a comparison is done between the two databases.
If you do not have free disk space equivalent to 20 percent of the size of the files being
checked, then there is greater likelihood of running out of disk space during the check. You
can add this switch to the command to redirect the “scratchpad” database to a drive with
more space:
/Tpath_to_temporary_database
For example:
ESEUTIL /G priv1.edb /T\\Server2\d$\scratchpad.edb
36
Note:
There is no space between the /T switch and the path specification. You can also use
an ordinary drive letter path specification if desired.
Ignoring Streaming Database Mismatches

Exchange will detect whether a database and its streaming database are synchronized with
each other. If they are not in synch, you can ignore the problem and force an integrity check
to proceed regardless, by using the /I switch. For example:
ESEUTIL /G priv1.edb /I
If there are no SLV files (.stm or streaming database files) checksum errors reported in the
.raw file output, then while the two files may be formally out of synch, the likelihood of
successful repair and reintegration of the streaming file data is high.

The following is the command line reference that can be obtained by running Eseutil /? and
then G from the Exchsrvr\bin folder:
INTEGRITY:
DESCRIPTION: Verifies integrity of a database.
SYNTAX: ESEUTIL /g <database name> [options]
PARAMETERS: <database name> - filename of database to verify
/t<db> - set temp. database name (default: TEMPINTEG*.EDB)
/f<name> - set prefix to use for name of report files
(default: <database>.integ.raw)
/i - bypass the database and streaming file mismatch er
ror
/o - suppress logo
NOTES: 1) Integrity-check does not run database recovery. If a
database is in a "Dirty Shutdown" state it is strongly
recommended that before proceeding with an integrity-
check, recovery is first run to properly complete
database operations for the previous shutdown.
2) The /i option ignores the signature mismatch error if
the database and streaming file do not match each other.


37
Eseutil /M File Dump Mode

While the Eseutil file dump mode is often overlooked by administrators, it is an invaluable
troubleshooting and diagnostic tool. This mode does not repair or make other changes to
files. Its purpose is to provide you with information about the state of the database files. For
example, to see if your database has been repaired by using the Eseutil /P command, dump
the header using one of the following commands for the private information store:
ESEUTIL /mh x:\exchsrvr\mdbdata\priv.edb |more
-or-
ESEUTIL /mh x:\exchsrvr\mdbdata\pub.edb |more
In file dump mode, you can:
 View header information for the database, streaming database, checkpoint and
transaction log files.
 View header information for individual database pages.
 Validate that a series of transaction log files forms a matched set and that all files are
undamaged.
 View space allocation inside the database and streaming database files.
 View metadata for all tables or for a specific table in the database file.
For more information about syntax and about running Eseutil /M in different scenarios, see
How to Run Eseutil /M in File Dump Mode.
The following table provides details of switches used to view headers of different types of
database files:
38
You can use the To
Eseutil /mh switch View the header information of Exchange

database files (.edb), streaming files (.stm)
and Patch files (.pat) for a private or public
information store.
Note Patch files only exist on pre-Service

Pack 2 (SP2) Exchange 2000 Server-based
servers.
Eseutil /ml switch View the header of a private information store

log file.
Eseutil /mk switch View the header information for private

information store checkpoint files.


For more information about /ml and /mh switches, see Eseutil.exe Examples.
How to Run Eseutil /M in File Dump Mode

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.
The syntax for Eseutil /m is:
ESEUTIL /m mode-modifier file_name [options]

39
The most common mode modifiers that are used with Eseutil are:
 h - dump database header (default)
 k - dump checkpoint file
 l - dump log file or set of logs
Note:
To list additional options for Eseutil, type eseutil /? at a command prompt, and then
press ENTER.
For more information about Eseutil file dump mode, see Eseutil /M File Dump Mode.
How to Run Eseutil /M

You can run Eseutil in file dump mode to do the following:
 View transaction log file and database page headers
 Validate transaction log files
 Check metadata and space usage
View file and page headers

The header for checkpoint, transaction log and database files is the first physical page of
each file. Some files have a “shadow” header—a copy of the header on the second page of
the file. The file header contains important state and diagnostic information about the file. By
correlating header information from various files, you can determine whether the files belong
together or are mismatched.
There are separate switches for viewing different kinds of file headers. Be sure that you use
the correct switch with the correct file type, or the output will be invalid.
To view the header of database files and page headers

 To view the header of a database, streaming database file or online backup patch file:
ESEUTIL /MH {filename.edb | filename.stm | filename.pat}
 To view the header of a checkpoint file:

ESEUTIL /MK filename.chk
 To view the header of a transaction log file:

ESEUTIL /ML filename.log
 To view the header of a database page:

ESEUTIL /M database_filename.edb /Plogical_page_number
40
Note:
There is no space between /P and the page number.
Validate transaction log files

Prior to Exchange 2000, it was necessary to closely check a set of transaction log files to
determine:
 If they were all from the same sequence
 If there were any gaps in the sequence of logs.
 Doing this required examining and comparing each file header. There was no way to
verify that a transaction log file was undamaged. Transaction log files in Exchange 5.5
were not checksummed.
Starting with Exchange 2000 Server, you can use the /ml switch to verify both the sequence
and the integrity of a set of log files.
To verify both sequence and integrity of a set of log files

 Run the following command syntax:
ESEUTIL /ML Enn
For example:
ESEUTIL /ML E00
Note:
By specifying only the log file prefix, rather than a particular log file name, all
log files in the current folder will be scanned and validated. You must run this
command from the folder where the log files exist. Processing each log file
will take a few seconds. To process the current log file in a running storage
group, all databases in the storage group must be dismounted.
Check metadata and space usage

The output of the metadata and space usage commands is very similar to each other. A
space usage dump is a metadata dump with columns added for space usage and streaming
databases statistics. A metadata dump will be faster to complete than a space usage dump.
Therefore, use the metadata dump when you are looking for table information such as
pgnoFDP and objidFDP values, and you are not concerned about space usage.
To view metadata dump

 Run this basic command syntax to display metadata information for a database:
41
ESEUTIL /MM database_filename.edb
You can also display data for a single table by specifying the name of the table. For
example, you may wish to view the Msg or attachments table:
ESEUTIL /MM database_filename.edb /t1-23
Note:
The attachments table in an Exchange 200x database is table 1-23.
Note:
The space usage dump syntax is identical to that for metadata, except that
the switch /MS is used instead of /MM.
An aggregate total of the free pages in the database is listed on the last line of a space usage
dump. You can multiply this number by the page size for the database to get an
approximation of the space that will likely be reclaimed by defragmentation.
Notes:
 In a typical database, the metadata dump will take multiple screens. To preserve the
output to a file, add a redirection command to the end of your command line, for
example:
 ESEUTIL /MM database_filename.edb > filename.txt

then M from the Exchsrvr\bin folder:
FILE DUMP:
DESCRIPTION: Generates formatted output of various database file types.
SYNTAX: ESEUTIL /m[mode-modifier] <filename> [options]
PARAMETERS: [mode-modifier] - an optional letter designating the type of
file dump to perform. Valid values are:
h - dump database header (default)
k - dump checkpoint file
l - dump log file or set of logs
m - dump meta-data
s - dump space usage
u - dump undefined codepoint fixup table
<filename> - name of file to dump. The type of the
specified file should match the dump type
being requested (eg. if using /mh, then
<filename> must be the name of a database)
OPTIONS: zero or more of the following switches, separated by a space
/p<pgno> - dump the specified page from the database
/t<table> - perform dump for specified table only
/v - verbose
42
/8 - set 8k database page size (default: auto-detect

/o - suppress logo

For more information about /ml and /mh switches, see Eseutil.exe Examples.
Eseutil /K Checksum Mode

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.
Note:
The checksum mode does not run a database recovery. If a database is inconsistent
or is in a "dirty shutdown" state, Microsoft recommends that you perform a recovery
operation to make sure that the database operations are completed correctly. After
you perform the recovery operation, you can use the Eseutil tool to perform the
integrity check.
For more information about running Eseutil in checksum mode, see How to Run Eseutil /K in
Checksum Mode.
43
With the inclusion of ESEFile features in Eseutil, the checksumming capabilities of Eseutil are
extended to include streaming databases, log files, and checkpoint files. Note the following
uses of the Eseutil /K checksum command:
 If you checksum only a streaming database, only the header pages in the database will
be checked. The data is ignored. If you wish to checksum an entire streaming database,
you must run checksum mode against the Exchange Database (.edb) file. The reason for
this is that the checksums for data in the streaming file are not actually stored in the
streaming file, but in a table in the .edb file.
 The Eseutil checksum mode will not allow you to checksum individual pages in the
database. But you can use the page dump mode to determine whether the checksum on
any given page is correct.
Previous Exchange Versions

Prior to Exchange 2003, a database could be checksummed during online backup, by
running Eseutil /G, or by using the ESEFile utility. Eseutil replaces the Microsoft Exchange
2000 Server and Exchange Server 5.5 ESEFile support utility.

How to Run Eseutil /K in Checksum Mode

This section explains how the Eseutil /K checksum mode works on Exchange Server 2003
databases, and covers basic operation procedures. Exchange 2003 uses a checksum
procedure, by using the /K switch, to confirm the data integrity of pages in the database. You
44
can also use the switch to perform a checksum procedure on a streaming file. For more
information about how to use Eseutil in checksum mode, see Eseutil /K Checksum Mode.
Before You Begin

Important:
Before you use the Eseutil tool, use Exchange System Manager to dismount the
stores that you want to examine.
The checksum feature does not run a database recovery. If a database is inconsistent, or in a
"dirty shutdown" state, we recommend that you perform a recovery operation to make sure
that database operations are completed correctly. After you perform the recovery operation,
you can use the Eseutil utility to perform the integrity check.
Procedure
To do a Eseutil /K checksum with basic syntax
 Enter this basic syntax at the command line to checksum an ESE database,
streaming database, transaction log, or checkpoint file:
ESEUTIL /K <filename>
Note:
Replace <filename> with the path and name of the file that you want to
checksum
The following optional command-line switches are associated with the /K switch:
 /s<filename> Use this switch to specify the streaming file name. The default setting is
none.
 /t<db> Use this switch to specify the temporary database name. The default name is
Tempchksum*.edb.
 /e Use this switch if you do not want to perform a checksum procedure on the database
file.
 /i Use this switch if you do not want to perform a checksum procedure on the streaming
file.
 /o Use this switch to suppress the Microsoft logo.
To use Eseutil to checksum only the .EDB or .STM file

1. Click Start, and then click Run.
45
2. In the Open box, type cmd, and then click OK
3. Switch to the C:\Program Files\ExchSrvr\Bin folder, type one of the following

commands (as appropriate for your situation), and then press Enter:
 To check the integrity of the public information store database:

ESEUTIL /K "c:\program files\exchsrvr\mdbdata\pub1.stm"
 To check the integrity of the private information store database:

ESEUTIL /K "c:\program files\exchsrvr\mdbdata\priv1.stm"
If you want to save time by checksumming only the files in question, you can use the /E
(ignore EDB) or /I (ignore stm) switches. If you use the /E switch, the checksum table for the
streaming database is read from the edb file, but no other edb file pages are checksummed.
Using the .stm file name in checksum mode will checksum only the first two header pages of
the streaming database. For example:
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)
Note You cannot checksum the whole streaming file unless the database files are in a Clean
Shutdown state. This is because the table storing the checksums in the streaming file is in the
edb file. If the database is not in Clean Shutdown state, you cannot know for sure that this
table is completely up to date and valid.
Command line syntax

The following is the command line reference that can be obtained by running eseutil /? and
then K from the Exchsrvr\bin folder:
CHECKSUM:
DESCRIPTION: Verifies the checksums of a database, streaming file,
checkpoint file, or log file (or set of log files).
SYNTAX: ESEUTIL /k <file name> [options]
PARAMETERS: <file name> - file name to verify
/t<db> - set temp. database name (default: TEMPCHKSUM*.EDB)
/p<x> - add artificial 1 second pause once every x I/O's
(default: no pause)
/e - don't checksum database file
/i - don't checksum streaming file
/o - suppress logo
NOTES: 1) This operation does not run database recovery. If
the database file (.edb) is in a "Dirty Shutdown"
state it is not possible to verify checksums in the
46
streaming file (.stm).

2) If the file is not a database file, the options are
ignored.
3) If the file is a streaming file, only the header is
verified and not the data pages.
4) The pause (/p) option is provided as a throttling
mechanism. It only applies when verifying checksums
of a database file.

Eseutil /Y Copy File Mode

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.
Note:
Since copy file mode does not accept wildcard file specifications, you must fully
specify a file name and copy one file at a time.
Depending on disk and network conditions, copy file mode may be able to copy a file up to 20
percent faster than a typical copy. It can also handle copying of very large files that previous
versions of Microsoft® Windows 2000 Service Pack 2 (SP2) would not copy.
For more information about how to run Eseutil in copy file mode, see How to Run Eseutil /Y in
Copy File Mode.
47

How to Run Eseutil /Y in Copy File Mode

You can use the Eseutil /Y switch to copy a database, streaming file, or log file. For best
speed and stability, you should run Eseutil /Y from a local command prompt on the copy
destination server rather than from an intermediate location. For more information about
understanding the Eseutil copy file mode, see Eseutil /Y Copy File Mode.
Procedure
To run the Eseutil /Y command
1. Type the syntax (as in examples below) at the local command prompt in the
destinationfolder.
 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
Note:
Unlike the default copy command, you must use the /D switch when you
48
specify the destination location.
Command Line Syntax

"Y" from the Exchsrvr\bin folder:
COPY FILE:
DESCRIPTION: Copies a database, streaming file, or log file.
SYNTAX: ESEUTIL /y <source file> [options]
PARAMETERS: <source file> - name of file to copy
/d<file> - destination file (default: copy source file to current
directory)
/o - suppress logo
NOTES: 1) If performed on arbitrary files, this operation may fail at the
end of the file if its size is not sector-aligned.


Database Recovery Strategies

This section explains the structure of a database and discusses database recovery
strategies.
49
Understanding Database Structure

To understand how a database is structured you should understand page levels, Exchange
Store Engine (ESE) table levels, and application levels of a database. The following is a quick
description of each level:
Page level: The file contains an ordered series of pages (typically 4 kilobyte or a multiple of
4 kilobytes), with each page sharing a common organizational structure. Each page has page
header information and page data. The header information includes the checksums for the
page that enable Exchange to verify data integrity and to correct single-bit errors on the page.
ESE Table level: Groups of pages are owned by tables that are managed by the ESE
database engine. A typical Exchange database contains thousands of individual tables.
Application level: ESE is a general purpose database that can be used by different
applications. For example, both Exchange and Active Directory directory service use ESE.
The ESE database engine stores information in its tables as directed by a particular
application. ESE itself does not understand the application-defined relationships between
tables or the meaning of the data stored in each table.
Understanding Database Recovery Strategies

The most basic strategy for recovering from database file damage is to restore a known good
copy of the database from backup and to roll the database forward using subsequently
generated transaction log files. To use this strategy, the following three assumptions must
apply:
 You have a good backup of the database.
 All transaction log files generated since the backup are available and undamaged.
 The problem in the database is not caused by a logical corruption or unintended deletion.
For example, if a virus scanner was to corrupt messages or delete them, then the
corruptions and deletions would be part of the transaction log record and would be
replayed into the database after restoration from backup.
Other database recovery strategies are described below.
Move Mailboxes
When you move an Exchange mailbox to a different database, the contents of the mailbox
are processed by the Exchange Information Store just as when they were created. Items that
have been damaged will be skipped. Therefore, moving all mailboxes to a new database is
an excellent strategy for removing damaged items while at the same time maximizing the
amount of salvaged user content.
50
After a mailbox has been moved, Outlook client profiles will be automatically updated to point
clients to the new database or server. For this to occur, the previous server must remain
online with its Information Store service that is running until after all clients have logged on
one time and have been redirected. If the previous server is not kept online, then Outlook
client profiles must be updated manually or through scripts.
Previous offline or cached mode client files will continue to work after a mailbox has been
moved. Client rule functionality is also preserved when a mailbox is moved.
Moving a mailbox has the same effect on the destination server as redelivering all the items
in the mailbox at one time. Therefore, if you are moving many mailboxes, it is best to do the
operation at off-peak times, and to provide clients information in advance about when the
move will occur and about how to receive help if they experience problems logging on after
the move.
Moving many mailboxes will cause a larger than ordinary number of database transaction log
files to be generated for the destination database. You should closely monitor transaction log
disk space on the destination server during a bulk mailbox move operation. If you are close to
running out of transaction log disk space, you can run an online full or incremental backup to
clear the log files or enable circular logging before the move and then disable circular logging
right after the move.
Moving all mailboxes to a new database, and discarding the previous database, maximizes
the preservation of salvageable user content while at the same time minimizing database
downtime.
For information about how to move an Exchange database to another server or storage
group, see Moving an Exchange Mailbox Database to Another Server or Storage Group.
Repair the Database

Generally, you should repair a database only when it is infeasible to restore the database and
roll it forward. Frequently, repairing a database will take more time than restoring from
backup.
Note If the database is severely damaged, repair will take longer to run, and the probability
of a successful repair is less likely. If you run repair on an undamaged or only slightly
damaged database using typical enterprise-class server hardware, the process will usually
take about an hour for every 5 GB of data. If you are calculating repair times as part of
designing Service Level Agreements (SLAs), you should perform your own benchmarks on a
typical database running on hardware similar to that used for Exchange in your organization.
If a database has been severely damaged, repair times may increase by a factor of 10 or
more.
For more information about how to use Eseutil to repair a database, see Eseutil /P Repair
Mode.
51
Restore, Repair, and Merge

Restoring, repairing, and merging a database is frequently called a hybrid strategy. It can be
used when you have a good backup of the database, but do not have all the transaction logs
created after the backup.
In this case, you can restore the backup, and in parallel, repair the damaged copy of the
database in a Recovery Storage Group on the same server or on a laboratory server. You can
then use the Recovery Storage Group feature to mount both copies of the database
separately and merge data from the repaired database to the restored database.
Assuming the repair is successful, this strategy has a chance of recovering almost as much
data as if you had been able to use the transaction logs. For more information about several
hybrid strategies using Recovery Storage Groups, see the guide on Using Exchange Server
2003 Recovery Storage Groups (http://go.microsoft.com/fwlink/?LinkId=47589).

Reference for Common Eseutil Errors

This section covers common Extensible Storage Engine (ESE) errors encountered when
running Eseutil on your information store database files, transaction log files, and streaming
files.
52
Error Codes, Descriptions

The table below describes some of the common database errors encountered when running
Eseutil.
Error number JET Error Error Description
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.
53
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
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.
54
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.
55
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_errBadCheckpointSignat This error indicates that the

ure 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.
56
Error -537 (0xfffffde7) JET_errBadSLVSignature This error indicates that the

current .edb file and .stm file
do not match each other. An
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_errDatabaseStreamingFi For more information, see

leMismatch Error -537.
57
Error -543 (0xfffffde1) JET_errRequiredLogFilesMis This error indicates that log

sing 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.
58
Error -544 (0xfffffde0) JET_errSoftRecoveryOnBack This error indicates that in

upDatabase 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_errLogSequenceEndDat This error may accompany

abasesConsistent 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
article 830408, "Exchange
database stores remain
mounted although all
transaction logs that are
available to a storage group
have been used."
59
Error -549 (0xfffffddb) JET_errStreamingDataNotLo This error occurs when

gged 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.
60
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_errConsistentTimeMism This error is closely related to

atch error -1216
(JET_errAttachedDatabaseMi
smatch). 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."
61
Error -552 (0xfffffdd8) JET_errDatabasePatchFileMi This error can occur in

smatch versions of Exchange prior to
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_errAttachedDatabaseMi This error is closely related to

smatch error -551
(JET_errConsistentTimeMism
atch). 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
database after error -1216."
62
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
<database>.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
Standard Edition, see
article, 313704 "XADM:
Running an Integrity Check
on the Srs.EDB Database
Always Returns a
JET_errDatabaseCorrupted
Error Message."
63
Error -939586631 (Unknown Unknown Error This error occurs when you
try to run Eseutil /CC with an
Error, Unknown Error)
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 about these error codes, see
 Microsoft Knowledge Base article 266361, "Extensible Storage Engine 98 Error Codes 0
to -1048"
 Extensible Storage Engine Error Codes
For more information about understanding Extensible Storage Engine (ESE) file types, see
Extensible Storage Engine Files.

64
Copyright
The information contained in this document represents the current view of Microsoft
Corporation on the issues discussed as of the date of publication. Because Microsoft must
respond to changing market conditions, it should not be interpreted to be a commitment on
the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information
presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO
WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS
DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in or
introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express
written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you
any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted in examples herein are fictitious. No
association with any real company, organization, product, domain name, e-mail address,
logo, person, place, or event is intended or should be inferred.
© 2006 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, ActiveSync,
ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN, MSN,
Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile,
Windows NT, and Windows Server System are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.

Windows 2003 EseUtil

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Windows 2003 EseUtil

Încărcat de

Drepturi de autor:

Formate disponibile

Microsoft Exchange Server Database Utility

Published: December 12, 2006

Author: Exchange Server Documentation Team

Comments? Send feedback to exchdocs@microsoft.com.

Eseutil /D Defragmentation Mode...........................................................................................12

How to Run Eseutil /D (Defragmentation)...............................................................................15

Eseutil /P Repair Mode........................................................................................................... 17

How to Run Eseutil /P (Repair) in Different Scenarios............................................................20

Eseutil /C Restore Mode......................................................................................................... 23

How to Run Eseutil /C (Restore) in Different Scenarios.........................................................24

Eseutil /R Recovery Mode...................................................................................................... 28

How to Run Eseutil /R in Recovery Mode...............................................................................32

Eseutil /G Integrity Mode........................................................................................................ 36

How to Run Eseutil /G in Integrity Mode.................................................................................36

Eseutil /M File Dump Mode.................................................................................................... 39

How to Run Eseutil /M in File Dump Mode.............................................................................40

Eseutil /K Checksum Mode.................................................................................................... 44

How to Run Eseutil /K in Checksum Mode.............................................................................45

Eseutil /Y Copy File Mode...................................................................................................... 48

How to Run Eseutil /Y in Copy File Mode...............................................................................49

Database Recovery Strategies............................................................................................... 50

Exchange Server Database Utility Guide

Eseutil Mode Switch Description

Defragmentation /D Eseutil defragments the

For more information, see

 How to Run Eseutil /D

Repair /P Eseutil repairs corrupt

For more information, see

 Eseutil /P Repair Mode

 How to Run Eseutil /P

Eseutil Mode Switch Description

Restore /C Eseutil displays the

For more information, see

 Eseutil /C Restore Mode

 How to Run Eseutil /C

Recovery /R Eseutil replays transaction log

For more information, see

 Eseutil /R Recovery Mode

 How to Run Eseutil /R in

Integrity /G Eseutil verifies the page level

For more information, see

 Eseutil /G Integrity Mode

 How to Run Eseutil /G in

Eseutil Mode Switch Description

File Dump /M Eseutil displays headers of

For more information, see

 Eseutil /M File Dump

 How to Run Eseutil /M in

Checksum /K Eseutil verifies checksums on

For more information, see

 How to Run Eseutil /K in

Copy File /Y Eseutil performs a fast copy

For more information, see

 Eseutil /Y Copy File Mode

 How to Run Eseutil /Y in

For More Information

Eseutil /D Defragmentation Mode

How Does Eseutil Defrag Work?

When an offline defragmentation is performed, Exchange makes temporary copies of the

How Long Does it Take to Defragment a

By default, after defragmentation is completed, the temporary database automatically

When to Run Eseutil /D?

When not to Run Eseutil /D?

For More Information