Tags

,


I want to enable PowerShell Remoting in our domain using Group Policy but before I try and sell management on it, I need to test it will work.  Most of the PCs have PowerShell 3 on as we were blocked from installing .NET v4.5 until recently.

Here’s a screenshot of the Group Policy Object I made.  I’ve got the Remote Registry service in there too since you need it for things like Get-Process.

PowerShell Remoting GPO

Needless to say, all did not go according to plan.  On trying to connect to the test machine remotely, I got the following error:

Remoting Error

At least the error message was descriptive.  A quick look at the Session Configurations confirmed the issue was a missing remoting endpoint.  There should be one called Microsoft.PowerShell:

Only One Endpoint

Hunting around online about this issue showed I was not alone.  A now defunct-thread on what was powershell.com was of particular interest and had various solutions to fix it.  The version of the thread visible on Idera’s site now is incomplete but I’ve found it exists in full still here.

After some experimentation, I came up with a script that could be used as a Computer Startup Script in the above GPO to check for and add any missing endpoints.  It handles both normal endpoints plus the x64 one.  [See the Update at the bottom of this post regarding the SDDL.]

# Add missing PSSessionConfigurations (Remoting Endpoints)

Start-Service -Name WinRM

$changed = $false

if ((Get-PSSessionConfiguration -Name 'Microsoft.PowerShell' -ErrorAction SilentlyContinue) -eq $null) {
    Register-PSSessionConfiguration -Name 'Microsoft.PowerShell' -Force -NoServiceRestart -SecurityDescriptorSddl 'O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)' -WarningAction SilentlyContinue | Out-Null
    $changed = $true
}

if ((@(Get-WmiObject -Class Win32_Processor -Property AddressWidth)[0].AddressWidth) -eq 64) {
    if ((Get-PSSessionConfiguration -Name 'Microsoft.PowerShell32' -ErrorAction SilentlyContinue) -eq $null) {
        Register-PSSessionConfiguration -Name 'Microsoft.PowerShell32' -ProcessorArchitecture x86 -Force -NoServiceRestart -SecurityDescriptorSddl 'O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)' -WarningAction SilentlyContinue | Out-Null
        $changed = $true
    }
}

if ($PSVersionTable.PSVersion.Major -ge 3) {
    if ((Get-PSSessionConfiguration -Name 'Microsoft.PowerShell.Workflow' -ErrorAction SilentlyContinue) -eq $null) {
        Register-PSSessionConfiguration -Name 'Microsoft.PowerShell.Workflow' -Force -NoServiceRestart -SecurityDescriptorSddl 'O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)' -WarningAction SilentlyContinue | Out-Null
        $changed = $true
    }
}

if ($changed) {
    Restart-Service -Name WinRM
}

The first time I tried a variant of the above, I never got past “Please Wait” during boot.  I noticed that when run manually, the Register-PSSessionConfiguration command was returning both an object and some output into the Warning stream.  I’ve not checked which of these was responsible.  Instead, I’ve piped the returned object to Null (which feels more PowerShelly than a cast to [void] even if it is a bit slower) and silenced the Warning stream.  Adding some logging of timings shows that the above script was running in 3-4 seconds.

I’d be interested in any thoughts on the above – especially as regards the security descriptor.  I notice that my Windows 10 machine has access on its endpoints for a new security group called “BUILTIN\Remote Management Users” and for “NT AUTHORITY\INTERACTIVE” too.

Something else I noticed when originally troubleshooting, was the following odd behaviour.  I’ll let the screenshots do the talking; I’m not sure what’s going on with those version numbers…

WSManTest1

WSManTest2

Update1
More on the SDDL:  I see that if you omit the SDDL string, then “the root SDDL for the WinRM service is used for this configuration”.  Well on my PC that equates to access for “BUILTIN\Administrators” and “NT AUTHORITY\INTERACTIVE”.
I got at that with this command:

Get-ChildItem "WSMan:\localhost\Service\RootSDDL" | Select-Object -ExpandProperty Value

I translated the SDDL script with this script.

If I delete all my Session Configurations and re-run Enable-PSRemoting, then the endpoints are created with an SDDL with access for “BUILTIN\Administrators” and “BUILTIN\Remote Management Users”.  They’re also created like that if I use Register-PSSessionConfiguration with no SDDL specified, so perhaps it’s better to omit the SDDL parameter altogether in the above script.

Update2
I’m a little unhappy with manually registering endpoints with static commands in case things change in future versions.  I thought perhaps it might be better instead to use an Enable-PSRemoting -Force
If I manually unregister my endpoints and try that, I always get an error and only one endpoint appears.  If I run it a second time, all is then OK.

ReRegisterEndpointsError

Maddening…  I wonder how you view the source of the script that’s apparently running behind the scenes?

Update 3

I’ve found that the above error goes away if I disable StrictMode (which I have enabled in my own PowerShell profile).  Also, with WMF 5, the endpoints are still not registered without running a script to do so!

Update 4

Please also see the newer article here.

Advertisements