If you’re an IT Pro, PowerShell remoting is a great tool for doing quick, ad hoc management tasks on computers from the comfort of your own home or office. However, before you can log into a machine, you have to make sure that it’s properly configured to grant you access – for safety’s sake, the default settings don’t allow remote access. If the machine you’re trying to log into is in a Workgroup, which doesn’t have the same stringent security requirements and infrastructure of a typical Domain setting, you’ll have to modify a few additional settings in order to get this done.
Below I’ve listed the steps required to configure two Workgroup machines so that you can remotely access one from the other using PowerShell. The computer you’re sitting in front of is called the client machine, while the computer you’re trying to remotely access is called the server machine.
First, configure the server machine to allow access. To do this, open a PowerShell command prompt (be sure to run as Administrator) and run the following cmdlet:
If one of the network cards on your computer has the network connection type set to “Public” then the required port won’t be opened in your firewall settings. If you’d rather not change your network connection type, you’ll have to manually configure your firewall to allow traffic through. If you plan on connecting using a specific port, be sure to set your firewall rules appropriately. If you’re just using the default ports, see this recent blog post to figure out which ports to open.
Make sure that the password for your Administrator account is not empty! If it is, you won’t be able to log in remotely.
Now you’ll need to configure your client machine. First you’ll have to enable WinRM local access so that you can modify the proper settings. To do this, start the WinRM service and enable the local account token filter policy (see this Microsoft support article for details on this machine-wide policy). Run these commands in an elevated PowerShell prompt:
Set-ItemProperty –Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System –Name LocalAccountTokenFilterPolicy –Value 1 –Type DWord
Both of those steps are unnecessary if you’ve already run the Enable-PSRemoting cmdlet on your client machine.
If you’re running on Windows XP, you also need to set the network access policy “Sharing and security model for local accounts” to Classic (see this Microsoft support article for more details):
Set-ItemProperty –Path HKLM:\System\CurrentControlSet\Control\Lsa –Name ForceGuest –Value 0
Now that WinRM local access is enabled, you’ll need to add the name of your server machine to the TrustedHosts setting in the WinRM configuration, which enables your client machine to connect to your server machine using an authentication mechanism that does not authenticate the server (like Kerberos does):
Set-Item WSMan:\localhost\Client\TrustedHosts –Value <ServerMachineName> -Force
Note: This command replaces any previous value that was stored in TrustedHosts! If there is an existing list of servers and you don’t want to remove then, use the –Concatenate parameter:
Set-Item WSMan:\localhost\Client\TrustedHosts –Value <ServerMachineName> -Force -Concatenate
If you want to use your server machine’s IP address instead of its name, you must specify explicit credentials when you connect.
A word of caution: by adding a server to the TrustedHosts list, you are allowing your credential information to be sent to a server without verifying its identity. Only add a server to this list if you know that the network path from your client machine to the server machine is secure.
You can now manage your server machine using PowerShell remoting!
Just in case things don’t work out perfectly the first time, here are some useful commands to check on the relevant configuration settings.
To check if the WinRM service is running:
To check the version of WinRM that’s installed:
Test-WSMan –Auth default
To check the remoting configuration for PowerShell:
To verify that local WinRM access is working:
To check if the local account token filter policy is enabled (on Windows Vista and Windows Server 2008):
Get-ItemProperty –Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System –Name LocalAccountTokenFilterPolicy*
To check if the network access policy “Sharing and security model for local accounts” is set to Classic (on Windows XP):
Get-ItemProperty –Path HKLM:\System\CurrentControlSet\Control\Lsa –Name ForceGuest*
To check the WinRM listener settings:
winrm enumerate winrm/config/listener
For additional help and troubleshooting steps:
Program Manager | WS-Management