Configure WinRM polling

Windows Remote Management (WinRM) is a protocol and set of services that enable remote management of Windows systems.

Compared to WMI, WinRM has the following advantages:

• It works over HTTPS. giving you the option to validate the connection using an SSL certificate.
• When managing WinRM, you can apply different rules on different target machines, you can restrict authentication type and manage the access to ports.
• The protocol works much faster for a single poll.
• Unlike WMI (DCOM), WinRM supports various authentication mechanisms.

To configure WinRM, complete the following tasks:

Set up WinRM on devices

To configure a machine to use WinRM (Windows Remote Management), you need to enable the service, set up listeners, and configure security settings.

1. Enable the WinRM service
2. Configure WinRM listeners
3. Configure firewall exceptions
4. Set trusted hosts
5. Configure authentication
6. Test WinRM configuration and connectivity
7. Advanced configuration

Enable the WinRM service

The WinRM service is not enabled and configured on all Windows Server versions by default. To enable it, complete the following steps on the device(s) that you want to monitor via WinRM.

1. Open PowerShell as an Administrator.

2. Run this command:

   Enable-PSRemoting -Force

   This command starts the WinRM service and sets it to start automatically. It configures a listener for HTTP (port 5985) and enables the necessary firewall rules.

Configure WinRM listeners

WinRM uses listeners to accept incoming requests. By default, it creates an HTTP listener. You can configure it to use HTTPS for secure communication. Complete the following actions on the device(s) that you want to monitor via WinRM.

Check existing listeners

To view existing listeners, run this command.

winrm enumerate winrm/config/listener

Create an HTTP listener

If an HTTP listener is not already created, run this command to create it.

winrm create winrm/config/Listener?Address=*+Transport=HTTP

Create an HTTPS listener

To use HTTPS, you need an SSL certificate. Install the certificate and complete the following steps:

1. Find the certificate's thumbprint. Run this command.

   Get-ChildItem -Path Cert:\LocalMachine\My

2. Create the listener. Run this command.

   winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="hostname"; CertificateThumbprint="your_certificate_thumbprint"}

Configure firewall exceptions

Ensure the firewall allows WinRM traffic. Run the appropriate command on the device(s) to be monitored via WinRM.

If your polling engine is under a strict outbound policy that blocks outgoing traffic to the TCP ports 5985 (HTTP) and 5986 (HTTPS), you also need to configure the firewall to allow outbound connections for these ports on the polling engine.

For HTTP (default port 5985):

netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes

For HTTPS (default port 5986):

New-NetFirewallRule -Name "WinRM over HTTPS" -DisplayName "WinRM over HTTPS" -Enabled True -Profile Any -Action Allow -Protocol TCP -LocalPort 5986

Set trusted hosts

If your machine is not in a domain, specify trusted hosts for remote management. Do this both on the device to be monitored via WinRM and on the polling engine.

• To allow connections from specific IPs or hostnames, run this command.

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "192.168.1.100,192.168.1.101"

• To allow all hosts, run this command.

  Setting all hosts as trusted is not recommended in production environments.

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value *

Verify the configuration. Run this command.

Get-Item -Path WSMan:\localhost\Client\TrustedHosts

Configure authentication

WinRM supports multiple authentication methods:

• Kerberos - recommended for domain environments.

• NTLM - fallback option for non-domain environments.

• Basic - requires HTTPS to secure credentials.

To configure authentication, run this code.

# Enable Basic authentication (requires HTTPS)
  winrm set winrm/config/service/auth @{Basic="true"}
# Enable Kerberos authentication
  winrm set winrm/config/service/auth @{Kerberos="true"}
# Enable NTLM authentication
  winrm set winrm/config/service/auth @{NTLM="true"}

Advanced configuration

• Adjust WinRM timeout and connection limits
• Enable CredSSP

Adjust WinRM timeout and connection limits

For environments with heavy usage, adjust the timeouts and limits.

# Set maximum concurrent operations
winrm set winrm/config/service @{MaxConcurrentOperations="100"}
# Set idle timeout (in milliseconds)
winrm set winrm/config @{IdleTimeout="60000"}

Enable CredSSP

If you're using delegation for remote commands, run this command to enable credSSP.

Enable-WSManCredSSP -Role Server
Enable-WSManCredSSP -Role Client -DelegateComputer *

Troubleshooting

• Confirm WinRM configuration on the target server
  • Check WinRM service status
  • Restart the service
• Confirm WinRM configuration in the SolarWinds Platform server
• Check the Group Policy configuration
• Inspect logs
• Ignore invalid certificates
• Test WinRM configuration and connectivity

Set up global settings for polling nodes using WMI/WinRM

The global settings are used for adding new nodes or testing credentials while adding single nodes or during a discovery.

You can specify the settings for individual nodes, either when adding nodes or when editing a node. Scroll down to Windows Connection Settings and WinRM Settings and adjust the values.

1. In the SolarWinds Platform Web Console, click Settings > All Settings > Polling Settings.

2. Scroll down to Windows Connection and specify the connection mode:

   • WinRmPreferred - the default option. First, polling is attempted via WinRM. If WinRM connection cannot be established, polling falls back to WMI over DCOM.

   • WinOnly - connect only via WMI over DCOM.

   • WinRmOnly - connect only via WinRM.

   Review the pros and cons of the connection modes:

   Feature	WimRMOnly	WinRmPreferred	WmiOnly
   Description	Uses WinRM (Windows Remote Management) exclusively for remote management.	Uses WMI (Windows Management Instrumentation) exclusively for management.	Uses WinRM when available; falls back to WMI if WinRM is not available.
   Primary Protocol	WS-Management (SOAP-based)	WinRM preferred, WMI as fallback	DCOM (Distributed Component Object Model)
   Remote Access	Designed for remote access over HTTP/HTTPS.	Tries to use HTTP/HTTPS, falls back to DCOM for WMI.	Designed for remote access over DCOM only.
   Performance	Optimized for remote communication with lower overhead.	Offers flexibility but may introduce latency when falling back to WMI.	Higher latency and resource usage due to DCOM overhead.
   Firewall Friendly	Works well across firewalls with ports 5985 (HTTP) and 5986 (HTTPS).	Works across firewalls if WinRM is used; DCOM fallback may require additional open ports.	Often blocked by firewalls due to random ports used by DCOM.
   Use Case	Best for environments with properly configured WinRM (modern remote management).	Useful in mixed environments with partial WinRM configuration.	Best for legacy environments that rely solely on WMI.
   Authentication	Supports Kerberos, NTLM, and certificate-based authentication.	Uses WinRM authentication (Kerberos, NTLM) when available; falls back to WMI authentication.	Relies on Kerberos, NTLM, or Basic authentication for WMI.
   Security	More secure due to encryption over HTTP/HTTPS.	Secure if using WinRM; less secure during WMI fallback.	Less secure due to lack of encryption and reliance on DCOM.
   Example Scenario	Managing remote servers in a modern, firewall-restricted network.	Managing systems in a mixed environment with both WinRM and legacy WMI.	Legacy systems where only WMI is available or supported.

3. Set the default authentication mode for WMI.

   Kerberos strict

   This mode is forcing the use of Kerberos. SolarWinds Platform will always try to resolve the IP address and hostname and find the FQDN.

   If the SolarWinds Platform fails to create a connection using the Kerberos authentication protocol a connection error will be logged and you can see it in the SolarWinds Platform Web Console.

   Kerberos preferred

   This mode tries to connect using Kerberos first. If the SolarWinds Platform fails to create a connection using the Kerberos authentication protocol, a connection error will be logged and SolarWinds Platform will try to connect using NTLM and IP address.

   Default

   This mode uses NTLM.

4. If you want to use the HTTPS protocol for WinRM, select Use HTTPS Protocol box. If the box is cleared, HTTP is used to send and receive WS Management protocol requests and responses.

5. Specify the default port for which the listener is created.

   • The default HTTP port for WinRM 1.1 and earlier is 80.
   • The default HTTP port for WinRM 2.0 is 5985.

6. To disable SSL certificate validation for HTTPS connections, select Ignore Certificates.

7. Review the URL prefix on which to accept HTTP or HTTPS requests. The default prefix is wsman.

8. Select the authentication mechanism to be used for WinRM.

   • Default - Typically uses NTLM if the node's address is not in Fully Qualified Domain Name (FQDN) format. Depending on the system's configuration, it may fall back to Negotiate, which can use Kerberos in domain environments.

   • Digest - uses a challenge-response mechanism where the password is hashed and not sent over the network in plain text.

   • Negotiate - automatically selects between Kerberos (if available) and NTLM, depending on the environment.

   • Basic - sends the user name and password over the network in plain text unless encrypted with HTTPS.

   • Kerberos - a highly secure ticket-based authentication protocol used in Active Directory environments for mutual authentication.

   • NtlmDomain - uses NTLM for challenge-response authentication.

   • CredSSP (Credential Security Support Provider) - allows the delegation of credentials from the client to the server, enabling single sign-on (SSO) and remote authentication.

   For details, see Authentication for Remote Connections in Microsoft documentation.