Increasing Database Limit from 18GB upto 75GB In Exchange 2K3 STD SP2

This is a scenario that I never would have thought i had to deal with.

If you receive an Event ID: 9688 - you probably have 24 hours to address the issue before your server unmounts the Priv.edb database.

Details of Event ID: 9688 --

Event Type: Warning
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 9688
Date: 01/08/2007
Time: 5:00:32 AM
User: N/A
Computer: EXCHSRV
Description:
Exchange store 'First Storage Group\Mailbox Store (EXCHSRV)': The logical size of this database (the logical size equals the physical size of the .edb file and the .stm file minus the logical free space in each) is 16 GB. This database size is approaching the size limit of 18 GB.

If the logical database size exceeds the maximum size limit, it will be dismounted on a regular basis.

For more information, click http://www.microsoft.com/contentredirect.asp.

--

This is a critical error, but fear not, if you catch it in time, you can fix the issue with less than 5 seconds of downtime.

Reasons for the error: Put simply, when Exchange 2003 was first released the database buffer sizes were limited to 16GB. Combining the *.edb with the *.stm files should not exceed 18GB or your server will dismount the database forcing you to remount it manually. If you do that and do not address the problem, at 5am the next morning, when the next Size Check is run on the server (by default), the server will find the db files exceed the Max limit and unmount the db again.

To avoid this, Microsoft implemented a change in Service Pack 2 that supports increasing the database size up to 75GB. To do this, it's as simple as adding a few REG_DWORD entries in the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Exchange Server Name>\Private-<GUID>

All DWORDS should be added to this key and they should always be DECIMAL values.

If you have more than one Private store, you would have to repeat these procedures for every Database that you have.

To increase the database size add the following DWORD (without quotes):

"Database Size Limit in GB" and then add a decimal value equalling the desired size, in my case it was "36" for 36GB.

Supported Sizes:

For Exchange Server 2k3 SP2 STANDARD: Licensed Supported Size is 18GB to 75GB

For Exchange server 2k3 SP2 Enterprise: Licensed Supported Size is 18GB to 8000GB -- (that's not a type-o .. Enterprise supports an 8 Terrabyte Database).

Now. By default, the checker will warn you that you are reaching the limit when there's a buffer of 10% space between actual logical space and the limit. You can increase this by adding another DWORD.

Let's say that you want a warning when you are within 15% of the limit's threshold. Add the following Key:

"Database Size Buffer Warning in Percentage".. Add a decimal value of "15"

There is one other miscellaneous entry that you can add. The Size Checker check the Logical vs. Limit space every morning at 5am. This is the default behaviour. It would like to change that time to a time when you are actually in the office, say at 1pm, add the following DWORD:

"Database Size Check Start Time in Hours from Midnight" with a Decimal Value of "13"

Once these changes have been made, simply stop/start the Information Store service. Upon restart you will see an entry within your Application Log "Event ID: 1216" that says the following, confirming your increased DB limit:

"Event Type: Information
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 1216
Date: 01/08/2007
Time: 3:10:48 PM
User: N/A
Computer: EXCHSRV
Description:
The Exchange store 'First Storage Group\Mailbox Store (EXCHSRV)' is limited to 36 GB. The current physical size of this database (the .edb file and the .stm file) is 18 GB. If the physical size of this database minus its logical free space exceeds the limit of 36 GB, the database will be dismounted on a regular basis.

For more information, click http://www.microsoft.com/contentredirect.asp."

And that's that. For me, this averted disaster, and is certainly less time-consuming than a 10 hour Database Defrag.


Faithfully Yours,

ALRO