SCOM 2016 – Network Monitoring MP Generator Tool

In one of my previous posts, I covered SCOM 2016 TP5 – What’s New and one of the topics mentioned was, that Microsoft will provide a tool to generate SNMP management packs. A what? Ok, let me explain. You are able to monitor network devices via SNMP. Well this is no magic and pretty common these days. SCOM 2012 provided a new rebuild SNMP stack for monitoring network devices. The magic was / is, that you just need to discover the device and SCOM will take care of the rest, meaning it will discover model, type, cpu, memory, network traffic and a lot more. There is just one problem, because there are so many devices available, SCOM cannot support all devices to the same level. What does that mean? There are “Certified” devices for SCOM which will be monitored very deeply and there are “Generic” devices which are just monitored in a less deep way.

1. Basic Monitoring – This includes “Availability Monitoring” and “Port/Interface monitoring” for all network devices that have implemented the interface MIB (RFC 2863) and MIB-II (RFC 1213) standards.
2. Extended Monitoring – This includes monitoring Processor and Memory components of the network device. This level of monitoring is currently available only for network devices certified by Microsoft, as those components could be discovered and monitored mostly through private MIBs.

As you can see there will be missing information depending on the device support. To close this gap, Microsoft created a command line tool to generate a management pack which will monitor these missing things.In this example here, I will kind “abuse” this tool to monitor a Windows Server via SNMP. Because I don’t have a network device and I want to do a bit more advanced stuff we will create a SNMP MP for a Windows Server 2012 R2. Some of you SCOM guys will now yell at me – “That is not possible, because you cannot discover Windows Servers via SNMP in SCOM!”. Of course it is!

How does this Network Monitoring MP Generator Tool work at a high level view? Well, basically you provide an OID (Object Identifier) for the target, an OID for the value you want to monitor and then you need to set thresholds for triggering alerts. That’s it, the tool itself will create all necessary information in the background. So let’s start, first we prepare our target server for monitoring…

Step 1 – Install SNMP service

On your Windows Server go to Add Roles and Features wizard and select SNMP Service in the Feature section, it will look like this…

After you installed the SNMP service, open the Services MMC and open the SNMP service, select the Security tab and configure the SNMP settings like below, in this example I will provide a read-only community string public…

So, now we are able to query our Windows Server with the “password” / community string public and getting all the SNMP information.

Step 2 – Configure SCOM for SNMP discovery

Out of the box SCOM will not discover any Windows Server, it is just prevented within a the network configuration files. BUT, it says configuration files and configurations files are there to configure properly :). Kevin Holman has blogged once about this hack. What you need to do is just to configure the \Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\NetworkMonitoring\rules\discovery\ic-post-processor.asl file and set the following settings…

We now just disabled four checks which test either for MICROSOFT, Windows, Windows Server OID, ntEMANATEMasterAgent OID. Now we are able to discover our Windows Server in SCOM…

Step 3 – Discover Windows Server

In the SCOM console go to Administration/Network Management and create a new Explicit Discovery Rule, like in this screenshot…

I am assuming you know, how to discover network devices, if not, please read this TechNet article here. After successful discovery the Windows Server will appear in the Network Monitoring/Network Devices view…

At this point we have build the foundation for monitoring our Windows Server. Next we need to figure out WHAT we want to monitor. If we check the Health Explorer we can see there are just two monitors…

…and one ICMP Ping Response Time rule, which we can see in a performance view…

Step 4 – Find Windows Server Management Information Base (MIB)

On the server, where you installed the SNMP service you will find some pretty neat information about the Windows Server MIB. During installation of the Windows SNMP Service, specific MIB files were added in the following directory C:\Windows\System32…

There are MIBs for FTP, IIS, DHCP etc. we are interested in the hostmib.mib file. A MIB file defines what OID provides real time values for cpu utilization, ram utilization, user session, storage information and a lot more. To explore these MIB files, we need a MIB browser tool, there are many on the internet. I downloaded the free version of iReasoning MIB Browser . Just download and install the tool…

Next open the hostmib.mib file in this tool, in my case I just pick two values which seem to have some information like these here…

• hrSystemNumUsers (.1.3.6.1.2.1.25.1.5) – The number of user sessions for which this host is storing state information.  A session is a collection of processes requiring a single act of user authentication and possibly subject to collective job control.  
• hrSystemProcesses ( .1.3.6.1.2.1.25.1.6) – The number of process contexts currently loaded or running on this system.

Ok now that I know what I want to monitor, we actually need to create the management pack. We will add some meat to that bone…

Step 5  –  Using Network Monitoring MP Generator Tool

This tool will be shipped under %Program Files%\Microsoft System Center 2016\Operations Manager\Server\ folder of SCOM 2016 Technical Preview 5 (Build # 11469). The primary goal of this tool is:

1. To have extended monitoring for their generic devices (non-certified as of SCOM 2012 R2).
2. To add monitoring to new components (like fan, temperature sensors, power supply) in addition to the existing ones (Memory and processor) for their devices.

The tool itself is very easy to use, there are only three parameters, input file, output path and if you want to overwrite the destination file…

So how does the input file look like? Let’s first get an overview, if you have authored management packs for SCOM before, then this configuration file should look familiar to you. I tried to show you in each section the corresponding output in within the SCOM console…

Now lets talk about each section, I have copied the relevant information from the actual guide which you can find here…

Manifest:

The Name specified here is used as the display name of generated MP. The general rules for any MP’s display name would apply to this field. The Id of generated MP is derived from this field by removing all non-alphanumeric characters and prefixing the “System.NetworkManagement” namespace with it.

The Version specified here would become the version of generated MP. Again, the general rules for any MP’s version would apply to this field. It’s recommended to update the version whenever users modify the input XML file and use it to generate the updated MP.

Device:

One device node for each device should be specified. Device node has one Mandatory Child element “Device Discovery” and optional child elements “Components” and “Monitoring”.

Device Discovery Node:

This is a mandatory node. Users would need to specify the system object id of network device that will be used by the generated MP to uniquely identify (discover) the device. Users can optionally specify the type, vendor and model name of the device under this node.

Component Node:

This node needs to be specified if you need to discover individual components of the device and create rules and monitors targeted on them. Create one Component child node for each device component that you want to discover and monitor.

Each Component node would have a type and a name. Currently the following types of components are supported for discovery and monitoring.

• Memory
• Processor
• Fan
• TemperatureSensor
• VoltageSensor
• PowerSupply

OID Node:

Declare all Oids needed to discover and monitor the device component in this section as shown.

Component Discovery:

ComponentDiscovery node is used to specify the OID that’ll be used to discover the device component. Only the name of an already declared Oid (in Oids section above) can be specified. The generated MP will do an SNMP walk of this OId to determine how many instances of the component exist and discover the index of each one.

Rules:

In this section users can specify one or more performance rules targeted on the device component.

Monitors:

In this section users can specify one or more unit monitors targeted on the device component. Currently, only two state monitors are supported. Each monitor would have two expressions that’ll define exclusive conditions for those two states. The state of an expression can be any one of: Success, Warning and Error. A unit monitor will issue an alert when it goes to error state. The alert will be resolved automatically when the monitor returns to healthy state. All the monitors targeted on the device and its components will roll up to the device’s health.

After you configured your desired file you need to actually build the management pack. Provide this file as input file, specify the output path and if you want to override the target MP file (if it already exists)…

That’s it! Next import the generated XML file. You could seal the MP if you want and need to…

Next let’s see what has been done under the hood…

Discoveries:

There are three discoveries created, one to discover the target Windows Server node and then the component e.g. processor…

The node discovery runs every 7 days…

The component discovery runs every 5 minutes…

In terms of Overrides there are only the default parameters exposed like interval etc…

Rules:

If you select the target WindowsDemo this class name we have specified in the configuration file, you will find our specified performance rules…

Both rules have a collection interval of 5 minutes…

…and some exposed Override parameters…

Monitors:

If we check the monitor section we will find the two specified monitors…

Both monitors are SNMP probes monitor and will check every 5 minutes…

For the configured threshold, like here…

…and of course you are able to override these settings…

Ok perfect, but how does it look like in the SCOM views? Because we classified the Windows Server within the configuration file a Router it appears in the Router view…

The Health Explorer looks like this…

The alert created by the monitor has basic information…

..and the alert context looks like this…

Just for the performance rules, I created a custom performance view…

….and added the rules, as you can see data is collected…

Write action of the rule is also targeted at the data warehouse, so you just could run reports on this collected data.

Conclusion:

As I have showed you, you can use this tool to create a SNMP MP easily for SCOM. You need to know the proper information and the rest is just creating a structured configuration file. The SCOM team has also written a short post about this tool here and also provides a bit more detailed guide for a more complex SNMP management pack. In this post I wanted to show, that there are not only network devices which we can monitor using SNMP, there are a lot more devices out there. What I am missing is a GUI to configure the configuration file, additionally it would be great if this tool would be more generic in terms of components. At this time we only can provide memory, processor, fan, temperature sensor, voltage sensor, power supply. But what if there is a case like mine? Which component should I use? I have not tried to build a more complex MP, it would be interesting to see how the tool behaves if we are going to query more complex values and instances. I think it is a good, easy and transparent way for creating SNMP management packs. Try it out!