Sunday, November 22, 2015

Exchange 2010 - ESEUTIL - ISINTEG - New-MailboxRepairRequest

For several generations of Exchange, we could verify the health of the information store with a combination of the tools known as ESEUTIL and ISINTEG.

ESEUTIL still exists - but with very limited value. The reader will see how limited in the lines below. It can even de dangerous.

ISINTEG, on the other hand, is no longer an option since Exchange 2010 SP1 and has been replaced by the New-MailboxRepairRequest cmdlet.

I'll present both of these tools successively in the lines below.

With words of warning...


ESEUTIL is able to perform various operations on a dismounted Exchange mailbox database. Here is the list:




Defragmentation:  ESEUTIL /d <database name> [options]
Recovery:  ESEUTIL /r <logfile base name> [options]
Integrity:  ESEUTIL /g <database name> [options]
Checksum:  ESEUTIL /k <file name> [options]
Repair:  ESEUTIL /p <database name> [options]
File Dump:  ESEUTIL /m[mode-modifier] <filename>
Copy File:  ESEUTIL /y <source file> [options]
Restore:  ESEUTIL /c[mode-modifier] <path name> [options]

Exchange performs "online" defragmentation of the mailbox databases automatically as a background process. Online defragmentation, however, does not recuperate what is known as "white space". This is free space resulting from (for example) the deletion of a former employee's mailbox. Exchange can use this free space but Exchange does not reduce the size of the mailbox database on disk. If we have a 10 GB database and the former employee was using 5 GB of this space, the size of the database remains 10 GB on disk (even though there are now 5 GB available inside the database). In other words, the size of the database (as a file) does not shrink when we delete (internal) content.

Quite often, on the Exchange TechNet forums, someone will ask about the ESEUTIL /d option because they want to reduce the size of the Exchange database in the file system.

On this subject, we need to keep a number of things in mind.

ESEUTIL /d performs an "offline defragmentation" of the Exhange mailbox database. The mailbox database must be dismounted ("offline") and mailboxes will not be available. Downtime must be scheduled.

Offline defragmentation requires additional free disk space, roughly equivalent to the size of the database being defragmented.

Indeed, the defragmentation of an Exchange mailbox database is not like the defragmentation of a hard drive volume.

When we defragment an Exchange database, we create, in fact, a new database and copy the content of the old database into the new database. Therefore, if we have a 100GB mailbox database, we need at least 100GB of free space somewhere to defragment.

The preferred option is simply to move mailboxes to a new database.

Moreover, if we have Exchagne 2010 (or above) and if we implement a DAG (Database Availability Group) we must NOT perform an offline defragmentation of any mailbox databases:

Offline Defrag And DAG Databases, Oh My!

Should You Defrag Exchange Server Mailbox Databases?

Concerning the ESEUTIL /P and /R options, I will simply note that while they might be useful last resort options, there is a risk of data loss. If ESEUTIL cannot find all the log files, it will skip them and the associated data will be lost. I have often seen the recommendation that one consult Microsoft before executing these commands.

So the value of ESEUTIL has greatly diminished since Exchange 2010. For some Exchange experts, it is even considered... "evil":

ESEUTIL is now the evil utility

What about ESEUTIL /g ?

We can use it but it works only on dismounted databases. This means downtime - potentially a lot of downtime if the database is very large. Some would argue that, if we are having problems with the database, we should just move mailboxes to another database:

Using eseutil in a DAG - Which databases do you scan?

Otherwise, ESEUTIL /G is a read-only operation and should be safe for the database.

Note: yes, these commands are case insensitive. We can write "g" or "G".

Perhaps the only reason to use ESEUTIL would be to view information about the database which we can obtain with variations of the /M switch. 


Microsoft documentation explains that it can "detect and repair" mailbox corruption.

Create a Mailbox Repair Request

This command has one major advantage over ISINTEG (besides the fact that ISTINTEG is not even an option anymore): it can be run on mounted databases. In fact, it MUST be run against a mounted database or we will have an EventID 10051 error.

The command can be used on a single mailbox or an entire mailbox database. Even so, it runs against a single mailbox at a time so only the mailbox being checked will be affected. The documentation mentions access being "disrupted".

We can detect four types of problems using one, all, or a combination of the following values for the parameter "CorruptionType":

- SearchFolder
- AggregateCounts
- ProvisionedFolder
- FolderView

Please see the following TechNet article for more details:

Here are some examples of the various uses of the command...

This command detects all forms of corruption in the mailbox of user Alex Heyne: 

New-MailboxRepairRequest -Mailbox Alex.Heyne -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,FolderView -DetectOnly

We must list all the tests we want to perform. If we only want to perform one type of test, we simply do not list the others:

New-MailboxRepairRequest -Mailbox Alex.Heyne -CorruptionType ProvisionedFolder -DetectOnly

If we want to repair the corruption, we omit the -DetectOnly parameter:

New-MailboxRepairRequest -Mailbox Alex.Heyne -CorruptionType ProvisionedFolder

If we want to check (and repair) an entire mailbox database (for all forms of corruption), we use this command:

New-MailboxRepairRequest -Database DB1 -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,FolderView

How can we view the status of the check?

For Exchange 2010, there is no Get-MailboxRepairRequest cmdlet allowing us to view what percent of the operation is complete.

Note: this command does exist in Exchange 2016 however:


We have to examine the Event Viewer logs, in particular the Event ID 10047 and 10048. These entries indicate that the check started and then completed successfully.

Of course, in case of corruption there would be another Event ID in the Event Viewer. For a list of possible entries, please consult this link:

View Mailbox Repair Request Entries in Event Viewer

We should also note that in the case of a mailbox, the entry in the Event Viewer does not refer to the mailbox scanned for corruption by its name but rather by a GUID called "Exchange GUID".

We can find the ExchangeGUID of a mailbox with this command:

[PS] C:\>Get-Mailbox Alex.Heyne | fl *ExchangeGUID*

ExchangeGuid : 7e51bb21-5100-4bbd-a493-4654eb24dcfd

No comments:

Post a Comment