The mystery of the slow Exchange 2007: when hard-coded values come back to haunt you

Following a migration from Microsoft Small Business Server 2003 to SBS 2008 users were complaining that Exchange was slower than before in some scenarios. How could this be? The new machine had 64-bit goodness and far more RAM than before.

I checked out the machine’s performance and noticed something odd. Store.exe, the Exchange database, usually grabs vast amounts of RAM, but in this case it was using surprisingly little, around 640MB. Could this be related to the performance issue?

I speculated that Exchange memory usage was limited in some way, so looked up where such a limit is set. I found this article. Ran ADSI Edit and there it was, a 640MB limit (or thereabouts), set in msExchESEParamCacheSizeMax.

I removed the limit, restarted Exchange 2007, and it immediately said “thank you very much” and grabbed 8GB instead.

Why did this setting exist? No doubt because back in the days of SBS 2003 and a much less powerful 32-bit machine, someone set it in order to prevent store.exe from crippling the box. It is another example of why Small Business Server is harder to manage than full server setups when Exchange invariably has a dedicated server (or several).

SBS 2008 cannot be installed as an in-place upgrade; but the official migration process does preserve Active Directory; and since that is where this value lives, and since it is not specific to any version of Exchange, it was dutifully transferred.

Why wasn’t the setting discovered and changed before? Well, you will observe that it is somewhat hidden. The main chances of finding it would be either if you were deeply schooled in the ways of Exchange, or if one of the Best Practices Analyzer (BPA) tools picked it up, or if the users screamed that Exchange was slow (which is what happened) and you figured out what was wrong.

The SBS BPA did not notice it. The Exchange BPA did, kind-of. It was not shown as a critical problem, but listed for information under “Non-Default Settings”, ironically with a tick beside it, as “Maximum ESE cache size changed”. Summoning help on this setting leads to this article which refers to Exchange 2000.

An admin failure, yes, but arguably also a defect in Exchange and SBS. Typical Microsoft: critical setting, hard-coded when it would make more sense to use a percentage value, not checked by setup and persistent across major upgrades of Exchange, deeply buried in Active Directory.

Mentioned here just in case it saves someone time when trying to figure out why their shiny 64-bit Exchange 2007 is running worse than 32-bit Exchange 2003 ever did.

2 thoughts on “The mystery of the slow Exchange 2007: when hard-coded values come back to haunt you”

  1. I think this is more of an Exchange “overclocking” than someone limiting the hit of Exchange on an underpowered box. By default if you aren’t using the /3GB switch, Exchange only uses 576 MB, so in this case someone was telling Exchange to use more than the default. This article actually recommends it as a step to optimize Exchange 2003 – http://technet.microsoft.com/en-us/library/aa998057(EXCHG.65).aspx.

    The real question is why wouldn’t Microsoft give you more of a warning in the Exchange BPA. OK, its not going to kill Exchange to drag that setting into EX2007, but since you have to move to a new server with Exchange 2007 (SBS or not), why bring that limit along? Definitely a mistake by the Exchange Team for bringing that setting forward into what is undoubtedly going to be a much more robust 64-bit server… And for recommending the setting in the first place. Since any Exchange 2007 upgrade would have been caught by this, I don’t think its an SBS specific issue.

  2. Thanks for the comments.

    Since any Exchange 2007 upgrade would have been caught by this, I don’t think its an SBS specific issue.

    If used to optimize with a larger value, that’s true. If used to limit the memory, more likely to be SBS since otherwise Exchange usually has its own dedicated box. I take the point though.

    Tim

Comments are closed.