Table of Contents
Since PSRemoting was born in Windows, it comes enabled by default but not universally and also not for all Windows OS versions.
On Windows Server, PSRemoting is enabled sometimes but not all of the time depending on what network profile Windows is running under. Below you’ll find a handy table to help you determine if your Windows OS has PSremoting enabled or not.
| Operating System | Network Profile | PSRemoting |
|---|---|---|
| Windows 7, 8, 10, 11 | Domain/Private/Public | Disabled |
| Windows Server 2008 R2 | Domain/Private/Public | Disabled |
| Windows Server 2012 & Newer | Domain/Private | Enabled |
| Windows Server 2012 & Newer | Public | Enabled within the same subnet |
Quick snapshot
Not like in a domain environment, enabling PSRemoting in WORKGROUP is more complicated. Here’s the quick snapshot about it. We’ll do it in details in the rest of this post.
On local computer:
- Change network category to Private
- Enable PSRemoting
- Add TrustedHost
- Always run remote commands with -Credential parameter
On remote computer:
- Change network category to Private
- Enable PSRemoting
PowerShell Remoting on Workgroup Computers
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.
PS C:\> Get-ChildItem -Path WSMan:\localhost\Service\Auth\
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Service\Auth
Type Name SourceOfValue Value
---- ---- ------------- -----
System.String Basic false
System.String Kerberos true
System.String Negotiate true
System.String Certificate false
System.String CredSSP false
System.String CbtHardeningLevel RelaxedHowever, if your computers are in a workgroup, you will have to use NTLM (Negotiate) 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:
- Local computer: 10.0.3.4 (Windows 10)
- Remote computer: 10.0.3.5 (Windows 11)
- User account using to login and configure is a member of local administrators group.
Enable and configure WinRM on the local computer
On server versions of Windows, Enable-PSRemoting succeeds on all network profiles. It creates firewall rules that allow remote access to public, private and domain networks. For public networks, it creates firewall rules that allows remote access from the same local subnet.
On client versions of Windows (Windows 10, 11), Enable-PSRemoting succeeds on private and domain networks. By default, it fails on public networks, but if you use the SkipNetworkProfileCheck parameter, Enable-PSRemoting succeeds and creates a firewall rule that allows traffic from the same local subnet.
Enable-PSRemoting -SkipNetworkProfileCheck -Force1️⃣ For security purposes, we recommended to change the networkcategory on the local computer to Private. We use the following command to do it with PowerShell ( Run as administrator).
PS C:\> Set-NetConnectionProfile -NetworkCategory Private
PS C:\> (Get-NetConnectionProfile).NetworkCategory
Private2️⃣ Run the following command to enable and configure WinRM on the local computer.
PS C:\Windows\system32> Enable-PSRemoting -Force
WinRM is already set up to receive requests on this computer.
WinRM has been updated for remote management.
WinRM firewall exception enabled.
Configured LocalAccountTokenFilterPolicy to grant administrative rights remotely to local users.Enable-PSRemoting cmdlet performs all of the following tasks:
- The WinRM service is started and set to automatic startup.
- Creates a listener on the default WinRM ports 5985 for HTTP traffic.
- Enables the firewall exceptions for WS-Management.
- Registers the PowerShell session configurations with WS-Management.
- Enables the PowerShell session configurations.
- Sets the PowerShell remote sessions to allow remote access.
- Restarts the WinRM server to apply all of the changes.
The same can be done using Windows cmd.exe (command prompt).
3️⃣ Because Kerberos authentication does not support in WORKGROUP environment. So, you need to add the hostname or IP address of the remote server to the Trusted Hosts list in the local computer’s WinRM configuration. Doing this enables the local computer able to connect to the remote server using NTLM as the authentication mechanism instead of Kerberos, which is used in domain-based environments.
By default, the TrustedHosts list is empty on every computer. So, it does not allow commands to any remote computer which is not in domain. You can get the list with command below:
PS C:\> Get-Item WSMan:\\localhost\client\TrustedHosts
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client
Type Name SourceOfValue Value
---- ---- ------------- -----
System.String TrustedHosts4️⃣ Now, add remote ComputerName or IP to TrsutedHosts list using Set-Item cmdlet as shown below:
That the –Concatenate parameter is mandatory if you want to add multiple conputers, otherwise every time you run the Set-Item command, it will keep overwriting the old values in TrustedHosts list. The -Force parameter is however optional, which is used to suppress the confirmation (Yes/No) prompt.
PS C:\> Set-Item WSMan:\\localhost\client\TrustedHosts -Value '10.0.3.5' -Concatenate -Force
PS C:\> Get-Item WSMan:\\localhost\client\TrustedHosts
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client
Type Name SourceOfValue Value
---- ---- ------------- -----
System.String TrustedHosts 10.0.3.5You can also allow remote connection to all computers (usually, it is not recommended as one of the major disadvantages of NTLM authentication is vulnerable to various malicious attacks:
Set-Item WSMan:\\localhost\client\TrustedHosts -Value * -Force
Enable and configure WinRM on the remote computer
To receive remote connections, you must enable PowerShell remoting on the remote computer.
1️⃣ Change the networkcategory on the remote computer to Private.
Set-NetConnectionProfile -NetworkCategory Private2️⃣ Run the following command to enable and configure WinRM on the remote computer.
PS C:\> Enable-PSRemoting -Force
WinRM has been updated to receive requests.
WinRM service started.
WinRM is already set up for remote management on this computer.3️⃣ To verify that remoting is configured correctly, run a test command such as the following command, which creates a remote session locally on the remote machine. If remoting is configured correctly, the command creates a session on the local computer and returns an object that represents the session.
PS C:\> New-PSSession
Id Name ComputerName ComputerType State ConfigurationName Availability
-- ---- ------------ ------------ ----- ----------------- ------------
3 WinRM3 localhost RemoteMachine Opened Microsoft.PowerShell AvailableThat’s it, the configuration process is complete. The remote machines are already for PowerShell Remoting.
Starting Interactive Remote Session
1️⃣ On the local computer, make sure that the remote computer now accepts remote connections via PSRemoting. This is optional step, but it could help for troubleshooting.
PS C:\> Test-NetConnection 10.0.3.5 -Port 5985
ComputerName : 10.0.3.5
RemoteAddress : 10.0.3.5
RemotePort : 5985
InterfaceAlias : Ethernet
SourceAddress : 10.0.3.4
TcpTestSucceeded : True
PS C:\> Test-WSMan 10.0.3.5
wsmid : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor : Microsoft Corporation
ProductVersion : OS: 0.0.0 SP: 0.0 Stack: 3.02️⃣ Then try to connect to the remote computer over PSRemoting:
Enter-PSSession -ComputerName 10.0.3.5 -Credential 10.0.3.5\admin3️⃣ Enter the remote computer’s administrator password and make sure that the connection has been established successfully (the hostname or the IP address of the remote computer is displayed in the PowerShell prompt).
PS C:\> Enter-PSSession -ComputerName 10.0.3.5 -Credential 10.0.3.5\admin
[10.0.3.5]: PS C:\Users\admin\Documents> hostname
Win11-PCFrom now, commands you typed in the console would be exexuted on the remote computer instead of the local computer. To end the interactive session, type Exit-PSSession or simply exit command.
PS C:\> Enter-PSSession -ComputerName 10.0.3.5 -Credential 10.0.3.5\admin
[10.0.3.5]: PS C:\Users\admin\Documents> hostname
Win11-PC
[10.0.3.5]: PS C:\Users\admin\Documents> exit #or Exit-PSSession
PS C:\Run remote commands
Alternatively, if you don’t want to create a full session to the remote computer. you can execute commands and scripts on remote workgroup computers using the Invoke-Command. For example, restart a computer remotely:
Invoke-Command -ComputerName 10.0.3.5 -Credential 10.0.3.5\admin –ScriptBlock {Restart-Computer}Use the -Credential parameter in all remote commands. This is required even when you connect as the current user. If you don’t want to type the password every command, you can create a variable as follows:
PS C:\> $cred = Get-Credential
cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential
PS C:\> Invoke-Command -ComputerName 10.0.3.5 -Credential $cred -ScriptBlock {Restart-Computer}You must enter a user password using the -Credential option
Note that in order to authenticate on a remote computer, you must enter a user password using the –Credential option. If you have many computers in your network with different local admin passwords, it is convenient to store connection passwords in a vault. It may be either a Windows Credential Manager password vault or an external store, like KeePass, LastPass, HashiCorp Vault, Azure Key Vault, or Bitwarden.
You can use the PowerShell Secret Management module to access saved passwords in such a vault. Now, in order to connect to a remote computer via PSRemoting, it is enough to:
1️⃣ Save a connection password, for example, to Credential Manager:
cmdkey /add:10.0.3.5 /user:psadmin /pass:Password1To run commands on a single remote computer, you can get the name and the password from the vault using the CredentialManager module then include it in the remote command.
$psCred = Get-StoredCredential -Target "10.0.3.5"2️⃣ Now you can execute commands and scripts on remote workgroup computers using the Invoke-Command. For example, restart a computer remotely:
$computers = @('10.0.3.5','10.0.3.6')
foreach ($computer in $computers) {
$psCred = Get-StoredCredential -Target $computer
Invoke-Command -ComputerName $computer -Credential $psCred –ScriptBlock {Restart-Computer}
}Windows Server in WORKGROUP
In a domain environment, servers running any supported version (Windows Server 2012 +) of Windows can establish remote connections and run remote commands in PowerShell without any configuration. However, to receive remote connections you must enable PowerShell remoting on the computer.
In WORKGROUP environment:
- On local machine (server): Add the hostname or IP of the remote machine (server) into TrustedHost.
- On remote machine (server): Enable PSRemoting using Enable-PSRemoting command.
By default, the remoting features of PowerShell are supported by the WinRM service, which is the Microsoft implementation of the Web Services for Management (WS-Management) protocol. When you enable PowerShell remoting, you change the default configuration of WS-Management and add system configuration that allow users to connect to WS-Management.
By default, no WinRM listener is configured. Even if the WinRM service is running, WS-Management protocol messages that request data can’t be received.
PS C:\> (Get-CimInstance -Class Win32_OperatingSystem).Caption
Microsoft Windows Server 2019 Standard
PS C:\> Get-Service -Name "*WinRM*"
Status Name DisplayName
------ ---- -----------
Running WinRM Windows Remote Management (WS-Manag...When you run New-PSSession locally on Windows Server, you would get the following error.
PS C:\> New-PSSession
New-PSSession : [localhost] Connecting to remote server localhost failed with the following error message : Access is
denied. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession
+ ~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailedTo configure PowerShell to receive remote commands:
- Start PowerShell with the Run as administrator option.
- At the command prompt, type: Enable-PSRemoting -Force
Once done, to verify that remoting is configured correctly, run a test command such as the following command, which creates a remote session on the local computer. If remoting is configured correctly, the command creates a session on the local computer and returns an object that represents the session.
PS C:\> New-PSSession
Id Name ComputerName ComputerType State ConfigurationName Availability
-- ---- ------------ ------------ ----- ----------------- ------------
2 WinRM2 localhost RemoteMachine Opened Microsoft.PowerShell AvailableFinally, from a local machine (server) open a remote sessiton to the remote machine (server).
PS C:\Windows\system32> Enter-PSSession -ComputerName 10.0.2.4 -Credential 10.0.2.4\psadmin
[10.0.2.4]: PS C:\Users\psadmin\Documents>Not a reader? Watch this related video tutorial:
