Use WinRM for application monitor polling in SAM
Starting in SAM 2020.2, WinRM is the default transport method used to collect data for WMI-based component monitors (for example, Performance Counter Monitors) 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.
|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.|
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
Attempt to use WinRM for application template polling failed.
Note the following details about this alert:
- It appears once for each application monitor that attempts WinRM polling but fails; it will not repeat in 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.