exchange 2003 offline Defrag

Our Exch DB currently over 75GB kept dismounting every other day or so.  I had people delete emails (empty the deleted items) and archive a bunch of emails (Approximately 20-25 GB worth).  
original priv1.edb file is 55GB and priv1.stm file is 27GB.
My action plan   (I had to stop after #4 because the size of the tempdfg.edb only reduced by 2gb and the stm file reduced by 2 gb as well----I was expecting it to reduce between 20 and 25 GB).    What did i miss?  see below for the action plan---

1.  copy ex_data and Ex_logs directory to F:\exchange.  (extra precaution)
2.  NTbackup on Z:\manual backup...\exchfull   (to minimize log files)
3.  dismount DB, stop exch services
4.  eseutil /d /p "e:\Ex_Data\priv1.edb" /t"F:\Exchange\tempdfg.edb".    (defrag didnt shrink as expected)......
5.  rename existing db and stm files
6.  copy from temp location to e:\ex_data  directory
7.  rename temp db to original name (priv1.edb and priv1.stm).  
Who is Participating?
Alan HardistyConnect With a Mentor Co-OwnerCommented:
There are two sizes that count with an Exchange Database:

1. Physical Size = .EDB plus .STM
2. Virtual Size = .EDB plus .STM minus "White Space"

To increase the White Space, you can reduce the Mailstore / Mailbox Retention period from the default of 30 days to 0 days and then that will mean the White Space increases by the amount you have recently purged, which should give you 20-25Gb of White Space, which will mean the database will stop dismounting.  Usually this will take effect overnight as the Online Maintenance interval is usually in the small hours.

If you want to reduce the Physical Size of the Database, lower the Mailbox / Mailstore Retention Period and then run eseutil /d to reduce the actual size of the .EDB and .STM files.  This is usually only necessary if you are running low on disk space though.

To identify the amount of Whitespace - look for Event ID 1221 in the Application Event Log (two of them daily - one for Public Folders and one for Private Mailstore).  This amount of space identified here is all you will reclaim if you run an offline defrag (eseutil /d), which seems to be what you are experiencing.

To reduce the retention periods, please read the following:

tastasConnect With a Mentor I.T.Commented:
Your Exchange server keep on dismounting because you have reached the maximum database size allowed for Exchange Server 2003.  What you are doing are correct, you need to do an offline defrag.  You are only getting a 4GB of storage back because there are compression in Exchange Databases.  The archiving of emails from your PST are not.

There are a few recommendation solutions.
1.  Do not keep non-existing employees on your Exchange Server. Archive them into a PST.
2.  Show archive policy.  Show people how to archive their emails; especially attachments
3.  Setup mailbox limit for each employees
4.  Lastly, purchase another Exchange Server since your company is growing and had reached the limit of your database size.
Alan HardistyCo-OwnerCommented:
@tastas - Do you have a link to an article that backs up your comments about compression in Exchange Databases?

Also, if you read the question, seven45 is clearly performing an offline defrag, so advising them to do exactly what they are already doing isn't exactly helpful.

Please stick to answering questions in zones where you have knowledge about the topic at hand.

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.

@alanhardisty:  see article and

I provided seven45 a few other recommendations such as archiving and removing non-existing employees, archive attachments and old items, and setup mailbox limits.  These are part of managing and reducing exchange server database size. I simply point out additional options.

You are also correct in advising him to  reduce the mailbox retention period.  I am not objecting to your suggestion.
Alan HardistyCo-OwnerCommented:
Thanks for those articles - unfortunately they don't explain your comment:

"You are only getting a 4GB of storage back because there are compression in Exchange Databases"

This is completely inaccurate.  The reason for only getting 4gb of space back is because the deleted items are being retained for the default retention period of 30 days (or whatever the store is set to), before being able to be overwritten and / or reclaimed by an offline defrag. So the reason is bsolutely nothing to do with compression.

Also, your recommended solutions don't address the question at hand and are not solutions - they are best practise methods for preventing the problem from happening in the first place.
There are compression within the Exchange Database which I was simply pointing out.  It is definately not 4GB vs 20GB ratio.  All the other space might well contribute to the retention period like you had suggested.  Either way, removing 20GB of emails would not decrease database size of 20GB.

Secondly, my suggestions are sound and accurate.  They might be items which seven45 might have been overlooked in cleaning up additional emails to decrease the database size.  You are NOT thinking outside of the BOX saying my suggestions are irrelevant.

Besides, this thread is not between us.  There is no need to question how I respond to seven45.  It's up to seven45 to determine the relevancy.

Seven45, how's reducing your Exchange Database coming?  If you can provide us with updates, we can continue to help you out.
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.