• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 32
  • Last Modified:

Identifying who's pounding the Exchange 2007 server

We recently had an incident where a use deleted gigs of email and would up with a corrupt mail box. This it appears was the root cause of large mail queue build-ups to the mailbox server. Once we took this user offline the spiking stopped. So we're fairly convinced this was the root cause. The problem: It took some hunches to figure this out. Is there any logging or diagnostic tool in Exchange to see who exactly is pounding the server and causing a denial of service in terms of ability to deliver email to the mailbox server? It is my understanding that RPC requests within a single (or a few) TCP connections are a limited resource on the Exchahge MB server.  Would there be any means of seeing that say 90% of all the RPC requests are related to one particular user? MS support so far has not offered any insight regarding being able to more quickly trouble-shoot this kind of issue in the future.
Screencap-953-Oct.-18-21.30.jpg
0
amigan_99
Asked:
amigan_99
1 Solution
 
it_saigeDeveloperCommented:
Before I started using an external service to filter my emails, I would log requests to port 25 at my router and use that in conjunction with the SMTP logs.

If you are receiving an excessive amount of potentially damaging traffic, it might serve you better in the long run to look into using an external service.

The benefit of this is that I only allow traffic from my filtering service.

-saige-
0
 
Jeff LewandowskiCommented:
Do you allow the Exchange server to be used as a relay?
0
 
amigan_99Network EngineerAuthor Commented:
No - not as a relay. We have CAS servers at the edge which in turn talk to the mailbox server. Based on a hunch we took on user offline and he problems went away. We put him back online and the problems came back. So we know the issue and in fact it's solved for now. But if this happened again in the future we might not know who was pounding the mail server. As I understand it multiple RPC requests within a TCP conversation are sent to the mailbox server from the CAS. Once a finite limit is reach the server can process no more requests. My question is - how do you tell how's making all of those RPC requests? Who's the pig??
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Jeff LewandowskiCommented:
Try something like Microsoft Exchange Server User Monitor (http://technet.microsoft.com/en-us/library/bb508855%28v=exchg.65%29.aspx) and SolarWinds® Server & Application Monitor (http://www.solarwinds.com/solutions/exchange-server-monitor.aspx).

Also, you can check the logs without any additional software or tools.
0
 
Simon Butler (Sembee)ConsultantCommented:
Most monitoring tools can detect a heavy user responsible for the bulk of the RPC traffic.
The Exchange Troubleshooting Tool can also flag a single user as well, although that needs to run in real time, rather than getting historic information.

Simon.
0
 
amigan_99Network EngineerAuthor Commented:
@Jeff It turns out we've been using Microsoft Exchange Server User Monitor. But oddly it revealed no anomaly for the user whose mailbox was causing the problems.  

I use Solar Winds a lot and have some Exchange monitoring. That's how I graphed the queue backups. Are there other Exchange monitors that would get into displaying user level stats??
0
 
Seth SimmonsSr. Systems AdministratorCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
0

Featured Post

[Webinar] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now