Eseutil: Handle with Care

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.

   Previous  [1]  2  Next