Liam Glanfield

Enabling PowerShell Remoting

Liam Glanfield -

Background

Many people I work with will tell you how much I love PowerShell, I have been working with PowerShell since version 1 and it has become a key asset to my daily working life.

My first large script (around 5000 lines of code!) was built with many WMI calls and using a list of servers from Active Directory (AD) processed one by one. This worked great for about 10 servers, however 300 proved slow. So implemented mutli threading to allow multiple servers to be processed at once, this made the script acceptable and I was happy with it.

Fast forward a couple of years. I am now working with different and larger environments with servers in the thousands not hundreds. My script has become error ridden and slow (WMI timeouts etc.), due to the larger number of servers and many networking hurdles presented by RPC dynamic ports. This all adding to the script that was taking as much as 4-6 hours to run.

This is when PowerShell remoting becomes useful.

But… Always a but!

Natively most environments are not ready for PowerShell remoting, so how do you get yourself up and running with PowerShell remoting? What are the risks? What are the benefits?

Implementing PowerShell Remoting

First of all the PowerShell version must be 2 or higher. This is supported on the following operating systems;

  • Windows Server 2003 (R2) SP2 or Windows XP SP3
  • Windows Server 2008 SP2 or Windows Vista SP2

Starting from Windows 7 or Windows Server 2008 R2, PowerShell version 2 or higher is always included with the OS.

You can deploy PowerShell version 2 via WSUS or manually, the KB article is here https://support.microsoft.com/en-us/kb/968929.

This post is all about computers joined to an AD domain, however you can include workgroup machines such as Exchange edge transport servers in the DMZ for example, I will cover workgroup PowerShell Remoting in a later post.

Single Machine Manual Setup

  1. Ensure you have the above KB installed if you are running anything less than 2008 R2 or Windows 7
  2. Launch an administrative PowerShell window
  3. At the command prompt enter Enable-PSRemoting -Force

That’s it after you have answered the few questions that prompt you with yes (Y) then the machine should be configured.

Using Group Policy

Now repeating the above for all your Windows client and server devices would be very boring and cumbersome to manage. However thankfully you can enable PowerShell Remoting using a group policy.

You will need;

  • Windows Server 2008 R2/Windows 7 or higher
  • Group Policy Manager installed

Ok now the configuration;

  1. Logon to your chosen management computer
  2. Launch Group Policy Manager
  3. Edit your chosen policy or create a new one
  4. Navigate to the following tree path Computer Configuration -> Windows Settings -> Security Settings -> System Services
  5. Find the service named Windows Remote Management (WS-Management) and set it to Automatic ensure you leave the security configuration untouched
  6. Navigate to the following tree path Computer Configuration -> Administrative Templates -> Windows Components
  7. Under Windows Components locate the sub tree item named Windows Remote Management (WinRM) and click on the sub tree named WinRM Service
  8. In the right hand pane select the setting named Allow remote server managment through WinRM

Configure it as shown below, for demonstration purposes I have placed a star in the IPv4 Filter box this will mean all network adapters will listen for remote requests, however I recommend defining your internal subnet

Network Configuration

For domain joined computers the only port you need to worry about is TCP 5985, this is the HTTP port however this does not mean it is not encrypted. The traffic is encrypted on this port. As Kerberos is used to authenticate you and protect your session. TCP 5986 is the HTTPS port but I will cover this as part of the workgroup post.

You need to ensure that the TCP port 5985 is accessible from your management server to the server you wish to remotely manage.

Unlike WMI that is all the ports you need opened, simples.

Using PowerShell Remoting

I will type up a more in-depth post on this but for now, we will do a simple 1 to 1 PowerShell remote session.

At a PowerShell window on your management computer, simply type Enter-PSSession HOSTNAME, of course replacing HOSTNAME with your remote computers name. If successful, you will now be presented with a remote session signified with the hostname prefixing the prompt.

This is very similar to using SSH to get a remote prompt on a Linux based machine and just as secure.

The Risks

Ok this all sounds straight forward so far, what are the risks?

Well not a lot really, many Microsoft and non-Microsoft applications and infrastructure services are making use of this technology. Take Citrix for example, it uses wsman which is the same method that PowerShell remoting uses.

I haven’t found any significant risks with PowerShell remoting, most are which all attribute to the fact an administrator has enabled Cred SSP or enabled trusted hosts. If left at default settings PowerShell remoting is designed to be secure from the word go.

Let me put this quote from an article on the SANS blog to you;

If you allow administrators to remote desktop into Windows hosts in your environment, then you should allow, and even encourage, PowerShell Remoting as an alternative since it does a better job of protecting domain credentials by avoiding interactive logons and delegation tokens.

Benefits of Remoting

PowerShell Remoting is not just for servers it’s for your client devices to.

The biggest benefit for PowerShell Remoting is the ability to quickly process a command across your estate and collect the information quickly and efficiently.

Take an example you need to identify non-managed Symantec antivirus clients on all desktops, using PowerShell remoting could see you having that very answer in your lap within minutes not hours or even days!

Wrap Up

This is my first post on here and something I have a great deal of passion for. I am hoping to produce more somewhat helpful documents like this. Although I struggled with the web based editor to write this up, I hope the big wall of text is broken down enough to make it readable.

PowerShell remoting is an absolute must with the direction Microsoft are taking their products in, not learning how to utilise it can see you spending countless man hours doing a manual task when there is no need.

My next post I will go through some examples of how you can use PowerShell Remoting for practical day to day tasks.

I would be interested to hear your thoughts, comments or PowerShell questions you have; I hope you found this useful, thanks for reading.