Windows Remote Management (WinRM) is used by the Windows connection manager to connect to nodes agentlessly.

Enabling WinRM via Group Policy

Using Windows Group Policy to enable WinRM provides users with an interface to centralize the management and configuration of WinRM for new and existing Active Directory computers. This article explains the steps required to create and apply an “Enable WinRM” Group Policy Object.

Creating and Configuring the Group Policy Objects

  1. Click Start, Run, and type gpedit.msc to open the Windows Group Policy Object Editor window
  2. Find the Windows Remote Management (WinRM) GPO under
    Computer Configuration\
      Administrative Templates\
        Windows Components\
            Windows Remote Management (WinRM)\
              WinRM Service
  3. Select the Allow remote server management through WinRM setting and click edit policy setting from the left information pane to open the Allow remote server management through WinRM configuration window


  4. Click on the Enable radio button and type in * for both IPv4 and IPv6 filter boxes as shown below and click Apply and OK to save the settings.


  5. Find the Windows Remote Shell GPO under
    Computer Configuration\
      Administrative Templates\
        Windows Components\
          Windows Remote Shell
  6. Select the Allow Remote Shell Access setting and click edit policy settings from the left information pane.


  7. Make sure the Allow Remote Shell Access setting is set to Enabled then click Apply and OK to save changes.


Validating that the Node Allows Remote Login

To validate that the GPO setting has been configured correctly, you can run the following command via a Powershell prompt on the node.

PS> dir WSMan:\localhost\Shell\
System.String  AllowRemoteShellAccess        GPO            true

Enabling HTTPS WinRM for Systems Not Connected to a Domain

When used between two systems on a domain, WinRM uses Kerberos to authenticate that the target server is trusted. Agentless scanning of non-domain-joined systems requires additional setup.

WinRM on the Connection Manager host must be able to authenticate the target system. This is achieved with certificates.

To perform agentless scanning on non-domain systems, the following is required:

  • An HTTPS WinRM listener on the scan target, with a certificate that is considered valid on the Connection Manager host
  • Basic authentication configured on the scan target WinRM listener, to allow local account user authentication
  • Firewall rules on the scan target to permit traffic to the HTTPS WinRM listener port (default 5986)
  • A TrustedHosts entry for the target in the WinRM configuration on the Connection Manager host

The following documentation describes the creation of a self-signed certificate on a target host and the configuration of an HTTPS WinRM listener service. It exports the self-signed certificate to a predictable location for importation into the trusted certificate store on the Connection Manager host.

Importing the certificate on the Connection Manager host and modifying the WinRM TrustedHosts list are manual steps, described further on.

Note that WinRM over HTTPS uses port 5986 by default, which will have to be configured on the scan target’s Node Edit page in UpGuard.

Remote Endpoint Configuration

Starting with the remote endpoint that we are wanting to initiate a connection to, the following PowerShell script will configure everything we need for HTTPS communication to be setup and will also (optionally) remove access for HTTP. You may need to first enable the ability to run scripts on your system using the command Set-ExecutionPolicy RemoteSigned.

Before you start, you may optionally set $VerbosePreference = "Continue" to view the status of the script during runtime. Run the following script on the client node that you wish to connect to:

Connection Manager Endpoint Configuration

The next step that is required is to transfer the winrm.crt file to the machine that will initiate HTTPS WinRM connections to remote endpoints.

First, copy the winrm.crt file from the current user’s home directory to the Windows Connection Manager host server. To install the self-signed certificate that we created on the host, we can use the following PowerShell command:

Verification of Certificate Installation

Optionally, you can verify that the certificate has been stored correctly on both the Windows CM host server and the remote endpoint servers using the certificate add-in of the Microsoft Management Console (MMC).

  1. Type ‘mmc’ on the Start screen and launch the mmc console.
  2. Navigate to File > Add/Remove Snap-in…
  3. Double click on Certificates from the Available snap-ins.
  4. Choose ‘Computer account’, followed by the ‘Local computer’. Hit OK to finish adding.
  5. Navigate to the Personal\Certificates folder from the sidebar.
  6. The certificate corresponding to the hostname or IP address should be in that folder.

Adding Remote Endpoints to the List of Trusted Hosts

To quickly add the remote endpoint server node to the list of trusted hosts on your Windows CM machine, you may run the following command, replacing "machineA" with the hostname or IP Address of your machine:

winrm set winrm/config/client ‘@{TrustedHosts="machineA"}’

You may also add more to the list of Trusted Hosts, as the string passed into the TrustedHosts key is a comma separated list of values which it will recognize. A quicker way to add remote endpoints if you choose to write a script for it is by working with the PSDrive (WSMan:\):

You can retrieve a list of your TrustedHosts by running the following command on your Windows CM host:

Get-Item WSMan:\localhost\Client\TrustedHosts

To set TrustedHosts (replace machineA etc. where appropriate):

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "machineA,machineB,machineC"

Wildcards are also accepted:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.140.*,machine*,*"

Verification of WinRM HTTPS Connectivity

To verify that HTTPS WinRM is setup, you can run the command:

Enter-PSSession -ComputerName COMPUTERNAME.DOMAIN.COM -UseSSL -Credential (Get-Credential)

where you will be prompted to enter the credentials of the user you would like to connect as (connection manager service account) to the remote endpoint. You should expect to successfully connect to the remote endpoint server from your PowerShell console.

Finally, your WinRM node in UpGuard can now be edited to use the port 5986.

Common Problems and Solutions

If you are trying to add a new agentless Windows node via WinRM, or a node is suddenly failing to scan, then this section attempts to list common problems you may be facing and methods to solve them. The important first step with each of these approaches is to ignore UpGuard Core for a second and attempt to gather raw facts about the connectivity of a node via PowerShell.

Testing Connectivity

The first step is to check that the Connection Manager can simply establish a TCP connection to the node. To test basic connectivity, open up a Powershell prompt on the host running the Connection Manager and type the following command:

PS> Test-NetConnection -ComputerName -Port 5985

Here we are testing connectivity to the WinRM port 5985 on our node with hostname

Below are some common responses and prescribed solutions.

Raw TCP connection being blocked

PS> Test-NetConnection -ComputerName -Port 5985
WARNING: TCP connect to failed

If this error message is returned by the command almost immediately then port 5985 is either not listening or a firewall is actively denying connectivity by replying. To check if a process is actually listening on port 5985, log into the node itself and run the following command:

PS> netstat -an | findstr LISTENING

Here, we see that a process is listening on port 5985 for connections from any location. If you have sufficient privileges you can run netstat with the -b option to see which process is doing the listening. If you don’t see an entry listing port 5985 listening you may need to either install or enable your WinRM service. If a service is running then check the Windows Firewall rules on the node itself, then on any network devices that live between the Connection Manager and the node.

Node hostname could not be resolved to IP address

PS> Test-NetConnection -ComputerName prod01.payments.corp.local -Port 5985
You cannot call a method on a null-valued expression.
  $Message = "Name resolution of $TargetName failed

Here, the hostname prod01.payments.corp.local cannot be resolved via a DNS to an IP address. You can double check this by running the following command:

PS> nslookup prod01.payments.corp.local

This is either resolved by confirming that the host the Connection Manager lives on has the correct DNS servers configured, or that the Network Team have correctly added a local DNS entry for the node’s hostname.

Testing Authentication

If you are able to estalish a TCP connection to the host and port, then the next step is to confirm that the username and password used to authenticate are correct. To test a username and password pair, run the following command on the host running the Connection Manager:

PS> Enter-PSSession -ComputerName <String> -Credential (Get-Credential)

Here, the Get-Credential sub command should prompt for a username and password via a popup. Entering a username and password will allow a remote powershell session to be established.

Below are some common responses to this command and prescribed solutions.

Service has remote connections disabled via GPO

PS> Enter-PSSession -ComputerName prod01.payments.corp.local -Credential (Get-Credential)
cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Enter-PSSession : Connecting to remote server prod01.payments.corp.local failed with the following error message : The WS-Management service cannot process the request. The service is configured to not accept any remote shell requests. For more information, see the about_Remote_Troubleshooting Help topic.

Here, we’ve attempted to connect to our node with hostname prod01.payments.corp.local, it has prompted us for a username and password and attempted to login but denied access. In this case, the WinRM service is running on the node, but is configured to not accept remote connections (only local ones).

To quickly confirm if this setting is enabled via a GPO, please see the section above titled Validating that the Node Allows Remote Login. If you find that the AllowRemoteShellAccess setting is set to false then please revisit the steps at the top of this article under Creating the Group Policy Object.

What Next?

Once you have configured a node to accept remove WinRM connections, you can proceed to add agentless Windows nodes. For more information on adding a WinRM agentless node to UpGuard Core, please visit our guide on Adding a WinRM Node.

Tags: https winrm gpo