Exchange Server 2003 SP2 – 75GB Limit Increase – Event ID 1216, 1217, 9688, 1221, 9689, 9690

Exchange 2003 SP2 Database Improvements

I guess most people would state that the main new features of Exchange 2003 SP2 are the improvements to mobility services, although the increase in database storage size up to 75GB has certainly grabbed most people’s attention. There are many other things to know regarding the database improvements within Exchange 2003 SP2 so I decided to have a closer look.

Goodbye 16GB
As I’m sure you are all aware, prior to Exchange 2003 SP2, the maximum permitted size of a single database on the Standard Edition of Exchange was 16GB. Furthermore, I’m sure you are all aware that Exchange 2003 SP2 brings with it the ability for the Standard Edition to have databases up to 75GB. Now that’s twice I’ve written ‘up to 75GB’. Why? Well, if you apply Exchange 2003 SP2 to your Standard Edition server, the database size limit is initially increased to 18GB. Whilst you can go on to change this figure to a value up to 75GB, it’s important to note that 18GB is the default setting.

Controlling the size of the database is set via the registry. For all the registry settings that I detail below that relate to making changes on a mailbox store, note that we’ll be working in the following registry key:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\{server name}\Private-{GUID}

It therefore follows that for registry settings that relate to making changes on a public store, you’ll need to work in the following registry key:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\{server name}\Public-{GUID}

Obviously in both cases {servername} means the name of your server and {GUID} is, well, the Globally Unique Identifier (GUID) of either the mailbox or public stores. For example, in Figure 1 below, you can see that my server DCEXCH1 has three mailbox stores and a public folder store. Obviously this is an Enterprise Edition server since there is more than one mailbox store. Therefore, any registry changes you make will only affect that specific store.

issp2fig1_2.jpg

Figure 1 – Mailbox & Public Store Registry Samples

Now back to controlling the size of a database. Under the relevant database, create the following registry information:

Value type: REG_DWORD
Value name: Database Size Limit in GB

Set the value data to be the maximum size in gigabytes that the database is allowed to grow to. For the Standard Edition of Exchange, you can enter numbers between 1 and 75. For the Enterprise Edition, you can enter numbers between 1 and 8000. Yes, that’s right, between 1GB and 8000GB or 8TB. Therefore, even if you are running the Enterprise Edition of Exchange, you can still enforce overall database size limits of, say, 150GB if you so desire.

Let’s assume I set the first mailbox store with a 25GB limit. To get this mailbox store to recognize the change, you simply need to dismount and remount the store. When you do this, you’ll see event ID 1216 logged informing you of this fact. For example, Figure 2 below shows the resulting information. We will talk about physical database sizes and logical free space later on. Additionally, it’s interesting to note that you will get event 1216 logged on an Enterprise Edition server for any database that has had a size limit configured. Previously, all databases on an Enterprise Edition server would have been unlimited and therefore logged the event ID 1217.

issp2fig2_1.jpg

Figure 2 – Event 1216 Showing Mailbox Store Limited to 25GB

Why 18GB?
So we’ve said that the default database size for the Standard Edition is 18GB. Like me, you’ve probably wondered where this 18GB figure came from. Well, to fully understand this, you have to understand something called the Database Size Buffer. This is essentially a setting that informs Exchange to log an event in the Application event log if a database nears its maximum size. However, how near is near? The answer to that is 10% by default. Now we can understand the thinking behind the 18GB default limit, since 10% of 18GB is approximately 2GB, which therefore means that the warning event log entry will be logged at about 16GB, the old Standard Edition limit.

Controlling the database size buffer is also achieved via the registry. In the same manner as previously described above, create the following registry information under the relevant database:

Value type: REG_DWORD
Value name: Database Size Buffer in Percentage

Set the value data to be the desired percentage. Therefore, if you enter 20 here, you’ll receive the warning event log entry when your database has 20% capacity left before it hits the maximum permitted size. What event log entry is actually logged? Well, it’s event ID 9688 as shown below in Figure 3. In this example, I set a database size limit of 1GB and waited until the database grew to within the specified percentage.

issp2fig3_1.jpg

Figure 3 – Event ID 9688 Warning of Database Size

Physical vs. Logical
As I mentioned earlier, we need to take a look at what is meant by the terms physical and logical as they relate to these event logs. It’s simple really; the physical size of the database refers to the size of the EDB and STM files added together as seen in Explorer. The logical size of the database is the physical size of the database minus any whitespace. As I’m sure you all know, whitespace is the term used to describe the areas of the database that are not currently in use and will be re-used before the size of the database is expanded. The amount of whitespace within a database can be determined by looking for event ID 1221 in the Application event log.

You will see from Figure 2 above that Exchange now calculates the size limit restrictions based on the logical space within a database. For example, imagine I set my maximum permitted database size to 25GB and my database is now showing in Explorer as being 25GB in size. However, if I have 2GB of whitespace within the database, my database will not currently hit the size limit since its effective logical size is 23GB. This is good news.

By default, these limit checks are performed daily at 5am but you can change this via the registry by creating the following information under your chosen database as before:

Value type: REG_DWORD
Value name: Database Size Check Start Time in Hours From Midnight

Set the value data to be the number of hours past midnight to elapse before the size check takes place. For example, if you want the checks to take place at 6pm (18:00) each day, you’d enter 18 here.

A Helping Hand
In the days before Exchange 2003 SP2, a Standard Edition database that exceeded the 16GB size limit would be dismounted. Of course, there were several little tricks that you could play, like temporarily increasing the store size to 17GB via a registry tweak. However, you now have a helping hand in Exchange 2003 SP2. Now, when the specified database size limit is reached and the first database size check has been performed by Exchange (remember, this is once every 24 hours at 5am by default, unless you’ve used the registry change above) the database is NOT dismounted. Instead, event ID 9689 will be logged as shown below in Figure 4.
Figure 4 – Event ID 9689 Showing Database Size Exceeded

You then have 24 hours to rectify the problem, otherwise, when the next database check is performed 24 hours later, the database will be dismounted and event ID 9690 will be logged as shown below in Figure 5.

issp2fig5_1.jpg

Figure 5 – Event ID 9690 Showing Database Dismounted

But wait! You can still mount the stores again even after event ID 9690 has been logged. Unfortunately, it will be dismounted again after the next database size check is performed 24 hours later but at least you now have time to rectify the problem. Despite this, I’m sure you’ll agree that Microsoft has made life much easier for Exchange administrators.

8 thoughts on “Exchange Server 2003 SP2 – 75GB Limit Increase – Event ID 1216, 1217, 9688, 1221, 9689, 9690

  1. Windows XP Service Pack 3

    We have been getting mixed feedback from users that have installed the Windows XP SP3. One of the biggest complaints is Microsoft did not include Direct X 10. The service pack employs many features of Vista and seems to turn your current version of XP into a steppingstone for purchasing a full copy of Vista. Please be sure your current computer programs will be able to handle the transition to SP3 or you may not be able to use them anymore.

  2. Windows XP Service Pack 3

    We have been getting mixed feedback from users that have installed the Windows XP SP3. One of the biggest complaints is Microsoft did not include Direct X 10. The service pack employs many features of Vista and seems to turn your current version of XP into a steppingstone for purchasing a full copy of Vista. Please be sure your current computer programs will be able to handle the transition to SP3 or you may not be able to use them anymore.

  3. hi, i found this article very useful for a situation i’ve had to resolve. now that i’ve tweaked the registry and upped the limit to 50GB, i’ve been getting errors with event id 1 WSH…Exchange’s information store is getting too big.Mailbox Store (server) store size is : 16359833600

    this was about a mth ago and the size has since increased to about 17.8GB (when i go to properties of the priv1.edb and stm to add up the size, it still shows 16GB (17,841,123,200 bytes)

    i’m wondering if you’ve noticed this before, i’ve tried googling but haven’t found a solution.

    • pls ignore my last comment, i found out that it was some script that was generating the errors as a warning to the admins. everybody say “kevin is a doofus!”

  4. thanks! very helpful!

    when creating the new registry value, i barely noticed that the default data type is hexadecimal.

  5. Hi,
    This is a really good article. Thanks.

    I have ran into this a few times on a few different exchange servers usually the registry change fixes the problem. But, I have one that is being stubborn.

    It’s running exchange service pack 2. I get the following error every morning at approx the same time:
    Event Type: Error
    Event Source: WSH
    Event Category: None
    Event ID: 1
    Date: 1/7/2010
    Time: 5:52:30 AM
    User: N/A
    Computer: EXCHANGE
    Description:
    Exchange’s information store is getting too big.Mailbox Store (EXCHANGE) store size is : 36156030976

    At any rate, priv1.edb is 25.588GB and pub1.edb is 9.719GB. The registry setting for both is 75GB. Not sure how this makes sense, but the total size of the MDBDATA folder is 33.8GB.

    I haven’t had a problem with the exchange server dismounting, it just logs this error every morning. 5:55am give or take 5 minutes. Started approx 2 weeks ago. Hoping to resolve the issue before it impacts production.

    And yet, I still get the error. So, I had a few questions:
    1. Kevin, where was that script? I may be a doofus too. I am not aware of any script, but maybe there is some other software installed before me that is generating it.
    2. what is the WSH source? Can that tell me more about where this is coming from?
    3. Is it fair to say that the limits are identified on a per-database level, but they are enforced on a sum (information store) level? I say that because it seems like the server has a problem with the fact that the 2 databases exceed 36GB, not that the priv database exceeds 18GB.
    4. It’s also interesting to note that when the error started getting logged (dec 22nd) it said that the store size is 36156817408 and now (jan 7) it says that the store size is 36156030976. So, the database actually shrunk? Could it be that the WSH source isn’t reading the sizes correctly and therefore not reading the registry correctly either?

    Thanks to all ahead of time. I am still a bit challenged by this one. We are also going to migrate to exchange 2007 in a couple of weeks, but I can’t ignore the error.

    Thanks!
    Ben

  6. You can get more than 75GB if you really want. I had been comming up against this silly artifical limt recently on a set of older sites.

    Options were to upgrade, go cloud, archive off etc. – all painfull to some extent. In the end I noted that restarting the Information Store every morning just after the 5am size check means you can have as much email as you want – well I’m up to 90Gb.

    i.e. : schedule a btach file daily at 5:10am to restart the IS service

    The below restarts the POP connector that SBS 2003 has – just omitt for standard Exchange 2003. The PING is just a little delay to let things settle before re-starting again. The PAUSE just keeps the DOS box open so I can see the results if there was any error – never has been in the year this has been on.

    net stop “Microsoft Connector for POP3 Mailboxes”
    net stop “Microsoft Exchange Information Store” /y
    ping 8.8.8.8
    net start “Microsoft Exchange Information Store”
    net start “Microsoft Connector for POP3 Mailboxes”
    net start “Microsoft Exchange Event”
    pause

Leave a Reply

Your email address will not be published. Required fields are marked *