August 7, 2017

How to create 100’s of TCP monitors in minutes with SCOM

Today we thought we'd highlight a fantastic new blog site from a rising star of the SCOM Community, Jasper Van Damme. We've worked closely with Jasper for some time, he really knows his stuff and now he's sharing the best of his knowledge of SCOM with the rest of the community. Although it's still in its infancy, we highly recommend you follow his blog, which is already full of useful hints and tips.

To give you a taster of the type of material you can expect from Jasper, we've published a guest blog from him below;

Create 100’s of TCP monitors in minutes with SCOM

By Jasper Van Damme

As you may or may not know, creating TCP monitors in SCOM through use of the template is a fairly time intensive task, especially if you have to create a ton of TCP monitors. Furthermore, templates are fine for smaller scale Operations Manager environments but tend to create a lot of unnecessary groups, overrides, views etc.

So naturally I was looking for a more elegant solution as I did not want to go through creating 100’s TCP monitors. My first thought was to google if anything exists already, and to my surprise, I did not find any immediate solutions. What I did find however was the following post (credits to Gowdhaman Karthikeyan).

This post explains how you can use a PowerShell discovery with a comma separated file or ‘CSV’ to add the proper TCP Port instances in SCOM. This has some significant advantages over using the template (as outlined in the blog post):

You can let other teams add TCP monitors themselves, with minimum SCOM knowledge or access
It is more scalable, as it does not create any unnecessary groups, overrides, views compared to the template
It is a lot faster, as you dont have to go through the template for each TCP monitor you want to create
The information is centrally stored in the CSV

The blog post covers the class/discovery creation of these TCP port instances, but does not cover the monitoring part. As I did not have time to wait for part 2, I decided to use his management pack to add monitoring to it as well.

To enable monitoring I went through the following steps:

Created a Visual Studio solution and migrated the classes/discovery in my new management pack
Create a ‘dummy’ TCP port monitor from the template wizard and save it in a new management pack
Export this management pack, and manipulating the data sources to change the hard-coded stuff to the properties of our custom class

The initial data source for the monitor, which was generated by the template, will look like this. The bold part is the hard-coded part we need to replace. However, we have not yet added any data from our target class to the data source - something we will need to add to this as well.

The data source therefore eventually looks like this.

The monitor types will have to be changed as well, as the properties of the class are not passed through in the template version of the monitor. So the code went from this to this.

By changing the monitor types and data source part of the code, the hardest part is basically done. All we have to do is create four monitors and use the proper monitor types. These are the monitors that are included in the management pack:

TCP Unreachable Monitor
TCP Timeout Monitor
DNS Resolution Monitor
Connection Refused Monitors.

I have not added any performance collection yet, but will endeavour to add this in a later stage.

Before or after importing the management pack, make sure you follow these steps:

A share on which you will place the CSV file. It should be reachable from the management servers and the default management server action account should have access to the share. The discovery runs on an a default interval of 4 hours. The CSV file should look like this (make sure to use a ‘comma’ as your delimiter!):

Change the ShareName of the discovery by overriding the file path property in the discovery (TCP Monitoring Class Discovery).
Create views based on the TCP Monitoring Class, as I always use SquaredUp instead of the standard scom console, I decided not to include any views in the MP. Here are some screenshots of what it looks like: