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/.
Dig deeper on Microsoft Exchange Server Database Management
Related Q&A from Andy Grogan, Contributor
With hosted Exchange email deployment chatter increasing daily, it's crucial to separate fact from fiction when it comes to security and reliability.continue reading
An Office 365 outage may be widespread or unique to your deployment. Discover how to find out, as well as the best ways to prepare your organization.continue reading
A coexistence period is an important part of any Exchange Server migration -- but why? Our expert explains.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.