Set Up PowerShell Remoting with WinRM Between Windows 10/11 PCs

PowerShell remoting between two Windows PCs is set up by enabling the WinRM listener and its firewall rule on each PC that will receive commands, then connecting from an administrator PowerShell session on the controlling PC. This guide supports Windows 10 and Windows 11, including Home and Pro editions, using the built-in Windows PowerShell 5.1 remoting endpoint and WinRM over HTTP port 5985. Use it on a trusted private LAN; for public, shared, or Internet-facing networks, configure WinRM over HTTPS instead.

Prerequisites and compatibility​

You need:

• Two powered-on Windows 10 or Windows 11 PCs on the same reachable network.
• A local administrator account on each target PC, or a domain account with administrator rights on the target.
• The target PC’s computer name or IP address.
• A password on any account used for remoting. Passwordless local accounts cannot be used for workgroup WinRM remoting.
• Windows PowerShell opened with Run as administrator when changing WinRM, firewall, listener, or TrustedHosts settings.

The PC issuing commands does not need WinRM remoting enabled unless you also want to manage it remotely. Enable remoting only on PCs that must accept incoming PowerShell sessions.
For domain-joined PCs, use the target’s hostname or fully qualified domain name whenever possible. This permits Kerberos authentication without adding TrustedHosts entries. For workgroup PCs, home networks, IP-address connections, or untrusted domains, add the specific target to TrustedHosts on the controlling PC and explicitly supply credentials.

Warning: Enabling remoting starts the Windows Remote Management service, creates a listener, enables firewall rules, and allows authorized users to run PowerShell commands remotely. Do not enable it on an untrusted network or expose TCP 5985 through a router or Internet firewall. Keep the network profile set to Private for a home or office LAN.

Click to expand...

Primary procedure​

1. Identify the target computer name and network profile​

On the PC you will manage, open Windows PowerShell and run:
Record the hostname result, such as DESKTOP-ADMIN01. In Get-NetConnectionProfile, confirm that NetworkCategory is Private or DomainAuthenticated.
If the network is shown as Public, change it before enabling WinRM.
Windows 11

• Open Start > Settings.
• Select Network & internet.
• Select Wi-Fi or Ethernet, depending on the active connection.
• Select the connected network’s Properties page.
• Under Network profile type, select Private.

Windows 10

• Open Start > Settings.
• Select Network & Internet.
• Select Wi-Fi or Ethernet.
• Select the active network connection.
• Turn on Make this PC discoverable. Windows treats this as a private network profile.

Expected result: Get-NetConnectionProfile reports Private or DomainAuthenticated.

2. Enable WinRM and the Windows PowerShell remoting endpoint on the target PC​

On each PC that must receive remote commands, open the built-in Windows PowerShell as administrator:

• Open Start.
• Type Windows PowerShell.
• Right-click Windows PowerShell.
• Select Run as administrator.
• Approve the User Account Control prompt.

Run:
Enable-PSRemoting -Force
Expected results include messages indicating that:

• WinRM is configured to receive requests.
• The WinRM service startup type changed to Automatic.
• The WinRM service started.
• A WinRM firewall exception was enabled.

This command also restarts the WinRM service. A full Windows restart is not required.
Use Windows PowerShell for this step rather than PowerShell 7 (pwsh) when you want the standard built-in Microsoft.PowerShell endpoint. If you also need a PowerShell 7-specific remote endpoint, run Enable-PSRemoting -Force separately from an elevated PowerShell 7 session.

3. Confirm that WinRM is running and listening​

Still on the target PC, run:
Expected results:

• Get-Service WinRM shows Status as Running and StartType as Automatic.
• The listener output includes an HTTP listener on port 5985.
• At least one WinRM firewall rule is enabled for the active Private or Domain network profile.

To confirm that the standard Windows PowerShell endpoint is available, run:
Get-PSSessionConfiguration
Look for an endpoint named Microsoft.PowerShell. On 64-bit Windows, Microsoft.PowerShell32 may also appear.

4. Test WinRM locally before testing across the network​

On the target PC, in the same elevated Windows PowerShell window, run:
Expected result: Test-WSMan returns WinRM identification information, and New-PSSession returns a session with State shown as Opened.
Remove the test session when finished:
Get-PSSession | Remove-PSSession
If this local test fails, do not proceed to the second PC. Go to the troubleshooting section and correct the target’s WinRM configuration first.

5. Prepare the controlling PC​

On the controlling PC, open Windows PowerShell as administrator.
First, test basic network reachability to the target. Replace TARGET-PC with the target’s computer name:
Test-NetConnection -ComputerName TARGET-PC -Port 5985
Expected result:
TcpTestSucceeded : True
If the result is False, the PCs cannot reach the target’s WinRM listener. Check that both PCs are on the same network, that the target is awake, and that its active network profile is Private or DomainAuthenticated.

6. Configure authentication for domain or workgroup PCs​

Domain-joined PCs​

If both PCs are in the same Active Directory domain, or in domains that trust one another, connect using the target computer’s hostname or fully qualified domain name. Do not add it to TrustedHosts unless you have a specific reason to use NTLM rather than Kerberos.
Continue to Step 7.

Workgroup PCs, home networks, IP-address connections, or separate domains​

Add only the specific target computer name or IP address to TrustedHosts on the controlling PC.

Warning: TrustedHosts suppresses server identity verification for NTLM-based WinRM connections. It affects every user of the controlling PC. Do not set TrustedHosts to *, and do not add broad wildcards such as *.local unless you understand and accept the security exposure.

Click to expand...

First, record the existing setting:
Get-Item WSMan:\localhost\Client\TrustedHosts
Then add the target while preserving existing entries:
Replace TARGET-PC with the target hostname. If you intend to connect by IP address, enter the IP address instead.
Confirm the new value:
Get-Item WSMan:\localhost\Client\TrustedHosts

7. Run a remote command​

From the controlling PC, run the following command. Replace TARGET-PC with the target name:
When prompted, enter an account authorized on the target PC:

• For a local account, use TARGET-PC\Username.
• For a domain account, use DOMAIN\Username or [email][email protected][/email].

Expected result: the output identifies the target PC, the account used, and the target’s current date and time. The command ran on the target, not on the controlling PC.
For an interactive remote PowerShell prompt, use:
Enter-PSSession -ComputerName TARGET-PC -Credential $cred
The prompt changes to show the remote computer name. Run:
hostname
Expected result: it returns the target computer name.
Exit the remote session when finished:
Exit-PSSession

8. Create and reuse a persistent session​

A persistent session is useful when you need to run several commands without reconnecting each time:
Expected result: the remote PC returns its Windows edition, version, and build information. Remove-PSSession closes the session cleanly.

Verification of success​

Your WinRM remoting configuration is complete when all of the following succeed:
The first command should return TcpTestSucceeded : True. The second should return WinRM protocol information. The third should return the target’s hostname without a connection, authentication, or access-denied error.

Troubleshooting and rollback​

“The WinRM client cannot process the request” or TrustedHosts error​

This normally occurs when connecting to a workgroup PC, an IP address, or a machine in an untrusted domain. Use the target’s hostname rather than its IP address where possible. Otherwise:

• Add the exact target hostname or IP address to TrustedHosts on the controlling PC.
• Use -Credential on Invoke-Command, New-PSSession, or Enter-PSSession.
• Confirm the target account has a nonblank password.

Do not use TrustedHosts * as a shortcut.

“The connection to the remote host was refused”​

On the target PC, open Windows PowerShell as administrator and run:
Then, from the controlling PC, retest port 5985:
Test-NetConnection -ComputerName TARGET-PC -Port 5985
If the port remains closed, check third-party endpoint security, router client-isolation settings, guest Wi-Fi isolation, or an organization-managed firewall policy.

Enable-PSRemoting fails because the network is Public​

The safe fix is to change the network profile to Private using the Settings paths in Step 1.
If the PC must remain on a Public profile but both PCs are on the same local subnet, run this only on the target:
Enable-PSRemoting -SkipNetworkProfileCheck -Force

Warning: On Windows client editions, this permits WinRM on a Public profile only from the same subnet. Do not broaden the firewall rule to permit all remote addresses on a Public network.

Click to expand...

“Access is denied” after connecting​

Confirm that the credentials belong to an administrator on the target:
By default, remoting access to administrative endpoints is intended for administrators. For a non-administrator account, adjust endpoint permissions deliberately rather than weakening UAC or registry protections:
Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI
Run that command locally on the target as administrator, grant only the necessary user or group permission, and accept the WinRM restart prompt if shown.
Do not set LocalAccountTokenFilterPolicy merely to bypass remote UAC restrictions unless you have a documented administrative requirement and understand that it weakens remote UAC protections for local administrators.

PowerShell 7 connects but the expected endpoint is missing​

Windows PowerShell 5.1 and PowerShell 7 can coexist. The built-in endpoint is normally Microsoft.PowerShell. A PowerShell 7 endpoint is separate and must be enabled from an elevated PowerShell 7 window:
Then connect using the displayed endpoint name, for example:
New-PSSession -ComputerName TARGET-PC -ConfigurationName PowerShell.7 -Credential $cred

Roll back WinRM remoting on a PC​

Run these commands locally on the PC you no longer want to manage remotely, from an elevated Windows PowerShell session:
Disable-PSRemoting disables remote access to the PowerShell endpoints, but it does not by itself remove every listener, firewall, or service change created during setup. Disabling the WinRM firewall rules and stopping and disabling the service prevents incoming WinRM connections.
If you added a TrustedHosts entry on the controlling PC, remove or restore it after remoting is no longer needed:
Replace PREVIOUS-VALUE with the value recorded before Step 6, or use an empty string if there were no prior TrustedHosts entries.