Notification Subscription problems, when mass updating alerts via Script


  • Hello Community,

    i would like to get some comments/help on a strange SCOM notification issue:
    Because of the nasty SCOM behaviour, that not all alerts contain usable hostnames, we created a script, which checks all new alerts, modifies some properties and raises the alert resolutionstate of ALL new alerts to a higher value (so that we can distinguish new Alerts from already processed ones).
    This script runs as a scheduled task every minute and it runs fine. But we discovered incidentally that some new alerts are not notified by notification subscriptions anymore...

    All subscriptions are based on ResolutionState = 0 and we assumed that, as soon as an alert is written into the database, it will be notified. But somehow our script was "faster" than the notification engine. So we modified the script: the script now checks the TimeAdded property of an alert and modifies only alerts which are at least 30 Seconds old. So an alerts stays at least for 30 seconds in the ResolutionState = 0. This should be enough time for the RMS to notifiy the alert. But unfortunately this is not the case. Some alerts still don't get notified, when the script is running.

    This issue raised several questions, which i can not answer myself an need some advice:

    - Why does the notification engine not process the alerts immediately?
    - How can we be 100% sure, that an alert is processed by the notification engine? We don't want reactive feedback of a customer, who complains about alerts not notified by SMTP.
    - Should we just raise the timeframe up to 60 seconds?

    By the way: Yes, we could change our subscriptions not to listen on RS = 0 but on RS > 0, but this would make our whole notification system 100% dependent on a successful script execution. As we can not 100% trust the task scheduler, this is not our preferred solution...

    Any answers are highly welcome,


    Friday, January 20, 2012 8:01 AM

All replies