How to Setup PowerShell Remote

How to Setup Windows PowerShell Remote v 2.0

The ability to create a remote connection is the most important difference between PowerShell v 1.0 and 2.0.  However, setting up remoting for the first time, is one of the most difficult tasks in PowerShell, especially in non-domain environments.  But no worries, I will lead through the steps and anticipate some of the potential problems with WinRm and TrustedHosts.

 PowerShell Remoting Tutorial Topics

• Introduction to PowerShell Remote
• Our PowerShell ‘Remoting’ Mission
• Two Types of Remote PowerShell
• WinRm – The Pre-requisite for Remote PowerShell
• Create a PowerShell Remote Session
• Troubleshooting PowerShell Remote Problems
• Remote Execution Enabler for PowerShell

 ♣

Introduction to Windows PowerShell Remote

PowerShell 1.0 is easier to learn than v 2.0, largely because there are few cmdlets and certainly no ability to create a remote session.  However, for those who mastered the basics of v 1.0, this inability to run scripts against another machine soon becomes a severe limitation.  Furthermore, once you have a working knowledge of PowerShell, then setting up remoting is not so hard after all.  It’s almost as though PowerShell 2.0 has this built in hurdle, you won’t be able to use remoting until your good enough to find, and then control, the TrustedHosts configuration.

In many ways my remote PowerShell tutorial reminds me of learning Telnet.  Sitting at our own keyboard, yet running the wonderful PowerShell commands against another machine transforms what we can achieve in terms of configuring settings and collecting data about your network empire.

Our Mission – To Enable Remoting in PowerShell v 2.0

The crucial component for this mission to get remote PowerShell working is WinRm.  If you have used a command line program such as NetSh then the techniques for configuring WinRm will be vaguely familiar.

I have divided this Remote PowerShell tutorial into four sections, this breakdown is particularly handy for troubleshooting.

• Install WinRm
• Enable PowerShell Remoting
• Set TrustedHosts *
• Create a Remote Session with PSSession

Goal – To Install the WinRm Service

The problem in explaining how to install WinRm is that each operating system has a different requirement.  Windows 7 and Server 2008 R2 already have WinRm, so there is no need worry about installing this service.  However, for Vista, XP and Windows Server 2008 you need to download the files from Microsoft and install WinRm.  Any doubts on what your machine already has installed either check the Services mmc, or better still use PowerShell and try: Get-Service winrm.

Goal – To Enable PowerShell Remoting

Launch PowerShell v 2.0 as an administrator then try this:

Note that unlike PSSession commands, this function only has one ‘S’ – PSRemoting.  Actually, the underling cmdlet is Enable-PSSessionConfiguration.  Running Enable-PSRemoting cmdlet achieves the following:

Starts the WinRM service and sets the startup type to Automatic.  Enables a firewall exception for WS-Management communications. Creates a listener to accept requests on any IP address.

Guy Recommends:  A Free Trial of the Network Performance Monitor (NPM) v11.5

SolarWinds’ Network Performance Monitor will help you discover what’s happening on your network.  This utility will also guide you through troubleshooting; the dashboard will indicate whether the root cause is a broken link, faulty equipment or resource overload.

What I like best is the way NPM suggests solutions to network problems.  Its also has the ability to monitor the health of individual VMware virtual machines.  If you are interested in troubleshooting, and creating network maps, then I recommend that you try NPM now.

Download a free trial of Solarwinds’ Network Performance Monitor

Goal – To Check TrustedHosts for *  (All)

First let us digress and check for PowerShell ‘providers’.

Get-PsProvider

The point of the other command is to show the existence of the WSMan namespace which maps to WinRm.  Next we can check its config settings in general and TrustedHosts in particular.

Note 1:  Beware, plain ‘cd wsman’ fails, we need that colon.

Note 2: You can usually omit the line ‘cd localhost\client’.

Crucial Goal – Configure TrustedHosts *

The concept is straightforward; on the ‘Victim’ machine, the one you are connecting to, you must specify which servers are allowed to connect, these are known as the trusted hosts.  Thus if you are on a server called ‘BigServe’, before you can remote to ‘LittleComputer’ you must set TrustedHosts on LittleComputer.

Important: this script will not work unless you are in the localhost\client folder of the WSMan namespace, see above instruction.  This method comes into its own in non-domain situation.  If you have an Active Directory domain then you can configure TrustedHosts via Group Policy.

Note 3:   You could simplify the above command to:
Set-Item WSMan:\localhost\Client\TrustedHosts *

Note 4:   For PowerShell to recognise the new TrustedHosts settings you need to restart the WinRm service.  It’s satisfying to use PowerShell itself to achieve this with:
Restart-Service winrm

Note 5:  Here is a rare plural – TrustedHosts.  All the PowerShell cmdlets are singular, but TrustedHosts is plural.

Note 6:  If this command gives trouble, revert to DOS!  Run winrm -? in a CMD box As Administrator, specifically:
winrm get winrm/config/client
or
winrm set winrm/config/client/ @{TrustedHosts="*"} 

Note 7:  Once the euphoria of success wears off you may want to limit * and substitute the names of servers on your network.

Note 8:  Managing TrustedHosts is a classic case for employing PowerShell’s ‘Get’ and ‘Set’ verbs in tandem.  After you Set-Item, then you Get-Item

Final Goal – To Complete Our Mission and Create a PowerShell Remote Session

Note 9:  Enter-PSSession requires a fully.quallified.domain.name, for example, BigServer.domain.local  Plain BigServer would NOT work, however the IP address is always good in this situation.

An alternative PSSession method:

Tip: If you want to test remoting but don’t have a second machine, then create a ‘Remote Session’ to your own own machine.  Explicitly, if your machine is called ‘KingMachine’, then try:
New-PSSession -computername KingMachine.  Weird – yes, illogical – maybe, but this technique will give you a taste of PowerShell remoting.

Guy Recommends: SolarWinds Engineer’s Toolset v10

This Engineer’s Toolset v10 provides a comprehensive console of 50 utilities for troubleshooting computer problems.  Guy says it helps me monitor what’s occurring on the network, and each tool teaches me more about how the underlying system operates.

There are so many good gadgets; it’s like having free rein of a sweetshop.  Thankfully the utilities are displayed logically: monitoring, network discovery, diagnostic, and Cisco tools.  Try the SolarWinds Engineer’s Toolset now!

Download your fully functional trial copy of the Engineer’s Toolset v10

Where Next With PowerShell Remoting v 2.0?

With the remote pipeline in place, you are ready to run PowerShell commands as though you were at the keyboard of the second machine, indeed, this is the whole point of creating remote shells.  For example,

As my mission in this remoting tutorial is solely to get you started, now it’s up to you to devise PowerShell commands to interrogate and even configure your remote computer.

Tip: If any of your remote commands don’t seem to work, test them on your local computer first.

Once remoting is working then there is no barrier to employing PowerShell to manage network computers, you can now run scripts against other machines.  Many cmdlets support the -computerName parameter, but remoting also enables you to use the PSSession family of cmdlets and also invoke-Command.

Troubleshooting PowerShell Remote Problems

• One common problem is ERROR: Access is denied.
  Solution: Launch PowerShell with elevated rights, in simple language: Run as administrator.
• Another PowerShell Remoting access is denied problem

• Solution append -Credential OtherMachine\AdminBod.  Remember Credential is singular, and remember the password for your user when prompted.
• Try setting TrustedHosts * on BOTH machines, that is the machine acting as the client as well as the server to which you are trying to establish a session.
• Remember that for once this is a plural TrustedHostS.
• Remember to restart the WinRm service, otherwise changes won’t take effect, try:
  Restart-Service WinRm
• Keep your eye on the difference between the namespace WSMan and the Windows service winrm.
• Bizarre and wacky.  Try connecting using Remote Desktop.  Bizarrely this may fail on the first attempt but succeed on the second attempt.  Now for the good news, re-try: Enter-PSSession DistantMachine

Remote Connection Problem: ‘Couldn’t connect to remote machine’

Solution: Start the Remote Registry Service
Start-Service RemoteRegistry

Wacky Solution: Try the old trick of using an IP address rather than the hostname name.

Firewalls, PowerShell and "The rpc server is unavailable"

• Security experts will hold up the hands in horror at this suggestion, but if you get the error message: "The rpc server is unavailable", then I suggest that you turn off the firewall on both machines.
• Now if that works, then great, but follow-up by testing which ports are involved (135, 445), then try configuring the firewall with exceptions that allow PowerShell remoting, but retain firewall protection from other threats.
• P.S. I have read that Enable-PSRemoting is supposed to take care of the firewall settings automatically, but in my experience this was not always the case.
• See how to disable Windows 8 firewalls with a Group Policy.

SolarWinds Firewall Browser

Here is an utility where you can review firewall settings such as access control lists (ACL), or troubleshoot problems with network address translation (NAT).

Other reasons to download this SolarWinds Firewall Browser include managing requests to change your firewall settings, and testing firewall rules before you go live.

 Guy recommends that you download a copy of the SolarWinds free Firewall Browser.

Two Types of Remote PowerShell

It’s time to point out that there are two varieties of Microsoft PowerShell remoting.  Firstly, the more sophisticated variation, which employs cmdlets that create a persistent pipe to the second machine.  These commands contain the aptly named noun PSSession, check what’s available with this cmdlet:

Secondly, there is also a more basic form of remote PowerShell which merely extends local commands by appending the -computerName parameter; the result is that your instructions run against another named machine on the network.  For example:

For a list of cmdlets that support this simple remote behaviour try:

For the full list you need to add: -And $_.parameters.keys -NotContains "Session".

See more tasks for PowerShell »

Summary of PowerShell Remote Tutorial

The secret of getting PowerShell remoting to work, is to understand the pre-requisites.  Install WinRm, run the Enable-PSRemoting to setup remoting, check the TrustedHosts*.  As for the actual Enter-PSSession, remember to specify the fully qualified hostname, else use the IPAddress.

See more Microsoft PowerShell tutorials

• PowerShell Home   • Real life tasks   • Invoke-Command   • PowerShell Windows 7

• Remote PowerShell   • PowerShell WSMan  • -Online   • PowerShell WinRm   • Test-Connection

• Jobs  -AsJob   • Receive-Job   • Get-Job   • Receive-Job   • Free WMI Monitor

Please email me if you have a better example script. Also please report any factual mistakes, grammatical errors or broken links, I will be happy to correct the fault.