Last month when I got back from holidays, helpdesk staff members complained that they could not reset user passwords anymore using the PowerShell constrained endpoint I setup almost a year ago.
They got a message saying Running the Get-Command command in a remote session reported the following error: A parameter cannot be found that matches parameter name ‘PowerShellVersion’
You know, there’s no tab completion in an interactive constrained endpoint. Your only friend is Get-Command.
So, to ease their pain with constrained endpoints, I usually create another script that imports the remote constrained commands using the Import-PSSession cmdlet.
What happened or changed during my summer holidays?
Before leaving, I started to deploy WMF 5.1 to computers mainly because:
As of June 1, 2017, users with WMF 5.0 must upgrade to WMF 5.1 to receive support.
Helpdesk members experienced this behavior after they rebooted their computers (WMF 5.1 installation wasn’t pending anymore). Entering interactively the constrained endpoint just works. It was only the import of the session that failed.
When I googled the error, there was already a github issue opened and a merge into the PowerShell Core branch. Nice, isn’t it? 😀
It appears that the server hosting the constrained endpoint was already running PowerShell 5.1 and connecting helpdesk workstations just shifted to this version and fall into this Import-PSSession issue.
Windows PowerShell 5.1, much like .NET Framework 4.x, will continue to be a built-in, supported component of Windows 10 and Windows Server 2016. However, it will likely not receive major feature updates or lower-priority bug fixes. With PowerShell Core, we are actively addressing bugs that may have existed in previous versions of Windows PowerShell.
The issue was fixed in a few days in PowerShell 6.0 (see https://github.com/PowerShell/PowerShell/pull/4222) and won’t be fixed in PowerShell 5.1 at the same speed unfortunately. Likely means “not” most of the time in this context unless it’s security related or really, really bad. The only issue fixed in PowerShell 5.0 as far as I know is cve-2017-8565.
Here’s the dilemma. Should I remove the only supported version of PowerShell from the server or from the clients?
Well, I chose the server because there are still some products that are incompatible with WMF 5.1 and 5.0.
I was lazy and didn’t even have to remove any PowerShell from any server.
I just found a Windows 2012 R2 running a default version of PowerShell, which is version 4.0.
I moved my module to the server and registered the constrained endpoint.
Now, I got another problem. I couldn’t get an alert telling me who did a password reset.
In PowerShell 5.1, I successfully used
To be able to get back the visibility on who did what, I had to use the following in PowerShell 4.0
I wonder why. Isn’t a restricted endpoint running in NoLanguage mode the same in PowerShell 4.0 and 5.x?
What’s the difference between the two syntaxes if $PSSenderInfo is just a read-only variable?
Using Get-Member, it looks the same, except that one is property and ConnectedUser appears to be a script property.
May I conclude and say that script properties on read-only variables are allowed in a restricted remote sessions running PowerShell 5.x in no lanugage mode?