Exchange Server 2003 Service Pack 2 is Coming!
All hail the latest service pack!

And there are some great changes being incorporated into E2k3 SP2...

  • Improved compression in Mobile email
  • Remote wipes of mobile devices (I love this one!)
  • Cert-based authentication for mobile devices
  • S/MIME for mobile devices
  • Improved spam protection (updated IMF)
  • Support for Sender ID
  • New OAB format for increased performance
  • Outlook cached mode enforcement
  • Exchange 2003 STANDARD edition increases limit from 16gb -> 75 gb

And at that point, my jaw dropped....

Increasing the ceiling past 16 gb can be great for Small/medium businesses
I can't even begin to tell you how many calls I have taken that went something like this:
   Me:   "Thank you for calling Microsoft Exchange support.  My name is Stephen.  How can I help you?"
   Joe Admin:   "My information store won't start."
   Me:   "OK.  Is this the first time this has happened?"
   Joe Admin:   "No.  It's been crashing several times a day for the last week or so.  People would start calling me when they couldn't get their email so I would go and start it back up.  It never had any problems restarting until today, and now it won't start.  It keeps saying something about 16 gigabytes."

We would then proceed to temporarily raise the limit to 17gb (if we could) to quickly pull data out before the floodgates of inbound email are opened thereby dooming the poor guy to Exchange 2003 standard server with a 17gb priv1.edb.  Or we start the explanation of different options to try to remove data from a store already packed so full of data that it's like an overstuffed sock drawer that won't open.  Oh, you know what I'm talking about...

It's going to be great to not have to worry about the 16 gb limit!

Increasing the ceiling past 16 gb can be dangerous for Small/medium businesses
Not every business has the resources to hire a properly trained administrator who is dedicated solely to running the company's messaging infrastructure.  Believe me, I understand that fact, and I've got a lot of respect for the one-man shops out there.  That's a lot of hats to wear, and your email systems should just keep running without the need for your daily attention.  You've got too many other things to worry about every day.  But Exchange is "mission critical"... just ask anyone who's had to waste precious time enduring a lecture from the boss, the CIO, and the CEO (or dozens of other people who don't understand your systems) while you are in the middle of a disaster recovery scenario.  But what does that have to do with the 16gb limit?

  1. When I hit the 75 gb limit...
    When.  Not if.  You remember back around 1992 when drives first started hitting 1gb?  "I'll never fill a 1gb hard drive!"  Yeah, I said that about 10gb.  I said that about 100gb.  And now I look at my PC at home with about 650 gb and worry about filling it up.  When Joe Admin called me, and we were in a position where we had to defrag his information store, we normally estimated about 2 gb an hour.  It often took 8 hours (or more) to complete the defrag on the store.  And then we had to try to get data out and defrag it again.  Now imagine this same scenario, but Joe is calling     Microsoft Support with a 75 gb store.  (Because Joe's boss said "Why do we need mailbox limits if we can grow to 75 now?  We'll never fill 75gb!")  It's true that servers are faster now.  And drives are faster now.  But a defrag on a 75 gb store will still take many hours.  Many, many hours.  Not a good thing to have to tell Joe Admin's boss.  Or CIO.  Or CEO.
  2. What do you mean "Outlook is retrieving data from the Microsoft Exchange Server"...
    In general on any given Exchange server, the bigger a store gets, the slower it gets.  It's a fact of life, and we can certainly do things to mitigate situation.  But in many situations, the solution to "making Exchange faster" is cost prohibitive to many small businesses.  Very often, this degradation of performance is due to a suboptimally configured (or architected) disk subsystem.  Or to put it in other terms, with Exchange we need to architect our disks for performance and not for storage capacity.
  3. Murphy is watching...
    And he doesn't like you.  Sorry.  I hate to be the one to break it to you.  And sooner or later, he is going to do something to take down you server.  Now your database is inconsistent (aka dirty shutdown).  And you need to ESEUTIL /P it... then defrag it... then ISINTEG it.  Maybe you had backups... maybe you didn't.  But chances are that your boss wants that data back NOW.  You can always repair the database on a recovery server.  You do have a spare recovery server just sitting around waiting, don't you?  Well, that's ok, you can just find some spare hardware and follow your detailed and tested disaster recovery action plan that you've been practicing in all your free time.  You've got all of that written out and tested right?  Well, let's just get the backup from last night restored so we can return the server to production.  What do you mean that the last good backup was 4 months ago? 
  4. We're okay as long as we have good backups...
    <Obvious statement> Backups are very important. </obvious statement>  But let's consider for a minute what happens when a backup starts on an Exchange server.  Actually, let's consider what doesn't happen -- a little subset of online maintenance called online defragmentation.  When we begin a backup on any database in a storage group, online defragmentation on all databases in that storage group stops until the backup completes.  With a 15 or 20 gb store, this probably isn't a problem.  We can even use NTBackup to back up a store of that size in a fairly short period of time.  And many small businesses don't have the resources to invest is blazing fast backup solutions.  So when the store grows to 60-70 gb, the backups take much longer.  Backups are now taking 10-12 hours instead of 2 hours.  Not a problem since we're an 8-5 shop.  Except that default, online maintenance is set to run from 1 am to 5 am daily.  And if your backup kicks off every evening... not much (if any) time left for online maintenance.  Well, what happens when my online maintenance doesn't run?  Lots of bad things.  Nothing dramatic and nothing immediate.  It's more of a slow rot.  No online defrag means new data cannot optimally use the white space within the database.  This can cause the file to continue to grow in size despite having free space in the database.      Other tasks that occur during the online maintenance -- Purge indices, tombstone maintenance, dumpster cleanup, public folder expiry, age folder tombstone, folder conflict cleanup, update server versions, secure folder cleanup, site folder check, and deleted mailbox cleanup.  These are all low priority tasks.  Bottom line is that if your backup times are consistently trampling all over your maintenance times, you won't have happy healthy databases.

So what do we do about it?
Well, with the new 75 gb limit (as with many things), just because you can, doesn't mean that you should.  The following best practices are nothing new, but should be revisited now to help you fully enjoy the 75 gb limit: