What I've been trying to do is filter the traps that come through from
the windows boxes to only those the customer is interested in. The
filters defined below are working pretty well to that end, with the
following exception: The customer has RSA services installed on each of
the domain controllers and the ACE client keeps writing [hundreds of]
security messages to the application event log (as errors, not
warnings) and these keep showing up in C1 in their hundreds. There
are only the two application errors that I want to filter out: event
ids 10022 & 10304. I have tried inserting an additional filter
:Filter5.EventID=!(10022,10304) - but this has no filtering effect on
the traps. Do you have any suggestions, please?
NTTRAP.INI*****************************************************************
[Available Filters]
Filter1.TrapType=system
Filter1.EventType=1
Filter2.TrapType=application
Filter2.EventType=1
Filter3.TrapType=security
Filter3.EventType=1
Filter4.EventID=(2,... [truncated] ...,5789)
[Actual Filters]
1=Filter1
2=Filter2
3=Filter3
4=Filter4
*****************************************************************
SITE MGMT SERVER Properties\Rules\Conditions\Alarms:
Severity = Critical or Major
Or if the Alarm state = Non-Operational
*****************************************************************
Thanks in advance,
Bronwyn.
>There
>are only the two application errors that I want to filter out: event
>ids 10022 & 10304. I have tried inserting an additional filter
>:Filter5.EventID=!(10022,10304) - but this has no filtering effect on
>the traps.
I don't have any idea for a real fix, but what about creating a rule that
auto-handles the events. This way the events will be purged when the
automatic purge happens.
This should save your db keeping C1 usable.
--
Jared Jennings - Data Technique, Inc.
Novell Support Forums Sysop
My Blog and Wiki with Tips, Tricks, and Tutorials
http://jaredjennings.org
I'm not sure this solution is a good idea since this particular client
will be feeding C1 onto a wall mounted flatscreen so the support staff
can monitor alerts as they come in... ...the servers generating these
events would still end up in a constant state of alarm, since the purge
is only running nightly.
Would it be possible to discard these events before they're written to
the database, or somehow force them to become unknown ?
>...the servers generating these
>events would still end up in a constant state of alarm, since the purge
>is only running nightly.
Hum, not that I know of.
Let me see if someone else has a suggestion.
Just checking....But the service was restarted after you made the
changes.. Right?
I have an updated file....that I would like you to try.. Were do you want
it sent too?
You can mail me directly at jaredljennings at gmail dot com .. If you
want... THe file will come from Novell.
Hi Jared,
I received the two dlls from Novell and replaced them on two servers
in our prdouction environment (as per instructions received) and I can
report, unfortunately, that there has been no improvement.
I cleared all the relevant traps from Console One prior to
implementing the trial fix and today (6 days later) there are 500 odd
of them returned from the two servers patched.
Any other ideas on where to? Is it back to the drawing board?
Bronwyn
>Any other ideas on where to? Is it back to the drawing board?
I will have to ask as I don't have a windows box to test this on...I will
get back with you on this.
Actually, could you send me the nttrap.ini and any errors from event
viewer that might happen when the snmp service is restarted.
Send them to jaredljennings at gmail dot com
>Filter2.TrapType=application
>Filter2.EventType=1
try moving this filter to the bottom of the config file.
>
>sent files through as requested
Thanks, I will look at them.
We see that you are filtering out events 10022 and 10304, are these the
only events that are making it past the filter or are other events making
it through?
Also, could you send me a Windows Event log, which should include these
events.
Yes - all the 'filtered' events are making it through. I have sent
the event log to your account previously specified.
>Yes - all the 'filtered' events are making it through.
Ouch.
Received the email. Looking at it.
Just to make sure..Because we are having trouble duplicating this issue.
You copied the updated agent files into ZFS_AGNT\ntagent\bin and
the ini file is in ZFS_AGNT\ntagent\ini
Hi Jared - yes, I do have the files in the locations above. Are you
using the filter I sent through? Could you send me your ini?
Regards,
Bronwyn.
At this point, I think it's best that you open a SR. I am unable to test
this at this time and it would take to long for me to play the middle man
for you between Novell.
Sorry I couldn't help more.