Exchange 2010 User Mailbox Database Size

Hi experts I have read so many confusing things about this issue so I decided to post it here.    The file size of my user mailbox database is 153 Gig.     That seemed very high to me so I ran a report.    the total size of all my users mailboxes is 72 Gig.    So where is all that space and how do I recover this?

thanks in advance
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Hi Zoldy2000,

Is the 153GB the size of the EDB file as viewed in Windows Explorer?

What report did you run to get the 72GB answer?


This is normal.  Firstly Get-MailboxStatistics doesn't perfectly tally item sizes.  Second and more important there's likely white space in the database.  When data is deleted from the DB the file doesn't shrink, it just marks the pages as available.  You can check this with something like:

Get-MailboxDatabase <DBName> -Status | fl Identity,DatabaseSize,AvailableNewMailboxSpace

The latter of those properties is the white space.  If you subtract it from the database size you should get pretty close to what you tallied with Get-MailboxStatistics.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Mustafa L. McLinnSystems Engineer/Systems AdministratorCommented:
or you could try this
Get-MailboxDatabase "<DATABASENAME>" | Get-MailboxStatistics | Sort totalitemsize -desc | ft displayname, totalitemsize, itemcount

Open in new window

What you're looking for, I presume is either corrupted information or a public folder/external folder connections that make it inflated.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Jose Gabriel Ortega CastroCEOCommented:
Here you can have 2 items: EDB size and LOG sizes in GB.

With that information, if LOG >>> EDB you need to Enable Circular Login and then remove it (if you want).
Here's another script for that:

Also, you can truncate the logs by doing a windows backup.

So the 152Gb are  EDB file and Logs (since the exchange server was installed).

Zoldy2000Author Commented:
So this command did show that I have 66 GB available space.       Any way to recover this space?

Get-MailboxDatabase <DBName> -Status | fl Identity,DatabaseSize,AvailableNewMailboxSpace
Most would say create a new DB and move your current mailboxes to it.  This would avoid downtime that you would incur from running an offline defrag (eseutil /d, but check the help file).  Of course if you had the space to do that, maybe this wouldn't be an issue in the first place.  You may have other motives like shrinking backups.  

Maybe you can tell me why you're interested in shrinking the file?  It may help plot a better course.
Zoldy2000Author Commented:
The server we are running this on was running low on space so we invested in an archiving product but never reclaimed the space.     This would now explain why.
I know this is being closed, and I appreciate the points, but I'd point out that archiving products for Exchange don't have the same allure they used to.  Depending on the product, but they tend to be very complex internally.  There's a number of reasons for this, not the least of which is having to emulate MAPI properties in an SQL (or other) DB.  Another is access control especially after they reintroduce single instance storage, compression and other features.  In addition once the data is parted from Exchange additional search discovery elements come in to play.  Additional alternate backup/restore DR...  The interplay between these things creates a complex environment with varied introductory learning curves and a greater long term knowledge burden both from a product and institutional perspective.

That's not to say there's never a use case for this product category.  Notably MS e-discovery features have a less than stellar track record.  In industries (eg. financial, legal) where this is a serious concern Archive products can be appealing.  Many such products grew into this area because it's a natural extension of first being exposed to then alternatively storing the data plus the aforementioned additional search apparatus.   That said, in this case the product is no longer being purposed to address capacity or related performance concerns.  It can be used without parting data from Exchange, allowing the user a more seamless and native Outlook experience.  Again case specific but limiting the use scope also allows avoidance of usually problematic Outlook add-ins that might otherwise be needed to bridge the gap.

So absent the E-Discovery (or other extended concerns) what do you do about capacity?  Always tempered by specifics the usual answer is to expand.  MS has pursued larger mailbox capabilities for some years now.  Their reasoning is in depth and difficult to fully relay here, but one aspect is that rotating disk  storage constantly gets cheaper and more dense.  MS chose to optimize their DB engine across versions to be stored on basic commodity disks even 7200 RPM SATA drives.  In short and all things considered it's generally much cheaper to scale up & out than to buy additional software to manage what's become an almost obsolete concern.  Once you look at software costs, continuing operational expenses, risks, user acceptance issues etc... I'm a very tough sell on this type of product.  The truth is by the time you've even evaluated a product you've likely spent more in man hours than you would've resizing your implementation.

Sorry to go on and on, I hope that adds some color though.
Zoldy2000Author Commented:
It was my understanding even if storage was not an issue for us that having large exchange mailboxes such as 50 Gig or more was not practical or recommended so I assumed archiving was the "only" answer?
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.