Reduce the size of Exchange 2013 mailboxes
Solved Email & Outlook
AJ
Andrew Jackson
May 8, 2019
2 replies
7,680 views
Reviewed by moderators

Exchange 2013 database has grown huge and mailboxes are the reason. I want to genuinely reduce their size, not just raise quotas to hide the problem.

What actually shrinks mailboxes and reclaims the database space?

Accepted Answer
Verified by Edwin J. Hoffer, Email Systems Specialist ยท Reviewed May 2019

The honest goal, real reduction rather than hidden growth, runs in two parts: shrinking the mailboxes and then reclaiming the database space they freed, which are separate steps people conflate.

Shrinking the mailboxes: archiving is the primary lever, In-Place Archives with a retention policy moving mail older than your threshold out of primary mailboxes into archive storage, genuinely reducing the primary size while keeping mail accessible. Alongside it, retention policies that delete truly aged content where policy allows and user cleanup of the dumpster and the sent items attachment mass that dominates bloat. The mailbox size report, Get-MailboxStatistics sorted by TotalItemSize, tells you which mailboxes to target first, the usual few dominating.

The dumpster detail that surprises people: deleted items you cannot see still count, the Recoverable Items folder holding content for the deleted item retention period and mailboxes under litigation hold retaining everything regardless of user deletion. Reducing a held mailbox may need the hold reviewed with whoever owns the legal requirement, since the hold is doing its job by keeping the size up.

Reclaiming the database space, the conflated second step: mail leaving a mailbox creates whitespace inside the database file, which does not shrink on its own, the file staying its largest ever size with free space inside. Get-MailboxDatabase -Status shows AvailableNewMailboxSpace, the whitespace. Reclaiming the actual file size to disk requires either a database defragment, the offline eseutil /d that needs downtime and free space equal to the database, or the cleaner modern approach of creating a new database and moving mailboxes into it, which packs them fresh, then removing the old bloated database. The move approach avoids the offline defrag's risks and is the standard answer for a genuinely oversized 2013 database.

The arrangement that keeps it reduced: archiving running continuously so primaries never regrow, quotas by role so accumulation has a ceiling and the whitespace understood so nobody panics that the file stayed large after the mailboxes shrank, the two steps kept distinct in everyone's mind.

Archived aggressively first, then moved everything to a new database and dropped the old bloated one, which reclaimed 200GB to disk that whitespace was hiding. The two steps are distinct thing was exactly my confusion, I had been waiting for the file to shrink on its own for weeks. Litigation hold on two mailboxes explained why they would not budge.