Eseutil: Handle with Care

How to use this helpful, but potentially dangerous, tool

In a past career, I drove a forklift. However, this wasn't just any forklift—it was large enough to lift a 10-ton cargo pallet 20' off the ground and load that pallet into the side of a military transport aircraft. The forklift was a great labor saver, but I had to be careful while driving it because my carelessness could have caused a lot of damage. There's an Exchange equivalent to that big forklift: the useful, but dangerous, Eseutil tool. At times, no other tool will do, but if you're careless with Eseutil, you can easily lose some or all of your data.

Before I talk about Eseutil in detail, heed this warning: Eseutil isn't for casual use. To run Eseutil, you need to either dismount the target database (Microsoft Exchange 2000 Server) or shut down the Information Store (IS—Exchange Server 5.5). Thus, you risk not being able to restore the service when you want to. So, don't use Eseutil unless you need to run it and you understand what it does. To understand Eseutil, you need to know about the format of the Extensible Storage Engine (ESE) database in which Eseutil works, and you need to be familiar with Eseutil's many modes.

The ESE Database Structure
The ESE database consists of 4KB pages that are grouped in a variety of treelike structures. Pages can have links between them, and some tables contain representations of those links. Exchange stores the tables as pages. When a page becomes corrupt, you might lose a small amount of data (if the page contains the body of a mail message) or a lot of data (if the page is a crucial page, such as a page from the attachments table).

Eseutil isn't concerned about the mail data contained in an ESE database. Eseutil's job is to examine the individual pages, check them for correctness by comparing a computed checksum against a checksum stored in the page header, and verify that each page's data is consistent. To check the mail data itself in an ESE database, you would need to use the Isinteg utility. Understanding the difference between Eseutil and Isinteg is important. Running Eseutil is like having a structural engineer check your house's foundation. The engineer doesn't care what's inside the house. The engineer cares only whether the underlying structure is sound. Running Isinteg is like having an interior decorator come inside your house to check the way you've laid out your furniture. The decorator doesn't care about the house's foundation. The decorator cares only whether the rooms' layout and decor meet with his or her approval.

Another way to look at the difference between Eseutil and Isinteg is that Eseutil checks and fixes individual database tables, but only Isinteg can check and fix the links between tables. However, neither tool can address fundamental corruption, such as that caused by hardware failure. For information about the kinds of hardware-related errors that Eseutil can tell you about but can't fix, see the Microsoft article "XADM: Understanding and Analyzing -1018, -1019, and -1022 Exchange Database Errors" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q314917).

Eseutil's Many Modes
Eseutil is a useful tool because it can operate in many modes. However, each mode has limitations or caveats. For safety's sake, let's start by looking at the modes whose operations don't modify the database pages, then examine one mode that's typically unnecessary. Saving the best for last, let's end with a look at the most useful modes.

The safe modes. Assuming that you don't mind taking your database offline, the integrity mode, file dump mode, and checksum mode are generally safe to run. The integrity mode (i.e., the /g switch) tells Eseutil to check the integrity of the database file that you specify. You typically use this mode to verify the integrity of a database that you've reloaded from a backup or that you suspect is having problems. The integrity check includes examining the database signatures, examining the signatures on each page, and for Exchange 2000, making sure that the .edb file has a matching .stm file. Although Microsoft says that you can check the integrity of an Exchange 5.5 database with the Exchange 2000 version of Eseutil and vice versa, I recommend that you match the tool's version with that of Exchange. (And don't forget to match the versions of Exchange service packs that you're running as well; database schemas sometimes change in service packs.)

The file dump mode (i.e., the /m switch) lets you obtain detailed diagnostic information about a database. The most commonly used subswitch for the file dump mode is /mh. This subswitch provides a summary of the data contained in that file's database header. The data includes the date and time of the last incremental backup and last full backup.

Another important application for the file dump mode is finding out who owns a damaged page before you attempt a repair. For example, if the bad page resides in an attachment within a user's Deleted Items folder, running a full repair might not be worth the trouble. The Microsoft article "XADM: How to Determine Which Mailbox Owns a Particular Page in a Database" (http://support.microsoft.com/default.aspx?scid=kb;enus;q262196) describes how to use the file dump mode for this application.

The checksum mode (i.e., the /k switch) scans every database page to verify its checksum. This scan usually takes place when you perform an online backup with an Exchange-aware backup product. The scan typically produces an event-log message for every page whose computed and stored checksums don't match. With Eseutil's checksum mode, you can perform this scan on demand, which is particularly useful if you're not performing regular online backups. In Exchange 2000, you can selectively skip .edb or .stm files. Note that if the .edb file is inconsistent, Eseutil won't be able to check the .stm file for consistency.

The typically unnecessary mode. The mode I get the most questions about is the defragmentation mode (i.e., the /d switch). Using this mode to defragment your Exchange database might seem like a good way to recover significant amounts of disk space—but it isn't. Exchange already performs an online defragmentation as part of its nightly database maintenance tasks. Eseutil's offline defragmentation doesn't recover any space from the .edb file—it just rearranges the pages. (To confuse the issue, Exchange 2000 recovers .stm file space during an online defragmentation because the data is organized in contiguous chunks in the .stm file but is all over the place in the .edb file.)

When Exchange needs more space, it uses the free space inside the database file before using more space from the disk. Thus, you don't need to perform an offline defragmentation unless you desperately need the disk space or you've done something to dramatically reduce the amount of space the database uses, such as moving numerous mailboxes or putting many attachments into a Hierarchical Storage Management (HSM) system. For example, if you shrink your 30GB database down to 5GB of data, you can run an offline defragmentation to reclaim that 25GB of disk space. However, doing so is pointless if your IS will just end up growing back to its original size, unless you're trying to reduce the amount of time your backups take.

In those rare cases when performing an offline defragmentation is desirable, you must take the database offline, which means stopping the entire IS in Exchange 5.5. In Exchange 2000, you can just dismount the target database. When you use Eseutil with the /d switch, Eseutil copies the old database to a temporary file, page by page. When the defragmentation finishes, Eseutil replaces the old database with the new database. This approach is quite safe because Eseutil doesn't delete the original database until the copy operation successfully finishes.

Although the defragmentation mode is safe, it requires a lot of free disk space and time to run. The Microsoft article "XADM: How to Defragment with the Eseutil Utility (Eseutil.exe)" (http://support.microsoft.com/default.aspx?scid=kb;enus;q192185), states that you must have free disk space equal to 110 percent of the size of the database you're defragmenting. For example, to defragment a 60GB database, you need 66GB of free space on the server. Although Eseutil's /t switch lets you specify an alternative location (e.g., a network disk) for the temporary database file, be prepared for an extremely long wait—defragmentation is an I/O-intensive operation.

The most important modes. The modes I've talked about so far are helpful to have, but what makes Eseutil indispensable is its ability to fix a corrupt database. Eseutil has three modes—recovery, repair, and restore—that are useful in this context.

The recovery mode (i.e., the /r switch) tells Eseutil to play back any uncommitted transactions to bring the database to a consistent state. Although this mode makes the database consistent, it makes no attempt to repair any internal damage. Thus, if the database has any corrupt pages, Eseutil won't fix them.

For the recovery mode to work, you must have a good backup of your transaction logs. Note that the store performs a similar task when you start it: The store examines the checkpoint file to see which transaction logs haven't been committed yet, then plays through them. (Tip: Did you know that you can run Eseutil to recover an Exchange database on a computer that doesn't have Exchange installed? You need to copy eseutil.exe and a handful of DLLs to the target machine. The Microsoft article "XADM: How to Run Eseutil on a Computer Without Exchange Server" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q244525 explains in detail what to do.)

The repair mode (i.e., the /p switch) repairs corrupt pages but makes no attempt to put the database in a consistent state. Thus, for Exchange 5.5, I recommend that you don't run Eseutil with the /p switch until after you've run Eseutil with the /r switch. Exchange 2000 lets you use Eseutil with the /p /g switch combination. If you use this combination, Eseutil checks the database for consistency, then prompts you to begin the repair process.

Remember that in Exchange 2000, each .edb file has an associated .stm file. Thus, the repair mode has separate subswitches you can use if you don't have the .stm file for a particular database or if you have a pair of .stm and .edb files whose signatures don't match. See the Eseutil documentation or online Help for details about when and how to use these subswitches. To access the online Help, type the command

eseutil /?

then choose the g or r option.

Be aware that the repair mode might truncate or modify corrupt pages to fix the database. Because these actions might result in data loss, I recommend that you determine which pages you might lose when using this mode. See the Microsoft article "XADM: How to Determine Which Mailbox Owns a Particular Page in a Database" for step-by-step instructions about how to make this determination. In addition, you might want to make a copy of your database and run the repair mode on that copy. That way, you can restore the damaged database in case Eseutil makes the database worse. However, be aware that following the article's instructions might take a long time because you must make a separate pass to check the database.

Only the Exchange 2000 version of Eseutil offers the restore mode (i.e., the /c switch). When you restore an Exchange 5.5 database from an online backup and start the IS process, IS automatically replays any pending transactions and performs several recovery steps to get the database back to usable form. Exchange 2000's store doesn't perform these tasks in case you want to restore a database without immediately mounting it. The store performs these tasks only when you select the Last Backup Set check box in the Windows 2000 Backup utility. (Click Start Restore on the Restore tab to access this check box.) This new process means that you need to select that check box as you start to restore the last backup set for your Exchange server. If you forget, you can initiate the recovery manually by using Eseutil's /c switch with the c option (i.e., /cc). For information about how to use this switch, see the Microsoft article "XADM: The 'Last Backup Set' Check Box and Hard Recovery in Exchange 2000" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q232938).

Use but Use Wisely
Eseutil can be a great laborsaving tool when your Exchange database has problems, but using this tool can lead to disaster if you're careless. Keeping good backups and practicing recovery on a test server will help reduce the risk that you'll use the tool inappropriately. Understanding when to use Eseutil and what each mode does will help you keep your Exchange data where your users need it: mounted and on the server.