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.

Is that in terms of network bandwidth, or server side performance?  I'm talking server side performance gains...

I've seen a definite improvement on resource usage on some of our older slower servers.  There is a lot less consumption of resources by WMI.  The one trade-off I've noted is that it can take a little space on the target with the install and logging created.

Monitoring is far and away faster and more efficient locally. In most cases there is less communication overhead since there's no need to authenticate for most locally collected information. There is of course some small overhead associated with any agent, even if that agent is SNMP or WMI. The agent typically consumes under 1% CPU (0.24% on average) and between 10-100MB of RAM depending on the number and type of jobs being executed. Bandwidth consumption as rob.hock stated above, is ~80% less than that of a WMI managed node.

Monitoring is far and away faster and more efficient locally. In most cases there is less communication overhead since there's no need to authenticate for most locally collected information. There is of course some small overhead associated with any agent, even if that agent is SNMP or WMI. The agent typically consumes under 1% CPU (0.24% on average) and between 10-100MB of RAM depending on the number and type of jobs being executed. Bandwidth consumption as rob.hock stated above, is ~80% less than that of a WMI managed node.

I am seriously considering moving a large chunk of our WMI monitors over to agent polling (25% aka 300 servers) for testing. One concern that was brought up in a meeting yesterday afternoon was the .net version. Hypothetically speaking of course if an enterprise had very old servers, say Win2k8 and old apps running, is there a possibility that the agent install could force a .net upgrade? As long as I get a chance to opt out and return to WMI I would be fine. I just have to be cautious as some very old apps have hard .net requirements. 

The Agent itself has a .hard NET dependency that is version-specific. If that version of .NET is not found, the Agent will self-satisfy that dependency by upgrading or installing the necessary version of the .NET framework. If you have applications that are dependant upon older versions of the .NET framework and are not compatible with later versions, I would recommend not installing the Agent on those machines. However, I have not encountered any application myself that is not compatible with later versions of the .NET framework which are supposed to be backward compatible. Note that .NET 2.0 and .NET 3.5.x run in parallel with .NET Framework 4.x. So it's less an upgrade and more of a side-by-side. 

.NET Framework support

• On operating systems that support .NET Framework 4.8, all Windows Agent Plugins are migrated to .NET 4.8.

• Upon upgrade to 2019.4, .NET 4.8 is deployed automatically to operating systems that support .NET 4.8.

• .NET Framework 4.5 is deployed for Windows Server 2012 with no .NET Framework installed
• .NET Framework 4.0 is deployed automatically when installing Agents on Windows Server 2008 R2 or earlier or Windows Core)

Thanks for the info! As always, exactly what I was looking for. Really appreciate the value you add here. 

Onward with the agent migrations I think.