In 2015, Paul Cunningham wrote about this topic. Time marches on, and new versions of Exchange Server mean that it’s good to review the current position up to and including Exchange 2019.
As time goes by, Exchange mailbox databases continue to grow. Mailboxes are added, users continue to send and receive email messages, the average message size increases, and users tend to keep all their email. At the same time, users delete messages, and Exchange administrators remove mailboxes when users leave the company. Unfortunately, Exchange mailbox databases don’t shrink.
Available New Mailbox Space
When individual items or complete mailboxes are removed, the space occupied by deleted items becomes available in the mailbox databases once their retention time lapses. This is called “available new mailbox space,” but is often referred to as “white space.” Over time, “available new mailbox space” can become significant in terms of overall database size.
To retrieve the available new mailbox space for a mailbox database, use the Get-MailboxDatabase cmdlet with the -Status option:
Get-MailboxDatabase -Status | Select-Object Name, DatabaseSize, AvailableNewMailboxSpace | Format-Table -AutoSize Name DatabaseSize AvailableNewMailboxSpace ---- ------------ ------------------------ DB01 553.9 GB (594,718,752,768 bytes) 381.4 MB (399,966,208 bytes) DB02 606.1 GB (650,821,763,072 bytes) 294.6 MB (308,903,936 bytes) DB03 508.1 GB (545,596,112,896 bytes) 4.519 GB (4,851,990,528 bytes) DB04 183.8 GB (197,300,060,160 bytes) 333.2 MB (349,339,648 bytes) DB05 787 GB (845,034,815,488 bytes) 146.1 MB (153,223,168 bytes)
Note. Besides the available new mailbox space, the -Status option can also return information regarding the following attributes:
- BackupInProgress – When a mailbox database is backed up, information regarding the backup is written in the header of the mailbox database. This information is only available offline using the ESEUTIL utility. When a backup is in progress, this information is available using this option.
- Mounted – Returns the status of a mailbox database, similar to the Get-MailboxDatabaseCopyStatus cmdlet.
- OnlineMaintenanceInProgress – Online maintenance is a background process that optimizes a mailbox database. It removes mailbox items and mailboxes that are past their retention, and it optimizes the available new mailbox space.
All three options return either FALSE or TRUE.
To get a more readable output that is also usable for reporting, I convert it to GB or MB, or both:
Get-MailboxDatabase -Status | Sort-Object name | Select-Object name,@{Name='DB Size (Mb)';Expression={$_.DatabaseSize.ToGb()}
},@{Name='Available New Mbx Space Mb)';Expression={$_.AvailableNewMailboxSpace.ToMb()}}
Name DB Size (Gb) Available New Mbx Space Mb)
---- ------------ ---------------------------
DB01 554 381
DB02 606 294
DB03 508 4627
DB04 184 333
DB05 787 146
Now you know the available space in the mailbox databases. In the list above, mailbox database DB03 can host a lot of new items before it grows.
Disk Full Scenarios
Exchange mailbox databases do not shrink automatically, i.e. they won’t get any smaller and return the available space to the operating system. The only way to reclaim space from a mailbox database is by creating a new mailbox database and moving all the mailboxes to the new mailbox database. Only the mailboxes will be moved to the new mailbox database, not the available new mailbox space. Suppose you have a 250 GB mailbox database, there is 200 GB of mailbox data in this mailbox database, and 50 GB available new mailbox space. Ather moving mailboxes to this new mailbox database, it will be 200 GB in size, and 50 GB will be returned to the operating system.
A common concern I hear a lot is about the Exchange Server standard edition, which can host 5 mailbox databases. When 5 mailbox databases are running, there’s no option to create a new mailbox database to reclaim the available new mailbox space.
There are a couple of options available in this situation:
- If you run virtualized Exchange servers, you can extend the disks to accommodate larger mailbox databases. You must, however, think about backup and restore times. Restoring large mailbox databases can take a long time.
- If you run an Exchange server in a Database Availability Group (DAG), you can remove one mailbox database copy, create a new mailbox database, and move all mailboxes to this new mailbox database and create a new copy.
- Upgrade to Exchange server Enterprise Edition (which supports up to 100 databases on a server), create a new mailbox database, and move mailboxes to the new mailbox database, assuming you have additional disks available.
- Offload mailboxes from the mailbox database you want to reclaim to Exchange Online. When this mailbox database is empty, remove it, create a new one, and redistribute some mailboxes to the mailbox database that you just created.
- If all other options are not feasible, you can take the mailbox database offline and use the ESEUTIL tool to perform an offline defragmentation. But this is a last resort, and you should make sure you know what you are doing. If you are in doubt, create a ticket at Microsoft Support. I have seen too many admins run into troubles because they didn’t understand in advance what to expect.
Moving Forward
All these options take some time and planning, and you must ask yourself how you ended up in this situation. My best guess would be a lack of monitoring, but I don’t want to judge your situation.
It’s natural for mailbox databases to grow over time, and if you don’t pay attention, your mailbox databases will expand and become too big. This can result in your server running out of disk space. You can check the amount of available new mailbox space to see if you have any ‘white space’ left inside a mailbox database, but the mailbox database will not shrink automatically.
As explained above, you have multiple options to overcome this issue. In the long run, it is better to have a proper monitoring solution so that you don’t run into this issue at all.
