Exchange mailbox database files (EDB-files) grow in size as the data within them grows. But when data is removed, their file sizes will not shrink back. Instead, the file will contain "white space", which will be re-used if additional space is needed again.

Older versions of Exchange (2007 and earlier) did (limited) automatic space reclamation as part of their online database maintenance routines. Starting from Exchange 2010, these maintenance routines have changed and space reclamation no longer occurs. It is up to the Exchange administrator to perform space reclamation if the need arises.

There are two viable methods for reclaiming disk space, each having their pros and cons:

• Create a new mailbox database and perform an online migration of all mailboxes of the old database to the new one.
  The resulting mailbox database will only contain the actual used space as the mailboxes are being migrated.
  This method can be done online, without much disruption to services, and is often a more safe approach, but it requires the overhead of creating a new mailbox database and migrating all mailboxes from one database to another. Additionally, this method will generate excessive transaction logs and require more space and vigilance on part of the system administrator.
  Moreover, you need additional free disk space, equal to the sum of all mailboxes to be migrated, and additional disk space to accomodate for the extra growth of transaction log files.
• Perform an offline defrag of the existing database, shrinking the database file in the process.
  As the name says, the database will have to be taken offline and then use eseutil to perform an offline defragmentation of the database file. This results in the database being cleared of all white space and the mailbox data being compacted, similar to a file system defrag.
  This method is more disruptive, as users with a mailbox on the affected database will not be able to access their mail as long as the mailbox database is dismounted. However, the process is faster than migrating mailboxes to a new database and has less overhead on the transaction logs. An offline defrag is not as safe as a mailbox migration to a new database, but is still viable as eseutil provides an option to keep the original database file intact.
  An offline defrag requires additional free disk space to accomodate for the temporary database file that's being created during the defrag. While in theory, this can be as large as the original database file, it usually grows up to the sum of the actual sizes of all mailboxes in the database, plus some overhead. If you do not have enough space on the disk holding the database files, you could also place the temporary files on another drive or even on another server through an UNC-path.

Which method is best depends solely upon the situation and preference of yourself. Weighing the pros and cons and then making an informed decision is always the best thing to do.

Determining free space in mailbox databases

First of, it's generally a good idea to see how much "white space" each mailbox database has. This can be done through EMS.

1. Log on to the Exchange mailbox server through EMS.
2. Run the following cmdlet:

   Get-MailboxDatabase -Status | FT Name,DatabaseSize,AvailableNewMailboxSpace -Auto

This will generate a list of all mailbox databases on the server, showing its name, the current size and the available new mailbox space, which is essentially the "white space" in a database. In essence, this shows how much space that can be reclaimed for each database, and should help you in choosing the method of space reclamation:

Name       DatabaseSize                     AvailableNewMailboxSpace
----       ------------                     ------------------------
EXCH10DB04 72.49 GB (77,838,123,008 bytes)  127.3 MB (133,496,832 bytes)
EXCH10DB02 453.1 GB (486,550,339,584 bytes) 127.6 GB (136,995,536,896 bytes)
EXCH10DB03 409.5 GB (439,707,303,936 bytes) 120.5 GB (129,396,211,712 bytes)
EXCH10DB01 348.9 GB (374,613,278,720 bytes) 138.7 GB (148,929,183,744 bytes)

Reclaiming disk space

I won't be going into too much detail on the method of migrating the mailboxes to a new database as this should be a fairly straight-forward procedure. In short, you'll create a new (empty) mailbox database, and then start migrating all the mailboxes from the old mailbox database (the one that is supposed to get its "white space" reclaimed).

Offline defrag of a mailbox database

An offline defrag can only be performed when the database is dismounted. This means that users with a mailbox on that database will not be able to access their mail as long as the database is dismounted. Other mailbox databases can remain mounted, allowing users with mailboxes in those to continue working.

Also, you'll need additional free space available to perform an offline defrag. In theory, this can be up to 110% of the predicted file size after a defrag. This usually boils down to the sum of all the actual mailbox sizes + 10%. You can quickly calculate this by using the numbers you got from the cmdlet you should have run before:

If you do not have enough disk space, you could also refer to another drive or even another server through an UNC-path. Be aware that if you need to use an UNC-path, this probably will significantly affect performance.

I also recommend verifying your backup to have a way back if the offline defrag fails for some reason. While eseutil is robust, it's still a good idea to have some backup plan in case things go wrong. In a live environment, you do not want to tempt fate...

1. Log on to the Exchange mailbox server using EMS.
2. Dismount the database you wish to perform the offline defrag on. Don't forget to inform your users.

   Dismount-Database <database-name>

3. cd to the folder where the database file (EDB-file) is. If you do not know where it is, you can retrieve the location with this cmdlet:

   Get-MailboxDatabase | Select Name,EdbFilePath

   This outputs a list of all mailbox databases along with the physical location of the EDB-file.
4. Start the offline defrag process:

   eseutil /d <databasefile>.edb

5. When the process completes, mount the database again:

   Mount-Database <database-name>

If you re-run the cmdlet to get the "white space" in a mailbox database, you'll notice DatabaseSize has decreased and that the AvailableNewMailboxSpace has been reduced to almost zero.