Exchange mailbox size differences

The hard drive that has our exchange database is running out of space.  We have archived a lot of e-mails for a couple of users but the database stayed the same.
When on the users outlook and go to folder size for the user, the local data and server data are about 5 Gb less that what is shows on ESM.
Trying to figure out why the difference, and how to gain more space.  Will I have to run eseutil /d?
Who is Participating?
kevalaConnect With a Mentor Commented:
Once online maintenance runs, the space created from moving the mailboxes will be marked as "white" space, or free space for the system to write to. So to to answer your question, once the pages are marked as free, new emails will be written to them. The size of the database itself on disk will only shrink with the offline defrag.

There are a couple of ways to view the free space in the database that i know of:
1. When online maintenance completes, you'll see event ID 1221 in the application logs. This will tell you the amount of white space detected.
2. Take the database offline and run Eseutil /MS - This will give you (at the end of the outpage) the total number of pages that are availalble. You take this number and multiple it by 4 (each page is 4KB) and you have your total free space in Kilobytes.

The only way to lower the size of the database file itself is to run "eseutil /d x:\path to the databasename"

This requires 120% the size of the database free.
If you don't have this on the drive housing the database itself, you can redirect to another drive, for example, here, i'm redirecting to the Z drive:

eseutil /d  c:\program files\exchsrvr\mdbdata\priv1.edb /TZ:\tempdfrg.edb


The size difference you are noting between Outlook and Exchange System Manager is pretty normal. The process that runs to update the size in the ESM is very, very low priority, and can sometimes take days to fully update. The best way to determine the true size is by doing exactly what you did in Outlook at the root folder.


Archiving email (moving it out of the database into PST files, etc.), then running the defrag is the only way to reclaim actual disk space (by reducing the size of the database after moving data out)

Does this answer your questions?

like all database, data that is deleted is not remove from the database at once.

In Addition there are 2 special behaiviors in Exchange
a) Nothing is deletec until a backup is done. This means a backup that exchange know about. like ntbackup
b) deleted mails are deleted 30 days after the user deleted them

So do a backup (with ntbackup), restart the server and do a offline defrag with eseutil

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

By default deleted items retention is not set, so by default you do not have to do a backup and the reboot before you perform a defrag.
If deleted items retention is set for 30 days, then you have to wait 30 days even after deleting the items or lowering the retention.
The ONLY process that has to happen after deleting an item if the retention is not set, and you want to see it reflected in the event viewer is online maintenance.

If you don't have retention set on the mailbox stores, just delete the items, take a backup (as you should always do before any maintenance) then do the defrag.
newgentechnologiesAuthor Commented:
yea that is what I thought,. The .edb fie is 75 Gb and the .stm is 15 Gb, any predications on how long it could take?

That totally depends on the hardware....
I've seen them go as fast as 15 to 20 gigs per hour, and as slow as a few gigs per hour.
You'd really have to start the defrag, then watch the progress to gauge how long it will take...
If you have a store of 100gb then you must be on Enterprise edition, or an awful lot of white space in the store.
If you are on Enterprise edition then move all the mailboxes to a new store and drop the original. Much safer than an offline defrag, which is not risk free.

Oh and if you are short on space you might have a problem running an offline defrag. You need 110% of the size of the store in free space to complete it, and that is not even taking in to account the backup of the original files that you will keep.

Finally, what ESM shows is not the true picture of the size of the mailbox. It only shows the size of the mailbox in one of the databases. Therefore the size in Outlook will often be very different to the one shown in ESM.

newgentechnologiesAuthor Commented:
It is standard edition, this is why we are doing clean up.
If you backup the database to tape or another machine (if low on disk space), there really isn't much risk to it. If something goes wrong, just put the original database files back. It really is an effective tool if you're looking to recover free disk space.

In my opinion, more things can go wrong with moving all mailboxes to a different store then simply taking a store offline, defragging, and starting it back up. Example, login problems after the move, profile problems (like not getting updated), moves hanging or not completing successfully resulting in duplicate items, etc. I don't believe that moving mailboxes is necessarily safer at all from my decade of supporting the product, and it can take just as long, and you have to worry about users being logged in while doing the move.

As i mentioned in my first post, if you're running low on disk space to do the defrag, you can use the command i listed to set the defrag file in a different location (different server, etc.). It wil place the new database over there, move the data into it, rename the file and move it back.
kevala - your opinion about move mailbox being higher risk than offline defrag is at odds with the rest of the Exchange community and Microsoft themselves. Move Mailbox is completely risk free, I have never seen a problem with, certainly no duplicate items, profile issues etc. I have moved 1000s of mailboxes over the last four years and I can count on one hand the number of mailboxes I have had problems with and they have all been caused by factors outside of Exchange.

So you would prefer the total downtime of the server for the offline defrag rather than the zero downtime of a move mailbox.


Here's the bottom line, if you can afford downtime, do the defrag:
-NO Risk if you have a backup - If something goes wrong, simply restore the old copies
- If you don't have enough space on the current server, reference my previous post for the command

If you can have SOME downtime, but not as much, do the move mailbox.
- There IS downtime because Microsoft recommends users to NOT be logged in while doing the move
- There are several things that can go wrong, namely: Profiles not getting updated, duplicate mailboxes (can be caused by several things) incorrect settings or stamping by RUS if A.D. replication or network health is in question, etc.
- If something to this nature goes wrong with the moves, you'll be looking at restoring the database AND an authrestore of A.D. potentially, or recreating the mailboxes with the data exported/imported.

Also, you can search the Microsoft site for "move mailbox" to get a little bit of an idea of how many different kinds of problems have been seen.

There are clearly ups and downs with both options, and you can recover from both options if you have a backup of the databases. However, if something goes wrong with the defrag, it is in MOST cases much easier to recover from; as i've stated before, simply drop the copies back in place and mount up.

In any event, i wish you luck with this project and i will keep monitoring in case you ask any direct questions to me.

newgentechnologiesAuthor Commented:
We have moved a few mailboxes, and deleted a lot of e-mails.  Do any new e-mails just take up that space?  If so, is there a way to see the space available?
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.