We help IT Professionals succeed at work.

Running eseutil on exchange 2000 database over 16GB limit

matmos asked
Medium Priority
Last Modified: 2010-03-06
We have a server running SBS2000.

Exchange stopped working today - when checking event logs noticed error 1112 indicating exceeded 16GB limit.

C Drive has 2GB free - D has 10GB free, but contains 45GB of exchange log files.

Can I run eseutil on this setup or do I need to have a temporary store in excess of 16GB ? I'm reluctant to delete LOG files as last time i did this exchange complained of corruption and refused to start. If I can run eseutil what would the syntax be, and do I need to stop any services ?

Am trying to rectify tonight as dreading phone calls in the morning about emails not working !!

Many Thanks

Watch Question

How to run eseutil:

If you can make a backup of the exchange store the log files will be commited to the store.
The overall size of the store will than be reduced as wel.

Good luck,


Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


Thank you - the MS article states "Defragmenting a database requires free disk space equal to 110 percent of the size of the database being processed." . Unsure how I can free this much space with moving LOG files. Sorry but I dont understand your comments  about backing up the exchange store - are you referring to the priv1.edb files or LOG files ? How will the size be reduced just by backing it up ? Thx


Thats right. I also would suggest you first try to make a full backup of the information store (can be done with ntbackup if you don't have a third party software). Of course you will need a tape or an additional hard drive as drives C and D do not have enough space left for backup. After the backup the log files should be gone, leaving res1.log and res2.log and a few other files. Then you can run eseutil to defrag the information store. If you just delete the log files Exchange will complain about corruption or inconsistence, thats true. The defragmentation will only work if you have a frequent maintenance job running on the database. If you have a maintenance job running, you will see entries in the event log that tell you how much space would be freed by a defragmentation. Look for event id 1202 in the application log.


No maintenance job running on the database. So should I backup the exchsrvr\mdbdata folder to tape - delete all the LOG files and then run eseutil ? I presume backing up the LOG files first will allow me to delete them without exchange complaining ? Thanks for your quick responses.
Ok MOVE all the log files to another machine. Also make a copy of the databases somewhere safe before you run utilities against them.

It is true that you need free disk space equal to 110 percent of the size of the database.

But the log files will be of no use anyway after a defrag. The reason is that when you defrag a database, it gets a new database signature. Whenever a log file is created while Exchange is running, it is hardcoded with the database signature at the time of creation. If the signatures don't match, then Exchange will not use the log file.

If the database shutdown gracefully, which it should have due to only reaching the 16 GB limit, then all the log files were committed into the database.
Do not do a file-based backup of the Exchange database!

Start ntbackup (Start -> Run -> ntbackup). Then use the backup wizard. You will be able to select Exchange Information Store explicitly. During the backup, the log files will be applied to the store and will be deleted automatically so you will free the 45 GB or a little less from drive D.

Have a look at http://www.eventid.net/display.asp?eventid=1112&eventno=1931&source=MSExchangeIS&phase=1. I think you will find all you need.


Thank you both - but 'The Kirschi" can I please confirm before I do anything stupid - NTBackup within backup has an option in the left pane for "Microsoft Exchange" and "Microsoft Exchange Server". I expand the latter - select the server name and then check Microsoft Information Store. Once this is backed up it will automatically delete source log files ?, allowing to me run eseutil on remaining .edb files ? (Am doing this remotely)
"Once this is backed up it will automatically delete source log files ?, allowing to me run eseutil on remaining .edb files ?"
This is correct   PROVIDED    the databases are mounted.
Expert of the Year 2007
Expert of the Year 2006

If you have hit the 16gb limit, then you can do a hack to get a 17gb limit.


That should let you mount the database. You can then run a backup to flush the transaction logs.



Sembee - I tried that registry hack before posting here - didnt work for me.  Even though all the exchange services seem to start afterwards , i get message from MSexchangeIS service that The information store database "First Storage Group\Public Folder Store ('ServerName')" is limited to 16384 MB, and am still unable to connect to exchange server
Expert of the Year 2007
Expert of the Year 2006
The registry hack is very precise. It also requires that you are on the latest service pack.
Did you restart the server after making the change?



Latest service pack - didnt restart server , but followed instructions about restarting information store service .


Thank you all - the registry hack worked - and I had missed a service pack from September 2003 which was needed in order for it to work. Thank you all for the other suggestions which I will be trying.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.