Submit a ticketCall us

AnnouncementsAre You “Flying Blind?”

When it comes to your complex IT infrastructure, you want to ensure you have a good grasp of what’s going on to avoid any fire drills that result from guesswork. Read our white paper to learn how proactively monitoring your IT environment can help your organization while giving you peace of mind.

Get your free white paper.

Home > Success Center > Network Performance Monitor (NPM) > NPM - Knowledgebase Articles > SNMP vs WMI polling

SNMP vs WMI polling

Created by John Salvani, last modified by Craig Healy on Oct 24, 2018

Views: 11,870 Votes: 6 Revisions: 6



A relatively new technique for monitoring windows servers via WMI instead of SNMP represents a measurable, but manageable, impact on both the target and the polling engine.


On a target server, monitoring with WMI plus a SAM template has no effect whatsoever on RAM or CPU, compared to simple ping monitoring. However, it represents an average increase of 12 Kbps.


The difference between WMI and SNMP polling is even less noticeable, with a 4 Kbps bandwidth bump as the only noticeable effect.


On the polling engine the impact is more pronounced. Monitoring 300 servers via WMI with a SAM template included (the most aggressive monitoring combination) results in the following increases compared to monitoring with simple “ping”:

  • 6% increase in average CPU utilization
  • 4% increase in average RAM usage
  • 4 Mbps increase in incoming bandwidth


The difference between monitoring 300 machines with WMI vs. SNMP has less of an impact on average:

  • 6% CPU
  • 2% RAM
  • 2.5 Mbps bandwidth received


If the difference between WMI and SNMP polling is statistically negligible, then why the need for additional hand-wringing? Why not just make the switch and go?


Note: The spreadsheet with the data behind this information appears as a separate upload. See here: SNMP_vs_WMI_20130410.xlsx


NPM 11.5 and earlier


The answer is that the choice of polling method has other impacts beyond the physical toll on the machines involved. Functionally, there are some pros and cons:

SNMP polling (as compared to WMI)


  • Fewer ports for enterprise firewall rules
  • No single point of failure for access
  • Extremely efficient use of CPU, RAM and bandwidth (on both target and poller)


  • Cannot monitor Windows Volume Mount points
  • Challenges with earlier versions of Windows (NT, W2k)
  • Requires additional non-standard configuration actions (enabling SNMP agent, etc)
  • Changing SNMP string requires enterprise-wide changes
  • Uses SNMP service start time for uptime metrics
    Work-around: set up UnDP for hrSystemUptime

WMI polling (as compared to SNMP)


  • Settings used by SAM automatically
  • Uses REAL reboot time for uptime metrics


  • WMI-only devices cannot use custom pollers (UnDP).
    Work-around: If the machine has EVER been an SNMP polled device, the snmp info is retained and custom pollers can be used (at least until the SNMP RO string changes)
  • Significantly more firewall ports required
    Work around: per-server config can nail down WMI to just a couple of ports
  • Will not work across a NAT-ed WAN connection (VPN, etc)
  • One password change in AD can cripple monitoring
  • Cannot monitor topology
  • Less efficient (vis a vis SNMP) use of CPU, RAM and bandwidth on both target and poller
Last modified