How do I run PowerShell on a remote computer without RDP?

Harjeet Sidhu · 2026-08-26 · 6 min read

You need to run a command on a client machine, or on fifty, without a full desktop session and without knocking the user off what they are doing. There are three ways to do it, and which one fits depends on whether the machines are in a domain, and whether they are on the same network as you.

Option 1: PowerShell Remoting over WinRM

This is built into Windows. On the target, once, as an administrator:

Enable-PSRemoting -Force

That starts the WinRM service, sets it to start automatically, and adds a firewall rule for port 5985 (HTTP) on the private and domain network profiles. On a machine whose current network is marked Public it refuses, unless you add -SkipNetworkProfileCheck. Port 5986 is WinRM over HTTPS and needs a certificate on the target.

Then, from your machine:

Invoke-Command -ComputerName PC01 -ScriptBlock { Get-Service wuauserv }
Invoke-Command -ComputerName PC01, PC02, PC03 -FilePath .\fix.ps1
Enter-PSSession -ComputerName PC01

Invoke-Command runs the block or the file and brings the output back; give it a list of names and it runs on all of them. Enter-PSSession is an interactive prompt on the remote box. Add -Credential (Get-Credential) to either to run as a different account.

In a domain this works out of the box with Kerberos, as long as your account is a local admin on the target (membership of Remote Management Users also works). Enabling it across a domain is a Group Policy job: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > "Allow remote server management through WinRM", plus the WinRM service set to Automatic and the firewall rule "Windows Remote Management (HTTP-In)" allowed.

What changes in a workgroup?

No Kerberos, so the client has no way to trust that PC01 is really PC01. You either use HTTPS on 5986, or tell your machine to trust the name:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Concatenate

* trusts every host and is a bad habit on an admin machine. The target also needs a local admin account, and for that account's admin rights to be honoured over the network the registry value LocalAccountTokenFilterPolicy under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System must be 1, or you use the built-in Administrator account, which is exempt. Most "access is denied" errors on workgroup machines are one of those two things.

Option 2: PsExec

PsExec from Sysinternals runs a command on a remote machine through the admin$ share. psexec \\PC01 -s cmd gives you a SYSTEM shell; psexec \\PC01 powershell -File \\server\share\fix.ps1 runs a script. It needs that share reachable on port 445 and admin rights on the target, and no setup on the target at all, which is why it is handy on a machine where WinRM was never enabled.

Attackers use PsExec for the same reason, so some antivirus products flag or block it. That, and the need for 445 open, is why WinRM is the better default.

Option 3: an RMM agent's terminal

The agent already has an outbound connection to the vendor, so there is nothing to enable on the machine, no firewall rule, no TrustedHosts and no VPN, and it works on a laptop in a cafe as well as a desktop in the office. Commands run as SYSTEM (or a chosen account) and are logged with who ran what. Most RMMs also let you save a script and run it against a group, with the output collected per machine.

Moorfox gives every managed machine a terminal running as SYSTEM over the agent's outbound connection, so Invoke-Command, WinRM and TrustedHosts never come into it, and the same command can be run across a group with per-machine output. Every command is in the machine's activity trail.

What should I never do?

Never expose port 5985 or 5986 to the internet, and never expose port 445. Remote PowerShell across the internet belongs inside a VPN or behind an agent that connects outbound. Do not set TrustedHosts to * on your admin machine.

What trips people up?

• The remote session has no interactive desktop. Anything that pops a window (a GUI installer, msg, an app that needs a logged-on user) hangs or fails. Use silent switches.
• Output objects come back deserialized: properties work, methods do not.
• The double-hop: a remote session cannot use your credentials to reach a third machine, such as a file share, unless you pass explicit credentials or set up CredSSP or resource-based Kerberos delegation.
• Execution policy on the target blocks scripts. Launch with -ExecutionPolicy Bypass through powershell.exe, or set Set-ExecutionPolicy RemoteSigned by policy.

Frequently asked questions

What port does PowerShell remoting use?

5985 for HTTP and 5986 for HTTPS. The HTTPS listener needs a certificate on the target. Neither port belongs on the internet.

Do I need to enable WinRM on Windows Server?

Windows Server 2012 R2 and later have it enabled by default. Workstations do not, so each one needs Enable-PSRemoting or the Group Policy settings that do the same job.

Why does Invoke-Command say access is denied on a workgroup machine?

One of three things: the target is not in your TrustedHosts list, the account you are using is not a local admin on the target, or it is a local admin but LocalAccountTokenFilterPolicy is not set to 1, so its admin token is filtered over the network. The built-in Administrator account is exempt from that last one.

Is PsExec safe to use?

Yes, it is a Microsoft tool. But attackers use it for lateral movement, so some antivirus products flag or block it, and it needs SMB on port 445 open to the target. WinRM avoids both problems.