In short
PowerShell Remoting lets you run PowerShell commands on another Windows Server without opening an interactive RDP desktop. On Windows Server 2025, the standard Windows PowerShell remoting path uses WinRM and the WS-Management protocol.
For a domain environment, the cleanest setup is:
Target Windows Server → enable PowerShell Remoting → confirm WinRM listener + firewall rules → use DNS/server name → authenticate with Kerberos → test with Test-WSMan → open Enter-PSSession or run Invoke-Command → restrict admin rights and network exposure
The basic server-side command is:
Enable-PSRemoting -Force
But a secure production setup is more than running one command. You still need the right authentication model, firewall scope, DNS, administrator permissions, and a decision about whether HTTP with Kerberos is sufficient or whether your environment requires a separate HTTPS listener.
This page is the canonical Raff guide for PowerShell Remoting / WinRM setup. For a broader command reference, see 25 PowerShell Commands Every Windows VPS Admin Needs.
What PowerShell Remoting actually does
PowerShell Remoting lets one Windows system execute PowerShell commands on another system.
Typical uses include:
- checking services across multiple servers;
- restarting application services;
- collecting CPU, memory, disk, and event-log data;
- running configuration changes remotely;
- administering Server Core systems;
- automating repetitive MSP or fleet-management tasks;
- running commands against several Windows VMs at once.
The three commands administrators use most are:
| Command | Purpose |
|---|---|
Enable-PSRemoting | Configure the target computer to receive PowerShell remote commands |
Enter-PSSession | Start one interactive remote PowerShell session |
Invoke-Command | Run commands or script blocks remotely, including on multiple servers |
Fresh US DataForSEO demand confirms this is a meaningful Windows admin topic: powershell remoting is roughly 590 monthly searches with KD 1, while invoke-command powershell is also around 590 and enter-pssession around 480.
PowerShell Remoting vs RDP
PowerShell Remoting and Remote Desktop solve different problems.
| Need | Better tool |
|---|---|
| Run one admin command remotely | PowerShell Remoting |
| Run the same command on several servers | PowerShell Remoting |
| Automate routine administration | PowerShell Remoting |
| Manage Server Core | PowerShell Remoting |
| Use a graphical application | RDP |
| Troubleshoot a GUI-only installer | RDP |
| Give employees a desktop session | RDS, not admin remoting |
PowerShell Remoting is especially useful when you want to reduce how often administrators log into each server interactively.
How WinRM fits into PowerShell Remoting
Windows PowerShell remoting uses the Windows Remote Management (WinRM) service.
In a typical configuration:
PowerShell client → WS-Man request → WinRM listener on target server → authenticated remote PowerShell session
Microsoft documents WinRM default listener ports as:
- TCP 5985 for HTTP;
- TCP 5986 for HTTPS.
Do not broadly expose either port to the public internet. For hosted Windows VMs, scope management access to trusted administrator networks, private networking, VPN, or another controlled management path.
Prerequisites
Before enabling remoting, confirm:
- the target is Windows Server 2025, 2022, 2019, or another supported Windows version;
- you have administrator rights on the target server;
- DNS resolves the target server correctly where domain authentication is used;
- Windows Firewall remains enabled;
- the administrator workstation can reach the server over the intended management network;
- you know whether the target is domain-joined or in a workgroup;
- you have a recovery path before changing firewall or authentication settings.
For a production VPS, do not solve connectivity problems by disabling Windows Firewall or opening WinRM to every source address.
Step 1 — Check the WinRM service
On the target Windows Server, open PowerShell as Administrator and run:
Get-Service WinRM
You can also inspect its startup configuration:
Get-Service WinRM | Select-Object Name, Status, StartType
If PowerShell Remoting has not been configured yet, the service state alone does not prove the server is ready to receive remote PowerShell sessions.
Step 2 — Enable PowerShell Remoting
On the server you want to manage remotely, run:
Enable-PSRemoting -Force
Microsoft documents Enable-PSRemoting as configuring the computer to receive remote commands. On supported Windows Server systems, the command performs the required remoting setup for Windows PowerShell, including WinRM-related configuration and firewall exceptions appropriate to the network profile.
The -Force switch suppresses confirmation prompts. It does not mean “ignore security.”
Afterward, check WinRM again:
Get-Service WinRM | Select-Object Name, Status, StartType
Step 3 — Inspect the WinRM listeners
Run:
winrm enumerate winrm/config/listener
or:
Get-ChildItem WSMan:\localhost\Listener
A default PowerShell Remoting configuration typically includes an HTTP WinRM listener.
Do not assume you need HTTPS just because the listener says HTTP. In a properly configured Active Directory environment, Kerberos provides authentication and message protection for the remoting session even when WS-Man uses the HTTP transport. HTTPS becomes more relevant when the architecture, trust boundary, or compliance requirement calls for TLS at the transport layer.
Step 4 — Review the Windows Firewall rules
PowerShell Remoting depends on inbound WinRM access.
Inspect relevant firewall rules:
Get-NetFirewallRule | Where-Object DisplayName -Like '*Windows Remote Management*' | Select-Object DisplayName, Enabled, Direction, Action, Profile
You can inspect port filters too:
Get-NetFirewallRule | Where-Object DisplayName -Like '*Windows Remote Management*' | Get-NetFirewallPortFilter
For general firewall administration, use Configure Windows Firewall on a Windows VPS.
Do not open WinRM broadly on a public VPS
A rule such as “allow TCP 5985 from anywhere” is a poor default for internet-facing infrastructure.
Prefer one of these patterns:
Administrator workstation → VPN/private network → Windows Server
or:
Known office/admin public IP → tightly scoped firewall rule → Windows Server
Use the smallest practical source range.
Step 5 — Test WinRM connectivity with Test-WSMan
From the administration computer, run:
Test-WSMan SERVER01
Replace SERVER01 with the target hostname.
A successful response confirms that the client can reach the target WinRM service and negotiate WS-Management communication.
If the test fails, check in this order:
- DNS/name resolution;
- network routing;
- Windows Firewall;
- WinRM service state;
- listener configuration;
- domain/workgroup trust model;
- administrator permissions.
Do not jump immediately to TrustedHosts.
Step 6 — Use Enter-PSSession for an interactive session
For an interactive remote shell:
Enter-PSSession -ComputerName SERVER01
If explicit credentials are required:
Enter-PSSession ` -ComputerName SERVER01 ` -Credential (Get-Credential)
Once connected, the prompt changes to indicate that commands are being executed remotely.
Run a harmless verification command:
hostname
Then:
Get-ComputerInfo | Select-Object CsName, WindowsProductName, WindowsVersion, OsBuildNumber
Exit the remote session with:
Exit-PSSession
Step 7 — Use Invoke-Command for one-off remote tasks
Invoke-Command is better when you want to run a command without entering an interactive session.
Example:
Invoke-Command ` -ComputerName SERVER01 ` -ScriptBlock { Get-Service WinRM }
Check disk space remotely:
Invoke-Command ` -ComputerName SERVER01 ` -ScriptBlock { Get-Volume | Where-Object DriveLetter | Select-Object DriveLetter, Size, SizeRemaining }
Restart a service remotely:
Invoke-Command ` -ComputerName SERVER01 ` -ScriptBlock { Restart-Service -Name W3SVC }
Only run change commands after confirming the target computer and expected impact.
Step 8 — Run commands on several servers
One major advantage of PowerShell Remoting is fan-out administration.
Invoke-Command ` -ComputerName 'SERVER01','SERVER02','SERVER03' ` -ScriptBlock { Get-Service WinRM | Select-Object MachineName, Name, Status }
A more useful inventory example:
Invoke-Command ` -ComputerName 'SERVER01','SERVER02','SERVER03' ` -ScriptBlock { Get-ComputerInfo | Select-Object CsName, WindowsProductName, OsBuildNumber }
For MSP and fleet-management workflows, this is the point where PowerShell Remoting becomes more efficient than opening three RDP sessions.
Domain-joined servers: prefer Kerberos
In an Active Directory environment, use server names that resolve correctly in DNS and let Kerberos handle authentication.
A clean domain pattern is:
Admin workstation joined to domain → SERVER01.contoso.local → Kerberos authentication → WinRM
Benefits include:
- mutual authentication;
- no need to create broad TrustedHosts entries;
- stronger identity assurance than treating arbitrary IP addresses as trusted endpoints;
- easier centralized administration.
Use the server's DNS name rather than an IP address when Kerberos is part of the authentication design.
Workgroup servers and TrustedHosts
Workgroup environments do not have the same Kerberos trust relationship as an Active Directory domain.
This is where administrators often encounter TrustedHosts.
You can inspect the current list with:
Get-Item WSMan:\localhost\Client\TrustedHosts
The dangerous shortcut is:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value '*'
Do not use a wildcard TrustedHosts value as a generic production fix. It tells the WinRM client to trust any remote computer for authentication scenarios that use TrustedHosts.
If TrustedHosts is genuinely required, scope it narrowly to explicit server names or addresses and understand that TrustedHosts is an authentication trust decision, not an encryption feature.
Example of a narrow entry:
Set-Item ` WSMan:\localhost\Client\TrustedHosts ` -Value 'SERVER01'
For multiple explicit hosts:
Set-Item ` WSMan:\localhost\Client\TrustedHosts ` -Value 'SERVER01,SERVER02'
Re-check afterward:
Get-Item WSMan:\localhost\Client\TrustedHosts
Should you use WinRM over HTTPS?
HTTPS uses a TLS certificate and normally listens on TCP 5986.
Consider a dedicated HTTPS listener when:
- the server is outside a trusted domain boundary;
- policy requires TLS transport;
- you manage systems across networks where Kerberos is unavailable;
- you need certificate-backed endpoint identity as part of the design.
Do not create a self-signed certificate and expose port 5986 globally just to say “we use HTTPS.” The certificate name, trust chain, firewall scope, and client verification still matter.
In a domain environment using Kerberos, HTTP does not mean the PowerShell command contents are simply sent in clear text. WS-Man authentication mechanisms protect the session. Transport HTTPS is a separate architectural choice.
High-level WinRM HTTPS setup
A proper HTTPS listener needs a server-authentication certificate whose subject or SAN matches the hostname clients use.
At a high level:
trusted certificate → WinRM HTTPS listener → firewall rule for TCP 5986 from management sources → client connects with -UseSSL
Inspect existing listeners first:
winrm enumerate winrm/config/listener
When an HTTPS listener has been correctly configured, test it from a client with:
Test-WSMan SERVER01 -UseSSL
and connect with:
Enter-PSSession ` -ComputerName SERVER01 ` -UseSSL ` -Credential (Get-Credential)
Because certificate enrollment and listener creation vary by PKI and environment, use Microsoft's current WinRM HTTPS documentation for the exact certificate/listener procedure rather than copying an unverified certificate script into production.
PowerShell Remoting authentication choices
PowerShell remoting can support multiple authentication mechanisms depending on environment and configuration.
For normal Windows Server administration, think in this order:
| Environment | Preferred direction |
|---|---|
| Active Directory domain | Kerberos with DNS names |
| Workgroup / no domain trust | Explicit credentials plus carefully scoped trust or HTTPS architecture |
| Cross-boundary managed environment | Evaluate HTTPS/certificate design and organizational security requirements |
Avoid enabling weaker authentication simply to make a test pass.
Administrator permissions and least privilege
By default, PowerShell Remoting endpoints are administrative management interfaces.
Do not give ordinary application users local Administrator membership merely because you want them to run one remote task.
For mature environments, evaluate Just Enough Administration (JEA) so operators can perform a defined set of administrative tasks without receiving unrestricted administrator access.
JEA is especially relevant for:
- help-desk teams;
- MSP operators;
- delegated application support;
- routine service restarts;
- controlled diagnostics.
This article does not turn JEA into a second canonical topic; it is a hardening direction for remoting deployments.
The second-hop problem
A remote session can authenticate successfully to SERVER01 and still fail when that remote server then tries to access another protected network resource such as FILE01.
Example:
ADMIN-PC → PowerShell Remoting → SERVER01 → attempts to access → FILE01
This is commonly called the second-hop problem.
Do not solve it by casually enabling credential delegation. Depending on the environment, Microsoft documents options such as resource-based Kerberos constrained delegation, Kerberos constrained delegation, CredSSP, RunAs session configurations, and other patterns.
Choose the least-risk design for the actual workflow. CredSSP, for example, delegates credentials and therefore has a different security trade-off than normal Kerberos remoting.
Secure configuration checklist
Before using PowerShell Remoting in production, confirm:
- Windows Firewall remains enabled.
- WinRM ports are not broadly exposed to the internet.
- Domain systems use DNS names and Kerberos where possible.
- TrustedHosts is empty unless the architecture specifically requires it.
- TrustedHosts never uses
*as a convenience production setting. - Administrator permissions are limited to people who need them.
- Remote commands are auditable.
- PowerShell logging is considered for sensitive environments.
- HTTPS certificates are trusted and hostname-correct when HTTPS is used.
- A recovery path exists before firewall/authentication changes.
- JEA is considered for delegated administration.
For the wider production baseline, use Windows Server Hardening Checklist.
PowerShell logging for remote administration
For environments where remote administrative actions need stronger visibility, PowerShell logging can help.
The broader hardening guide covers script block logging and security logs. Relevant signals include:
- PowerShell Operational logs;
- WinRM Operational logs;
- Security logon events;
- process-creation auditing;
- administrative group changes.
Remember that verbose PowerShell logging can capture sensitive values if administrators place secrets directly inside commands or scripts. Do not type passwords or tokens into script text.
Common errors and fixes
Connecting to remote server failed
Check:
Test-WSMan SERVER01
Then verify DNS, routing, WinRM service, listener, firewall, and authentication.
WinRM cannot complete the operation
Confirm the target hostname resolves and the management port is reachable.
Test-NetConnection SERVER01 -Port 5985
For HTTPS:
Test-NetConnection SERVER01 -Port 5986
Access is denied
Check whether the account has the required rights on the target server and whether you are connecting to the intended endpoint.
Do not fix this by adding every operator to Domain Admins.
The IP address works poorly with domain authentication
Use the server's DNS hostname so Kerberos can work as designed.
Workgroup authentication fails
Confirm whether the design requires an HTTPS listener or a narrow TrustedHosts entry. Do not immediately set TrustedHosts to *.
Port 5985 is reachable but Enter-PSSession fails
Network reachability is only one layer. Check authentication, endpoint configuration, credentials, and authorization.
HTTPS fails with a certificate error
Verify:
- hostname matches certificate subject/SAN;
- issuing CA is trusted by the client;
- certificate is not expired;
- the correct certificate is bound to the WinRM HTTPS listener.
Useful PowerShell Remoting commands
Enable remoting
Enable-PSRemoting -Force
Test WS-Man
Test-WSMan SERVER01
Interactive remote shell
Enter-PSSession -ComputerName SERVER01
Interactive session with credentials
Enter-PSSession ` -ComputerName SERVER01 ` -Credential (Get-Credential)
One-off command
Invoke-Command ` -ComputerName SERVER01 ` -ScriptBlock { Get-Service }
Multiple servers
Invoke-Command ` -ComputerName SERVER01,SERVER02,SERVER03 ` -ScriptBlock { hostname }
Inspect WinRM service
Get-Service WinRM
Inspect listeners
winrm enumerate winrm/config/listener
Inspect TrustedHosts
Get-Item WSMan:\localhost\Client\TrustedHosts
Where Raff fits
Raff Windows VMs provide the Windows Server infrastructure where PowerShell Remoting can be used for administration and automation.
For a small Windows fleet, a practical model is:
Admin workstation or management VM → private/trusted management path → Raff Windows VMs → PowerShell Remoting
Raff provides the VM infrastructure; the administrator remains responsible for Windows identity, WinRM configuration, firewall scope, certificates, PowerShell authorization, and automation scripts unless a separate managed service explicitly covers them.