SBS 2003 Database Consolidation

I have a client whose Exchange 2003 database is growing out of control.  They are currently at about 50 GB, which is a lot considering there are only 5 people in the office.  The issue is they are architects and need to email large files back and forth to clients.  They always copy other workers in the office and due to the letigious nature of the business they must keep ALL emails.  As you can imagine with multiple copies of the same large files floating around things got out of control.  

We've since implimented an archiving system which requires all users to move project related emails into public folders.  Once the projects are done the specific public folder is archived and removed from Exchange all together.

The issue is the scheduled online defrag of the database does not remove any whitespace, therefore despite massive reductions in mailbox size the overall database size remains the same.  I have tried an offline defrag of the private databases, but despite doing this the size of the database stayed the same.  Below is the command prompt I used:

c:\program files\exchsrvr\bin\eseutil /d d:\exchsrvr\mdbdata\priv1.edb /b c:\priv1_bak.edb

It created the backup on c: which was the original size and the "defragged" database is int he original location the exact same size.  With help from a guru I found event ID 1221 and discovered the whitespace was only 2 MB.  We adjusted the maintenance period and set the deleted mailbox save period to 0.  After waiting a couple hours event ID 1221 reported 17 GB free.  I ran the same command line again but got this error.

C:\Program Files\Exchsrvr\bin>eseutil /d d:\exchsrvr\mdbdata\priv1.edb /b c:\pri

Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating DEFRAGMENTATION mode...
            Database: d:\exchsrvr\mdbdata\priv1.edb
      Streaming File: d:\exchsrvr\mdbdata\priv1.STM
      Temp. Database: TEMPDFRG8656.EDB
Temp. Streaming File: TEMPDFRG8656.STM

                  Defragmentation Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100

Operation terminated with error -1014 (JET_errOutOfBuffers, Out of database page
 buffers) after 15210.828 seconds.

C:\Program Files\Exchsrvr\bin>
Who is Participating?
Glen KnightCommented:
infact if you look at your question the file that is being used is listed in that screen shot.

Because the eseutil crashed out it wouldn't have been deleted.
Glen KnightCommented:
How much disk space is there on the server, there should be around 130% of the size of the EDB file available, if there isn't move the file to another server and run eseutil on that server.

Also try increasing the size of the page file?
Lower your deletion retention to 0 days before online maintenance.  Then the event will show you the space you know should be there.  demazter is correct if you dont have enough space move the edb somewhere else and run the offline defrag.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Glen KnightCommented:
Already covered that in a different question absremote.
broadway69Author Commented:
Thanks guys, I did lower the retention rate before.  I use Tree File and discovered the temp edb and stm files were never deleted eating up about 30 GB of space?  Is that normal?  I did use the /b switch again and when i examine it appears there wasn't enough space for the backup on the C: drive because these temp files were not removed (two sets from me running eseutil two night in a row).  Now that I think I found the problem I'm concerned why those temp files were not deleted.
Glen KnightCommented:
It doesnt always delete them, i have seen this a lot.
Can often be because the process doesnt complete due to some reason or another.

Its always good to check.

At least you know what the problem is, glad i was able to help you again.

eseutil does not automatically delete the files it was creating the new database on when it crashes.

If they are the temporary files and NOT the priv1/pub1 .edb/.stm files, you can safely delete them. If Exchange is running, you cannot delete the database files anyway, as they will have file locks on them preventing them being deleted.

You said earlier in your question:

>>  As you can imagine with multiple copies of the same large files floating around things got out of control.  

Exchange 2003 uses Single Instance Storage (SIS) for all emails - including attachments - so if messages are copied in to co-workers, only one copy of that message is ever stored in the database.

It is a good idea to not use Exchange for long-term storage, so I like the sound of you archiving the data out of Exchange once you're done. Exchange is a collaboration tool, not a long-term storage tool -- many people seem to forget that!

broadway69Author Commented:
I attached a gif with all the temp*.* files I found in the c:\program files\exchsrvr\bin folder.  I think I know the answer to my questions (whether or not I can just delete them) but wanted to be 100% before I did!

Glen KnightCommented:
They can be removed they are simply the temporary defrag files.
If you are not sure then move them somewhere else that way if something goes wrong you can move them back but I doubt it will.

Besides if they are in use you won't be able to move/delete them.

Yes, you can safely delete those files.

broadway69Author Commented:
Thanks guys
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.