Link to home
Start Free TrialLog in
Avatar of digitap
digitapFlag for United States of America

asked on

Exchange queue alert

Hello - I have a client running Exchange 2007.  We employ GFI MailEssentials and MailSecurity.  I have a problem where the Exchange queue stalls and email flow fails ingress/egress.  I resolve the issue by restarting some of the GFI MailSecurity services.

Primarily, I'd like to know how I can kick off events when this scenario occurs...I'd like to setup an event that either restarts the whole server or specific services.  This client's dependence on email is growing and I see these issues affecting them negatively in the future.

I know that troubleshooting and resolving the issue with MailSecurity would be the first choice.  GFI is working on a new release that we believe will resolve this issue, but it's still in BETA.  That's not to say, however, that we would not employ a solution to this specific issue if someone has one.

Hope my explanation is clear.  Please inquire if more detail is needed.


Regards,

Digitap
Avatar of suriyaehnop
suriyaehnop
Flag of Malaysia image

If GFI fail, then you may forward the outgoing to DNS as smart host.
Avatar of digitap

ASKER

I don't understand your inference to DNS.
Thanks for the heads-up dude.

If my understanding is correct, this is what you are asking:
a) If exchange queue grows beyond a certain threshold, you'd want to restart A,B,C exchange service ?
OR
b) If exchange queue grows beyond a certain threshold, you'd want to log events which you can check in event viewer ?

Option-A is fraught with risks:
Lot many times legit emails will be clogging the queue and the queue will get flushed on its own accord after it resolves the DNS.
For example - someone is sending out an email blast and you have 100+ mails in the queue. Restarting services in such a scenario doesnt make sense.

If you are trying to come-up with a solution like that, you'd need some service / powershell combination which queries the queue and then does necessary tasks. I dont have an elegant method to do this yet.

I'd rather focus on the main issue first:
- why are emails sitting in the queue. Is it specific to a particular domain like @yahoo.com - and you are getting 5.5.1 / 5.5.4 etc errors.
- is it for a handful of domains.
It will be worthwhile to investigate.

I have a client who had a similar situation after one of their clients changed their mail-security software. I configured a smarthost on Exchange 2003 and had those specific domains relay through my Exchange server. This was a temporary solution, till the client could figure out why it was rejecting emails from us.

Let me know what you think ?
Avatar of digitap

ASKER

your understanding is close.  i believe we know the issue to be with our GFI products and restarting the services resolves the issue.  can't say we've ever had an issue resolving DNS causing an issue with email delivery.

when we encounter an email flow issue, we review the queue and fine over 900 email messages sitting there.  restart the services and email flows again causing the queue to decrease.

our problem is finding a way to monitor the queue so that we "know" when the queue is full allowing us to respond accordingly.

i'm hoping an update fixes this issue within our security software, but having a solution for this particular problem for future challenges would be nice.
Can you check the DNS in GFI mail essentials.

Here's a kbase.
http://kbase.gfi.com/showarticle.asp?id=KBID001770

I will post back when I come up with a Exchange 2007 queue monitor.
The usual way is Open Exchange > Toolbox > queue viewer.

Avatar of digitap

ASKER

this tests out properly.  however, the issue is with the mailsecurity product not mailessentials.
ASKER CERTIFIED SOLUTION
Avatar of digitap
digitap
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of digitap

ASKER

The GFI MailSecurity 2011 update appears to have fixed the stalled service.  Since this is the case, our client has requested we not spend any more time coming up with a queue monitoring solution.  As such, I'm closing this question.