Link to home
Start Free TrialLog in
Avatar of zachreisman
zachreisman

asked on

Remove Exchange 2003 Information Store

I have had a single Exchange 2003 Standard server running on Server 2003 R2 in a VM.  The mailboxes have grown rapidly and filled most of the drive.  I added a second exchange 2003 server and move all the user mailboxes to it.  The old exchange server is configured as a front end for OWA/OMA, however the information store is still the same size.  Can I decrease the size of that database safely?  Do I need to abandon that server entirely?
ASKER CERTIFIED SOLUTION
Avatar of Akhater
Akhater
Flag of Lebanon image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
You can safely delete the database if you are not use. Microsoft also recommend  on the front end server information store never keep.
to reduce the database to the actual size of the contents in it use eseutil

C:\program files\exchsrvr\bin> eseutil /d c:\progra~1\exchsrvr\mdbdata\priv1.edb

 The above command should do the job, for detailed switches check the link below.

http://support.microsoft.com/kb/192185 

I would recommend eseutil instead of deleting because an empty database don't do you any harm as long it doesn't consume unnecessary space

Take the database offline
Run eseutil
You can do this without any downtime as you don’t have any mailbox on the database

I don’t go for deleting as you can optimise first, Once the space is reduced just dismount it for 5-10 day till you are sure that everything is normal and if our want then go ahead and delete it…

Hope that helps
Thanks
loosing time in defraging an empty database doesn't make sense at all
at Akhater..

I completely agree with you but I always take a safe approach, we don't know the complete scenario and there may be some dependencies which may be the user is not aware at this time as well.
when you have time on your hands I always prefer a safe approach...
Hope you understand...

u are right but it’s just the way I prefer....
Thanks
Nice idea of mitigating the low disk space on Exchange server #1, but without the proper maintenance tasks, you'll find that you'll run into the same disk space issues again.

In order to prevent this from happening again, add regular maintenance plans for offline defrags to reduce the size of your Information store.
http://support.microsoft.com/kb/328804

Regarding the old server...if it's not in use then delete the information store.

However before deleting, I'd suggest first unmounting the store for a few days just to confirm that there are no dependancies on the information store. After about 1 week/month or whatever time you feel comfortable, if no issues then delete the store. Monitor the event logs daily on both servers to confirm that there are no errors/dependancies.
No offence but offline degrag should not be done as it is totally useless starting 2003 sp2
No offence but offline degrag should not be done as it is totally useless starting 2003 sp2

[hijack]
Hey ANTOINE, off topic discussion, why do you say the above?
Do you have any links to this discussion?

We still use offline defrag for reducing mailstore sizes on Exc2007
I'm interested in the reasons so I can explain it to others at my Company.
[/hijack]

@zachreisman, sorry about the hijack
I don't think there is any hijack and the purpose of this site is to share info and ideas

1. pre exchange 2003 sp2 the database limit calculation was done on the edb size and not the used space inside the database so we needed defrag to stay within the maximum size limit in standard edition. In sp2 the limit is based on the actual used size and not the edb size

2. offline defrag needs down time for all the database and all the users

3. in exchange 2003 standard edition we are limited to 1 database so, if the physical drive comes to a limit, we had little choices to extend the drive or do an offline database defrag. In 2007 you can create more than one DB even in standard so the better option is to simply create a new database and move all the users to it. advantages? No downtime at all and you end up with one clean database
Thanks for the update, while adding additional databases is one of the methods we already use to manage store growth. SAN storage comes at a premium cost, which management often doesn't understand and then they start questions capacity planning capabilities. The issue we face is constantly having to justify why we need additional space.

In mail intensive environments with Rightfax connectors sending faxes directly to mailboxes we often still had capacity issues.

I already use stubbing and journaling through Mimecast, and previous sites I've used Zantaz EAS for the same tasks. But even with those solution inplace our main processing mailbox, for incoming faxes, used to regularly consume about 30GB in a week.

In a scenario where there is limited available storage; what else would you suggest as a means to manage/reduce storage requirements for Information stores?