Windows Remote Management

This document describes setting up Windows Remote Management and troubleshooting various issues.


Windows 2008 R2 and Below

Liongard no longer support Agents deployed on Windows Server versions 2008 R2 and below.


What is Windows Remote Management? (WinRM)

Windows Remote Management (WinRM) is the Microsoft implementation of WS-Management Protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that allows hardware and operating systems, from different vendors, to interoperate.

The WS-Management protocol specification provides a common way for systems to access and exchange management information across an IT infrastructure.

How Liongard utilizes Windows Remote Management

In order to keep Agent deployment minimal, Liongard utilizes WinRM with several Inspectors, including Windows and Hyper-V, to allow remote inspections from a single Agent.

Test Network Connectivity and the WinRM Connection

Step 1: Ping the Server

When troubleshooting Windows Remote Management, first, from the Server where a Liongard Agent is installed, ping the associated Server to the failed Windows Server Inspector to test DNS setup.


If this fails, there may be an issue unrelated to Windows Remote Management.

Step 2: Test the Connection Directly

If this is successful, from the Server where a Liongard Agent is installed, test the connection to the Server associated to the failed Windows Server Inspector directly.

Test-WSMan should work on both the local agent and the remote Windows server.

Test-WSMan # Run this on both local and remote Windows servers.

If this fails, there may be an issue unrelated to Windows Remote Management.

Step 3: Create a Remote PowerShell Session

If this is successful, try creating a remote PowerShell session from the Server where a Liongard Agent is installed to the Server associated to the failed Windows Server Inspector.

$Computer = "MY-HOST01"
$Session = New-PSSession -ComputerName $Computer
$Username = "domain\user"
$Password = "mypassword"
$Computer = "MY-HOST01"
$SecurePassword = ConvertTo-SecureString -AsPlainText -Force -String $Password  
$Credential = New-Object -Typename -ArgumentList $Username, $SecurePassword
$Session = New-PSSession -ComputerName $Computer -credential $Credential

If this fails, then PSRemoting has not been enabled on the server associated to the failed Windows Server Inspector. Follow our how to Enable PSRemoting documentation to continue troubleshooting.

Enable PSRemoting

Follow this section only if the steps above failed.

PSRemoting can be enabled in two ways:

Enabling PSRemoting via PowerShell will enable PSRemoting for the specific server that is associated with the failed Windows Inspector, whereas enabling PSRemoting via Group Policy will enable PSRemoting for all servers within the domain.

Enabling PSRemoting via PowerShell


  • The local and remote Windows machines must be on the same Active Directory domain

On both systems you will need to enable PSRemoting using the following command.

Enable-PSRemoting -Force

After successfully running this command, in Liongard, re-run your failed Windows Server Inspector.

If the Windows Inspector continues to fail, please open a chat with Support.

Enable PSRemoting via Group Policy

  1. Create a Group Policy Object that targets the remote machine(s) that you want to enable WinRM on (e.g. “Enable WinRM”).
  2. Enable the Allow remote server management through WinRM policy setting found under Computer > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service.
  3. You will need to specify the IP Address ranges that the service will accept connections. Be cautious if you just add a wildcard “*” in the field as this can potentially allow incoming connection from all network locations. If possible, specify the exact IP address of the local system.
  1. You need to enable the “Windows Remote Management (WS-Management)” Service via the Group Policy Preferences Services under Computer > Preferences > Control Panel Settings > Services. Right click and choose New > Service.
  1. You need to open up the firewall rules to allow the incoming TCP connection on the Domain Network profile. Go to Computer Configurations > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security. Then, right click on Inbound Rules and click on the New Rule… option.
  1. Check the Predefined option and select Windows Remote Management from the drop-down list. Then, click Next.
  1. Uncheck the top “Public” rule to again reduce the exposure of this service to the internet, and then, click Next.
  1. Click Finish.

To again reduce the exposure of this service, you can double-click on the new rule you just created and remove “Private” from the network profiles that this applies.


After following these steps, in Liongard, re-run your failed Windows Server Inspector(s).

If the Windows Inspector continues to fail, please open a chat with Support.

Local or Remote System are not on the same Domain or any Domain at all

In this situation:

  • The local and remote systems are not on the same Active Directory domain
  • On both systems, you will need to enable PSRemoting and establish trust using the following commands:
  • The ServerMachineName should be replaced with the server with which you're going to establish trust. Generally, this will be the remote system.
    • For example, if you have machine1.domain.local and machine2.domain.local, you can log on to machine1 and set as "machine2.domain.local" and vice versa.
Enable-PSRemoting -Force
Set-Item WSMan:\localhost\Client\TrustedHosts –Value <ServerMachineName> -Force -Concatenate

Common Errors

Access Denied

Execution Policies

You can run the get-executionpolicy PowerShell command to see the execution policy on a Windows computer. Whether you are running inspections locally or remotely, the execution policy should be set to RemoteSigned (preferred) or Unrestricted. If it comes back as restricted or undefined you can use the following command to set it to the preferred setting: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Agent Permissions

The Agent needs to be able to do remote connections. Make sure the Agent is running with domain admin credentials.

Two Hops

If there are two hops in the network to reach the remote machine, then the Windows/Active Directory inspections will not currently work. You must run the inspection from a machine in the same network with a single hop.

Protected Users Group

Adding the Agent Service Account to the Protected Users Group in Active Directory can cause WinRM failures.

How do I troubleshoot Windows Remote Management issues?

Please note that there are a wide ranging number of issues that can occur depending on many factors. This is not an exhaustive list but an attempt to enumerate as many issues as possible.

It's common that we may see the following error from PowerShell (we've omitted the server name in this example). This section details how to troubleshoot this error as well as other errors:

Connecting to remote server <SERVER_NAME>
failed with the following error message : The client cannot connect to the 
destination specified in the request. Verify that the service on the 
destination is running and is accepting requests. Consult the logs and 
documentation for the WS-Management service running on the destination, most 
commonly IIS or WinRM. If the destination is the WinRM service, run the 
following command on the destination to analyze and configure the WinRM 
service: "winrm quickconfig". For more information, see the 
about_Remote_Troubleshooting Help topic.

Testing the Connection via PowerShell



If you are connecting to a computer that is not a domain, the username will be in the form of the example below (see snippet).



If you see any type of error about Kerberos while establishing sessions via WimRM, it usually means one of two things. Either TrustedHosts has not been set up (see above) or potentially the password contains special characters.

Try changing the password to an alphanumeric password only to verify that this is not the issue.


Windows Remote

Currently inspecting Windows servers remotely is only allowed if the servers are on the same domain. The script below provides two tabs, the first is for Hyper-V and the second is for testing Windows remote.

Checking if the user has remote management access on the remote machine

Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell -Force


What to check?

You will want to make sure the user, or one of the groups the user belongs to, appears in the dialog.

If the user does not appear, you will need to add/grant them remote management access.

Testing WinRM is Running and Listening

winrm e winrm/config/listener


What to check?

You will want to verify it has Enabled = true and ListeningOn contains

Testing the firewall is set up properly if enabled on the remote machine

Get-NetFirewallRule WINRM-HTTP-In-TCP

Testing no proxy server is set up

netsh winhttp show proxy


Proxy Settings

If you are using a proxy on the server, you will need to make sure that connections on the WinRM are being allowed through.

Testing if the remote computer is allowing a connection

netstat -anp tcp


What to check?

You should see a TCP connection at the local address in the LISTENING state.

Testing if IP Bindings Exist

netsh http show iplist


Loopback Binded

If you see listed above, then run the command:
netsh http delete iplisten ipaddress= to remove it.

Testing your Network Type


Run the following command to verify the Network Category is not Public:



Remote Access

PowerShell does not allow you to use a remote session if you have a network configured as public instead of private it is considered unsafe.

This applies to the Hyper-V Inspector in particular.

For more information, please visit Microsoft's Documentation about Remote Troubleshooting