Netcool/OMNIbus Probe for SCOM: Out with the old and in with the new

By on July 5th, 2013 in Advanced Event Management, Best Practices, Netcool, Technical

The original version of the Netcool/OMNIbus Probe for SCOM 2007 proved somewhat troublesome to configure, specifically the communication that required the set-up of SSL certificates. Thankfully the latest version relies on standard Kerberos authentication and so configuration is much simplified.

The Netcool/OMNIbus Probes for SCOM (there are versions to support SCOM2007 and SCOM2012) collect alarms from Microsoft Systems Center Operations Manager (SCOM) and map the alarms into OMNIbus alerts, facilitating the integration of SCOM into the wider enterprise systems management solution. During a recent implementation a few sticky points did arise, but nothing that some extra documentation can’t resolve.

The configuration of the probe connection to the SCOM server is now based on four properties to identify the SCOM Root Management Server hostname and the authentication details (Windows Domain, User and password). These are demonstrated in figure 1.

Figure 1 - Configuration of the Netcool/OMNIbus Probe for SCOM

Figure 1 – Configuration of the Netcool/OMNIbus Probe for SCOM

The probe registers as a connector with the SCOM Server, visible from the menu option Administration->Internal Connectors in the SCOM Console. Selecting the properties for the connector enables the SCOM Administrator to subscribe alarms to the connector thus identifying which alarms will be made available to the probe. See figure 2.

 

Figure 2 - Netcool Probe Connector registred with SCOM

Figure 2 – Netcool Probe Connector registred with SCOM

A few key things to remember during the implementation are:

  • The probe is supported on Windows only
  • The probe cannot be run directly as a Windows Service, but can be run indirectly via process control. This means you must install the Netcool/OMNIbus Server component in addition to the Probe Support
  • The probe will install v14 of the Netcool/OMNIbus non-native-probe. This has implications on the OMNIbus fix pack installed on the probe server, for example FP06 must be installed for OMNIbus v7.3. Failure to install the relevant fix pack may cause dynamic link library errors for the module libOpl.1.dll. Read this IBM technote for more details
  • The probe requires Microsoft .NET Framework v3.5 to be installed. This can be installed via the role manager (the Application Server role) on Windows 2008R2 servers. The following exception is seen when running the probe in console mode if .NET framework is not installed:

Unhandled Exception: System.TypeInitializationException: The type initializer for ‘com.ibm.tivoli.netcool.integrations.scom2007r2.nco_p_scom2007_r2’ threw an exception. —> System.IO.FileNotFoundException: Could not load file or assembly ‘System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ or one of its dependencies. The system cannot find the file specified.

File name: ‘System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’  at com.ibm.tivoli.netcool.integrations.scom2007r2.nco_p_scom2007_r2..cctor()

  • The Probe cannot handle a Windows password that includes certain special characters, for example the asterisk “*”. The probe logs an error when connecting to the SCOM server indicating the user does not have the suitable roles applied
  • The user must copy the SCOM SDK files to the local file system on the probe server. The location is referenced by the probe property ScomSdkDir

During testing and initial configuration it is useful to configure the probe to log informational messages to the standard log file (set the MessageLevel property to “info”). At this logging level the connection set-up to the ObjectServer and SCOM Server can be verified (see figure 3).

Figure 3 - Probe Log file - SCOM connection

Figure 3 – Probe Log file – SCOM connection

 

It is worthwhile noting from the log file entries how long the probe takes to connect to the SCOM Server and consider this when configuring the polling interval for the probe. The default value for the PollInterval property is 10 seconds, much too frequent in many scenarios.

Another key property for the SCOM connection is AlertsBatchSize. This limits the number of alarms that can be collected at a specific polling interval, a protection for the Netcool solution in case of an event storm on the SCOM system.

The default probe rules will be sufficient in many scenarios for basic integration, dependent on the SCOM modules that are being used. If the SCOM subscription includes the “Closed” state then such alarms are suitably formatted to ensure events align with the standard OMNIbus generic clearing trigger. However, on occasions the word “null” is seen in the Node field of the OMNIbus events, dependent on the alarm source, for example, SCOM Heartbeat and Veeam alarms. Basic probe rules updates can be used to capture this condition and populate the field from other tokens.

The optional WebGUI and Native Desktop tools provided are legacy, applicable to Webtop, and are best ignored. However, the batch update tool does provide a scalable solution for bi-directional synchronisation of the state of the SCOM alarms and OMNIbus events. The tool provides the foundations for feeding back acknowledgment and resolution information to the SCOM Server. A few key pointers for implementing this solution are:

  • Perl v5.6 or greater is required
  • ObjectServer v7.3.1 FP05  or above or v7.4 otherwise there are issues with the format of the data returned for the scom_tool.pl

As with all such integration tools the solution will require tailoring for the specific environment and operational requirements, for example the  subscription of alarms for the SCOM Connector and specific event enrichment, but with minimal effort (and fewer headaches than for the previous version) it does enable the swift integration of SCOM Alarms into the Netcool enterprise management solution.

Visits: 473