I’ve talked about this before, calling it the hidden ‘nag mode’ inside of SCOM, but I really need to find out whether it’s intended or not.
Please see the following bug report I filed @Connect.
Essentially, if you grab an alert object via Get-Alert, then call the Update method, one of two things will happen depending on what parameters you fiddled with.
Open up the command console and grab an alert, something like $oneAlert = Get-Alert | Select -First 1
Now, change something in that alert, such as the resolution state ($oneAlert.ResolutionState = 111), then call $alert.Update(“”) (Or comment it with $alert.Update(“Changed resolution state”)).
As you expect, not much, just the alert resolution state was changed. Now grab another alert and call the update method alone ($alert.Update(“”)) or with only a comment ($alert.Update(“Testing an issue”)).
Whatever notification channel attached to that alert – usually email – will now fire again. So is it a bug, or not? If it isn’t a bug, then that’s excellent – we have more tools at our disposal and can now easily add that nag mode. If it’s a bug, that means it will be fixed, and as such shouldn’t be used.
There are additional bugs I need to file, regarding how a lot of the OpsMgr Commandlets, while stating they support the common parameters, actually don’t. And how the filter parameter should follow basic syntax and use “-Filter” instead of “-Criteria”. But that’s for another post.