The Alert Object’s Update method – bug, or intended feature?

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”)).

What happens?

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”)).

What happens?

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.

PS: It’s my birthday on Friday. Perhaps you’d like to buy something from my wish list? Or at least enter the contest. The next 2 will have considerably better prizes, I promise!

Be Sociable, Share!

•