Take the 2-minute tour ×

We have some internal processes that send email to our Exchange 2003 system (on Win2K3 R2 32bit). Recently they have been intermittently failing with various errors -- boiled down they report "Exchange refused the connection". We use XWall as our spam filter (and XWall Filter for Outlook client integration) and it is also reporting "Connection closed for no reason" which could indicate that the Exchange server is having problems keeping up.

We only have about 25 user mailboxes (about 20-25GB total) and the CPU load on the machine is not pegged (it's a 8-core Dell w/4GB RAM). My guess is that it's I/O bound in some way. We get a metric ton of spams and my guess is the box can't keep up. How would I go about diagnosing this (user mailboxes are not reporting anything amiss)? What should I look at to see where the bottleneck is -- disk I/O? Network I/O? CPU? etc.? How do I tweak Exchange?

Yeah, I can look at Task Manager, but that's not really telling me anything. Thanks!!

share|improve this question

4 Answers 4

up vote 3 down vote accepted

Perfmon is your friend. Chart gross performance of CPU (% utilization, % user mode vs kernel mode, context switches), disk (queue length, % disk time), and memory (page faults / sec, working set sizes) for starts. That'll give you a place to start looking. If you're most interested in IO, you might grab the "Process" counters for the Exchange services associated with IO (IO Read / Write Bytes or Operations per second) and get those on the chart, too.

Without knowing more details, it's difficult to tell you what counters on Exchange services to look at. I haven't seen a lot of situations where the Exchange/Windows SMTP service doesn't answer for connections. It surprises me, actually, to hear that it's not answering for SMTP. I wonder if you might have a network problem in the mix here, too. You might consdier sniffing traffic between the XWall machine and Exchange (if you can catch it in the act) and see if it's really a matter of unanswered SMTP sessions.

share|improve this answer

You could enable diagnostic logging and see what's happening in more or less real time. Also you could look into trying to block domains or IP ranges from which the spam is originating if you haven't already.

share|improve this answer

Does this server have any other function than Exchange(that's a lot of CPU)?

Do you use OWA? Do you have the /3GB boot switch enabled? (These don't always play well together).

What client do users use to connect with and if Outlook do they use "Exchange Proxy"?

What's the storage look like (local/SAN, SATA/SAS, RAID level). You should see too much trouble with just 25 users.

There are lots of angles to an exchange environment to look at.....

share|improve this answer
It's just Exchange -- but we are using OWA AND The /3GB -- can you give some more information on that? –  Matt Rogish Jun 12 '09 at 13:50
p.s. hardly anyone uses OWA so if that's causing problems I have no problems taking it out back and shooting it –  Matt Rogish Jun 12 '09 at 13:51
32bit Win Svr has a limited amount of Non Page Pool(NPP) memory to start with. Using the /3GB flag chops that to a crippling number. IIS needs to use npp or you'll have issues with connections coming through OWA (HTTP-RCP/Exchange Proxy) or ActiveSync over RPC (Smartphones). I had fun with this one a few years back and had to back out my /3GB because I needed all the connectivity through HTTPS/IIS. Peek into your IIS logs for errors about NPP or try turning off IIS. –  Jeff Hengesbach Jun 12 '09 at 15:39
You can't "turn off IIS" with Exchange 2003 without crippling its functionality. You can stop the "World Wide Web Publishing Service", but that's not IIS. Without knowing what Perfmon is saying about gross performance characteristics of the system I think any rush to take specific corrective action is premature. –  Evan Anderson Jun 12 '09 at 18:20

The first thing I would do is to use process explorer to determine where the bottleneck is, is it disk or RAM etc. Once you know that you can look at resolving what's causing it. The easiest option is obviously to throw hardware at it, will more RAM or faster disks help, or moving Exchange to its own disk. If this is being caused by spam, you could also look at putting in a front end server to handle spam before it gets to Exchange, something like postfix.

As for configuration fixes, you could look at getting XWall to drop as much spam as possible before it even reaches the Exchange server, which will help reduce the load on Exchange.

share|improve this answer

Your Answer


