Lucid8 created this article as a courtesy and will not provide further support or guidance unless you have engaged a team member for paid Professional Services for Microsoft Exchange.  All information in this article is provided on an "AS IS" basis with no warranties, guarantees of completeness, accuracy, usefulness or timeliness, and as such any action you take thereafter, are done so at your own risk.  

NOTE: If you would like assistance in regards to your Exchange Database .EDB files, for self-service check out DigiScope or engage one of our experts for paid  Professional Services for Microsoft Exchange  assistance.

ESEUTIL /D for Defragmention of Microsoft Exchange Database (EDB)

Exchange databases (.EDB files) grow in size as data is added. However, when data is deleted/removed from a mailbox, or if an entire mailbox is deleted the physical size of the Exchange Database (.EDB file) will not automatically shrink.

Defragmentation is a process in which the database is rebuilt to make it as contiguous as possible and thereby reducing its size while improving its performance and reading speed. For example, if you have a 200Gb database file and delete 60GB of items from mailboxes the .EDB file will remain at 200Gb in size. However, the database itself (once the deleted retention setting has been met) will have 60Gb of “Available Free Space” in it, i.e. space available for new data to be overwritten without growing the size of the .EDB file.

The options to reclaim the physical space are to either:

  • Create a new mailbox database, move all the mailboxes to the new database and then delete or dial tone the original database (.EDB file).
  • Perform an offline defragmentation to shrink the existing database (.EDB file)


Both options have pros and cons. An offline defrag requires an outage for all users on that database, but may be more convenient for your organization depending on the situation. That said, mailbox migration has fewer risks, &  is (usually) less disruptive as a whole. Keep in mind moving mailboxes will generate a lot of transaction logs, hence more i/o and disk usage, so it may impact users and take longer (i.e. several days to migrate all the mailboxes) as opposed to just one outage for a defrag.

Determining Free Space within an Exchange Database

To determine how much free space is available within an Exchange database .EDB file, take the following actions:

  • Launch the Exchange Management Console
  • Use one of the cmdlets below:

DISPLAY INFO FOR ALL DB'S on SERVER

Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace -auto

DISPLAY INFO FOR SPECIFIC DB on SERVER

Get-MailboxDatabase -Identity <dBname> -Status | ft name,databasesize,availablenewmailboxspace -auto


In this case, you can see that the Fabrikam-13 database size is 287.3 GB and it has 125.8 GB of free space. To regain that 125.8 GB, you need to use the ESEUTIL tool to perform the process of defragmentation.


Preparing to Defrag an Exchange Database

When planning a defrag It is important to remember that: 

  • A Defrag can only perform this task when the database is dismounted. Which means users with mailboxes on that database will not be able to access their email during the defragmentation process
  • To perform the defrag you need a minimum of 110 % of the “estimated size of the new DB” in available/free disk space. This is because data is streamed from the old into the new DB, so for a period of time both the old and new files will exist

In this example, by using the calculation method below, we require about 180GB of free space: 

  • Current DB size of 287.3 – 125.8 of Available Free Space = Estimated New size of 161.5 GB
  • Its important to note that the "AvailableNewMailboxSpace" option displays how much space is available in the root tree of the database. However it does not factor in the free pages within mailbox tables, index tables, etc.  So it is not representative of all available white space within the database.  To obtain that you would run ESEUTIL /MH
  • New Estimated DB size of 161.5 x 1.1 = 177.65 GB of required free space to successfully defrag the database

Since I don't have 177.65 GB of free space on the same drive as the database, I will need to specify a temporary location that contains at least 180GB of free space when I run eseutil.  NOTE: This can be another local drive or a UNC path, however, when using a UNC path, the defrag will take longer due to network latency.

ATTENTION: Before taking action with ESEUTIL or any other utility against your Exchange Database .EDB file, make sure you have created a "MASTER Backup" of the .EDB and its associated (log & .chk) files which provides you with a rollback position in case something goes wrong wrong such as a power outage, hardware failure, etc. 

Dismount the database using the following cmdlet:

Dismount-Database –Identity <database_name>



Defrag the database using the the ESEUTIL tool cmdlet along with options of "/d" to defragment and /t for designating the temporary path 


Format:   ESEUTIL /D <database_name> /T <LOCAL_path> or <UNC_path>


Example: ESEUTIL /D Fabrikam-13 /T S:\Temp

Once the defragmentation is completed the screen will look similar to the image below



Upon completion the database is ready to be re-mounted using the commands listed below


Format:   Mount-Database –Identity <database_name>


Example: Mount-Database –Identity Fabrikam-13


Defragmentation Results

As you can see in the window below we exceeded expectations for the Estimated New size of 161.5 GB, with the actual new size of 142.9 GB. This is because as stated earlier the "AvailableNewMailboxSpace" option does not count the free pages within mailbox tables, index tables, etc., that are freed up during the defragmention.

FINAL ACTIONS: 

  • Run/Execute a new full Exchange Aware Backup of defragmented database
  • Delete the offline master backup copy of the EDB to free up disk space