ESEUTIL is now the evil utility

ESEUTIL has a long history with Exchange. A command-line utility that has clung magnificently to the same interface since Exchange 4.0, ESEUTIL used to be one of the go-to utilities for any administrator. But that was in the bad old days of single databases, flaky disks, and wholesale software bugs, a toxic combination that endowed ESEUTIL with almost magical powers of restoring any Exchange server to rude good health if applied with care.

In today’s context, ESEUTIL can be compared to leeches. A good solution to specific problems when applied with good reason but not something that you’d use to cure more general ailments. Yet it amuses me how many people still think of ESEUTIL as something that should be used on a frequent basis, the colonic irrigation mechanism for the product.

A long time ago, when my hair wasn’t grey, an Exchange server boasted just one mailbox database that was a colossal single point of failure. The database was limited to 16 GB, a size that seemed enormous when 128 GB or 256 GB disks were deployed. But it was good enough when mailbox quotas of 50 MB were carefully assigned to users who received no more than a few messages a day, none of which came from marketing and therefore had no 10 MB attachments.

Life was easy. That is, until you realized that the Exchange database engine was a tad untidy in its habits. Sloppy, in fact, when it came to the management of unused pages within the database. Exchange just wasn’t very good at reusing pages freed by deleting unwanted messages and insisted on grabbing more and more space from the file system. The result was swollen databases.

Adding to the problem were the many ways that databases could suffer physical or logical corruption. Sometimes it was hardware bugs, with storage controllers being the usual culprit. Software bugs also came into their own and could cheerfully cause a problem. Event logs were cluttered with -1018, -1019, and -1022 errors, to name a few.

But Exchange administrators had an answer. Telling users that the server would be offline for a while, we charged ourselves with favorite beverages and impressed observers with the fluency in which we could remember and use the different command-line switches for the ISINTEG (deprecated in Exchange 2010) and ESEUTIL programs, both of which could take a very long time to run and provided every opportunity to get other work done while they ran.

ISINTEG only dealt with logical corruption inside the database. Things like counts being wrong. Not the kind of massive problems that ESEUTIL could handle as it fixed gaping holes that had opened up inside databases after pages suffered the indignity of a failed checksum. ESEUTIL could also put manners on a database and restore it to a svelte shape by returning space to the file system. In short, ESEUTIL was a real man’s utility (insert proper socially aware phrase here).

And so we spent hours running ESEUTIL /D to perform an offline defragmentation of a database or ESEUTIL /P (also called a "hard repair") to rescue a database from physical corruption. Both operations ran at 2-3/GB hour; both required exclusive access to the database; both required 110% free disk space of the database size to be available to build the new version of the database; and both required you to take a full backup before and then another afterward just in case. After all, ESEUTIL invalidated any transaction logs because running it to defragment or rebuild a database created a new database and no association existed between database and logs thereafter.

We were simple people and enjoyed ESEUTIL in those days. But, aside from using ESEUTIL/M to dump database headers from time to time, ESEUTIL’s worth has been steadily eroded since Microsoft shipped Exchange 2000 in 1999. Better code eliminated software bugs and improved the way that the Store reuses deleted pages, aided by automatic online defragmentation. Less white space is kept in today’s databases and the rapid drop in storage costs and growth in available space makes it totally unnecessary in 99% of the cases to ever consider performing an offline defragmentation. In any case, the always-connected mode that we operate in today means that users wouldn’t tolerate administrators taking databases offline for a bit of rebuilding. 

The introduction of the Database Availability Group (DAG) in Exchange 2010 put a knife through the heart of ESEUTIL. Multiple database copies and automatic fixes through single page patching has largely eradicated the scourge of -1018 and similar errors. Simply put, unless you’re talking to Microsoft Support and they come up with a very good reason to run ESEUTIL to rebuild a database, there is no need to use this program, no matter what you read on the Interweb.

More recently, Microsoft changed its support policy to force people to move all mailboxes from a repaired database after using ESEUTIL.  I think this is a good thing because the new database should be free of all the woes that might cause you to want to run ESEUTIL. In addition, Exchange is now so good at keeping service going to users while moving mailboxes that it should be an operation that is second nature to all.

Let's face it, you wouldn’t sign up for a colonic irrigation just because you read how wonderful someone says their bowel feels after the procedure. Why listen to people who want you to run ESEUTIL just because they think it’s a good idea?

Follow Tony @12Knocksinna