How To Enable PowerShell Remoting | Enable Remote Management

Running Enable-PSRemoting in an elevated PowerShell session enables remote management by configuring WinRM to accept commands.

Setting up remote management on Windows requires knowing how to enable PowerShell remoting, and the process is refreshingly short. A single command in an elevated PowerShell session configures the machine to accept remote commands, and the entire setup takes under a minute. Whether you manage one desktop or a server room, this is the foundation for remote administration on Windows.

What Does Enable-PSRemoting Actually Do?

The Enable-PSRemoting cmdlet prepares a Windows machine to receive PowerShell remote commands sent over WS-Management, which is Microsoft’s implementation of the WS-Management protocol. Microsoft’s official documentation notes that WS-Management-based PowerShell remoting is currently supported only on the Windows platform.

Behind the scenes, the command starts the WinRM service, sets its startup type to Automatic, and creates firewall rules that allow incoming remote management traffic. It also registers any needed session configurations on the machine. If remoting was previously disabled, the same cmdlet re-enables it.

One important limitation: this approach works on Windows hosts only. Linux and macOS systems cannot use WS-Management-based PowerShell remoting out of the box, though they support other remoting mechanisms through PowerShell 7.

How to Enable PowerShell Remoting on Windows

The setup is a single cmdlet, but it requires an elevated PowerShell session. Running it from a standard console produces an access-denied error every time.

1. Open PowerShell as Administrator. Right-click the Start menu icon and select Windows PowerShell (Admin) or Terminal (Admin). Click Yes on the UAC prompt.
2. Run Enable-PSRemoting. Type Enable-PSRemoting and press Enter. The output shows each step WinRM takes, and the process completes in seconds.
3. Suppress prompts with -Force when automating. For scripts or noninteractive setups, use Enable-PSRemoting -Force. The -Force flag skips the confirmation prompts and pushes straight through the configuration.
4. Confirm the result. The final line reads “WinRM has been updated to receive requests” or similar confirmation text. If you see errors about firewall rules or permissions, the system likely needs those resolved before remoting will work.

Microsoft’s cmdlet reference covers the full parameter set, with additional options for scoping the change to specific network profiles or session configurations.

How to Test That PowerShell Remoting Is Working

After running Enable-PSRemoting on the target machine, verify the connection from a second computer — or from the same machine using its local hostname — before relying on it in production.

• Enter-PSSession opens an interactive remote session. Run Enter-PSSession -ComputerName <hostname> to connect. When the prompt changes to [<hostname>]:, the connection is live.
• Exit-PSSession closes the interactive session and returns your prompt to the local machine.
• Invoke-Command runs a script block on a remote system without an interactive session. Use Invoke-Command -ComputerName <hostname> -ScriptBlock { Get-Service } to confirm command output returns correctly.

The success cue for any of these commands is clean output with no access-denied or connection-timed-out errors.

PowerShell Remoting Commands at a Glance

Can You Enable Remoting for Multiple Machines at Once?

In a domain environment, Group Policy is the standard route for enabling PowerShell remoting across multiple machines. Manual configuration works for one or two hosts, but any fleet of ten or more benefits from the GPO approach.

The relevant policy path is Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > Allow remote server management through WinRM. Enable that policy and set the allowed IP ranges or leave it at * to allow all.

You also need to start the WinRM service. Under Computer Configuration > Policies > Windows Settings > Security Settings > System Services, find Windows Remote Management (WS-Management), set its startup to Automatic, and apply the policy. After the GPO updates, each machine enables remoting on its next policy refresh or reboot.

Workgroup and Cross-Machine Considerations

When machines are not joined to a domain or when crossing trust boundaries, one extra step is often needed. The client must know which remote hosts to trust for Kerberos authentication, and the workaround is to configure TrustedHosts on the connecting machine.

Run this on the client to allow all hosts (use with caution in production):

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

A more restrictive approach lists specific hostnames or IPs separated by commas. Remote access also requires the connecting user to have Administrator privileges on the target system. Without admin rights, any remoting command fails regardless of how the service is configured.

Common Remoting Mistakes and Their Actual Results

Important Safety Caveats

Because PowerShell remoting exposes a management surface over the network, a few precautions keep the setup secure. WinRM traffic uses port 5985 (HTTP) and 5986 (HTTPS) by default. If those ports are unreachable, remoting fails even after the Enable-PSRemoting step succeeds — verify connectivity from the client side.

TrustedHosts=”*” combined with Basic Authentication is a notable risk. In that configuration, credentials pass in plaintext unless you enforce HTTPS for WinRM. For domain-joined machines, Kerberos authentication handles trust securely without the TrustedHosts workaround, so the broader trust setting is rarely needed in enterprise environments.

Non-elevated consoles remain the single most common failure point. Every remoting task — enabling, testing, or running commands — requires an Administrator-level PowerShell window. Checking that one detail saves more troubleshooting time than any other single step.

PowerShell Remoting Quick-Reference Checklist

• Run PowerShell as Administrator — the most common gate to check first.
• Run Enable-PSRemoting -Force — suppresses prompts and completes setup in one line.
• Verify with Enter-PSSession — test connectivity before scripting around it.
• Check WinRM firewall rules — confirm port 5985 or 5986 is reachable from the client.
• Confirm admin rights on the target — without them, every remoting command fails.
• Use Group Policy for fleets — manual setup does not scale beyond a few hosts.
• Restrict TrustedHosts — use specific hostnames, not a wildcard, whenever possible.