Configure PowerShell Remoting using Group Policy in 2003 Domains

Posted: 13/10/2010 in Active Directory, PowerShell
Tags:

The objective of this post is to provide instruction on enabling PowerShell 2.0 remoting capabilities in non 2008 R2 domains. In this example I will demonstrate in a 2003 domain environment.

Prerequisites

To complete this work instruction you will need the following:

1.     PowerShell version 2.0 will need to be installed on all systems that will be used for remoting. On down level clients PowerShell 2.0 is bundled into the Windows Management Framework.

The Windows Management Framework makes some updated management functionality of Windows 7 and Windows Server 2008 R2 available on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

Windows Management Framework contains the following three components:

  • Windows Remote Management (WinRM) 2.0
  • Windows PowerShell 2.0
  • Background Intelligent Transfer Service (BITS) 4.0.

I recommend that WSUS is used as the deployment method for the Windows Management Framework on down level clients and it will be assumed from this point that this is already installed as this was released some time ago.

2.     The ‘Windowsremotemanagement.adm’ file will need to be imported into the GPO later in the process. This will need to be downloaded as part of the ‘WS-Management v1.1 Package’ at the following link http://support.microsoft.com/kb/936059 . Once downloaded install onto the system you will be using to create and edit GPO’s.

Create the Group Policy Object (GPO)

Launch the Group Policy Management (GPMC) and create a new GPO titled ‘Windows Remote Management’.

Edit the newly created GPO and add both the ‘Windowsremoteshell.adm’ and ‘Windowsremotemanagement.adm’ Templates, if either of the adm files cannot be found please ensure that the ‘WS-Management Package’ is downloaded and installed as advised in the prerequisites.

Now Expand trough the Computer Configuration policy structure to ‘Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service’ and select ‘Allow automatic configuration of listeners’

This policy setting allows you to manage whether the Windows Remote Management (WinRM) service automatically starts and listens on the network for requests on HTTP over port 5985 and if enabled HTTPS on 5986.

Note: The above ports are correct as of WinRM 2.0. The previous version WinRM 1.1 used the default HTTP and HTTPS ports 80 and 443 respectively, the documentation on TechNet and also on the help section for this GPO have not been updated to reflect this at the time of writing.

Enable the GPO and complete the IPv* filters text boxes, an example of a relaxed configuration can be seen in Figure 1

Figure 1

The service listens on the addresses specified by the IPv4 and IPv6 filters. IPv4 filter specifies one or more ranges of IPv4 addresses and IPv6 filter specifies one or more ranges of IPv6addresses. If specified, the service enumerates the available IP addresses on the computer and uses only addresses that fall within one of the filter ranges.

You can use asterisk (*) to indicate that the service listens on all available IP addresses on the computer. When * is used, other ranges in the filter are ignored. If the filter is left blank, the service does not listen on any addresses.

For example, if you want the service to listen only on IPv4 addresses, leave the IPv6 filter empty.

Ranges are specified using the syntax IP1-IP2. Multiple ranges are separated using ‘,’ (comma) as the delimiter.

Example IPv4 filters:

2.0.0.1-2.0.0.20, 24.0.0.1-24.0.0.22

Example IPv6 filters:

3FFE:FFFF:7654:FEDA:1245:BA98:0000:0000-3FFE:FFFF:7654:FEDA:1245:BA98:3210:4562.

Confirm WinRM Listener

Assuming the GPO in now Enabled and Linked to an OU containing the computers targeted for remoting, log onto one of the client machines in the domain, run “gpupdate /force” or wait for the group policy to be deployed to the client machine.

To enumerate the currently applied GPO use the “gpresult” command and confirm that the GPO titled ‘Windows Remote Management’ is listed in the ‘Applied Group Policy Objects’ section.

To enumerate the WinRM listener(s) and confirm the GPO configuration successfully applied use the following command:

winrm e winrm/config/listener

A new GPO source listener should have been created automatically and the output should resemble Figure 2

Figure 2

Open up a PowerShell console on a system connected to the same domain and create an array of computers to which you have just enabled remoting e.g.

$Servers = 'SERVER01','SERVER02','SERVER03','SERVER04',’SERVER05’

Using the Invoke-Command cmdlet I will demonstrate running a simple script block to collect the last boot time:

icm -ComputerName $Servers -ScriptBlock { [System.Management.ManagementDateTimeConverter]::ToDateTime((gwmi Win32_OperatingSystem).LastBootUpTime) } | ft -a pscomputername,datetime

The output of the above command should resemble Figure 3

Figure 3

Over the last year I have been using PowerShell 2.0 remoting capabilities extensively and I will follow up with a few example over the coming weeks.

For those interested I recommend the following for further reading:

Microsoft help documentation on ‘about_Remote_Troubleshooting’

http://technet.microsoft.com/en-us/library/dd347642.aspx

Windows Management Framework Core package (Windows PowerShell 2.0 and WinRM 2.0)

http://support.microsoft.com/kb/968930/en-gb

Windows Remote Management feature for Windows Server 2003 and in Windows XP

http://support.microsoft.com/kb/936059

Thanks for reading,

jfrmilner

Comments
  1. […] Configure PowerShell Remoting using Group Policy in 2003 Domains […]

  2. Joakim says:

    Thanks, I was wondering about this. I’m curious about the fact that I can’t seem to find a way of limiting what _remote_ IPs are supposed to be able to connect – in an environment without firewalls in use. Did I miss something?

    • jfrmilner says:

      Joakim,

      This is mentioned in the post, please see the “configuration of listeners” section. If you are using Windows Advanced Firewall you could also use this to control IP access with the predefined “Windows Remote Management (HTTP-In)” rule. A fair amount of cmdlets use Windows Management Instrumentation (WMI) so you may want to investigate this as well.

      Regards,

      jfrmilner

      • Joakim says:

        I believe one of us have misunderstood something. As I interpret it, the filters you specify for the listener determines what IP addresses the local network adapters on the server have to listen on. It doesn’t really make sense to me, but it’s what they say:

        “The service listens on the addresses specified by the IPv4 and IPv6 filters. IPv4 filter specifies one or more ranges of IPv4 addresses and IPv6 filter specifies one or more ranges of IPv6 addresses. If specified, the service enumerates the available IP addresses on the computer and uses only addresses that fall within one of the filter ranges.”

        I interpret the part about “the service enumerates the available IP addresses on the computer and uses only addresses that fall within one of the filter ranges” as what I described above. That you can basically limit the listening to certain IP subnets that the server’s NICs might be on.

        I’m having trouble explaining it clearly, but it’s what the documentation says, basically. So if you specify “10.0.0.1/24”, the server will listen on the network adapter that has an IP within that range, it doesn’t limit remote connections to connections from within this range.

        I feel exceedingly dense, but if this is not what they mean, the docs are very unclear. At least to me. I think a firewall might be necessary, if I interpreted the text correctly.

        Thanks.

  3. […] Check out this procedure, from Jfrmilner’s Tech Blog, which covers Windows 2003 and Windows Xp. […]

Leave a comment