Exchange 2003: One foot in the Grave.

Exchange 2003 is getting on, there’s no doubt about it, but there’s still three years to go before it moves into PAL support, so there’s life in the old dog yet.

2003 is my favourite Exchange product. It does what it does well and without making a big song and dance about it. There are no judderingly mad features (like the M: drive!) and it’s relatively easy to administer once you’ve got the hang of the permissions model.

It works. All the features run properly. It doesn’t suffer from any major unfixables. Exchange 2000 had memory fragmentation and instant messaging, Exchange 5.5 had the glass-jawed SMTP service. Pretty much everything in Exchange 2003 is functional. There’s the odd exception – the RUS is pretty pathetic, but most installations aren’t really affected.

It’s mature. There are plenty of hotfixes out there, there’s a huge fund of knowledge on the internet describing how to get it to do stuff. There are plenty of people who know how to administer it, and users (by and large) know what they can expect from it.

It’s robust. OK, this may be a relative thing, but i see about half the calls with Exchange 2003 as i did with Exchange 5.5. things like recovery storage groups, a well understood backup and restore system, outsourced directory all add up to a product that doesn’t cause much pain. Well, anything like as much pain as its predecessors, anyway.

However, to keep it running into the next decade, there are some things we all need to be mindful of. Messages are getting bigger and more frequent. There’s more data out there in general. Constant pressure has resulted in mailbox limits being increased, if they are present at all. There’s a LOT of third party stuff out there that wants a piece of your database. You might well have succumbed to running anti-virus on your Exchange server, rather than separately. There are also some quite specific things that can bite the unwary in the backside.

The biggie is pool memory depletion[i]. Exchange 2003 is a 32 bit system, in an increasingly 64 bit world. If you use the /3GB switch (you DO use the /3GB switch, don’t you?) you are reducing your paged pool to 256MB and non-paged pool to 128MB (on windows 2003, anyway – it’s a different story on 32 bit windows 2008, but, seeing as how you can’t install Exchange 2003 on windows 2008, a different and irrelevant story). “Oh, well, that’s how big it’s always been, we’ve coped for years, we’ll be fine” I hear you say. Well, that’s what they all say, and they’re often wrong. I’ve got two words. Smart. Phone. Oh, and two more. Outlook. 2007. Strictly, 2007 isn’t a word, but hey hoe.

If you’re using Exchange 2003 with Outlook 2003, exclusively, pool depletion will pass you by, most likely, as these two products were designed to work together and be scalable. You may have a problem if you have users in scores or hundreds of security groups, but otherwise don’t worry. You’ll be fine.

Smart phones, Blackberries and later versions of Outlook however are very, very selfish things. A small number of users won’t be a problem, but as they become more and more frequent things will become unpleasant. You’ll start getting users moaning about being disconnected. In the event logs you’ll start to see 9646 errors. You’ll implement the fixes here:

http://support.Microsoft.com/kb/842022

and increase the number of mapi sessions allowed per user[ii]. And then the fun will begin. Outlook 2003 will typically open between five and ten mapi sessions. Blackberries will open significantly more than this. Some smartphones more again. Add in desktop search, active sync etc., and users can be trying to open a hundred or more sessions.

Why is this a problem? Every session requires an access token. Access tokens consume paged pool memory[iii]. Say you have a reasonably typical user, with a token size of about 2KB. They use Outlook 2003 fairly heavily, so are using say, 20KB of paged pool. Generally speaking, we only see problems when token consumption hits about 130MB of paged pool memory. That means you could have 6500 relatively heavy users concurrently connected before you hit pool depletion problems. You’ll run out of CPU, storage or hair before this is an issue, I reckon. Start replacing those users with smart-phone/Blackberry/desktop searchers, with a hundred connections at once.  650 concurrent users. Now start, say, an ad migration, and increase the numbers of security groups they belong to. Token size increases proportionally to 4KB. 300 concurrent users. Once you hit 80 security groups token size doubles to 8kb (One of our customers had multiple users in over 200 security groups – it happens). 150 concurrent users. Worried yet? There’s more on what to do at Mike Lagase’s blog, here: http://blogs.technet.com/b/mikelag/archive/2009/09/15/how-to-monitor-and-troubleshoot-the-use-of-nonpaged-pool-memory-in-Exchange-server-2003-or-in-Exchange-2000-server.aspx

it’s not just paged pool, either – that neat-o VSS backup solution you’ve installed? Gobbling up your non-paged pool.[iv]

Another major problem that’s only recently come to light is transaction log filename depletion. That’s right; we’re running out of things to call our transaction logs.

http://support.Microsoft.com/?kbid=830408

So long as you’re prepared for it, it’s not a problem. Unfortunately, we’ve had a number of customers who were shocked to discover that a finite resource eventually runs out.

So, my top tips for keeping your Exchange server frisky, with a glossy coat and cold nose for the next three years:

Keep an eye on it. If you run the BPA[v] monthly, and are baselining server performance then you’ll have a good idea what’s coming, and when things are going to start falling over. If you have addressed all the issues raised by the BPA, got rid of all the warnings and errors from your event logs and can keep all your perf counters in the green, then yours is the earth and all that’s in it…

Shoot iphone users on sight. If you can’t do this, use the Exchange user monitor[vi] (exmon) to quantify the impact that new versions of Outlook and the like are having on your system. In conjunction with perfmon you can produce some pretty persuasive data. You can also spot the “power” users who are ruining it for everybody else.

Don’t put more than 4GB of physical RAM in your Exchange server. It can’t use it, and it WILL make things worse.

Stop playing call of nature on your Exchange server. Put the base Microsoft video driver on[vii]. You’ll have to make do with Castle Wolfenstein.

 

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: