Enable Powershell Remoting via Group Policy

Comments

Powershell really is a game changer when it comes management and scripting on Windows, but one of the areas where it really shines is in its remoting capability. Powershell remoting lets you connect to a remote system and run commands locally, then returns the results to the calling machine. This can be done as an automated block or as an interactive session.

Remoting requires Powershell 2.0 which comes built-in on Windows 7 and Windows 2008 R2, but it needs to be installed on Windows Vista / Server 2008 and below. The WinRM service will also have to be configured and enabled.

I’ll show you how to accomplish this with group policy for the range of operating systems that can run it.

Update 2013/02/20: I have confirmed that this method is working on Server 2012 (core and GUI) as well.

Update 2013/05/07: With the help of Jacob in the comments below, I was able to fix a problem in the VB Script. Since Powershell requires the .NET framework, this whole process will fail on Windows 2003 / XP if .NET is not installed. The VB Script now installs .NET as part of the process. The GitHub Gist has been updated. Thanks Jacob!

Update 2013/10/09: Updated the name of the WinRM policy setting based on user comments. Thanks to Micahel M. of Miller Computers and Giorgi Gordeziani.

The Policy Split

We basically have three operating system “classes” to deal with here:

  • Windows 7 / Windows 2008 R2 (and newer)

  • Windows Vista / Windows 2008

  • Windows XP / Windows 2003

The requirements for each are as follows:

Windows 7 / 2008 R2+

  • Needs WinRM enabled / configured.

  • Needs firewall rules.

  • Needs service configuration.

Windows Vista / 2008

  • Needs everything above.

  • Needs Powershell 2.0 installed.

Windows XP / 2003

  • Needs everything above.

  • Needs .NET framework.

  • Cannot directly configure WinRM with Group Policy.

What does that last bolded bullet mean? There are already administrative templates for enabling and managing WinRM, but they only work on Vista clients and later, so our XP and 2003 machines are out of luck there. Vista and 2008 are covered by that, but they don’t have Powershell 2.0 installed by default. Windows XP and 2003 don’t have .NET framework by default either.

In my environments I’ve chosen to do this with two policies. The first policy uses the administrative templates to enable WinRM, and it sets a few additional policies for Windows firewall rules and WinRM service parameters which will apply to all of the OS classes. The second policy is filtered with WMI to only apply to Vista / 2008 machines and lower, and it consists solely of a startup script which installs Powershell 2.0 and .NET framework (as needed) and enables WinRM.

The Enable Powershell Remoting Policy

This is the first policy described above. If you are lucky enough to have no machines in your environment below Windows 7 / 2008 R2 then this is the only one you need. All of the settings we are using will be in Computer Configuration so if you want to disable User Configuration as I have go ahead.

  1. Create your GPO, name it what you want, place it where you want, etc.
  2. Edit your policy.

Enabling WinRM

  1. Browse to Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service
  2. Depending on your operating system:
    Server 2008 R2 and later: Open the Allow Remote Server management through WinRM policy setting.
    Server 2008 and earlier: Open the Allow automatic configuration of listeners policy setting.
  3. Set the Policy to Enabled.
  4. Set the IPv4 and IPv6 filters to * unless you need something specific there (check out the help on the right).

Setting the Firewall Rules

  1. Browse to Policies > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile
  2. Open the Windows Firewall: Define inbound port exceptions policy setting.
  3. Set it to Enabled if it isn’t already.

  4. Click the Show… button and add the port exception. We’re going to be opening TCP port 5985, so the exception string will look something like this:

    5985:TCP:*:enabled:WSMan

If Windows XP and 2003 are not a concern:

You can use the newer Firewall with Advanced Features policy to configure the rule instead, but this will only work on Vista and above. Additionally, you should configure this from a Windows 7 / 2008 R2 machine because of a difference in the pre-defined rule.

  1. Browse to Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall… > Inbound Rules
  2. Right click and choose New Rule…
  3. Choose the Windows Remote Management pre-defined rule.
  4. When you click next you should see the two rules that will be added.
  5. Click next, choose to Allow the connection, and then Finish.

Service Configuration

At this point we have enough in place to get this working, but I like to do a few more things to ensure that the WinRM service is configured to start automatically and to restart on failure.

  1. Browse to Policies > Windows Settings > Security Settings > System Services
  2. Find the Windows Remote Management (WS-Management) service.
  3. Define the policy and give it a startup mode of Automatic.
  4. Browse to Preferences > Control Panel Settings > Services
  5. Create a new Service preference item with the following parameters:
    1. General Tab
      1. Startup: No Change (the policy we set above will take precedence over this anyway)
      2. Service name: WinRM
      3. Service action (optional): Start service
    2. Recovery Tab
      1. First, Second, and Subsequent Failures: Restart the Service

The Install Powershell 2.0 and WinRM Policy

Now we’ll create the second policy that I described. This one will install the Windows Management Framework Core package and .NET framework via a startup script. This policy will use a WMI filter so that we aren’t trying to do these steps on Windows 7 / 2008 R2 where it’s unnecessary.

Since these are distributed as a Windows updates and not as an MSI, we can’t use software distribution to install them. That also means that if you’re using WSUS you’ll have to make sure that these updates are approved:

  • KB968930
  • KB951847

Create The WMI Filter

First, let’s create the WMI filter that we’re going to use so that this policy will only apply to Windows Vista / 2008 and below.

  1. In the Group Policy Management console, scroll down to WMI Filters.
  2. Create a new WMI Filter, and give it a name and description.
  3. In the Queries box, click the Add button.
  4. Keep the namespace as root\CIMv2 and then click into the Query box.
  5. The following WQL query will match Windows Vista, Windows 2008, and lower operating systems:
SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.0%" OR Version LIKE "5.%"

Create the GPO

  1. Create the GPO and link it to the same places as the first one.
  2. Make sure that the WMI filter we created above is applied to the GPO.

Set up the Startup Script

  1. Browse to Policies > Windows Settings > Scripts
  2. Open the Startup item, and make sure you’re on the Scripts tab (not PowerShell scripts).
  3. Click the Show Files… button below. This location is where you must put the script. You can download the script from this GitHub Gist.
  4. Once the file is in place, click the Add…* button in the Startup Properties window.
  5. Type or paste the name of the VBScript file (just the name, not the full path).
  6. Leave Script Parameters blank.

Wrapping Up

With this in place, you’re ready to go! As with any group policy changes, test, test, and test again. I usually remove Authenticated Users from the Security Filtering and add in individual computers to test out policies on several machines before I let them loose on the domain (virtual machines with snapshots are great for this).

Windows XP / 2003 machines probably need to be rebooted, maybe twice, for it all to work (especially if the script installs .NET). If you’ve got any other remote administration in place and working (psexec, WMI, third-party tools) you could use that to kickstart the execution of the VBScript that installs the management framework.

Don’t forget about domain controllers! They’re usually in a different OU than the other computers in your domain, so don’t forget to link the policies to all of the appropriate containers.

Happy remoting!