How to trap NT Event log messages with message rules/actions

[chicocouk]

Sorry, just cannot figure this one out -

Unicenter 2.4, how do you write a message rule to catch anything that is written to the nt event console, and write it to the sendkeep area? I know how to write the sendkeep action, it's the message rule I'm stumbling on, can't seem to get it to match

Advise much appreciated

 

[j1bber]

This may be a daft question but why would you want to do that? Thats what the event log is for. If its its anything like the average server youll just end up with a very full sendkeep area.

 

[chicocouk]

It's not really a daft question given the info i've provided. Basically we have a very unusual architecture, where we have lots of remote sites linked by isdn demand dial. To accomodate this, we don't have a standard unicenter architecture at all. We have a dsm at our end, which doesn't poll the satellite offices, no dsm on their side, but we have an event log on their side which traps critical messages and forwards them up to us. As a proof-of-concept thing, we needed to forward all NT event console messages up, to prove that this would actually be too expensive to management. It's easier to ask people how to set traps to send the message to sendkeep, and let us worry about the forwarding action, as we can write that side of it. It was writing the message rule we were having trouble with, rather than the action. But we've sorted it now, we trapped everything that came through with a user of "N/A". It's not perfect but seems to catch 90% of what we're trying to trap.

Anyway, cheers.

 

[JonnoGT]

I am presuming that you mean the CA event console and not the NT event log. IF not then sorry.
When you forward everything from a remote node why don't you just add a prefix to the message before you forward it.
EG: on remote node:
action is: forward, text is: REMOTE: &TEXT

Then on your main console do a message record to capture REMOTE *

If you wanted you could strip off the prefix at the main console by doing an action of: sendoper or sendkeep,
text: &(2
This will send the 2nd word and anything after it to the console.

Many apologies if I have got completely the wrong end of the stick.

 

[chicocouk]

Thanks for the thought, and you've actually suggested what we already do. We forward events with a prefix to let us know what sites they're being forwarded from.

However, it's not the actions I was concerned about. I know how to write sendkeep actions, forwarding actions etc. It was the message record I was having trouble with. I did actually mean NT events. These are duplicated in the TNG event log, or at the very least, they are on our systems, I don't really know if this is standard or not.

What we were trying to achieve was forwarding anything that originated from an NT event log (duplicated in the TNG event log), and forward that up to us. The nearest thing I could find to achieve this was to trap anything listed in the TNG event log as having a user of "N/A". Other tng events would originate with a user of DomainName\caunint or perhaps NT AUTHORITY\System or DomainName\Administrator and various other things. Observation showed that most, if not all (I am not sure on this point) events which originated in the NT event log, and were duplicated in the TNG event log, were written with a user of "N/A". So we used that in the message record, in the Domain/User field, and this trapped NT event logs, and allowed us to then perform actions on them.

But you're right, we do send the messages up with a prefix, and then on our side check for those prefixes and use actions to highlight them, etc. And we have sort of established that this idea would be too expensive (Our isdn satellite offices call us all the time to tell us someone has printed a document, for example. On isdn demand dial, that's not really appropriate)

Thanks for the thoughts

 

[JonnoGT]

Ah-ha.
Well in that case in the message record gui, on the second "criteria" tab page there is a field called program.
In this put *caoprlog.exe

This will match any message that comes from this program. the NT event log reader.

If you change your console options to display all columns you will see that all NT event messages come from this program.
I've done this before with 2.4 so it should work.

 

[chicocouk]

Right, that's good to know. We went some way down the road of trying to trap caoprlog messages, because we noticed that the nt event logs seemed to come through with caoprlog on them, but in the TNG console log, they're logged as (eg) "Process: 3184,caoprlog.exe", so we tried putting caoprlog.exe in the Source field in the msgrecord, but this didn't work. So if process actually relates to the program field on the msgrecords, that's great, we can trap on that. We've probably given up on this idea for the moment because of cost considerations, but it's good to know how to do it, thanks!