I originally wrote this in 2015 for the Microsoft Store team to monitor cash registers and printers back when Microsoft had retail stores throughout the country. Some years later I saw that some other dude (Jasper) wrote a blog article explaining almost the same monitoring concept so I never bothered to publish this MP. However, I don’t know that he actually provided the MP. I can’t seem to find it. Since then I’ve deployed this MP for number of customers who were unable to write their own. Seems like there might be more folks who would enjoy this so here it is. Mine contains a few differences (MatchCount and a performance view).
This is a very simple solution which has some features which I think are nice, details below.
Bulk port monitoring
Enable Discovery
Use a path where ALL members of the All Management Servers Resource Pool can access (read)
Sample Discovery File
Discovered Instances
ConnectionTime Performance
4 Replies to “PortGenie – Bulk Port Monitoring for Devices with SCOM”
How does one get a copy of this MP…Thanks?
@Mark, The MP appears in the site search results but now I also added a direct link to the post.
Is there any solution for UDP port monitoring with SCOM. Thanks
None come to mind. UDP monitoring is incredibly nuanced.
Why is UDP Port Monitoring Nuanced?
UDP (User Datagram Protocol) is connectionless and stateless. Unlike TCP, there is no handshake, session establishment, or teardown.
You cannot simply “see” when a UDP port is “open” or “listening” in the same way as TCP, since UDP does not maintain a persistent connection.
UDP does not guarantee delivery, ordering, or error checking beyond basic checksums.
When monitoring, a sent UDP packet may not get any response even if the service is running and the port is open.
The lack of reply could mean:
Many UDP services only respond to properly formed, protocol-specific requests. Sending a generic packet to a UDP port may not elicit any reply, even if the port is open and in use.
For accurate monitoring, you need to craft probes that follow the expected protocol (e.g., DNS queries to port 53, SNMP requests to port 161).
Firewalls and NATs often block or silently drop unsolicited UDP traffic, making monitoring results less deterministic.
Since UDP is stateless, traditional connection tracking is not possible. Monitoring tools must rely on traffic patterns, volume, and protocol-specific heuristics.