question

OllieWoodall-0542 avatar image
0 Votes"
OllieWoodall-0542 asked CyrAz commented

SCOM Connector vs SCORCH Integration

Hi All.

I have a requirement to send selected SCOM Alerts, as SNMP traps, to a third party Event Management product. There is no current product connector for this.

The proposed solution is to use SCORCH, which would presumably receive SCOM alerts into a Runbook, via the Integration pack, and then forward these on, as SNMP.

This seems like overkill, we don't need SCORCH for any other purpose right now. Would it not be more sensible to create a custom SCOM connector that can push these alerts? No write-back or bi-directional control is required. Is that quite simple to achieve? Or does it require significant dev? Anyone doing this?

msc-operations-manager
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

CyrAz avatar image
0 Votes"
CyrAz answered CyrAz commented

Creating an actual connector, which is a very specific scom component, would require quite a lot of specialized work as well.
However, given your requirements, a much simpler powershell script that just fetch a list of alerts at a regular interval and send them to another system should be doable.
Or a script triggered by a notification channel everytime one of the specified alerts shows up.

· 4
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks. In the past, I have used Powershell and the Notification Channel to spit alerts out into a flat file, at which point a 3rd Party SNMP trap generator read in the lines and wrapped each line up as an SNMP trap, to a probe collector. I have to say though, that SCOM was quite unreliable with that, sometimes the SCOM Management server just didn't generate the script output, or high volumes of New Alerts would throw it (we have a large environment of 4,000+ monitored servers). Other times, you'd get nothing till you kicked the Management Server in the Notifications Resource Pool.

If we go SCORCH, does the integration pack and RunBook designer give you much value add? Is it's connector a lot more robust?

0 Votes 0 ·
CyrAz avatar image CyrAz OllieWoodall-0542 ·

The issues you mention with scripts triggered by a notification channel are unfortunately pretty common...

I don't really like the SCORCH integration pack and I've not used it for a very long time so I won't make any specific comment, but keep in mind that using another product (here SCORCH) means having to deal with the realiability issues that may happen with that product...

A SCOM connector is basically a windows service (developped with any language you like) that will query SCOM SDK at regular intervals for alerts corresponding to a specific criteria. The service then forwards these alerts to the target system, and mark them as "acknowledged" in SCOM.
Which means that you should never miss an alert with that mechanism : if the service fails for some reason, the alerts are not acknlowedged until the service successfully retries to query and forward them.

0 Votes 0 ·

Thanks. I think the choices we have are the simple script to fetch alerts on an interval, and SCORCH. Development of a new connector seems unlikely. My main concern about the script is the impact on SCOM performance, interrogating the SDK every minute or so with a Get-SCOMAlert cmdlet. I guess one consideration is that any script will need to ensure that it can execute the commands against the Management Server Resource Pool instead of specific Management Servers, for resilience when MS's are patched / rebooted. Will have to do some testing. Can Powershell generate SNMP traps by itself? Or does it need some sort of trap forwarder utility installed on the management servers?

0 Votes 0 ·
Show more comments