Enable Powershell Remoting via Group Policy

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
  • 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 (where do you work?!) 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

    1. Open the “Allow Remote Server management through WinRM” policy setting (Server 2008 R2 and later).
    2. Open the “Allow automatic configuration of listeners” policy setting (Server 2008 and earlier).
  2. Set the Policy to Enabled.
  3. 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:
If Windows XP and 2003 are not a concern:

You can use the new 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!


  1. Firstly, great article. Thanks for this. I am having having an issue on a few XP machines. I have tried running the script locally and receiving an an error (The system cannot find the file specified) from line “Enable-PSRemoting”. I imagine this is besuase it did not install. I have tried to remove these lines but still receive the following error (0x80240024) at DLer.Download(). Any ideas why this is failing. Thanks.

    • Hi chalk! I assume you’re talking about the VBScript file. It sounds like you’re talking about the “Enable-PSRemoting” call that’s done on line 20, and that when you commented it out, you took out the whole block (lines 18 through 22).

      What’s happening is that on line 18, the “if” statement is checking to see if there is nothing to download. If that’s the case, the script tries to enable psremoting anyway (this is to enable psremoting in a case where you have already installed powershell but haven’t enabled psremoting yet), and then it quits the script.

      By commenting out the block, the script doesn’t exit when there is nothing to download and it tries to download nothing which throws the other error.

      So what this ultimately means is that the windows update which contains Powershell 2.0 ( KB968390: http://support.microsoft.com/kb/968930 ) is not available/showing up in the list of updates being received.

      Most likely, this means that you’re pointing Windows Update at WSUS, and this update is not approved; once it’s approved it should be smooth sailing.

      I made a lot of assumptions here so please correct me if I’m wrong and I’ll see what else we can figure out.

      Thanks for commenting!

      • Wesley Hader says:

        Hi. Thanks for this article! Very detailed and informative!

        I am also getting an error on line 20 of the vbs script. I have checked the registry and the keys do not exist. Furthermore, this is a brand new XP vm and I know its getting Windows Updates from Microsoft. Yet Powershell does not install. Please let me know if you have resolved this with the other commenters. Thanks!

        • Hi Wesley, actually with help from Jacob (below) I have figured out the problem and I have a fix, I just haven’t had a free moment to publish it. The gist of the problem is that the .NET framework is required, and the VBScript code is not checking for/installing it. If you manually install .NET it will work, but I’ll put up the fixed script soon.

  2. Hi, Just wondering why you are setting the service to automatic and then also define a preference for the same service?

    • Hi curns! The main reasons for setting a Preference item for the service are to start the service if it’s stopped, and to set the recovery actions. You’re correct in that setting the startup type to Automatic in both places is redundant. I’ll update the post. Thanks!

  3. Brian –

    I am testing this script for my company, which has an unbelievable number of Server 2003 machines still. I have a brand new testing server that is getting Windows Updates through the Windows Update website, not through WSUS or any other third party tools. After a reboot of the server I get the error message below.
    Script: \\corp.domain.com\sysvol\corp.domain.com\Policies\{Random Numbers}\Machine\Scripts\Startup\InstallWindowsManagementFramework.vbs
    Line: 20
    Char: 2
    Error: They system cannot find the file specified
    Code: 80070002
    Source: (null)

    What am I doing wrong?

    • Hi Jacob, it looks like you’re having a similar problem as the other commentor above. Can you confirm for sure that Windows Update (the wuauserv service) is not pointed at WSUS? The best way to check is probably to look in RegEdit at the following key:


      Look for vales called WUServer and WUStatsServer. If those are set, then that’s the WSUS server, if not then you’re probably looking directly at Microsoft.

      If you’re definitely not using WSUS, then please let me know as I’d like to learn more about the circumstances under which this problem occurs. Thanks!

      • In HKLM\Software\Policies\Microsoft\Windows there is no WindowsUpdate key. I also searched the registry fro WUServer and WUStatsServer and it returned nothing found.

        Server is 2003R2 Enterprise x64 SP2

      • Doing some more digging, I found the WindowsUpdate key, not sure how I missed it the first time. Those keys aren’t there, but there are keys for SusClientID and SusClientIDValidation that do have values. Does that help?

        • Hi Jacob, sorry for replying so late! I didn’t get notified about your additional replies. If WUServer and WUStatsServer don’t exist then you are correct and you are getting your updates from Microsoft Update. I’d like to e-mail you and learn more about this circumstance and what is going on here. I’ll use the addresses you submitted with your comments, if that’s ok. Hopefully we’ll get to the bottom of this!

  4. Hi Brian, thank you very much for this complete article !

    I’m just wondering, the other Settings of the WinRM Service aren’t we supposed to enable them ?

    • Hi Ahmad, the WinRM settings I’ve laid out here are the basics. After this configuration you should be able to enter a PSSession on a configured host or run commands remotely.

      There are other settings you can configure for other scenarios, but they aren’t required to get this basic functionality and I don’t cover them here.

      I have been putting thought into securely setting up WinRM and Powershell Remoting on DMZ hosts to aid in management, and if I ever get around to that I’ll be sure to post about it!

      What other WinRM settings and scenarios are you interested in?

      • Thank you for replying on such short notice !
        I wanted to know more about the encrypted connexion between pssessions and the pssessions acrossing domains or from a non-domain computer.

        I find some informations here : http://blogs.technet.com/b/jonjor/archive/2009/01/09/winrm-windows-remote-management-troubleshooting.aspx

        • Whoops, looks like I missed this comment. I need to figure out why I get notified about initial comments but not additional replies from the same person! Sorry about that.

          As your link states “While WinRM listens on port 80 by default, it doesn’t mean traffic is unencrypted.” So you do not have to configure SSL to get encryption with WinRM, it’s just a choice about which type you want to use.

          As far as using PSSessions between computers that are not in the same/trusted domain, I’m currently researching this in my environments. I know it’s certainly possible to do it, what I’m trying to figure out is the way that works best (for me anyway), some balance of trust and security that will let me manage DMZ machines easily but isn’t a gaping security hole. It’s something I’d like to write about when I get a better handle on it, but for now I don’t have a complete picture of how I want to or should structure it.

          I welcome comments from anyone who has such a configuration in their environment to comment here and let me know how you’re doing things.

  5. Thomas Vanderbilt says:

    Just a quick question. Does this work for both 32 and 64-bit machines? Wasn’t sure if the WMI filter itself was also for 64-bit machines. Thanks.

    • Hi Thomas,

      First, sorry about the late reply. This does work for any bit-ism. The WMI filter also works for both. Win32 is the name of the Windows subsystem, and it shows up in all sorts of places even on 64 bit Windows. I think it will be a long time before the naming is changed everywhere.

      So yeah, no worries about 64 bit systems.

  6. This is not working for me. The policy is getting applied to servers but I can’t carry out any remote sessions.

    winrm /e /winrm/cinfig/listener returns this

    Listener [Source=”GPO”]
    Address = *
    Transport = HTTP
    Port = 5985
    Enabled = true
    URLPrefix = wsman
    ListeningOn = null

    Notice ‘ListeningOn = null. On machines that I have manually configured using wirm qc there are IPv4 and IPv6 addresses.

  7. Ignore that last comment. Replication was taking it’s time :-)

  8. Hello, thanks for the write up. I was configuring this on Server 2012 and I ran into a little difference that may help others, when setting the GPO up for WinRM, the “Open the “Allow automatic configuration of listeners” policy setting.” has been renamed “Allow Remote Server management through WinRM”. Maybe add a little update note. 😉 Happy Computing!

  9. Hi and thanks for this really useful writeup. I am trying to deploy this script in a test environment with windows xp machines but so far I am having no success.

    At boot time it takes about 10 minutes of “running startup scripts” and then I can login to the machines. And it doesn’t look like the script did what it supposed to do. So my question is – how could I debug the vbs script execution (i.e. how could I verify the script is working as intended?). I tried running it directly on the target machines but I have no feedback whatsoever.

    Thanks in advance,

    • Iancul,

      From your comment I can’t think of anything offhand. I will email you at the address left in your comment and see if we can figure out what’s going on.

  10. We’ve set up domain policy to enable all listeners and applied this to specific machines as part of a WinRM pilot. The firewall in the domain is turned off for all networks (public, domain, etc.). The WinRM service is running. I get a good response from these machines using the test-wsman cmdlet, but when I try to create a new-pssession, I’m getting error: “The
    WS-Management service cannot process the request. Cannot find the Microsoft.PowerShell session configuration in the WSMan: drive on the XXX computer”.


    Thank you

  11. kemal miller says:

    Thank you for the code. I am almost done: still need to modify xp machines. My windows xp machine is erroring on the script: Line 4, char 1, which is: Set searchResult = updateSearcher.Search(“IsInstalled=0 and Type=’Software'”). I’ve searched the web but cannot find an answer. It is a XP SP2 without .net.

  12. Nice job, the small detail on the firewall rule made the difference for my environment. I appreciate you taking the time to share this information.


  1. […] Computers References: Technet Article Installation and Configuration for Windows Remote Management Enable Powershell Remoting Via Group Policy Event Log Subscriptions use the Windows Remote Management (WinRM) service to send messages between […]

  2. […] You haven’t enabled Powershell Remoting yet? C’mon! Check out this blog post. […]

Speak Your Mind