Hello, is it possible to use winRM to create memory, cpu load and diskspace sensors? For the WMI and SNMP there need to be additional ports opened up which I rather not do. WinRM has already been used in multiple applicationson the server which would mean no additional network changes.
thank you for your KB-Post. Currently there are no plans to change the standard Windows sensors from WMI / Performance Counters to WinRM.
You are of course free to pursue this approach with custom sensors.
I'm a bit confused by this, WinRM (CIM) is a standard, and very lightweight to get most metrics. The problem for some, is opening up remote registry is not an option due to security requirements, in addition, WMI- even newer WMI- has too much overhead. While we can certainly use custom sensors and write a powershell script to get this info via WinRM in a very effecient time (we are using winRM to get disk i/o in about 350ms per poll/drive), the added overhead of having to run PS sessions makes it not ideal as we start to scale. It would be a HUGE benefit for us if we had a way winRM sensors could run in-band, like other native sensors.
Is there a specific reason WinRM was avoided? Is there something we should know about limitations trying to use it inside PRTG?
One of the reasons why we decided against WinRM is, that WMI/PerfCounters are active by default. To use WinRM you have to configure a WinRM-Listener, according to Microsoft. So WMI/PerfCounters are almost always ready out-of-the-box.
Is there any update on this?
Given Microsoft has depreciated SNMP from Server 2012 onwards and does not support SNMP v3, and the high performance overhead of the WMI sensors in PRTG we want to move to WinRM if at all possible.
SNMP counters are still available in the latest Windows versions. I'm afraid that monitoring via WinRM needs to be added with a custom sensor by you.
Felix Saure, Tech Support Team
I appreciate that SNMP is still available for now, but Microsoft depreciating a feature is a strong signal that we shouldn't rely on that feature being present in future and lack of support for v3 is a strong argument against using it at all.
I can't find any articles on using WinRM via a custom sensor. Can you point me in the right direction please?
PRTG is able to start your personal scripts which then create the monitoring tasks for you. This could for instance be a PowerShell script which establishes the connection using winRM and monitors the metrics using Get-WmiObject. For a guide for creating Powershell custom sensors, kindly take a look at this page.
Felix Saure, Tech Support Team
Windows is moving away from DCOM (WMI) based management in favor of WSMAN/CIM (WinRM). One evidence of this is the addition of CIM cmdlets in Powershell which connect using WSMAN by default. All of WMI is available via the WinRM interface, WinRM simplifies network configuration greatly by requiring only a single port (5985 or 5986) to be open, rather than a huge range of dynamic ports. And, besides just Windows support, WSMAN is a cross platform standard that enables querying any system that implements CIM, including Linux servers.
In an enterprise environment, configuring WinRM-Listeners is trivial via group policy. Anything small enough to not have a domain is probably small enough to configure WinRM on all systems in less than a day.
I think not implementing WSMAN/CIM (WinRM) is a mistake, and will become more apparent as time goes on.
While we can certainly use custom sensors and write a powershell script
to get this info via WinRM in a very effecient time (we are using winRM to
get disk i/o in about 350ms per poll/drive), the added overhead of having to
run PS sessions makes it not ideal as we start to scale.
If you're resorting to writing your own scripts while Paessler seeks the glory of WinRM, you can improve efficiency with CIM cmdlets, which saves you from PSSession overhead to some extent.