On my local machine, you can see that my listener is listening on any address it can find on my IP stack.

I’d like to set this to only listen only on a single IP V4 Address. When I first tried to change this I started looking at the value for Address under my listener but kept running into an error that reads Set-Item : Item has already been added. Key in dictionary: ‘Address’  Key being added: ‘Address’

Poking around the WSMAN provider, (which is fantastic by the way!) I found something else that looked promising. In WSMAN:\localhost\Service there are items called IPV4Filter and IPV6Filter.

Sweet!  Let’s try to set it to my local IP Address… and fail with this error

Set-Item : The WinRM client cannot process the request. The IP Filter is invalid. Ranges are specified using the syntax IP1-IP2. Multiple ranges are separated using , as delimiter. * is used to indicate that the service should listen on all available IPs on the machine. When * is used, other ranges in the filter are ignored. If filter is blank,
the service doesn’t listen on any address. For example, if service should be restricted to listen on only IPv4 addresses, IPv6 filter should be left empty.

But this is great news. The error message is actually helpful – Christmas miracle maybe?

If you want to listen on a single IP Address, you can specify a range that starts and ends at the same IP. For example,

So why would you have to enter all these crazy ranges.? Well it turns out you can specify these in a GPO. Say you have a Hyper-V Cluster that has a client access network (10.10.10.0/24), an iSCSI network (10.11.11.0/24), and a few others for things like heartbeat and live migration.  If you only wanted to have a listener on the client access network for all of your cluster nodes, you could specify the IPv4Filter to be 10.10.10.1- 10.10.10.254 and the policy would apply to all our servers and they would not be listening on the 10.11.11.0/24 iSCSI network.

To configure GPO settings, you can go to Computer Configuration\Administrative Templates\Windows Components\WinRM Service and in there you will find a setting called “Allow automatic configuration of listeners”

The default value is 150, which seems well and good for most commands. However, this is the second time I have run into it with different commands so I think it is worth noting. After upping the config to 512, all was right with the world again.

set-item wsman:localhost\Shell\MaxMemoryPerShellMB 512

I have to say i love the new WSMAN: provider. It makes something that was incredibly difficult to manipulate a snap.

Hope that helps,

Andy

start /w ocsetup MicrosoftWindowsPowerShell

Note that ocsetup is case sensitive and you need to get the name of the feature and/or role exactly right.

Once you get the feature installed, you can launch powershell from the cmd prompt by using the full path to c:\windows\system32\windowspowershell\v1.0\powershell.exe.

Now that we have PowerShell V2 running, we can get-started with Remoting. To enable V2 remoting, there is a built-function called Enable-PSRemoting which typically is all you need. However, there is a known issue with Windows 7 Beta x64 systems where WOW components are not installed – a category which server core falls into.

If you try to enable remoting, you will get an error about a corrupted plugin in WSMAN.

To work around this, you need to remote a registry value. Run the following command

remove-item HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\Microsoft.PowerShell32

After that, you can run Enable-PSRemoting and you are good to go.