An Introduction to PowerShell Remoting (WinRM) — Managing Multiple Windows Machines at Once

“After Windows Update, go and check that all twenty servers came back up properly.” “Find out what that setting is currently set to on the PCs at every site.” — Are you handling requests like these by logging into each machine one at a time over Remote Desktop? Even at three minutes per machine, twenty machines is an hour. People get bored partway through, and checks get missed.

PowerShell Remoting is the mechanism that turns “the same work across many machines” into a single command. Windows ships with a remote management foundation called WinRM, and it is enabled by default on Windows Server. In other words, in many workplaces you can start using it today without installing anything. Despite that, we often hear “it just feels risky” or “it wouldn’t connect in our workgroup, so I gave up.”

This article is aimed at IT staff and operations people at small and medium-sized businesses. It covers how Remoting works (what runs on which port, and who can connect), running commands across many machines with Invoke-Command, the difference between domain and workgroup environments, well-known traps such as the second hop problem, and safe day-to-day operation that “starts from read-only.”

1. The Bottom Line First

• PowerShell Remoting runs on top of WinRM (an implementation of WS-Management) and uses ports HTTP 5985 / HTTPS 5986 by default. Even over HTTP, the traffic is protected by message-level encryption provided by the authentication protocol.¹
• By default only members of the Administrators group on the remote side can connect, and the session runs in the connecting user’s context. Enabling Remoting does not mean “anyone can get in.”¹
• What Enable-PSRemoting does is clearly defined. It starts the WinRM service and sets it to start automatically, creates a listener, adds a firewall exception, and enables the session configurations. It is enabled by default on Windows Server; on client editions of Windows you enable it manually.²¹
• A domain environment works as-is with Kerberos; a workgroup needs NTLM + TrustedHosts + explicit credentials. TrustedHosts is not a setting that says “I trust this machine” — it is a list of machines whose identity you have given up verifying, so keep it to a minimum.³¹
• Use Invoke-Command to run something everywhere, Enter-PSSession for interactive work, and New-PSSession when you want to keep state and reuse the connection. Invoke-Command processes up to 32 machines in parallel by default.⁴⁵
• What comes back from the remote side is a deserialized object with no methods. Complete the actual operations inside the ScriptBlock (on the remote side), and only aggregate the results locally.⁶⁵
• You cannot reach a further server from the machine you connected to (the second hop problem). This is not a defect; it is the consequence of a safe design that does not send your credentials to the remote machine. There are several remedies, chosen according to requirements.⁷
• PowerShell 7 also supports SSH-based Remoting. It is an option when you need to manage Linux alongside Windows, or in environments where you would rather not open WinRM.⁸

2. How It Works — Who Gets In, and How, on Top of WinRM

The foundation of PowerShell Remoting is WinRM (Windows Remote Management). WinRM is Microsoft’s implementation of the standard WS-Management protocol, and PowerShell Remoting delivers commands to PowerShell on a remote computer through it.¹ Communication uses ports 5985 (HTTP) and 5986 (HTTPS) by default.¹³

People worry that “HTTP means plain text,” but once the initial authentication completes, WinRM encrypts the traffic. Over HTTPS that is TLS; over HTTP it is message-level encryption negotiated by the authentication protocol (AES-256 with Kerberos in a modern environment).¹ Also, by default only members of the Administrators group on the remote side can connect, and because the session runs in the context of the connecting user, access control on files and the registry applies just as it normally would.¹

Preparation on the receiving side is Enable-PSRemoting. What this cmdlet does is enumerated officially. It runs Set-WSManQuickConfig internally to (1) start the WinRM service, (2) set the startup type to automatic, (3) create a listener that accepts requests on any IP address, (4) enable the firewall exception for WS-Management traffic, and (5) create and enable the session configurations (endpoints) and grant remote access — then it restarts the WinRM service.²

# Run once on the machine that will BE connected to, from an elevated PowerShell session
# (usually unnecessary on Windows Server, where it is enabled by default; required on client Windows)
Enable-PSRemoting

# Connectivity check from the machine you connect FROM — if this succeeds, the Remoting foundation is in place
Test-WSMan -ComputerName sv-app01

There are two behaviours that will trip you up if you do not know about them. The first is the firewall. On Server editions of Windows, Enable-PSRemoting creates a rule for public networks too, restricted to “from the same subnet only”; on client editions, if the network profile is Public then enabling it fails outright (a classic problem when you connect a test machine to the office Wi-Fi). In that case, add -SkipNetworkProfileCheck, or change the profile to Private.²

The second is the relationship between PowerShell versions and endpoints. Enable-PSRemoting configures the endpoint “for the version of PowerShell you ran it from.” Running it under PowerShell 7 has no effect on the Windows PowerShell 5.1 endpoint, and vice versa.² What is more, even when you connect from PowerShell 7, the existing Windows PowerShell 5.1 endpoint (Microsoft.PowerShell) is used by default,⁹ so “I’m on 7 locally, but 5.1 was what actually ran remotely” happens routinely. Get into the habit of printing $PSVersionTable on the remote side to check.

3. Domain vs Workgroup — This Is Where the Authentication Wall Is

The biggest stumbling block for newcomers to Remoting is not command syntax but authentication. The preparation you need changes with the environment.

In a domain environment, Kerberos mutual authentication (client and server each verify the other) is in play, so Invoke-Command -ComputerName sv-app01 { ... } simply works. In a workgroup, Kerberos is unavailable,³ so you register the target in TrustedHosts on the connecting side.

# Run on the machine you connect FROM, from a PowerShell session started as administrator (workgroups only)
# Changing TrustedHosts also requires administrator rights. The existing value is overwritten, so check it first
Get-Item WSMan:\localhost\Client\TrustedHosts

# Append only the minimum set of host names you need. Without -Concatenate the existing entries are wiped. Avoid allowing everything with '*'
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'sv-app01,sv-app02' -Concatenate

# Test the connection with explicit credentials
$cred = Get-Credential sv-app01\Administrator
Invoke-Command -ComputerName sv-app01 -Credential $cred -ScriptBlock { hostname }

What matters here is what TrustedHosts actually means. The official documentation states plainly that “computers in the TrustedHosts list are not authenticated, and the client may send credentials to them.”³ In other words, this is less “a list of machines you trust” and more “a list that suppresses the warning that the server’s identity cannot be verified.”¹ In an environment where DNS or ARP has been tampered with, you risk handing administrator credentials to an impostor server. So avoid wildcard entries, and list only a minimal set of fixed host names or IP addresses. For a workgroup environment or DMZ you intend to operate seriously, the sounder engineering judgement is to obtain a certificate and configure an HTTPS (5986) listener.¹

One more thing: if you find yourself writing credentials received from Get-Credential into a script in plain text, that is a warning sign. The standard approaches to storing and passing credentials are collected in “Handling Credentials Safely in PowerShell,” published alongside this article.

4. Invoke-Command — The Basic Shape of “Do the Same Thing on 20 Machines”

The star of Remoting is Invoke-Command. You pass multiple machines to -ComputerName and write “what to do remotely” in -ScriptBlock.⁴ Starting from a read-only inventory is the golden rule of safe operation.

$servers = 'sv-app01', 'sv-app02', 'sv-db01'

# Post-patch status check — read-only, so it is safe to run without worry
$result = Invoke-Command -ComputerName $servers -ScriptBlock {
    # Everything inside this block runs on the REMOTE side
    $os = Get-CimInstance Win32_OperatingSystem
    [PSCustomObject]@{
        LastBoot   = $os.LastBootUpTime                      # Has the reboot completed?
        SpoolerRun = (Get-Service -Name Spooler).Status      # Status of a service the business depends on
        FreeGB     = [math]::Round((Get-PSDrive C).Free / 1GB, 1)
    }
}

# PSComputerName tells you which result came from which server
$result | Sort-Object PSComputerName |
    Select-Object PSComputerName, LastBoot, SpoolerRun, FreeGB |
    Export-Csv -Path .\patch-check.csv -NoTypeInformation -Encoding UTF8

Connections to each server are processed in parallel, and the default concurrency (ThrottleLimit) is 32.⁵ Results come back interleaved in the order they arrive, so sort them using the automatically added PSComputerName property, as in the example above.⁶

4.1. Passing Variables — $using: and -ArgumentList

Because the ScriptBlock runs remotely, your local variables are not visible inside it. There are two ways to bring values in.¹¹

$threshold = (Get-Date).AddDays(-30)

# Method 1: $using: — embeds a copy of the caller's variable value into the remote side
Invoke-Command -ComputerName $servers -ScriptBlock {
    (Get-ChildItem 'D:\AppLogs' -Filter *.log |
        Where-Object LastWriteTime -lt $using:threshold).Count
}

# Method 2: -ArgumentList — received by a param declaration inside the ScriptBlock (easier to read with many arguments)
Invoke-Command -ComputerName $servers -ScriptBlock {
    param($limit)
    (Get-ChildItem 'D:\AppLogs' -Filter *.log |
        Where-Object LastWriteTime -lt $limit).Count
} -ArgumentList $threshold

The value passed via $using: is an independent copy on the remote side. Modifying it remotely does not change your local variable.¹¹

4.2. What Comes Back Is a “Snapshot” — Deserialized Objects

This is the first thing that confuses people about Remoting results. Live .NET objects cannot cross a network, so remote output is serialized to XML (CLIXML), sent, and restored locally as a deserialized object. It is a snapshot of the properties as they were at execution time, and it has no methods.⁶⁵

For example, you cannot take the result of Get-Service locally and call .Stop() on it. If you want to stop a service, run Stop-Service inside the ScriptBlock — that is, split the roles so that operations are completed on the remote side and only reporting data is brought home. Local post-processing such as selecting properties, formatting, and writing CSV works exactly as it does in everyday PowerShell (for these basic operations, see “PowerShell Command Basics”).

5. Enter-PSSession and New-PSSession — Interactive Work and Reuse

When you want to investigate a single machine interactively, use Enter-PSSession. The prompt changes to [sv-app01]: PS> and the commands you type run remotely. You leave with exit.¹⁰ Unlike Remote Desktop it does not bring a GUI with it, but for “looking at a log” or “checking a setting” it is faster, and it likewise requires membership in the remote Administrators group to connect.¹⁰

Meanwhile, every time you call Invoke-Command with -ComputerName, a connection is established and torn down.¹² For investigative work where you throw many commands at the same set of servers, creating a persistent session with New-PSSession and reusing it is faster — and remote-side variables and state are retained between commands.¹²¹³

# Open the session once and reuse it through the variable $s
$s = New-PSSession -ComputerName $servers
try {
    # First call: create a variable named $hotfix on the remote side
    Invoke-Command -Session $s { $hotfix = Get-HotFix | Sort-Object InstalledOn -Descending }

    # Second call: the variable created by the previous command is still available (the session retains state)
    Invoke-Command -Session $s { $hotfix | Select-Object -First 5 }
}
finally {
    # Always dispose of it, even if an error or interruption happens partway (frees resources on the remote side)
    Remove-PSSession $s
}

6. Pitfalls — the Second Hop, and SSH as an Option

6.1. The Second Hop (Double Hop) Problem

This is the most famous wall in the field. You connect from your PC (A) to server B via Remoting, and from inside B you try to read \\fs01\share (server C) — and you get access denied. The default Kerberos/NTLM authentication is a safe scheme that authenticates without sending your credentials themselves to B, so B cannot authenticate to C on your behalf.¹⁷

There are several remedies, and the official documentation organizes them in recommended order.⁷ The main ones are as follows.

• Pass credentials explicitly inside the ScriptBlock — the easiest, requiring no server-side configuration changes. You pass credentials to the inner Invoke-Command with $using:cred.⁷ However, since the credential object is handed to the session on the intermediate server (B), a compromised B could also use whatever you passed — so the premise is that you do this only when you can fully trust B, and that the account you pass is a dedicated account with the minimum necessary rights on C.
• Resource-based Kerberos constrained delegation — a scheme that stores no credentials and instead configures the target (C) to “accept delegation from B.” It can be configured without domain administrator rights and strikes a good balance between security and configuration simplicity.⁷
• CredSSP — credentials are cached on the remote server, so if that server is compromised the credentials are stolen along with it. It is disabled by default, and enabling it should be limited to your most trusted environments.⁷

# The easiest workaround: pass credentials to the inner Invoke-Command with $using:cred
# Connect to the outer machine (sv-app01) with your own credentials, and pass inward only a
# dedicated account with the minimum rights needed on fs01 (do not hand out administrator credentials)
$cred = Get-Credential CONTOSO\svc-fileread
Invoke-Command -ComputerName sv-app01 -ScriptBlock {
    Invoke-Command -ComputerName fs01 -Credential $using:cred -ScriptBlock { hostname }
}

The cheapest solution of all is to ask first whether you can avoid “reading C’s files by way of B” entirely and instead run Invoke-Command against C directly from your own machine.

6.2. With PowerShell 7 You Can Also Choose SSH-Based Remoting

From PowerShell 6.0 onwards you can use Remoting over SSH instead of WinRM. Invoke-Command / Enter-PSSession / New-PSSession gained SSH parameter sets with -HostName, -UserName, and -KeyFilePath, allowing management across Windows and Linux.⁸ The target needs an SSH server and PowerShell’s SSH subsystem configured, and features that exist in the WinRM-based world, such as endpoint configurations and JEA, are not currently supported.⁸ It is worth remembering as an option in environments with a mix of Linux servers, or where you want to standardize on key-based authentication. Windows PowerShell 5.1 does not have this capability, so it can be a motivation to migrate if you need it (for the full picture of the differences, see “Differences Between Windows PowerShell 5.1 and PowerShell 7,” published alongside this article).

Incidentally, a Remoting session does not create a desktop session the way RDP does. How the meaning of “runs remotely” differs between the two is covered in “How to Think About Windows Session Isolation.”

7. Standard Practice in the Field (Decision Table)

Let me emphasize that last row. Invoke-Command is simultaneously “the command that fixes 20 machines in an instant” and “the command that breaks 20 machines in an instant.” Fortunately, many change-oriented cmdlets such as Stop-Service and Set-ItemProperty support -WhatIf, and they work the same way inside a ScriptBlock. Make a habit of three stages — first one machine, then all machines with -WhatIf, and only then the real run — and your accident rate drops visibly.

8. Summary

• Remoting runs on WinRM (WS-Management), with default ports HTTP 5985 / HTTPS 5986. By default only members of the remote Administrators group can connect, and traffic is encrypted after authentication.
• Enable-PSRemoting starts the WinRM service, creates a listener, adds a firewall exception, and enables the session configurations. Note that it configures the endpoint for the version of PowerShell you ran it from.
• Domains work as-is with Kerberos; workgroups need TrustedHosts + explicit credentials. TrustedHosts is a list of machines whose identity verification you have abandoned, so keep it minimal.
• Use Invoke-Command to run something everywhere (32 in parallel by default), Enter-PSSession for interactive work, and reuse New-PSSession when you need to keep state. Results are deserialized objects with no methods, so complete your operations on the remote side.
• You cannot reach beyond the machine you connected to (the second hop). Start with explicitly passed credentials; for permanent operation, consider resource-based Kerberos constrained delegation.
• Start operations with read-only commands. For change operations, use three stages: one machine → -WhatIf → the real run. For a concrete example applied to a file server inventory, see “Taking Inventory of a File Server with PowerShell,” published alongside this article.

Related Articles

• PowerShell Command Basics — The Operations to Learn First and How to Use Them Safely
• Practical PowerShell Command Recipes — Growing the Small Tools You Use Every Day
• Taking Inventory of a File Server with PowerShell — Capacity Analysis and Access Permission (ACL) Auditing
• Handling Credentials Safely in PowerShell
• How to Think About Windows Session Isolation — Session 0, RDP, and Running Multiple Users Concurrently
• Handling Windows Impersonation Tokens Correctly — Borrowing Privileges per Thread and Reverting Safely

Related Consulting Areas

KomuraSoft LLC handles building mechanisms for managing servers and clients en masse with PowerShell, designing and reviewing operational scripts that incorporate Remoting, and investigating WinRM and authentication issues such as “it won’t connect” or “authentication fails only in this particular environment.”

• Technical Consulting & Design Review
• Bug Investigation & Root Cause Analysis
• Windows App Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What happens when I run Enable-PSRemoting?

Internally it runs Set-WSManQuickConfig, which starts the WinRM service and sets its startup type to automatic, creates a listener that accepts requests on any IP address, enables the firewall exception for WS-Management traffic, and enables the session configurations (endpoints) while changing their security descriptors to allow remote access. It is enabled by default on Windows Server, but on client editions of Windows you have to run it yourself. It is only needed on the machine that receives connections; you do not need to run it on the machine you connect from.

What do I need in order to use PowerShell Remoting in a workgroup (non-domain) environment?

Without a domain there is no Kerberos, so authentication falls back to NTLM. The basic pattern is to register the target in the WSMan TrustedHosts list on the connecting machine and pass credentials explicitly with -Credential. Note, however, that a host listed in TrustedHosts may be sent your credentials without ever being authenticated (no identity verification), so register only the minimum set of host names you actually need rather than a wildcard, and consider configuring an HTTPS (5986) listener where you can.

Why can't I call methods on the objects returned by Invoke-Command?

Because the output of a remote command is serialized to XML (CLIXML) in order to travel over the network, and is then restored locally as a deserialized object. That object is a snapshot of the properties as they were at execution time, not a live object, so it has no methods. Operations such as stopping a service must be performed inside the ScriptBlock (on the remote side) rather than by calling a method locally.

What is the second hop (double hop) problem?

It is the problem where you connect from PC A to server B via Remoting, and then get access denied when B tries to reach yet another server C (a file server, for example). The default Kerberos/NTLM authentication does not send your credentials themselves to B, so B cannot authenticate to C as you. The remedies include passing credentials explicitly inside the ScriptBlock, resource-based Kerberos constrained delegation, and CredSSP (which increases risk because credentials are handed to the remote side); you choose based on your requirements.

Can anyone connect to PowerShell Remoting?

No. By default only members of the Administrators group on the remote computer can connect. In addition, once connected, the session runs in the context of the connecting user, so the operating system's access controls apply exactly as usual. That said, it is a powerful entry point for administrators, so operate it in combination with layered defences: reviewing firewall rules, HTTPS listeners, and restricting access to only the administrators who need it.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.