Table of Contents


PowerShell remoting provides a method to send any command to a remote networked operating system device for local execution at runtime. The commands do not have to be available on the computer that originates the connection; it is enough if just the remote operating system are able to execute the commands.

Windows PowerShell remoting relies on the web services managements (WS-Man) protocol. WS-Management is a distributed management task force (DMTF) open standard that depends on HTTP (or HTTPS) protocol. The Windows Remote Management (WinRM) service is the Microsoft implementation of WS-Management, WinRM is at the heart of Windows PowerShell remoting but this service can also be used by other non-PowerShell applications.

Remoting can be achieved by many commands below example only talks about the Invoke-command method. Chapter 1.14 will talk about computer sessions.

Using the Invoke-Command method you may remote onto another networked operating system and run powershell commands on that host., You are able to specify any number of computer names to target (Either by using a variable with multiple computer names e.g.

$computers = ""," Fileserver01", "DomainController01"

or using the localhost to target your own computer. When selecting your own computer as a localhost target you will have to add the –credentials parameter of the local computer.

Then you will have to select in the –Scriptblock parameter as indicated by the curly brackets the remote commands you want to run. For example.

Invoke-command –credentials $credentials –computername localhost –scriptblock {RemoteCommandToRun}

A live example is below of remoting onto a test server to get the WMI records of the Operating system.

Invoke-Command -credential (Get-Credential) -ComputerName localhost -ScriptBlock {Get-WmiObject -Class win32_operatingsystem}

The bracketed get-credential command will ask for a credential to use for the remainder of the script.

And the result is to run the remoting command against the localhost target and retrieve the data back.

Note when using the invoke-command method, the values returned from the remote computer are deserialised into XML and not live data. This means in the process of running the command on the target machine, the returned data isnt a live object that you can manipulate methods against that will change its state as you will have to run another invoke-command command to get that extra data required.

You are still able to manipulate the contents retrieved of the static returned deserialised XML data by placing the contents of the object returned into a variable. E.g. The below command will return the current directories items and place into a local object to view further.

$credentials = get-credential

$RetrievedObject = Invoke-command –computername localhost -Credential $credentials –scriptblock {Get-ChildItem}


Notice that if we check the members of the retrieved object $RetrievedObject you can see that there are only two (2) methods available out of the normal twenty four (24) available for the System.IO.FileInfo object type.

If you would like to use invoke-command without winrm in case there is a firewall block, you can use the –hostname parameter to use the SSH protocol instead of WinRM.

To see further parameters you may use with Invoke-command visit the Microsoft Docs webpage for more uses. https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/invoke-command?view=powershell-6

By default, WS-Man and PowerShell remoting use port 5985 and 5986 for connections over HTTP and HTTPS, respectively. This is much friendlier to network firewalls when compared to other legacy communication protocols such as the distributed component object model (DCOM) and remote procedure call (RPC), which use numerous ports and dynamic port mappings.

Remoting is enabled by default on Windows Server 2012 and it is required by the server manager console to communicate with other Windows servers, and even to connect to the local computer where the console is running. On client operating systems, such as Windows 7 or Windows 8, remoting is not enabled by default.

Once enabled, remoting registers at least one listener. Each listener accepts incoming traffic through either HTTP or HTTPS; listeners can be bound to one or multiple IP addresses. Incoming traffic specifies the intended destination or endpoint. These endpoints are also known as session configurations.

When traffic is directed to an endpoint, WinRM starts the PowerShell engine, hands off the incoming traffic, and waits for PowerShell to complete its task. PowerShell will then pass the results to WinRM, and WinRM handles the transmission of that data back to the computer that originated the commands.

To enable remoting on a device you may use the command Enable-PSRemoting which will open up the required ports and setup the configuration of the local computer to allow powershell to transmit and receive data.


Powershell shell will need to be run as administrator to allow the exceptions to be made on the local computer. Note your domain firewall policies will take precedence in transmission of Powershell so be sure to check in a live production environment with a senior network engineer to enable remoting. You are also able to enable Powershell remoting through group policy.