SCOM: Locally Monitoring a Listening TCP Port

Typically, one would monitor a TCP port remotely, from a designated watcher node, as a means of confirming availability of a network service, but in some cases, this may not be the most desirable method to poll for TCP port status.   For example, if you wanted to monitor the availability of tcp port on a large number of servers that are SCOM agent-managed systems, where you are concerned with the availability of the particular port only when the rest of the system is functioning normally, it may make more sense to monitor this port status locally from the agent.   This minimizes the number of false alarms (each time the monitored nodes are taken down for maintenance, the remote monitor will throw alerts) and also makes deployment much easier (simply target groups for overrides to enable the monitor).  
A simple VBS script that calls portqry.exe (from the Windows Support Tools) or “netstat –an” and parses the output to confirm port listening status can fulfill the monitoring role in this scenario.   I wrote such a script that will use netstat –an to check the TCP ports currently in a listening state on the localsystem  and parse the output to determine that the defined TCP port is in a listening state. 

The core logic can be seen in this excerpt:

sCmd = “netstat -an -proto TCP”
set objShell = createobject(“”)
set objExec = objShell.exec(sCmd)
set oStdOut = objExec.stdout

bl_Healthy = false

Do until oStdOut.AtEndofStream
 sLine = “”
 sLine = oStdOut.ReadLine
 if instr(sLine, “LISTENING”) > 0 and instr(sLine,”:” & nPortToCheck) then
  bl_healthy = true
 end if  

The full script can be downloaded here (this is provided as-is, with no guarantee of function or support, test before deploying, etc).

Walkthrough on creating a corresponding Unit Monitor behind the cut

Start by creating a new two-state timed script Unit Monitor.

Provide a name and Management Pack, and target it to the Windows Computer class, be sure to deselect the “Enable” option.

 Set a polling schedule.

Define the script name and timeout, and copy the text of the script into the window.

Configure the Expressions (the script will return a ‘Status’ property of OK or Error)


Configure the Health States


Configure the alert (the script will return a message string as a property with the name ‘Message’)

To enable the script, override the Enabled property for a single node or a group.   To edit the port to monitor, edit the nPorttoCheck variable in the script.


About Kristopher Bash
Kris is a Senior Program Manager at Microsoft, working on UNIX and Linux management features in Microsoft System Center. Prior to joining Microsoft, Kris worked in systems management, server administration, and IT operations for nearly 15 years.

3 Responses to SCOM: Locally Monitoring a Listening TCP Port

  1. J. Random-User says:

    It looks like netstat needs -p instead of -proto in my case. Also, I’m sometimes getting a Status code of 1 or 128 back from Exec(). Should Run() be used instead?

  2. Keith says:

    What if I wanted to monitor a second port with the same monitor (ie: SIP for 5060/5070)?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: