Hi Dojo,

I recently read an article about a comparison of WMI API vs. WinRM for Windows system management and monitoring. There is the main difference between both methods to monitor a Windows OS as per https://support.quest.com/kb/4311903/comparison-between-dcom-wmi-and-winrm-technologies

“Both DCOM and WinRM use WMI to collect data about resources or to manage resources on a Windows OS.

DCOM

• DCOM is older technology introduced with Windows NT.
• It is enabled by default on many Windows server for historic reasons
• It is considered obsolete and out of date by Microsoft. It is not recommended to use this protocol.
• DCOM remains integrated into the Windows OS and is how many Windows services communicate – like Microsoft Management Console (MMC).
• Since DCOM can run programs on other computers, hackers can leverage it for lateral movement attacks through your network, gaining access to more data. This activity can be difficult to detect because it’s not malware or hacker tools: all it takes to access DCOM is PowerShell. 

WinRM

• WinRM is the more modern protocol and is recommended by Microsoft.
• It is the protocol allowing for remote management of machines over http(s) using SOAP.
• It can use port 80 and 443 for communication, a port that is usually always open by firewalls and client machines on a network. Ports 5985 and 5986 (SSL) are used in WinRM v2.
• WinRM is more basically an HTTP based API for WMI. Data is returned formatted in XML rather than objects. Because WinRM is XML based, it will also pass through firewalls that performance packet inspection on port 80.
• WinRM 1.1 had some smart code which allowed port 80/443 to be shared with IIS web servers. However when implementing network load balancing, as NLB takes control over the network stack it breaks this smart code. As a result MS had to move the WinRM ports to 5985 and 5986 for SSL in version 2.0
• The ports must be open along with WinRM listener on the server which you want to manage remotely. Both Listener and port can be configured using WinRM command.
• All WinRM data is encrypted using whatever the “Integrated Windows Authentication” is set to on the host machine (Either NTLM or Kerberos). Alternatively if you have a PKI setup you can setup SSL for use with WinRM on your internal network. If SSL is in use NTLM and Kerberos get ignored.
   

“Range of ports” 

• Standard remote WMI queries use RPC to connect and RPC uses a mess of ports. First, the Collector would connect to the remote system over TCP 135. The remote system would then pick a high port and ask the Collector to use this new high port for future communications. The high port depends on the OS but current Windows uses ports 49152 thru 65535. If there is a firewall/router between the Collector the remote system and it’s not RPC/WMI-aware (being stateful is not enough), you need to open all of those ports between the two or modify Windows to limit the IP range but it would be global on that server.
• Support recommends using a static port instead of a range of port for easier configuration: https://support.quest.com/kb/4289831″

There are quite some downsides with WMI, which we partially already faced in implementing WMI monitoring in large IT infrastructures. As per my knowledge the Microsoft Platform uses WMI as of today. Alternatively SNMP can be used for Microsoft monitoring. Is there any alternative integration using WinRM available already? If not, are there specific reasons against using WinRM for monitoring applications?