Enable PowerShell Remoting on a standalone (workgroup) computer

• Author
• Recent Posts

Michael Pietroforte

Michael Pietroforte is the founder and editor in chief of 4sysops. He has more than 35 years of experience in IT management and system administration.

Latest posts by Michael Pietroforte (see all)

• Poll: How reliable are ChatGPT and Bing Chat? - Tue, May 23 2023
• Pip install Boto3 - Thu, Mar 24 2022
• Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022

In a previous article, Tim explained how to enable PowerShell Remoting on computers that are members of an Active Directory domain. On workgroup computers, things are a little more complicated, and you might stumble into a few pitfalls along the way.

The reason is that enabling PowerShell Remoting is a security risk because the bad guys certainly would love to automate their hacking efforts remotely on your computer. Thus, you have to jump through a few additional hoops.

We have to distinguish here between things that need to be done on the local and the remote computer. Let’s start with the remote machine.

On the remote computer

As on a domain member, you also enable PowerShell Remoting with the Enable-PSRemoting cmdlet. Make sure that your PowerShell host has administrator rights; otherwise, you will receive this error message:

Enable-PSRemoting : Access is denied. To run this cmdlet, start Windows PowerShell with the "Run as administrator" option.

Even if you considered this pitfall, you will get the next error message on a workgroup computer:

WinRM has been updated to receive requests.
WinRM service started.

Set-WSManQuickConfig : <f:WSManFault…. 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.

WinRM firewall exception will not work.

You probably know that Windows has three network connection types: Private, Public, and Domain. Windows will ask for the connection type when you first connect to a network. You can set different rules for network discovery and file and printer sharing in the Network and Sharing Center.

The above error message indicates that we have set the network to Public in order to enable PowerShell Remoting. Several ways exist to change the connection type. For some reason that only Microsoft knows, you can’t do this in the Network and Sharing Center. None of the other options in the Metro interface worked for me with regard to my goal to enable PowerShell Remoting.

Update: Akos mentioned in a comment a much easier solution than what follows in the next paragraphs. You simply have to add the -SkipNetworkProfileCheck parameter:

Enable-PSRemoting -SkipNetworkProfileCheck -Force

It is odd that the error message doesn't mention the parameter. By recommending to change the network connection type to private the message put me on the wrong track. I explain in the following paragraphs how this can be done. 

Update 2: There is an much easier way to change the network connection type than editing the Registry (see below). You can simply use a PowerShell cmdlet:  Set-NetConnectionProfile -NetworkCategory Private. However, I didn't test this in combination with Enable-PSRemoting.

The only way that did work was to change the connection type in the Registry. Before you follow the procedure below, you have to ensure that the computer is connected to the network and, if possible, to the Internet. (By the way, you might also stumble upon the above error when you try to enable Remoting on a machine that has no network connection.)

This is the Registry key that you have to edit:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

You might see different profiles in the Profile folder. Make sure that you get the right network connection, where ProfileName corresponds to the name of your current network connection, as demonstrated in the screenshot below:

Change network connection type from Public to Private.

You then have to change the Category value to 1 to set the network connection type to Private (0 stands for Public). Also ensure that the CategoryType is set to 0. After you change the Registry, you have to reboot the computer.

Now you can enable the PowerShell Remoting with this command:

Enable-PSRemoting -Force

The -Force parameter just saves you from a few confirmation prompts.

Enable-PSRemoting works now.

Note that Microsoft’s documentation mentions another solution to solve the network connection type problem. However, for me, this way didn’t work. If it worked for you, please let me know. For the sake of completeness, this is the command that Microsoft recommends:

Set-NetFirewallRule –Name "WINRM-HTTP-In-TCP-PUBLIC" –RemoteAddress Any

On the local computer

In an Active Directory environment, you can just use the computer name to connect to a remote machine. If you remotely connect to a standalone machine, you usually have to use the IP address instead. If you try to connect to the remote computer with the Enter-PSSession cmdlet using the IP address of the remote machine, PowerShell will throw the following error:

Enter-PSSession : Connecting to remote server 10.0.2.33 failed with the following error message : The WinRM client cannot process the request….

Connecting to a remote computer via IP address errors

The error message suggests to use the winrm command to add the IP to the trusted hosts. However, if you enter the correct command in PowerShell, you will get this error message:

winrm : Error: Invalid use of command line…

Update: Just learned that you can also run this wirm command in PowerShell, if you put the argument in quotes (winrm set winrm/config/client '@{TrustedHosts="10.0.2.33"}').

What we need here is an elevated command prompt:

winrm set winrm/config/client @{TrustedHosts="10.0.2.33"}

Adding the IP addresses to the list of trusted hosts with winrm

You’re probably wondering why you need an old-fashioned command prompt to do this. You rightly asked. There is actually a PowerShell command that does same thing. I don’t know why the above error message doesn’t mention it. This is the PowerShell way to add an IP address to the trusted hosts:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.0.2.33" -Force

Adding an IP address to the trusted hosts with PowerShell

If you have to manage several remote hosts, or if the IP always changes, you might want to add all IP addresses to the trusted hosts:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force

You can also read the trusted host list with PowerShell:

Get-Item WSMan:\localhost\Client\TrustedHosts

Displaying the trusted hosts

PowerShell might then sometimes show this error:

Get-Item : Cannot find path 'WSMan:\localhost\Client\TrustedHosts' because it does not exist.

In this case, you probably only have to start the Windows Remote Management (WS-Management) Windows service manually.

Note that the list won’t change if you reboot the machine. If you want to clear the list of your trusted hosts, you can run this command:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "" -Force

Now, you are finally ready to remotely manage the machine via PowerShell Remoting:

Enter-PSSession -ComputerName 10.0.2.33 -Credential $Credentials

Connecting to a remote computer with Enter-PSSession