Thursday, July 05, 2007

Crashing mailbox/public folder store on Exchange 2000

When you have a mailbox or public folder store on an Exchange 2000 which has crashed, changes are pretty good that the database size has exceeded its maximum permitted size of 16 GB.

Check your eventviewer to see if you see messages:

Event ID: 1112
Description: The database "Mailbox Store" has reached the maximum allowed size. Attempting to unmount the database
Event ID: 445
Description: Information Store (3160) The database D:\Program Files\Exchsrvr\MDBDATA\priv1.edb has reached its maximum size of 16383 MB.

This is default behaviour, designed by Microsoft to protect the database from inserting more data than it can handle.

There are 2 things you can do to rectify the problem, which are probably best used together:

1. Temporarily increase the limit size to 17 GB, mount the store back in your exchange server and start archiving/deleting old mails.

To increase the limit size it suffices to locate the registry key add the registry key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ MSExchangeIS\AEX\Private-15908017-eb7c-473f-93a9-6e5ab8762fc7] and adding a REG_DWORD value
Temporary DB Size Limit Extension with the value of 1.
This value is only read when the database is started, so in the services we have to restart the Microsoft Exchange Information Store.

2. After you've succesfully mounted the store in you exchange and archived/deleted old mails, you'll notice that the size of the database file priv1.ebd is still the same value. That is because the data is removed from the database, but the remaining data does not move up, thus creating white spaces in the database.
To physically shrink this file, we have to perform an offline defragmentation.

To do this we Dismount the store in your exchange system manager and then run the eseutil from the command prompt. This util is located in the \Exchsrvr\bin folder on your server.
Execute the command: eseutil /d to start defragmenting the database.

Be advised that this offline defragmentation can easily take 4 hours or more, depending on the hardware and the state of the database.
Also ensure that you have at least 110 % of the current database size of free space left on the partition, otherwise the offline defrag will fail!

Further options with this eseutil are repairing the database (/p), checking the integrity (/g), recovery (/d), restore (/r).

Last, but not least important, don't forget to remove the registry key, so you still have options next time you have this problem ...

No comments: