Our company is running Exchange 2003 on Server 2003. Our primary exchange store file (priv1.edb) keeps growing and is now at over 45GB. If I add up the size of the mailboxes in that store I get less than 16GB. I ran an offline defrag but didn't regain even a single KB from the .edb file (the .stm file shrank from 8GB to 2GB). I've also looked up the size of the Recoverable Items using Performance and it seems insignificant (not sure if the display is in bytes or KB, either way it would not account for the discrepancy). How do I find out what is taking up all this space, and more importantly, how do I remove it?


Are you getting good online backups? My guess is that you're not, and as a result you're seeing delete items piling up instead of being cleaned up. That would be consistent with the lack of any decrease in size that you saw with the offline defragmentation.

You can force deleted item retention to delete items even if the Information Store hasn't had a good online backup, but I'd recommend fixing your backups first if that turns out to be the culprit. If you want to try it, untick the "Do not permanently delete mailboxes and items until the store has been backed up" on the "Limits" tab of the Mailbox Store's properties.

Let us know how it turns out.

  • Thanks, but I check that too. Online backups seem to be completing successfully and Exchange was never configured to care anyway (box not ticked). Any other thoughts? – Justin Driscoll Aug 28 '09 at 13:02

Look for Event ID 1221 in your Application Event Log. This will tell you how much free 'white space' is in your Exchange DB.

Also see:

Event ID 1221 reports less free space than should be the case

  • I looked up the event before I ran eseutil. Only found an event entry for the Public store, not the private one. I did run a full offline defrag anyway and as I said, recovered zero space from the private edb file. – Justin Driscoll Aug 27 '09 at 18:54

The best solution to strange database issues like this is to create a new, empty store and move mailboxes to it; this achieves the same effect as a full database defragmentation, allows you to check for database corruptions and doesn't create a prolonged downtime for your users.

  • The only issue with that is if using the standard edition you only get one store. – SpaceManSpiff Aug 31 '09 at 14:16
  • This will also break single instance storage for that database, and attachments will now be duplicated into the new DB. – DanBig Aug 31 '09 at 14:32
  • This appears to be true. I'm unable to create a new store to move the mailboxes to and upgrading is out of the question. – Justin Driscoll Aug 31 '09 at 14:40

An offline defrag should reduce your database size. Do you have public folders in the same database that are increasing the size? What is your deleted item retention period set to? Are you including the log size with your EDB file (if so, is it being backed up?)

These are just some things to check into. The most likely culprit is the retention period though.

  • Retention period (I'm looking at "Deletion settings" under "Limits" for the store) was set for 5 days, I've reduced it to 1 for the time being. Public store (pub1.edb) is only 100k. I'm not including the log size with the .edb, just the file itself is 45.5GB. I'm totally stumped. – Justin Driscoll Aug 27 '09 at 18:30

Some more steps you can take:

  • ESEUTIL /G. This will check for any trouble at the ESE storage level; if it finds any, then you'll need...
  • ESEUTIL /P. A damaged database comes in, a repaired one comes out.
  • ISINTEG. This fill fix any error at the Exchange store level, with special regard to logical inconsitencies; you need to run it after repairing a database with ESEUTIL, but you can also run it on its own if you suspect your database has any logical trouble; and I think you should be suspecting it, at this point.
  • Also, be aware that running ESEUTIL /p on a 45GB database could take as long as 9hrs. – DanBig Aug 31 '09 at 18:32
  • Yes, and you have to dismount the database in order to do that. He already tried ESUTIL /D, so I assumed he knows. – Massimo Aug 31 '09 at 20:47

How are you backing up? I'm wondering if your backup software isn't setting the correct flags for Exchange to run post backup maintenance.

What happens if you actually run an exchange-aware backup with NTBackup?


If the online maintenance isn't running (not seeing the event log is a sign it isn't) then there will be no space marked for deletion by the offline defrag.

Check that no backup is trying to run during the maintenance periods set. You may have to leave an extended period and disable backups on say a weekend to get a full runthrough if it hasn't happened before.

Once it gets the online maintenance completed, the event log will tell you how much space the offline one will recover.


Thanks to everyone for all your help. What I ended up doing was using exmerge to export each users data (after using auto-archive to bring them down below the 2GB limit, why doesn't exmerge use the newer unicode .psts?), creating a new private store and then using exmerge again to re-import the mailboxes. Unfortunately, this causes outlook to go into recovery mode for each user but at least it worked with a minimum of downtime.


Though becoming depreciated with Exchange 2010, you'll lose the disk-saving capacity of Single Instance Storage by extracting and importing mailboxes with ExMerge.

I tend to add date and folder filters when extracting with ExMerge. Don't forget to ignore Contacts, users get upset when half of them suddenly "go away" due to the export.. ;) Importing "just" the contacts back wasn't too bad, though..

Between the mailbox store teetering around 72G and whitespace inching less and less, I took charge and began exporting mail. Couldn't wait for the users to hit my 73G hedge limit. Now.. offline defrag. Good times!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.