How To Check Database White Space In Exchange

From time to time we need to see how our Exchange databases are doing so that they are being managed proactively.  One aspect is tracking size and the utilization of each database.  At the simplest level we want to ensure that the database and transaction log LUNs do not run out of disk space.  That would be bad.

Sometimes we want to take a peek at the database, and check that the size of the database is within design expectations.  We can look at the amount of user data stored in the database, system usage for recoverable items in addition to looking at the size of the database on disk.  Some folks also want to see the blank space that is within a database.  This blank space is sometimes called:

  • Available Mailbox Space
  • White space
  • Free database pages
  • Free space


Historical Approach To Checking White Space

In ye olden days when Exchange admins went to work on horses (alright, iron horses), we would look for the venerable application event log entry 1221.  This event would tell us the amount of white space within the database.  This event was introduced in Exchange 5.5 SP1 back in August 1998.  That’s more than 15 years ago, eeek!!   

In those simple Exchange days we would have one Public Folder (pub.edb) and one Mailbox database (priv.edb) per server.  Standard Edition could have a database of up to 16GB, and Enterprise had the “unlimited” database.  This was before the advent of the .stm file so all content lived in the .edb file.  Event ID 1221 would then report on the white space contained within the database file.  Life was indeed simple and good! Additionally Exchange 5.5 SP1 also added a second enhancement for determining white space which was the ESEUTIL /MS switch to dump out the space consumed by tables in the database.  More on this later….


As mentioned in the KB, the free space that is reported by Event 1221 is a conservative estimate. If you perform offline defragmentation, you will recover at least the amount of space that is reported as free. All space in an Exchange database is owned either by the database root or by particular tables in the database. Event 1221 estimates free space by calculating the number of empty pages owned by the messages table, the attachments table, and the database root. Free pages that are owned by other tables in the database are not taken into account.

Things advanced, the dotcom bubble popped and with the advent of Exchange 2000 the streaming file was introduced.  The intent was to store native RFC content in the streaming file as the Internet was the future and content would be converted between the .stm and .edb as needed.  Event 1221 does not review this shiny streaming thingymabob, and did not report what free space may have been available within the .stm file.  For a trip down memory lane there is an excellent read in this document Determining the True Amount of Space in an Exchange Database

If ESEUTIL /D was executed against a database the .stm would have been defragmented in addition to the .edb by default.  Though this could be changed by specifying the /I switch.     Details on defragmenting databases are can be found in this KB.

Exchange 2007 dropped the .stm file and just like Atomic Kitten, the .edb became whole again.  Event 1221 was still with us and reporting on the database white space!

Then along came Exchange 2010, sans Event ID 1221….


Getting White Space In Exchange 2010

Exchange 2010 introduced numerous improvements to the Mailbox role.  These improvements included things like

  • Enhanced ESE physical store to improve performance
  • Larger 32 Kb ESE page size
  • Dumpster 2.0
  • No database level attachment table
  • Updated Online Maintenance routines


    As part of the changes to the mailbox role, the venerable event ID 1221 was removed, and output was added to Get-MailboxDatabase called AvailableNewMailboxSpace.  This data is returned when the –Status parameter is also specified to execute the more expensive work items.  We can see the difference below, note the second command has –Status added:

    AvailableNewMailboxSpace In Exchange 2010


    So NewAvailableMailboxSpace looks good?  Well not so much.  This parameter only looks at the root portion of the database.  This is clearly stated in the Exchange team blog post.  For reference the relevant text is shown below.

    How Can I Check White Space In Exchange 2010

    Remember we would come back to ESEUTIL /MS? 

    We need to use ESEUTIL /MS to get an accurate picture of white space in an Exchange 2010 database. 


    Running ESEUTIL /MS against a lab database shows the following:

    Using ESEUTIL /MS To Check White Space In Exchange 2010

    From this we can see the breakdown in the database structure and where space is being consumed.  Note that this can only be executed against a dismounted database, and you will receive the following error if running against an active mailbox:

    Operation terminated with error -1032 (JET_errFileAccessDenied, Cannot access file, the file is locked or in use)

    And if you are thinking that I’ll be sneaky and run it on a passive database copy in a DAG, then you will receive this error instead, after stopping the replication service else you will get the same error as listed above:

    Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was not shutdown cleanly. Recovery must first be run to properly complete database operations for the previous shutdown.)




    To get an accurate representation of the amount of white space in an Exchange 2010 database we need to use ESEUTIL /MS.    Note that the database must be dismounted, else you will receive JET errors and no data will be returned. 

    Dumping out the table information is a fairly quick operation, unless the verbose /V option is used and then the time taken will greatly increase. 


    How often do I expect this to be used?  Rarely and typically as part of troubleshooting.

    The days of online maintenance killing itself trying to defragment partially filled 4K pages of data to be on a single ESE page are gone.  The same goes for offline defragmentation.  We now live in a world where large mailboxes are the norm and any white space will be quickly re-used.  Also consider that many organisations are now running 24 * 7, and it is hard to justify the impact caused by taking a database offline. 

    Defragmenting databases to reclaim whitespace should be a rare event nowadays.  Exchange 2010/2013 are designed to use larger and cheaper storage which means you can get more storage capacity for the same price point.  Rather than defragmenting databases we should look to leverage the online mailbox move experience in Exchange 2010/2013 and simply move mailboxes to a new database and then discard the original one.  This is critical when we are discussing DAG replicated databases. 





    Comments (25)
    1. Charles Derber says:

      Frankly speaking I like the old way of checking white space via event ID 1221 🙂

    2. Hi Charles!

      Totally understandable, though I just wanted to make sure folks knew that the AvailableNewMailboxSpace was not a direct replacement for 1221



    3. Charles Derber says:

      Yea – with that few more statistics need to gather for precise white space.

      Good that you brought to notice – people will see, know and learn including me 🙂

    4. anonymouscommenter says:

      Nobody commented on the link to Atomic Kitten? They were awesome! I loved Whole Again.

    5. Glad you like the zany humour!  For more song related antics, take a peek at…/hyper-v-did-not-find-virtual-machine-to-import.aspx



    6. anonymouscommenter says:

      thats a pretty stupid way to have to do this now. I have 3 databases of 1.6TB in size each which I moved out a fair chunk of mailboxes into 3 new databases. Based on the fact the new databases are approximately 700GB each I can guess how much free space
      I have in the existing databases, but who in their right mind wants to dismount production databases impacting users in a 24×7 environment just to make sure I still have enough space.

    7. anonymouscommenter says:

      It is a very nice post. I like this post.I sell unlimited buy email database.

      –Edit RMILNE Please do not link out to sell items and services.

    8. anonymouscommenter says:

      You can use below script , it works for exchange 2007 & send the white space report in email

    9. Thanks Vikas – I see this is using the EventID 1221 information in this line

      $record = get-wmiobject -computer $Computername -class Win32_NTLogEvent
      -Filter “logfile = ‘application’ AND EventIdentifier = 1074136261 AND sourcename
      = ‘MSExchangeIS Mailbox Store'”| select -First $db.count

      That will work for E2007 and no-one should be running 2003 in ~6 weeks 🙂

      Thanks for sharing!


    10. anonymouscommenter says:

      It is a very nice post .we are like this post.

    11. anonymouscommenter says:

      What about public folders? All of the focus on improvements seems to have gone into the mailbox store. Microsoft would like people to forget that public folders exist but that’s just not the case in the real world.

    12. We have made html report using these Shell cmdlets & sent it to email

    13. anonymouscommenter says:

      Nicely written and clear article but, as Mark commented, AvailableNewMailboxSpace is pretty useless and taking a database offline just to find out how much free space you have is not practical. Moving all your mailboxes to a new database just to optimise
      your storage utilisation is also just plain silly.

      Is there no way to view actual free space in a mailbox database without taking it offline? Does Microsoft plan to provide a way of doing this going forward? Surely this is quite a glaring omission?

    14. anonymouscommenter says:

      Would doing a mailbox report and discovering the total usage of mailboxes in the database and subtracting that size from the .EDB file not be a more accurate view of the available whitespace in a DB?

    15. @John – yes and no.

      Yes you can tot this up, but the way space usage is calculated in Exchange 2010 and older is not perfect. This is why we say you may see ~40% size "growth" when a mailbox is moved to 2013. Its not growing, rather the size is now being calculated more accurately.

      So the net result is that your calculations will not reflect the underlying white space in the DB.


    16. @Wayne – I can’t comment on what may or may not added in this space (sorry for the pun), but when we look at the vision of Exchange with larger and larger mailboxes on 8TB JBOD disks then chasing down whitespace is probably not going to be a priority.
      Users just keep adding more and more to their mailboxes, and than means available space in the DB will be used once freed up.


    17. anonymouscommenter says:

      A couple of comments.

      Very nice article that explains a lot. Read this when you first wrote it and went back to it today after finding that ’13 seems to be ‘worse’ than ’10 at reporting

      Second comment is to argue against this point specifically: "but when we look at the vision of Exchange with larger and larger mailboxes on 8TB JBOD disks then chasing down whitespace is probably not going to be a priority. Users just keep adding more and more
      to their mailboxes, and than means available space in the DB will be used once freed up. "

      The continuous defragmentation process introduced with ’10 was designed to assist with reducing the IOPS footprint of Exchange databases and is targeted not at whitespace reclaimation, but rather contiguous pagination of the database. With the push to use JBOD,
      an unthinkable tenet for many organizations, it just wasn’t a priority from every article I’ve read and discussion I’ve had.

      Also, Exchange has simply always been crappy (highly euphemized) at re-using whitespace in the first place, which is at least partly due in ’10 & ’13 due to my point in the previous paragraph.

      Which leads to what I’m currently seeing today. A DB that is physically 508GB, with 131GB of "Available" space. Listed database size is 485GB (Yes, that’s 108GB of "it only looks at the root table"). Add to that, there is only 244GB of mailbox data in the DB.
      Yep, that’s more than half the space taken up by tables and real whitespace that won’t be re-utilized. Top it all off, there have only been mailboxes in it for about 60 days.

      Isn’t that swell?

    18. anonymouscommenter says:

      This post is very good post. I like this post.I hope that you next time same this post
      . you can buy XXX from us.
      Thank for your post

      EDIT RMILNE – Removed hyperlink.  Please do not add sales links to the comments.

    19. Thanks for providing a detailed scenario John!

      If you can – what is the output when you take the DB offline and do an ESEUTIL /MS please?


    20. How to clear this white space

    21. Let Exchange reclaim and re-use the whitespace.

      If you attempt an offline defrag, better read this


      1. In 2013/2016 are there better options for freespace? Does the ‘add all the mailboxes up’ method work?

        1. Hi Roger,

          Same story. We really should not be focussing on the whitespace in normal operations. Should you move a lot of mailboxes out of the database, then I’d move the remainder out to a different database and delete the original. Take a look at the blog post I have called Exchange offline defrag, oh my! That shows the grief offline defrag causes a DAG.


    22. anonymouscommenter says:

      The year 2015 is almost done, and 2016 is upon us! As in previous years , I thought it would be interesting

    Comments are closed.

    Skip to main content