Packer: Support PowerShell Core (6.x) as a provisioner

[bengaywins]

This is a feature request. This would reduce some headaches that have to be dealt with when using Windows PowerShell.

https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/wsman-remoting-in-powershell-core?view=powershell-6

[jborean93]

Just an FYI the powershell provisioner is run over WSMan/WinRM and not through PowerShell Remoting (PSRP). The docs you linked to is how to set up the PSRP endpoint/configuration for PowerShell Core whereas Packer would need to change the executable it uses but still continue to run over WinRM.

[bengaywins]

@jborean93 Not sure if you missed this?

This is an explicit opt-in scenario where the user runs Install-PowerShellRemoting.ps1 to create the WinRM endpoint. The installation script is a short-term solution until we add additional functionality to Enable-PSRemoting to perform the same action. For more details, please see issue #1193.

Specifically calls out that it is over WSMan/WinRM.

[jborean93]

@bengaywins that page you linked to talks about PowerShell Core over WSMan yes but it is talking about how to set up an endpoint for PSCore for PowerShell Remoting (PSRP). PSRP is a protocol that historically sat on top of the WSMan stack but since PS v5 and PSCore this has been expanded to include more transport options like;

• SSH
• Named Pipes
• Hyper-V
• Docker containers

It works by serialising the PS Objects in XML, similar to CLIXML, and passing that over whatever transport is used. These objects are complex and not just simple string commands, you can see a basic example of just one of the many objects in PSRP at https://msdn.microsoft.com/en-us/library/dd340567.aspx.

What the Install-PowerShellRemoting.ps1 script does is to register an endpoint, this case powershell.6.0.0, with the WSMan server stack so when a host connects with a specific resource URI the server will direct it to PSCore's pwrshplugin.dll. This dll is called by the WSMan stack when a WSMan message is sent to the resource powershell.6.0.0 and is responsible for reading the raw input from the payload and processing it accordingly. This all happens under the covers when you run something like Invoke-Command -ComputerName server -ConfigurationName powershell.6.0.0 -ScriptBlock { $PSVersionTable.PSVersion }. This will send numerous XML objects, like CREATE_PIPELINE to execute this scriptblock using the PSCore engine and return the objects back in a PowerShell fashion.

This is not what Packer does to execute commands over WSMan, in reality it uses something called Windows Remote Shell (WinRS). WinRS also uses WSMan as the transport option but it designed around a more traditional stdio concept with text streams for stdin, stdout, and stderr. Instead of dealing with PowerShell objects it is a more traditional stdio based stream execution process. To do the same thing as the Invoke-Command example but over WinRS you can run winrs -r:http://server:5985/wsman pwsh.exe $PSVersionTable.PSVersion. You can see that I needed to specify the executable to run with as WinRS is not run within a PowerShell instance. This is the same in Packer and means that to support PSCore in the PowerShell provisioner it would need to change the executable it calls from powershell.exe to pwsh.exe.

I hope that clears up some of the confusion.

[bengaywins]

Ah that makes sense. Thanks for the clarification. I tried to follow the source to understand what that library did, but was unable to find it in my cursory attempt.

[nywilken]

Hey folks, I'm not clear from where the conversation ended: is there still interest in keeping this request open?

In reading through the comments, (@jborean93 thanks for the detailed explanation) it doesn't appear that this is something that we could add into Packer, at least with how things currently work, but wanted to reach out for clarification in case there has been any changes since this issue was opened. If the state of things are still the same feel free to close the issue. Thanks!

[bengaywins]

I would think that whether this should stay open would depend on the direction one expects. Considering this blog post[1] from Microsoft, that they are going to replace Windows Powershell, I think it should effectively stay open or some kind of research gets done to ensure the methods and mechanisms stay current. In the future at some point, it seems that Windows Powershell as we know it today will die.

In this [2] blog post, it makes it clear that PS7 and beyond _is_ the future.

1. https://devblogs.microsoft.com/powershell/the-next-release-of-powershell-powershell-7/
2. https://devblogs.microsoft.com/powershell/announcing-powershell-7-0/

[nywilken]

Hi @bengaywins thanks for the response and provided links. The direction is to ensure that the Powershell provisioner can continue working as things change in future releases so I agree that this issue should remain open. I don't have a timeline yet on when we will start this work but for now we will make sure to keep an eye on upcoming changes to start thinking about next steps. Thanks again!