Windows Remote Management (WinRM) Guide

Windows Remote Management (WinRM) is Microsoft’s implementation of the Web Services-Management (WS-Management) protocol, which provides a standardized method for systems, both hardware and software, from various vendors to communicate

This protocol facilitates the exchange of management data across an organization’s IT infrastructure, enabling seamless interoperability between diverse systems. By providing a unified framework, WinRM is especially beneficial for IT administrators who need to oversee extensive Windows-based network environments.

WinRM plays a crucial role in simplifying remote management tasks, such as system configuration, monitoring, and troubleshooting, making it an indispensable tool for network administrators. Microsoft first introduced this protocol with WinRM 1.1, which was compatible with Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. This initial version laid the groundwork for the more advanced functionalities that followed.

The release of WinRM 2.0 brought significant enhancements, including the ability to execute PowerShell 2.0 scripts and cmdlets on remote systems. This version was included with Windows 7 and Windows Server 2008 R2, further streamlining administrative tasks across multiple machines. In 2012, Microsoft introduced WinRM 3.0, which came pre-installed with Windows 8 and Windows Server 2012. This version featured improved performance and deeper integration, cementing WinRM as a vital component of modern Windows infrastructure management.

Why is the WinRM protocol important?

Why is the WinRM protocol important and why do we need it? With WinRM protocol, the connection between computers or servers can be easily established, so that remote operations can be performed. You can obtain data or manage resources on remote computers as well as the local computer. Connecting to a remote computer in a Windows Remote Management script is very similar to making a local connection. The WinRM protocol is intended to improve hardware management in a network environment with various devices running a variety of operating systems.

As a command-line tool, WinRM is built into Windows operating systems and based on .NET and PowerShell, which allows scripts and remote PowerShell commands to be invoked on Windows-based machines or a large set of remote machines without RDP or log into the remote machine. This method makes it easier for Windows Administrators to manage multiple machines using scripts and cmdlet, and perform tasks such as:

• Monitor, manage and configure servers, operating systems, and client machines from a remote location.
• Remotely communicate and interface with hosts through readily available channels/ports within your network, including workstations, servers, and any operating system that supports it.
• Execute commands remotely on systems that you are not local to you but are network accessible

The Windows Remote Shell (WinRS) command-line tool relies on WinRM to execute remote commands. It leverages WinRM to let you launch processes on remote machines. WinRM is the server component of this remote management application and WinRS is the client component for WinRM, which runs on the remote computer attempting to remotely manage the WinRM server. However, both computers must have WinRM installed and enabled on them for WinRS to work and retrieve information from the remote system.

WinRM architecture and components 

The WinRM architecture consists of components on the client and server computers. The diagram in Figure 1.0 below shows the components on both the requesting client and responding server computers, and how they interact with each other, including the protocol that is used to communicate between them.

Table 1.0  below is a breakdown of the various WinRM components and where they reside.

Table 1.0 | WinRM components and description

WinRM configuration and commands

For the WinRM command-line tool and scripts to run, and perform data operations effectively, Windows Remote Management (WinRM) must be installed and configured. However, the good news is that WinRM is automatically installed with all currently-supported versions of the Windows operating system, including IPMI (Intelligent Platform Management Interface) WMI (Windows Management Instrumentation) provider components.

By default, WinRM is enabled on Windows Server OS since Windows Server 2012, but not on Windows 10 operating system. This means that you need to enable it on Windows 10 machines. To enable WinRM on a Windows 10 machine, open PowerShell and run the following cmdlet:

Enable-PSRemoting -force

If you have a single Windows 10 machine that is not part of an Active Directory domain network,  you may need to add the machine you are going to connect from to the trusted host of the Windows 10 machine. The reason we need to add trusted hosts is to be able to connect to a Windows machine using WinRM.

However, in situations where you have 100+ Windows 10 machines in an Active Directory domain network, you may need to use a Group Policy (GPO) to get it working with minimal effort. To use a GPO, create a new one or edit an existing one and modify the following settings and set WinRM to “Enabled”:

• Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > Allow remote server management through WinRM

Remember to apply the GPO to the Organizational Units (OU) that have all your Windows 10 machines. Within a few minutes after applying the GPO to the OU, all your hosts will get the policy update. In this case, there is no need to modify the trusted hosts’ list.

The table below is a collection of some WinRM commands you can use to execute remote operations. Please note that these commands work best when you are on an Active Directory domain network. For workgroup machines, the WinRM service may require additional configuration such as modifying the trusted hosts’ list.

Table 2.0 | Common WinRM commands and description

WinRM security

By default, WinRM uses Kerberos for authentication. This means that Windows never sends the actual credentials to the system requesting validation instead of relying on features such as hashing and tickets to connect.

WinRM listens on TCP port 80 (HTTP) by default, it doesn’t mean traffic is unencrypted. Traffic by default is only accepted by WinRM when it is encrypted using the Negotiate or Kerberos SSP. WinRM also includes helper code that lets the WinRM listener share port 80 with the Microsoft IIS  web server or any other application that may need to use that port. Although WinRM listeners can be configured to encrypt all communications using HTTPS, with the use of Kerberos, even if unencrypted HTTP is used, all communication is still encrypted using a symmetric 256-bit key after the authentication phase completes.

You can manually configure WinRM to use HTTPS. The purpose of configuring WinRM for HTTPS is to encrypt the data being sent across the network. This allows for additional security by ensuring server identity via SSL/TLS certificates thereby preventing an attacker from impersonating it. To configure WinRM to use HTTPS, a local computer Server Authentication certificate with a CNAME matching the hostname is required to be installed. To install certificates for the local computer, follow the steps below:

• Select Start and then select Run (or using keyboard combination press Windows key+R)
• Type MMC and then press Enter
• Select File from menu options and then select Add or Remove Snap-ins
• Select Certificates and select Add
• Go through the wizard selecting the Computer account
• Install or view the certificates under Certificates (Local computer) >> Personal >> Certificates.

Once the certificate is successfully installed, use the following command to configure WRM to listen on HTTPS: winrm quickconfig -transport:https

Notable applications of WinRM

• SolarWinds Server & Application Monitor software (SAM) enables remote access for PowerShell with WinRM. It utilizes a WinRM server on monitored servers for its PowerShell integration.
• Thycotic Secret Server—privileged access management (PAM) solution, relies on WinRM components to run PowerShell scripts.
• Ansible—an agentless open-source software provisioning and deployment tool, leverages WinRM to communicate with Windows servers and run PowerShell scripts and commands. Ansible is agentless because of its ability to remotely connect via WinRM, thereby allowing remote PowerShell execution to do its tasks.
• CloudBolt—a hybrid cloud management platform, leverages WinRM as part of Blueprints, Server Actions, and CB Plugins to execute remote scripts on Windows servers using the python pywinrm module.

Windows Remote Management FAQs