Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


Exchange database very large, user mailboxes small

Posted on 2009-04-02
Medium Priority
Last Modified: 2012-05-06
Hello all:
   I have an Exchange 2003 database that is 81 GB in size according to event ID 1216.  There is also 7 GB of free space, so the effectual size should be 74 GB.  When we add up the total space used by all mailboxes in System Manager, they add up to only about 35 GB.  Our retentions are set to 0 days (both for deleted items and mailboxes) and mailbox manager runs each night at 2:00 am.  Wait for next backup check box is unchecked.  So, why doesn't the database drop in size, and why don't we see more white space??  
   The server is 2003 standard, single domain, single Exchange server environment.  
Question by:jhuntii
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
  • 2
LVL 10

Assisted Solution

augwest earned 400 total points
ID: 24051568
this is because there are whitespaces in the edb file, these happen when stuff is deleted.

Deleting items does not reduce the size of your database

Only way to do that is by doing an offline defrag of the database however you would need the space to have 2 database which it appears you do not
LVL 10

Expert Comment

ID: 24051578
LVL 65

Expert Comment

ID: 24052724
Another person doing the add up the mailboxes and expecting the result to match.
It will not. Never will.

ESM does not show you the true size of the mailbox. It only shows you part of the database. Therefore adding up the sizes of the mailbox will not match the size of the files.

The reason for this is in http://support.microsoft.com/kb/828070/ 

"... a mailbox may appear to use only 250 MB of space in Exchange System Manager, but the total space that the mailbox uses may be 450 MB. This difference occurs because the 200 MB of space that the Priv.stm file uses does not appear in Exchange System Manager."

Therefore it is perfectly possible for the sizes in the store to be very different from what you expect.

An offline defrag is going to be a waste of time, because you only have 7gb of white space in the store.


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.


Author Comment

ID: 24053449
So would having the physical size at 81 GB cause us problems?  Or would this only happen if 81 less the white space was greater than 75 - at which point the store would dismount on a regular basis.  (That's how I understand it...)  So, even if we archived everyone's email to their local drive and had 0 email and 0 attachments in Inbox, sent, deleted, etc. the database size would still be 81 GB but with 81 GB of free space??  Would the backup still back up 81 GB of blank space??
Would the physical size being greater than 75 GB cause slow downs for users in Outlook???  We've seen some severe slow downs over the past few weeks and we're trying to fix it.  We do have plenty of disk space on external drives.
Does priv1.stm contain the attachments?  We have a lot of attachments.  Priv1.edb is 27.2 GB, Priv.stm is 59.6 GB.  

Author Comment

ID: 24053488
And, I get about 20 or so .IFS files per day on the MDBDATA folder.  What are these for?  Do I need them or can get rid of them??  -Thanks.
LVL 65

Accepted Solution

Mestha earned 1600 total points
ID: 24053719
The space is logical - so a physical store of 80gb is not a problem if you have more than 5gb of white space in the store. The size of the store would have no impact on the users in Outlook, unless your storage was badly configured. I have built and maintained servers with stores over 250gb in size and they were fine - because the storage was configured correctly.
However you are correct on the behaviour of the database if you removed all of the content. The simple rule is that the Exchange database never shrinks in its physical size.

I am in the middle of a blog posting on this subject, so I have some text to hand.

The EDB file should be thought of as the MAPI database and will consist mainly of internal email.
The STM file should be thought of as the SMTP database and will consist mainly of external email.

What tends to happen when there is a data base purge is that internal email is deleted, but more external email arrives, so there is a mismatch.
Do you receive lots of attachments from external senders?

As for the IFS files, do not delete them.


Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article will help to fix the below error for MS Exchange server 2010 I. Out Of office not working II. Certificate error "name on the security certificate is invalid or does not match the name of the site" III. Make Internal URLs and External…
As much as Microsoft wants to kill off PST file support, just as they tried to do with public folders, there are still times when it is useful or downright necessary to export Exchange mailboxes to PST files. Thankfully, it is still possible to e…
In this video we show how to create an Address List in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Organization >> Ad…
This video demonstrates how to sync Microsoft Exchange Public Folders with smartphones using CodeTwo Exchange Sync and Exchange ActiveSync. To learn more about CodeTwo Exchange Sync and download the free trial, go to: http://www.codetwo.com/excha…
Suggested Courses

618 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question