The following article briefly explain the components of a SCOM management tool I published on GitHub that allows you to monitor network connections and listening ports with the help of netstat and PowerShell.

Ruben Zimmermann

Ruben is an infrastructure specialist who specializes in Active Directory, public key infrastructure (PKI), and System Center Operations Manager. He automates in VBS, PowerShell and C#. Ruben lives in Suzhou, China, and you can follow him on Twitter @Ruben8Z.

System Center Operation Manager (SCOM) TCP port monitoring allows you to identify whether a port on a target machine responds. However, cases exist where you don't want to or can't establish a connection to the remote machine. The management pack discussed in this post uses netstat and PowerShell to monitor active connections and listening ports.

Diagram view showing monitored listening ports and TCP connections

Diagram view showing monitored listening ports and TCP connections

To ensure the management pack also runs on Windows Server 2008 R2, it is compatible with PowerShell version 2.

SCOM connections and ports discovery ^

SCOM first has to discover the connections or ports that need monitoring. The file named monitoredTcpConnects.csv stores the connection and has this structure:

It needs to store the ports in a file named monitoredListeningPorts.csv:

Listing connections and listening ports ^

Running netstat -ano lists all established connections and listening ports including the process identification number (PID):

Listing all connections and listening ports with netstat

Listing all connections and listening ports with netstat

The PowerShell function below runs netstat, stores the result in a file, and then converts the file into a list of objects for further processing. A parameter decides whether the list will contain "listening port objects" or "established connection objects." Note that piping the output of netstat ‑ano into a file that it then reads is faster than directly storing the result in a variable.

Interpreting output and initiating reaction ^

To check whether a defined connection is active or a port is listening, we compare "should and is." I only show the script for the connections below because the code for listening ports is very similar. You can download the entire solution from GitHub.

Management pack components ^

Classes

Everything in SCOM that has a health state is an object. Instead of checking all Windows computers whether those files exist, we define a dedicated computer class.

We also require a class for TCP connections and listening ports:

Discoveries

"Discovery" is the the mechanism of creating objects that match the definition and storing them in the SCOM database. There are different types of discoveries, starting from matching registry values over results of a Windows Management Instrumentation (WMI) query to scripts that can cover everything. Targets define on which component the discovery will run.

First, we use the discovery Discovery.NetstatWatcher.Computer to find computer objects. It targets all Windows computers (which SCOM already monitors).

The FilteredRegistryDiscoveryProvider discovery scans the registry, and if the key HKLM\ SOFTWARE\ABCIT\NetstatWatcher exists, it will create the object. The interval is daily.

Also discovered here is the FilterPath, which defines the path in the file system where we'll find both text files.

The second discovery Discovery.NetstatWatcher.listeningPorts finds listening ports reading out monitoredListeningPorts.csv. It targets the previously discovered …NetstatWatcher.Computer computer objects.

The TimedPowerShell.DiscoveryProvider triggers the DiscoverNetstatWatcherItems.ps1 PowerShell script that does the logic (see above: Preparing raw data). The interval is hourly.

The third discovery Discovery.NetstatWatcher.tcpConnections finds listening ports reading out monitoredTcpConnects.csv. It targets the previously discovered …NetstatWatcher.Computer computer objects.

The fourth and fifth discoveries Discovery.NetstatWatcher.ComputerHostsTcpConnections / …ComputerHostsListeningPorts create the relation between computers and the monitored objects.

The TimedPowerShell.DiscoveryProvider also triggers DiscoverNetstatWatcherItemRelations.ps1 script. The interval is hourly.

Monitors

Monitors are for finding out which health state an object has.

  • tcpConnection targets all objects of the class Network.Windows.Computer.NetstatWatcher.TcpConnection.
  • listeningPort targets all objects of the class Network.Windows.Computer.NetstatWatcher.ListeningPort.

This monitor here uses the PowerShell script MonitorNetstatWatcherItems.ps1 to determine the state of the object (see above: Interpreting output and initiating reaction). The interval is every five minutes.

Views

State views make all discovered objects and their health states visible.

State view showing listening ports

State view showing listening ports

State View showing TCP connections

State View showing TCP connections

The system creates alerts for non-listening ports or lost connections. The NetstatWatcher Alerts view shows these.

Conclusion ^

You can download the management pack with the .xml or. mpb extensions from GitHub. I published the entire software under the GNU General Public License GitHub. Feel free to use it without costs or obligations. The software is provided "as is" without express or implied warranty.

If you don't like the naming used, feel free to change the text in the XML file. Make sure you search with case sensitivity. I used Visual Studio 2015 with the Authoring Extensions add-on for this management pack.

Are you an IT pro? Apply for membership!

4+

Users who have LIKED this post:

  • avatar
Share

Related Posts

0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2018

Log in with your credentials

or    

Forgot your details?

Create Account