PowerShell Remoting in a Workgroup Environment: A Step-by-Step GuidePowerShell Remoting in a Workgroup Environment: A Step-by-Step GuidePowerShell Remoting in a Workgroup Environment: A Step-by-Step Guide
This tutorial guides you through setting up PowerShell remoting between non-domain-joined computers.
As a frequent PowerShell user, I often connect to remote machines via the command line. Recently, I have been working on a project that requires sending PowerShell commands between two non-domain-joined computers.
This poses a problem because PowerShell remoting relies on WinRM, which depends on Kerberos—and Kerberos needs domain-joined computers.
a PowerShell screenshot displays a failed connection because the computers are not joined to a domain
Figure 1. The connection fails because the computers are not joined to a domain.
Thankfully, PowerShell remoting can still work in a workgroup environment. However, setting up and configuring remote management proved more complex than anticipated.
Step 1: Enable PowerShell Remoting on the Remote Machine
As with a domain-joined PC, the first step is to enable PowerShell remoting on the remote machine. Open an elevated PowerShell session and run the following command:
Enable-PSRemoting -Forcea powershell window showing the command enable-psremoting -force
Figure 2. Enable PowerShell remoting on the remote PC.
Step 2: Configure the Windows Firewall
Next, modify the Windows firewall to allow inbound WinRM traffic. While you could use the winrm quickconfig command as a shortcut, it often fails to update the firewall rules properly. Instead, it's usually better to manually create the rule through the Windows GUI or PowerShell. Here is the PowerShell command:
New-NetFirewallRule -Name "WinRM" -DisplayName "Windows Remote Management" -Enabled True -Direction Inbound -Protocol TCP -LocalPort 5985 -Action Allowa PowerShell window shows commands for creating a new firewall
Figure 3. Create a Windows firewall rule using PowerShell.
Related:Securing PowerShell: How to Stop Prompt Injection Attacks, Part 5
Step 3: Set Up Trusted Hosts on the Local Machine
After that, you must set up a list of trusted hosts. While WinRM and the firewall rule were configured on the remote machine, this step must be done on the local machine—the machine initiating the connection.
Open an elevated PowerShell session on the local machine and run:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "<RemotePCName or IP>" –ForceStep 4: Resolve Any Errors
You may encounter an error saying you can't connect to the remote PC. If that happens, try restarting the WinRM service on the remote machine:
Restart-Service WinRMAnother common issue is that Windows might use a Public firewall profile rather than the Private one. To check, enter the Get-NetConnectionProfile command on both machines.
In Figure 4, you can see my machine was trying to use the Public profile. To switch to the Private profile, run this command (again, on both computers):
Set-NetConnectionProfile -Name "<Network Name>" -NetworkCategory Privatea PowerShell screenshot shows the Get-NetConnectionProfile command in action
Figure 4. My computer tried using the Public profile.
If you still have issues, double-check the firewall rules using the GUI. You may have mistyped the port number.
Additionally, Microsoft recommends entering these commands on the remote machine:
winrm invoke Restore winrm/Config
winrm quickconfig In my case, when I tried adding the remote machine to my trusted host list, I received the following error:
Set-Item : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
Related:Securing PowerShell: How to Stop Prompt Injection Attacks, Part 4
Using the winrm quickconfig command didn't fix my problem. I had to take two additional steps to resolve it. First, on the remote host, run the following commands:
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/Auth '@{Basic="true"}'
Restart-Service WinRM These commands enable unencrypted WinRM traffic and basic authentication. Unfortunately, this is necessary in a workgroup environment since Kerberos isn't available.
The second step I needed to take was running winrm quickconfig on my local machine. I initially thought WinRM was enabled, but it wasn't. WinRM must be enabled on local and remote machines in a workgroup environment. Running the winrm quickconfig command on my local system allowed me to add the remote system to the trusted hosts list.
Step 5: Connect to the Machine
Once the remote computer is added to the trusted hosts list, you can connect using the following commands:
$Cred=Get-Credential
Enter-PSSession -ComputerName <computer name> -Credential $CredThe first command will prompt you to enter your credentials for the remote machine, and the second command establishes the remote session. Note that your user account must have a password for this to work.
Related:Securing PowerShell: How to Stop Prompt Injection Attacks, Part 3
About the Author
Technology Analyst
Brien Posey is a bestselling technology author, a speaker, and a 20X Microsoft MVP. In addition to his ongoing work in IT, Posey has spent the last several years training as a commercial astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space.
You May Also Like
Enterprise Connect 2026 – All In on What’s Next