Vladville - Vlad Mazek's Blog Vl-Advisory Warning
Articles About Links SBS Show Contact RSS Feeds

Changing Exchange Store Database Limits

I am writing the following article against my better judgement. Guiding a novice to override Exchange Information Store databases through registry keys is kind of like teaching someone to clean their gun while looking down the barrel and pulling the trigger. It is not a good (safe) idea but I understand there are realistic business and technical reasons why you might want, and eventually will, try to bump up the Exchange 2003 Standard databases to 75GB. There is an excellent article on the official Exchange blog "You Had Me At EHLO" written by Ethan McConnell and Michael Palermiti but it maybe a little too advanced for people who are not intimately familar with Exchange.

Please promise me that you will read this article in full before scrolling down and taking a shortcut.

Why You Should Not Do This

There is only one reason why you should want to take the steps below: more control over your Exchange server. More control in the way of selecting where the store size limit should be set, when warnings should be issued, when to run daily database size checks. In reality, you probably have a business need to store more than 16 GB of mail that the current Exchange 2003 Standard stores are limited to.

So why should you NOT modify these preset limits? Here are some things to consider:

  • Hard drive size - First question you should ask yourself is "Do I have enough space to support a much larger Exchange database on my SBS server" I realize this is a trivial question but keep in mind that your SBS server is your mail server, your file server, your SQL server, your domain controller, your SharePoint/web server in addition to a few other things it does. All these activities take up space, generate logs, etc. Do some basic math in your head before you bump up the Exchange database limit to full 75GB on both public and private stores on a hard drive that only has 10GB of free space.
  • Maintenance intervals - If you're familiar with the eseutil command you know what I'm getting at. The larger the database, the longer your maintenance interval will take. The longer it will take to repair the database. The longer it will take to back up the Information Store. If you perform off-site backups over the Internet how long will it take to copy the new database?
  • Backup considerations - Check your backup gear (USB Drives, Tapes, Hard Drives) and make sure you have enough space to perform these backups. More simple math: will the backup device hold more than a single backup? If your SBS backup schedule runs 7 days a week and you swap it once a week - but you double or triple the amount of data being backed up - will that drive retain all the required backups or just start failing after two? If it does, how do you explain it to your client (or worse, your boss) that you can not restore documents from yesterday because the backup device filled up three days ago.
  • Performance effects - More data in the information store can adversely impact your server performance: searches take longer, server experiences higher load (if your desktop search is also trying to index your Mailbox via Outlook like Google Desktop for example,) and all of the above contribute to degraded performance by extending the time to perform basic maintenance tasks.

I realize I have not talked you out of it, so if you're still considering it let me ease your mind: Exchange Information Store design is quite capable of handling your measly 75GB store. The underlying database technology (Jet) has a limit of 8 TB so you're not going to destroy your server by going above the preset 16GB limitation.

The Three Tweaks

Microsoft Exchange 2003 Service Pack 2 introduces three new registry “tweaks” that adjust default coded Exchange behavior. First of all, you are allowed to set the limit of your information store up to 75 GB in Standard Edition of Exchange 2003. You are also allowed to select when the check of the store size happens, by default it is at 5 AM, so if 5 AM is your peak hour this is great news. Finally, you can now choose when the system notifies you that you're out of space – by default it is within 10% of the database limit. If any of these speak to your needs follow the directions below, I will walk you through settings for each one.

Assuming you've created plenty of backups and followed all the best practices and proper procedures before making potentially catastrophic registry changes, start regedit. Start > Run > regedit

When the software launches navigate down to your private database. It is located under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\\Private-GUID.

Once you've found it, right click and create a New DWORD Value

First, lets set the limit of the private information store to 25 GB. To do this type the name of the new registry key as “Database Size Limit in GB” and double click on it. Select Decimal base and enter 25 for Value Data. Click OK to set the new key.

Next, lets pick when we want to get alerts about potentially running out of space. Create a new registry key named “Database Size Buffer in Percentage”, select Decimal base and set your limit. I'm setting mine at 25% but keep in mind that default is 10%. Why am I setting it so high? Well, it takes an impressive packrat skill for a company of less than 75 users to start taking up more than 20 GB of Exchange database with mail. Setting it this high gives you an opportunity to re-evaluate (“Umm.. We need a $15,000 budget approval for new hardware and storage systems to support our lawyers habbit of storing all his documents inside his folders”) the situation and find out just how important all those daily Dilbert cartoons are.

Finally, lets decide when we should let Exchange check its databases. By default it is 5AM, but if you're running a printing press and 5 AM is a real peak time for you, this is the setting you will want to change. So, create a new registry key “Database Size Check Start Time in Hours From Midnight” and set the Decimal Base Value data to the hour of the day you wish to run these checks. The value is the time in hours after midnight, so if you want to do it at 4 AM enter 4, if you want to do it at 5 PM enter 17. You get the idea.

You've set your limits. Now restart the Exchange Information Store and check your work.

Putting It Together

So now you've let the Exchange store know who's the boss. You have your own limits, your own warning comfort zone set and you even command Exchange when it can check its database size. But how do you make sure these changes have taken place?

Restart the Microsoft Exchange Information Store through the services pannel: Start > Run > services.msc. This will launch the Services management console. Find the Microsoft Exchange Information Store and restart it. Close the Services console.

Now for the moment of truth: Start > Run > eventvwr.msc. You will see an MSExchangeIS Mailbox Store entry under your Application Log. Open it up and see what it tells you.

If the new “limited to” size is way off from what you typed in the new registry key, make sure you entered it as a Decimal Base value and not as a Hex.

 

Read my other Exchange articles:

Publishing SenderID records for Exchange SP2 IMFv2
Enabling IMF 2 in Exchange 2003 SP2
Changing Exchange 2003 Store Database Limits
Exchange 2003 SP2 for SBS
Modifying the Outlook Web Access Login Page
Disabling NDR (non-delivery reports) on Exchange 2003
Setting up Exchange 2003 as an ATRN Client
Setting up Exchange 2003 as an ATRN Server

 

Additional Resources

Exchange 2003 SP2 Webcasts
Top 10 Reasons to Install Exchange Server 2003 SP2
Exchange Server 2003 SP2 Release Notes
What Is New in Exchange Server 2003
Exchange Server 2003 Support for Mobile Device

Vlad
Hi! I'm Vlad Mazek and this is my geek blog. I'm the CTO of Own Web Now Corp (which includes ExchangeDefender, TheOfficeServer and Arrow 5). I'm an alumn of University of Florida, leader of Orlando SBS IT Pro Association and these are some of the things I find important.

Copyright © 2005, Vladimir Mazek. All Rights Reserved.
Syndicate this blog: RSS