Tags

,


I saw an odd error message today whilst testing PSRemoting on a couple of PCs, a process which involved my disabling and re-enabling it.  It brought up an interesting problem I thought worth sharing.

I have a Group Policy Object with a Computer Startup script that looks for missing PowerShell Remoting Endpoints (i.e. PSSession Configurations such as “Microsoft.PowerShell”) and re-runs Enable-PSRemoting if required to fix them.  If you look at my earlier post, you’ll see why I ended up with such a config.  I thought this would ensure remoting would always work for PCs in this particular Organisational Unit.

Here’s the error I got trying to remote to one PC that had had Remoting expressly disabled but had then been put back in the OU that should have re-enabled it again but clearly hadn’t done so successfully:

1-EnterPsSession

Testing WSMan connectivity showed that side of things was working:

2-TestWSMan

Both expected Session Configurations were also present but I decided to investigate them closer with the following command.

Get-PSSessionConfiguration | Format-List -Property *

Going down each property in turn on the two PCs I spotted a difference in the rather unfriendly SecurityDescriptorSddl property.  Fortunately this is interpreted into something more meaningful in the Permission property which of course was the last one of over 30 in the list!  Picking that one out, here’s how it looked on a working PC:

3-Permissions-Working

And here’s how it looked on the faulty PC:

4-Permissions-Failing

This Denied Network access entry could also be seen using the GUI equivalent:

5-Permissions-UI

I thought it odd that there was a Deny entry in there but I fixed it with an Enable-PSRemoting again (which would actually would have been the first fix I’d have tried, except I wanted to try and work out exactly why it was broken).

The explanation of course is that I hadn’t looked into the details of exactly what Disable-PSRemoting might do.  From the documentation comes the phrase:

Disable-PSRemoting blocks remote access to all session configurations on the local computer. This prevents remote users from creating temporary or persistent sessions to the local computer. Disable-PSRemoting does not prevent users of the local computer from creating sessions (“PSSessions”) on the local computer or remote computers.

If you look at the Examples in that cmdlet’s help, you will see how the Network Deny we’ve seen gets put in.  It’s more of a Deny-PSRemoting than a Disable-PSRemoting!

Looks as though I need to alter my Startup script to make a check for these denies as well as just a check to see if the endpoints exist, as a Disable-PSRemoting makes them still exist, just no longer work remotely…!

Advertisements