Documentation forServer & Application Monitor

Use WinRM for application monitor polling in SAM

Starting in SAM 2020.2, Windows Remote Management (WinRM) is the default polling method used by WMI-based component monitors (for example, Performance Counter Monitors) to gather data from target nodes for SAM templates and application monitors. A fallback mechanism automatically switches to legacy RPC/DCOM polling, if necessary.

If you're building a new environment with SAM 2020.2, WinRM application polling is automatically enabled for the Orion server and WMI component monitors. By default, WinRM application polling is also applied to any Windows network nodes that you decide to add later, although you still need to make sure that the Orion server can connect to the nodes.

If upgrading from an earlier version of SAM, see Configure WinRM polling in your SAM environment to learn how to start leveraging this functionality.

This feature is SAM-specific. It differs from the main polling method selected when adding nodes to the Orion Platform, that determines how basic metrics such as node status and packet loss are collected. The WinRM option described here only controls SAM-based polling for WMI-based component monitors on target nodes that do not use Orion agents to collect data.

Using WinRM instead of RPC/DCOM for WMI queries can increase SAM's scalability while collecting the same data with higher reliability and in less time. The following table provides more details about these methods.

  WinRM RPC/DCOM
Protocol Web Services (WS)-Management is a faster protocol developed for Windows Server 2012 R2 and the modern internet.

RPC is a legacy protocol, originally created for LANs, that could be deprecated in the future.

Firewall requirements Requires a single open port: 5985 (HTTP) or 5986 (HTTPS). Requires multiple open ports, starting with TCP Port 135 to initiate communication with a server, and then switching to random ports between 1024 and 65535.
Security Uses a modified form of HTTPS. Uses dynamic port allocation.
Performance No unmanaged code. Uses a stateless protocol for HTTPS requests and responses. Possible memory leaks, increased CPU consumption related to unmanaged code, and polling issues if WMI components timeout.
Execution

Runs queries locally on target machines. Switches to DCOM if WinRM fails.

Executes queries remotely so the Round-Trip Time (RTT) between SAM and target machines can increase overall scan times. No fallback mechanism.
Scalability Asynchronous API support means caller threads can execute other parts of code while waiting for results.

Multiple application monitors assigned to a node can collect data in parallel, but each component monitor in a single application monitor can only collect data serially. The more application monitors you assign to a single node with WMI-based component monitors, the more ports may be consumed and the longer polling may take.

For a list of component monitor types that use WinRM as the primary fetching method, see Configure WinRM polling in your SAM environment.

WinRM application polling alerts

The following out-of-the-box alert writes to the event log when WinRM polling fails and DCOM/RPC is used as a fallback method:

Attempt to use WinRM for application template polling failed.

Note the following details about this preconfigured alert:

  • It appears once for each application monitor that attempts WinRM polling but fails; it does not repeat for consecutive failed polling cycles.
  • It will not appear for nodes where WinRM polling is disabled, or if WinRM polling is disabled on the Orion server. See Configure WinRM polling in your SAM environment.

To resolve WinRM polling issues, see Troubleshoot application monitor polling with WinRM.