I have been looking at ways to dump rules so that they are readable at the moment. There is a command shell line you can use to output the MP contents to XML which is great, but what good is that actually to you in terms of reporting ? Well, after messing around with it for a while I found good old Excel was the best bet for viewing the data and a conversation with Jakub Olesky one of the MOM developers on the newsgroups helped a lot as well.
First up the powershell, this is pretty well known but you can dump all your rules using this line:
Get-ManagementPack -Name “Microsoft.SystemCenter.2007″ | Export-ManagementPack -Path “C:\”
this leaves you with an XML file but to make sense of this I find it easier to open it in excel and use the “use xml source task pane” option when you open it. This gives you all the schema down the right hand side (see the picture “The Excel Spreadsheet”).
You can now just drag and drop the fields onto excel and then right click and choose to “refresh xml data” and it populates the column”. You have to know what you are looking for but some experiementation gets you there.
In my case I was after all rules that result in a critical alert being raised. To find this I used the Rules part of the XML schema and was interested in any rules that had a “Write Action” with Severity 1 which meant they raised critical alerts. By dragging the ID column of write action and the “Severity” column of write action I was able to get the alert name that would be raised and could sort by severity. If I had added the Rule “ID” column that would have given me the rule name as well though these two fields are commonly the same.
The only other thing I wondered Jakub helped me with. If you are forwarding your alerting to an upstream environment then what about state changes ? It’s alright having alerts as they are documentable but how do you “document” state changes to an upstream monitoring system. This is where Jakub helped me out, here’s the thread, but read it from the bottom up because its a dump of replies in the newsgroups:
The short answer is nothing.
Longer answer: If a monitor is defined as going to a critical state, but not
generating an alert mostly likely one of two things is happening:
1. The state is being rolled up in some fashion and the “critical”
nature of that state change is reflected via the roll-up to a different
monitor which WILL generate an alert when appropriate roll-up conditions are
met (worst-of, percentage, etc).
2. There is a bug in the monitor’s design =)
The connector api as designed does not deal with state changes, but rather
alerts. State changes without alerts are there for modeling problems in
greater detail, while minimizing “noise” of generated alerts for the same
problem.
Does this make sense?
For your requirements, I am not sure what is the “right” approach. You
*could* go through the process of documenting all the montiors that don’t
generate alerts as well, but this would never be seen in a console that
looks at alerts.
–
Jakub Oleksy
Developer
Blog: http://blogs.msdn.com/jakuboleksy/
Log a bug or Feature Request directly to the SCOM Product Team by going to
http://connect.microsoft.com/site/sitehome.aspx?SiteID=209. This posting is
provided “AS IS” with
no warranties, and confers no rights.
“Mike Betts” <mike@nospam.com> wrote in message
news:79CDF7C8-4F0A-4E04-9D61-3639A9440EAA@microsoft.com…
> Thanks Jakub,
>
> That leads me neatly onto the crux of where the question leads… I have
> successfully looked at the xml output and using Excel no less produced
> something that lists rules if the write action generates a critical error
> which is great but (and this is a very general question).. MOM only
> generates alerts for some things now, whereas many are done by health
> state via monitors which often do not generate an alert (I think, correct
> me if im wrong). When it comes to both documenting the “severity” of
> monitors and also exposing this to a parent monitoring system for the
> building of a connector what do health state changes “appear” as to a
> parent monitor if you see what I mean. By example, take the SDK connector
> example on MSDN – it picks up alert objects and forwards them but how does
> it detect state changes and what does it send upstream if a state change
> occurs but no alert is raised on the back of the monitor.
>
> Where Im coming from is that the parent monitoring team are asking for a
> list of alerts and their severity both from a documentation perspective
> and also with a view to the upcoming connector we will build, but how do I
> present from an object sense the idea of a health state change because it
> is “critical” but it isnt an “alert” so what should they look for or
> expect to receive upon this occurring in MOM at the parent monitor level.
>
> Apologies if my question is a bit foggy, I am using general terms because
> state is something that is easy to explain within windows but I dont see
> how you can “convert” it into the id-alert-severity approach the
> traditional monitoring systems are used to.
>
> Thanks
>
> Mike
>
> “Jakub Oleksy [MSFT]” <jakub.oleksy@online.microsoft.com> wrote in message
> news:O4StlQjwHHA.2004@TK2MSFTNGP06.phx.gbl…
>> Are you concerned only with rules that produce alerts, or is there some
>> heuristic you use for all rules?
>>
>> For alert-based rules, the first thing you need to do is figure out if
>> the rule is an alert based rule. You do this by looking at the write
>> action module of the rule (either from exported xml, UI or SDK). In the
>> configuration of the module, the severity of the generated alert should
>> be present.
>>
>> Monitors can also generate alerts, but their alert generation is built
>> into the schema of the monitor itself, rather than generic module
>> configuration.
>>
>> Let me know if you have further questions or need some specifics.
>>
>> –
>> Jakub Oleksy
>> Developer
>> Blog: http://blogs.msdn.com/jakuboleksy/
>> Log a bug or Feature Request directly to the SCOM Product Team by going
>> to
>> http://connect.microsoft.com/site/sitehome.aspx?SiteID=209. This posting
>> is
>> provided “AS IS” with
>> no warranties, and confers no rights.
>>
>> “Mike Betts” <mike@nospam.com> wrote in message
>> news:9458AC34-186D-4498-94AA-9ACF033A6421@microsoft.com…
>>> Hi this is just a new spin on an old question: I need to document all
>>> rules in each MP with their severity. So for example I need to list all
>>> rules that will raise severity critical in the windows 2003 OS MP. I am
>>> aware I can dump sealed MP’s to xml using PS but this does not (as far
>>> as I can tell) give me this information. Is there any way to report or
>>> retreieve this information ?
>>>
>>> Thanks
>>>
>>> Mike
>>>
>>
>
