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.
Overview
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.
ping <REMOTEHOST>
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 system.management.automation.pscredential -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
Constraints:
- 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
- Create a Group Policy Object that targets the remote machine(s) that you want to enable WinRM on (e.g. “Enable WinRM”).
- Enable the Allow remote server management through WinRM policy setting found under Computer > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service.
- 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.
- 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.
- 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.
- Check the Predefined option and select Windows Remote Management from the drop-down list. Then, click Next.
- Uncheck the top “Public” rule to again reduce the exposure of this service to the internet, and then, click Next.
- 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
Username
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).
computername\user
.\user
Password
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 127.0.0.1.
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 0.0.0.0:5985 in the LISTENING state.
Testing if IP Bindings Exist
netsh http show iplist
Loopback Binded
If you see 127.0.0.1 listed above, then run the command:
netsh http delete iplisten ipaddress=127.0.0.1 to remove it.
Testing your Network Type
Get-NetConnectionProfile
Run the following command to verify the Network Category is not Public:
Get-NetConnectionProfile
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
Updated about 1 year ago