I've heard a lot about Exchange Server mailbox database white space, but am unsure what to make of it. What exactly is it, how do I determine how much I have, and should I worry about it?
Database white space is the area within Exchange Server mailbox databases that has been reclaimed after an item or object -- such as a mailbox -- has been deleted.
The Exchange information store automatically reuses white space for new items/objects before expanding the physical size of the mailbox database .edb file.
Up till and including Exchange Server 2007, Exchange mailbox database white space was reclaimed as part of the online defragmentation maintenance process. Admins can review the amount of free white space in the database by locating Event ID 1221 in the application event log on the mailbox server.
In Exchange 2010, the process changed so that online defragmentation is constantly running. However, the white space online defrag summary Event ID is no longer posted to the application event log.
To check the amount of white space, admins can use one of these two options:
1. Use the Get-MailboxDatabase <DB Name> -Status | fl Name,Avail* command:
With that said, there's a common misconception regarding this command. While this is a quick and viable option, many believe that it returns a completely accurate overview of the amount of white space within the mailbox database, it does not.
The above command only tells admins the amount of space that's free within the database to create new mailboxes. The command returns the amount of space available in the root tree of the database; it does not factor in mailbox tables, indexes, etc.
2. To get a completely accurate representation of white space in
the mailbox database, admins should use the ESEUTIL /MS command:
Note: When using ESEUTIL /MS, you must dismount the target database while the process runs.
Don't worry too much about white space; Exchange does a good job managing it for you. However, if you begin running out of space on a mailbox disk and see that there's a large amount of white space within a particular database that resides on that disk, you should install a new set of disks (or provision a new LUN), create a new store and move the mailboxes over.
Note: Although it is an option, performing an offline defragmentation to physically shrink the database is an invasive process that results in downtime and rarely returns enough physical disk space to make the process worthwhile.
About the author
Andy Grogan is an Exchange MVP based in the U.K. He has worked in the IT industry for the last 14 years -- primarily with Microsoft, HP and IBM technologies. His main passion is Exchange Server, but he also specializes in Active Directory, SQL Server and storage solutions. Grogan currently works for a large council in West London as the networks and operations manager supporting 6,000 customers on more than 240 sites. Visit Andy's website at www.telnetport25.com/.
This was first published in December 2012