Monitor network connections and listening ports with SCOM

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.

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 ^


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:


"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 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.


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.

Want to write for 4sysops? We are looking for new authors.

Read 4sysops without ads by becoming a member!


Leave a reply

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


© 4sysops 2006 - 2020


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


Log in with your credentials


Forgot your details?

Create Account