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:
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.
First of, it's generally a good idea to see how much "white space" each mailbox database has. This can be done through EMS.
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)
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).
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...
Get-MailboxDatabase | Select Name,EdbFilePath
eseutil /d <databasefile>.edb
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.