Using PowerShell Remoting (Invoke-Command) to Run Scripts on Remote Windows Machines

Desired outcome

Run a PowerShell script or command on one or more remote Windows computers and collect the output locally, enabling centralized administration without logging into each machine.

Prerequisites

• PowerShell 5.1 or later installed on both the local and remote machines.
• Windows Remote Management (WinRM) service running and configured for PowerShell remoting.
• Firewall allowing inbound TCP 5985 (HTTP) or 5986 (HTTPS) on the targets.
• An account with permission to create remote sessions (typically a local administrator or domain admin).

Procedure

1. Enable PowerShell remoting on target computers

On each target machine, open an elevated PowerShell session and run:

Enable-PSRemoting -Force

This configures the WinRM listener, creates firewall rules, and sets the service to start automatically. Administrative rights are required.

2. (Optional) Configure TrustedHosts for workgroup scenarios

If the computers are not domain‑joined, add their names to the TrustedHosts list on the client that will initiate the sessions:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'Computer01,Computer02' -Concatenate -Force

Run this in an elevated PowerShell session on the client machine.

3. Test connectivity

From the administrative console, verify the WinRM listener:

Test-WSMan -ComputerName Computer01

A successful response includes SchemaMaj, SchemaMin, Protocol, and Product fields without any error messages.

4. Invoke the script

Assume you have a script named Get-SystemInfo.ps1 stored at C:\Scripts\Get-SystemInfo.ps1 on the client. The script returns the OS version and last boot time.

Invoke-Command -ComputerName Computer01,Computer02 `
    -FilePath 'C:\Scripts\Get-SystemInfo.ps1' `
    -ArgumentList @() `
    -Credential (Get-Credential) `
    -ErrorAction Stop

Replace Computer01,Computer02 with your actual target list. The -Credential prompt runs under an account that has permission to create a remote session.

Expected checks

• After Test-WSMan, confirm the output shows Protocol as http (or https if you configured SSL) and no Connecting to remote server failed message.
• Run a quick sanity check before the full script:

Invoke-Command -ComputerName Computer01 -ScriptBlock { Get-Date }

The returned timestamp should match the remote system’s clock (allowing for a few seconds skew).

When the full script runs, inspect the returned objects for expected properties such as OSVersion and LastBootUpTime and verify that no error records appear in the pipeline.

Recovery / Rollback

Enabling remoting changes the WinRM service and firewall rules. To revert:

Disable-PSRemoting -Force

Run this on each target computer with administrative rights. Afterwards, review the inbound firewall rules for ports 5985 (HTTP) and 5986 (HTTPS) to ensure they match your organization’s baseline.

Limitations and practical verification

• PowerShell remoting requires that the WinRM service be reachable; network segmentation or host‑based firewalls can block traffic even if the service is running.
• Using HTTP (port 5985) transmits credentials in clear text unless Kerberos or CredSSP is employed. For production environments, configure HTTPS with a trusted certificate and use -UseSSL.
• The TrustedHosts approach is less secure than domain authentication; limit its use to isolated test labs.

To verify that remoting has been successfully disabled after rollback, run:

Test-WSMan -ComputerName Computer01

You should receive a connection error or an indication that the service is not responding, confirming that the listener is no longer active.