Polling Using WMI versus the new Agent

In terms of bandwidth consumption, our internal testing has seen ~80% reduction with the agent vs. native WMI queries.

I've noticed that my application templates seem to have chosen agent based polling without any direction on my part. Is this a known bug?

This is by design. All application templates by default utilize the agent unless no agent is installed; in which case agentless polling is used. This functions the same as the 64bit polling method when/if SAM is installed on a 32bit operating system. In that scenario it will automatically use 32bit polling. The option to override a template to use agentless polling when an agent is installed can be handy in the event you wanted to measure response time of user experience. You would likely get a far more accurate measurement polling from the Orion server than the Agent polling the localhost.

Thanks for the reply. So if I have say 1000 servers running a particular app monitor, and I have an agent on 10 of them, if the app template is set to use agent it will use the agent on those 10 and use (in my case) WMI for the other 990?

Thanks for the reply. So if I have say 1000 servers running a particular app monitor, and I have an agent on 10 of them, if the app template is set to use agent it will use the agent on those 10 and use (in my case) WMI for the other 990?

Yes. That is correct.

Hi aLTeReGo, would you be able to share, when to use Agent based vs. Agentless polling method?

---

itengineer wrote:

Hi aLTeReGo, would you be able to share, when to use Agent based vs. Agentless polling method?

---

This is somewhat use case driven, and part personal preference. Some customers prefer to use Agents anywhere/everywhere possible because Agents don't require credentials with elevated permissions or specially created least privilege accounts to be created, updated, and maintained on the endpoints. Simply install the Agent and go. Agents also have store and forward capabilities, allowing them to continue polling, even when the poller they're associated with is unreachable. Once the poller is reachable again, all monitoring information collected by the Agent while the poller was inaccessible is automatically uploaded to the poller and written to the database. This helps with availability reporting and limiting any gaps in data. 

Obviously, there are distinct advantages to agentless monitoring, so I'm not at all suggesting this is how agents should be used in every environment. These reasons really come down to a matter of personal preference. 

There are certain use cases where the Agent is advantageous or possibly even required. For example, if monitoring nodes across high latency links (upwards of 500ms) and low bandwidth connections. Unlike protocols like WMI, the Agent communications protocol is extremely latency friendly and high compression is used to limit bandwidth to a tiny fraction of that of WMI or RPC. 

Agents also run over a single TCP Port, compared to WMI which by default can use any random port greater than 1024. This, along with the ability to control directionality (push/pull) can be helpful in secure environments where access control lists, firewall policies, and even NAT present difficulties with monitoring. For example, most ISPs won't allow monitoring via WMI across the internet because it uses the RPC protocol. In these situations, an Agent may be required if a VPN tunnel isn't available. Similarly, secure environments that do not allow any listening ports to be running on the endpoint, even WMI or SNMP, the Agent allows for a 'push' method to the pollers (Agent initiated communications) whereby there is no need for any listening ports on the monitored endpoint's IP for monitoring. 

So in short, it really depends on what you're wanting to accomplish, as well as how agent-friendly the environment is. 

Researching a lot of security events has also shown that many of the more established Russian hacking groups love WMI. Another possible use case for agent based monitoring. I have always loved agentless but as the times are changing I think I may have to revisit my old way of thinking. Thanks for the info AlterEgo

That is so greatly explained

Many thanks aLTeReGo