PowerShell Remoting is a great tool that allows you to connect and run commands on remote computers via WinRM. If computers are joined to the Active Directory domain, then PSRemoting uses Kerberos to authenticate to remote hosts. However, if your computers are in a workgroup, you will have to use NTLM (TrustedHosts) or SSL certificates for authentication. Let’s look at how to configure and use PSRemoting (WinRM) in a Workgroup (Non-Domain) environment.

In this example, there are two hosts in a Windows workgroup:

• Administrator workstation — 192.168.13.100
• User’s computer — 192.168.13.222

Our task is to connect to the user’s computer remotely via PowerShell Remoting.

The first step is to enable and configure WinRM on the remote host. You will have to enable WinRM locally or remotely (for example, using RDP, psexec, or GPO).

Make sure that the WinRM service is running on the target user computer:

Get-Service -Name "*WinRM*" | select status

If the service is not running, enable it:

Enable-PSRemoting

WinRM has been updated to receive requests.
WinRM service type changed successfully.
WinRM service started.
WinRM has been updated for remote management.
WinRM firewall exception enabled.
Configured LocalAccountTokenFilterPolicy to grant administrative rights remotely to local users.

If the Public type of network connection is set on a computer, you will see the following error when enabling WinRM:

Set-WSManQuickConfig : ...?WinRM firewall exception will not work since one of the network connection types?on this machine is set to Public. Change the network connection type to either Domain or Private and try again.

Change the network type to Private (Set-NetConnectionProfile -NetworkCategory Private) or run the command below:

Enable-PSRemoting –SkipNetworkProfileCheck

Open the port TCP/5985 in Windows Defender Firewall to connect to WinRM. The easiest way is to open a Windows Firewall port using PowerShell. In this example, we will open the remote access only for the IP address of the administrator’s computer (more secure), but you can open it for everyone (specify Any instead of an IP address):

Set-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)" -RemoteAddress 192.168.13.100
Enable-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)"

On the administrator computer, make sure that the user’s computer now accepts remote connections via PSRemoting:

Test-NetConnection 192.168.13.222 –Port 5985
Test-WsMan 192.168.13.222

However, if you try to connect to a user computer remotely using the Invoke-Command or Enter-PSSession cmdlets, the following error appears:

Enter-PSSession 192.168.13.222

Enter-PSSession : Connecting to remote server 192.168.13.222 failed with the following error message: The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. PSRemotingTransportException.

The WinRM HTTP Listener on the remote computer only allows connection with Kerberos authentication.

Get-ChildItem -Path WSMan:\localhost\Service\Auth\

In order to use Negotiate authentication with NTLM, your computer must trust the remote computer. In a domain, this is achieved using Kerberos, while in a workgroup environment, you’ll have to add the computer’s IP addresses to TrustedHosts.

Add a user computer to TrustedHosts on the administrator’s computer (you can do it using its IP address or FQDN):

Set-Item wsman:\localhost\client\TrustedHosts -Value 192.168.13.222 -Force