Notification Subscription problems, when mass updating alerts via Script
-
Friday, January 20, 2012 8:01 AM
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,
Dirk
All Replies
-
Tuesday, January 24, 2012 2:13 AMModerator
Hi,
Firstly, please disable the script and check if the issue persists.
To customize the contents in the notification, please try the following methods:
Adding custom information to alert description (s) and notifications
Some Notification properties that may prove useful
http://blogs.technet.com/b/cliveeastwood/archive/2007/10/12/a.aspx
Alert Notification Subscription Variables, and linking that to the console, database, and SDK
Hope this helps.
Thanks.
Nicholas Li
TechNet Community Support
- Proposed As Answer by Nicholas LiMicrosoft Contingent Staff, Moderator Tuesday, January 24, 2012 2:14 AM
- Unproposed As Answer by Nicholas LiMicrosoft Contingent Staff, Moderator Tuesday, January 24, 2012 2:14 AM
- Edited by Nicholas LiMicrosoft Contingent Staff, Moderator Tuesday, January 24, 2012 2:18 AM
-
Wednesday, January 25, 2012 6:01 AM
Hi Nicholas,
thanks for your reply. The issue doesn't exist, when the script is stopped.
Dirk
-
Friday, January 27, 2012 9:24 AMModerator
Hi,
Thank you for your update.
May I know if the method of customize the contents in the notification can meet your requirements.
Based on the current situation, I think you may need to check the script. Meanwhile, please see the following method:
Updating custom alert fields using subscriptions and powershell
Thanks.Nicholas Li
TechNet Community Support
-
Friday, January 27, 2012 9:43 AM
Hi Nicholas,
i don't think that is related to the script. Inside the script i do a simple:
$colAlerts = get-alert -criteria "xxx"
foreach ($alert in $colAlerts) {$Alert.CustomField1 = y; $Alert.Update($comment)}
As soon as in $colAlerts are Alerts which are younger than 60 Seconds, SOME (not all) new Alerts will not be notified by SMTP. If i modify the Script in a way like this:
$colAlerts = get-alert -criteria "xxx And TimeAdded -gt (Now + 60 Seconds)"it works.
IMHO this has something to do with the internal processing mechanism inside of the SCOM Notification engine. Is there any explanation for this behaviour?
Dirk
.png)
