Is it by design that the Alert Descriptions do not change past the first alert? Such as the "Logical Disk Fragmentation Level" has a Description such as this: The disk C: (C:) on computer XTINDC01.xt.local has high fragmentation level. File Percent Fragmentation value is 11%. Defragmentation recommended: true. The condition hasn't changed but the Fragmentation amount has. I want that number to represent the value as of the last check, not the value it was when it alerted. This obviously isn't the only instance that this would occur. I have a management pack I'm creating that does a query on a database where if the query returns results (which could be multiple rows) I want to display an alert with the return values in it. If more rows return during the next check, I want those rows to be displayed as well. I'm trying to replace an inhouse monitoring solution that does just this and I'm having one heck of a time. Any help is appreciated. Thank you! Daven

Hi, The polling interval varies from monitor to monitor. This monitor (Logical Disk Fragmentation Level is high) runs once a week, every Saturday at 3 a.m. by default. So you would not see the updated value until the monitor runs again. I believe this is the reason why the current value is not reflected in the alert description. Thanks, Shaikh

Unfortunately that doesn't seem to be the case. For instance, I created a Rule that generates an alert. This is what the alert looks like 45 minutes after the alert triggered: Instance xtincvi25\private$\incomingstats Object MSMQ Queue Counter Messages in Queue Has a value 60448 At time 2010-07-28T14:04:06.0000000-06:00 The "At time" hasn't changed since the alert went off. The interval is 5 minutes for this rule and the current value for this MSMQ has gone from 60,448 to 109,551 and it was a steady increase over the past 45 minutes. It appears that ALL of my alert descriptions are doing this. The information in the description is valid information for the time that the alert triggers but doesn't update afterwards. Could you possibly verify this with your own findings? Maybe it's something related to some state that my SCOM infrastructure is in? Thank you! Daven

Hi Daven This is the way OpsMgr works. The initial alert is the one you see in the console - so in the alert properties, you'll see Created: Date \ Time and the Alert Description for that alert. After that, Alert suppression just counts how many times this has happened but doesn't change the underlying alert properties. If you open the alert, you can see on the Alert Context tab, the last value time the problem occured and depending on the underlying rule \ monitor, you should see the last value here as well. Cheers GrahamView OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

Ok, so the Alert Context doesn't update any different than the Alert Description. I suppose this is the answer - but definately not a desired result. I understand that this ties into Alert Supression - but really? As a programmer at heart, I can't help but seeing how easy it would be to include the last sampled value SOMEWHERE. We likely will have to turn off alert supression entirely as no one wants to see stale data. Especially when customers are moving from monitoring tools such as Nagios that, while sends you more alerts, visually shows you through it's interface only the current value of the situation. Don't get me wrong, I see the value of knowing what it was when the alert was generated - but between wanting to know what it was when it alerted and what it was the last time it was sampled, I can only believe that a survey would tell you that a very large majority want to see what the most immediate value is as that is what most people use to determine what their response to the alert will be. I'll mark this as "Answered but dissatisfied."

Hi Don't shoot the messenger ;-) I fully agree that it would be extremely useful to see at least "last value" if not a chart of values over a period of time. Some of the alerts do have hyper links in the product knowledge to fire up performance views (e.g. CPU utilisation alert) but that is only a small minority of alerts. You can open up enhancement requests and bug fixes at http://connect.microsoft.com - this will allow others who agree (and I'm one!) to post comments and add their request for this to be added to future versions. Sorry I can't provide a better answer. Cheers GrahamView OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

Hey, Definately not shooting the messenger! I believe some of my frustration is just evident in the message as this complicates my situation and will result in some uncomfortable conversations and unwanted critisims of the product from within our organization. Thank you for pointing out the enhancement/bugfix link. I will defiantely be posting it. Thanks again! Daven

i think you are mistaken. The alert context does show the latest value (well usually) like graham says... Not that it really matters what value in a monitor alert u see as long as you know it's still active. if you feel you need to know the exact value because it determines whether you are going to do something about it or not, then the threshold is wrong and you shouldn't get an alert until the condition where you need to take action. e.g. disk defrag >10%. Does it matter it is 11% or 21%? not really, you just start the defrag. When you feel you should start defrag above 20% and not below, raise the threshold to 20%, so you won't get an alert at 11%. (btw this monitor only checks disk defragmentation once a week). Btw, there's no "alert suppression" possible for monitor alerts as those alerts are only generated (or closed) on state change. Rob Korving http://jama00.wordpress.com/

Just saw that this got a tail-end reply. I disagree, and maybe it is just situational but in my previous jobs it applies as well. In our environment we have pools of servers that have different service-based purposes. Those services have a certain amount of volatility to them as some of the freedoms we give our customers within our AP occasional can cause the service to become unpredictable in many ways. It's besides the point really, but it results in a situation where we want to be proactive to the problem and notice when it's ocurring, not reactive. These pools are mostly 300 - 500 servers per pool and when the situation occurs, <said alert> will trigger. The value that is alerting is suddenly paramount to know on all 300-500 servers. How quickly is that number going up (the number being memory, cpu, disk space, etc) The number could be increasing at different rates on different servers - thus we need to prioritize mitigating steps from within the application based off those servers where "the number" is increasing faster. Since it's not feasible in SCOM (unfortunately) to load 300-500 performance graphs, the one thing we had relied upon from nagios was that the last check gave us the most recent number. We effectively lost that with the move to SCOM on the most basic alerts as well as non-standard alerts. I found a bit of a work around but it's ugly and only works on script monitors. I now get the alert description to update with every check if there was a change from the last number checked as well as send another notification to subscribers.Daven