TCP Port Check – Status Codes and Alert Parameters

One of the Management Pack Templates in the Operations Console offers a TCP Port check capability.  This template creates a monitor which uses the Microsoft.SystemCenter.SyntheticTransactions.TCPPortCheckProbe probe action module type from the Microsoft.SystemCenter.SyntheticTransactions.Library management pack.

We can reference this probe to build out our own custom port check monitors.  If you do, you might want to know the various Status Codes for configuring state and alert, as well as the available runtime output we can use to build our alert description.

Status Codes

0 = Success
2147952461 = Refused
2147952460 = Timeout
2147953401 = DNS Resulution Failure
2147952465 = Unreachable

Runtime Output (for alert description)


Comments (3)

  1. I think this is one of the things I've been searching for. I have created several TCP monitors to monitor our 3 license server's licenseing ports. I've also created a powershell function to give me some details regarding the flex licensing of a given port.

    So I am creating a unit monitor, targetd at one of my license ports, and for paramters I don't see the information you list above, can I substitue $Data/Context/$Port$ for $Target/Context/Port$? My function expects a servername and a port number, then it will return the status of the license daemon. I would like that information to be stored with the object.

    Some guidance would be appreciated, thanks!

  2. There are probably more than a couple ways to go about it.  One way you could do this is to discover a target class which is based on windows local application.  This would inherit Windows Computer properties, so you'll have FQDN.  Discover one property on this class, which would be the port to check.  You could use a MS as the watcher node, ensure the workflow is running under secure reference that has priveleges to run get-MonitoringObjectProperty and create a probe using POSH (…/return-discovered-inventory.aspx) to enumerate through the target class and build a FQDN and port list.  Then run these variables through the TCP port check probe.  Generate alerts based on the thresholds set on the status codes defined above.

    Just an idea…

  3. Jose Fehse (MVP) says:

    Hey Jonathan, tks for the valuable info. I'm doing just this: trying to author my own tcp port monitor. I basically want to target a group of computers and run the port check against all of them (all of them have a certain application that responds on that port). The idea is pretty straight forward, but the authoring console can become tricky. My question is: can I use a parameter in the servername so I can kind of target the datasource to different servers, on different monitors? Still, I'd need to define a watcher node, which complicates the whole thing. Any ideas?

    Thank you,

    Jose Fehse