Alarms not getting triggered for Windows Application log event id 11515

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)
• CA Unified Infrastructure Management On-Premise (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

For one of the servers - I can see that an event - 11515 was triggered in the system. But this didn't reflect in the alarm console (alarm didn't get triggered) due to which the alert didn't reach to ServiceNow, as snmpget is integrated with ServiceNow. Below are the snapshots of the event viewer from the server and enabled profile for 11515 in the ntevl probe of the robot.

Environment

• DX UIM 20.4, UIM 23.4

Cause

• ntevl configuration

Resolution

1. Upgrade robot  to version 9.40 or higher

2. Ensure ntevl v4.35 is in place on the given robots.

   http://support.nimsoft.com/download.aspx?ReleaseId=5203&state=GA 

3. Set 'Maximum Number of Threads' to 100 (minimum)

4. Set Alarm Timeout to an empty value

Even though you cannot reproduce the alarm, you can always test ntevl performance and try to reproduce an issue by using Microsoft eventcreate and send a bunch of back-to-back events simply by using the command history in the cmd window and pressing enter over and over and you can see the events update in the ntevl probe Status Tab.

It's very useful and it's easy to run tests using the eventcreate tool:

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/eventcreate

Here is an example of an eventcreate message that can be used in testing a given event/event ID, e.g., 999.

C:\>eventcreate /t error /id 999 /l Application /d "An unexpected error has caused a DPM service failure. Restart the DPM service." /so MSDPM

SUCCESS: An event of type 'error' was created in the 'Application' log with 'MSDPM' as the source.

Its not necessary to use the exact event ID to prove that the alarm is generated when using eventcreate to generate the event. Use 999 for now to make sure an alarm is generated. In the profile set the event ID to asterisk *. Then you will know the rest of the filters are working as expected.

If youre ever suspicious that alarms are being generated but not showing up for some unexplained reason, always check the alarm tables for the alarm youre expecting, just in case you have some nas AO Profile(s)/pre-processing rules interefering with the alarms, e.g., 

select * from nas_alarms where message like '%Switch initiated%'

select * from nas_transaction_summary where message like '%Switch initiated%'

select * from nas_transaction_log where message like '%Switch initiated%'

The query results will tell you if and when any alarm regarding the message such as a 'Switch initiated' event occurred but was opened and closed very quickly, or filtered or excluded via pre-processing.