• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 89
  • Last Modified:

Exchange server (2003) Information Store

My Exchange server Information store database size is now 103GB and I need to defragment the same using eseutil

Please suggest the steps of eseutil so that size can be minimized.
1 Solution
Todd NelsonSystems EngineerCommented:
1) Time to start thinking about a transition to Exchange 2010 at a minimum as Windows 2003 has been out of support for over a year, Exchange 2003 has been out of support for over two years now, and Exchange 2007 will no longer be supported after April 2017.

2) Do you know how much white space is in the database?  Review the application log 1221 event IDs to see if it's even worth it to defrag the database.

3) Make sure you have at least enough free disk space as the existing size of the database as the defrag process creates a copy of the database. Here are some references to defrag...
     - https://support.microsoft.com/en-us/kb/328804
     - https://support.microsoft.com/en-us/kb/192185
     - https://technet.microsoft.com/en-us/library/aa995748(v=exchg.65).aspx
kurajeshSenior Systems AnalystAuthor Commented:
Yes, the transition to Exchange 2016 is in the pipeline. But it will take another three months to complete.

Currently Exchange database is on SAN and LUN is mapped to Exchange server. I can create one more LUN with similar space. Hope then we can defrag the database.

"The database "First Storage Group\Mailbox Store  has 35 megabytes of free space after online defragmentation has terminated." is the last message for event 1221.

Please advice
If it has only 35 megs of free space it is useless to Defrag

Moreover defrag is not really necessary, just create a new blank database / storage group and move all mailbox to it. You will have a new db defragged and no downtime to speak off
Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

Addy NadiaExpertCommented:

this is the Best article for following Eseutil tool in exchange 2003.


recommended several users for the same with successfull feedback

Todd NelsonSystems EngineerCommented:
With 35 MB free in the database, it is not worth running a defrag against it.

Why do you feel you need to defrag the database?  What is the reasoning behind asking the question on EE?

What version of Exchange 2003 are you running?  Based on the size of the existing database, you have Exchange 2003 Enterprise Edition.

My advice to you is if you are running out of disk space where the current database resides is to take Akhater's suggestion.  And because you seem to have enough space availabile on your SAN to present to the Exchange 2003 server, I also recommend creating a new database, moving the mailboxes to it, and then removing the old database.  Alternatively, maybe you should reconsider your Exchange transition timeline by moving the date closer (of course depending on your need and ability to do so).

When you finally make the decision to move to Exchange 2010 and then ultimately to Exchange 2016, keep in mind that database sizes can grow up to 50% when moving from Exchange 2003 to Exchange 2010 and potentially another 20% when moving to Exchange 2016.
MB ShaikhCommented:

I guess the below link is usefull to you, but if there is only 35 MB free space no need to run the defragmentation.


kurajeshSenior Systems AnalystAuthor Commented:
created SAN space as additional 300GB and now how would  I change the database location

logged in exchange as domain administrator
Todd NelsonSystems EngineerCommented:
This link should provide you guidance to move the database and logs to another drive...

kurajeshSenior Systems AnalystAuthor Commented:
Thanks Todd for the post.

I will be carrying out this activity tomorrow.

But before that I would like to know about the following :

In the link while I was going through it is written that "You must grant the following default permissions to the new Mdbdata directory that contains the log files and database files:

Administrators: Full Control Authenticated Users: Read and Execute, List Folder Contents, Read Creator Owner: None Server Operators: Modify, Read and Execute, List Folder Contents, Read, Write System: Full Control "

I have logged in as domain administrator so do I need to give this permissions exclusively (like in my case teh location is F:. In case I create a directory called "MDBDATA", this directory will have all the permissions, right?

Also approximately how much time will it take to change the location (the information store is 107gb)

Is the "Point Registry to new database path" is mandatory
Todd NelsonSystems EngineerCommented:
do I need to give this permissions exclusively

Not if you are logged in as an administrator of the server and created the folder.  Domain admin is sufficient.

approximately how much time will it take to change the location

Don't know.  Depends on several factors ... disk speed, CPU, RAM, what other applications are runnng at the time of the move ... that varies from server to server and company to company.

Personally, I would perform the move after hours.

Is the "Point Registry to new database path" is mandatory



Quite honestly the only thing you need to do is change the location of the database files in the database properties within the Exchange System Managers and the rest should be taken care of with the move.
kurajeshSenior Systems AnalystAuthor Commented:
Hi Todd,

Million thans, I tried to move the log files whihc gave 47GB free and database not moved as I thought w will move the database later.

However we will speed up for the transition from Exchange 2003 to Exchange 2016

Your post has really helped, thanks again.

Featured Post

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.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now