Validate PS7 Import-Module -UseWindowsPowerShell in Azure Functions cloud environment

[Francisco-Gamino]

Need to validate PowerShell 7 module compatibility feature (Import-Module -UseWindowsPowerShell) in Azure Functions

[TylerLeonhardt]

@rjmholt has something for this I believe... Or at least has expertise.

Also cc @SteveL-MSFT @joeyaiello

[rjmholt]

@Francisco-Gamino can you elaborate on what you need here? Do you need to evaluate what modules generally have different compatibility with PS 7 vs PS 6.2, or is this more specific to Windows modules or similar?

[rjmholt]

Also what level of validation do you need? PSCompatibilityCollector can build a list of modules for example, but based on successful import -- working on the PS AzF platform before I've needed to make particular tweaks in the past to make the output more accurate. But that's fairly easy to do. That module actually provides mechanisms to improve manipulating profiles in PowerShell before writing them out as JSON.

[AnatoliB]

@rjmholt The goal here is to validate that whatever is described on https://github.com/PowerShell/WindowsCompatibility actually works in Azure Functions on the cloud. At this point, we don't have any reason to believe that it does not work, but we still want to validate it because this environment is special.

[rjmholt]

Ah, I see. Well it's not quite what's described in that repo. The main difference is that rather than using PowerShell remoting, the built-in PS 7 windows compatibility feature communicates to a powershell.exe subprocess over stdio, making it more likely to work than the PSRP option

[joeyaiello]

Unfortunately, that's going to be an extremely difficult exercise to do with any kind of real confidence. The effort to build that compatibility knowledge was extremely ad-hoc, manual, and time consuming, and relies on a lot of internal Windows tests. And I understand it'll be additionally difficult to know what may or may not get broken by the sandbox's security boundary, as well as to take those tests and execute them anything except the Windows build/test systems (i.e. the Azure Functions environment).

I think a better approach might just be to point people at that compatibility table and to caveat that certain modules may not work, maybe with a pointer to where they should file an issue in case we need to investigate. Then we can mark known incompatible over time.

As a side note, I'd guess a bunch of them don't even really make sense from Azure Functions, as a significant amount are for managing roles and features on the local Windows Server node. E.g. if customers need, the NetAdapter module, they're actually remoting into their own servers and executing the NetAdapter module housed there, and that remoting call could also be agnostic to whether it's hitting a Windows PS or PS Core/7 instance.

[Francisco-Gamino]

The main goal of this issue is to validate Import-Module <ModuleName> -UseWindowsPowerShell in the Functions cloud environment.

This would be an important scenario for our customers in order to use modules that are not PSCore compliant.

[AnatoliB]

@joeyaiello @rjmholt I want to emphasize this:

The main goal of this issue is to validate Import-Module -UseWindowsPowerShell in the Functions cloud environment.

The goal is not to create and validate a comprehensive compatibility list. The goal is to validate that the -UseWindowPowerShell approach works on Azure Functions with PS7 in general. Because it starts powershell.exe and communicates with it, it may hit something unexpected on the Azure sandbox.

@Francisco-Gamino Perhaps we could edit the title and the description to clarify that this is about validating the PS7 feature.

[rjmholt]

Oh forgot to tag @anmenaga. He should be able to give you any more info you need as to whether this feature should work in general

[anmenaga]

FYI. General info. https://github.com/MicrosoftDocs/PowerShell-Docs/blob/staging/reference/7.0/Microsoft.PowerShell.Core/About/about_Windows_PowerShell_Compatibility.md

Simple test if WinCompat is working:

# example uses module ScheduledTasks, but any module can be used

PS C:\> Import-Module -Name ScheduledTasks -UseWindowsPowerShell
WARNING: Module ScheduledTasks is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell Core please use 'Import-Module -SkipEditionCheck' syntax.

PS C:\> Get-Module ScheduledTasks | select ModuleType,Path # type should be `Script`; path should be under %Temp%

ModuleType Path
---------- ----
    Script C:\Users\UserA\AppData\Local\Temp\remoteIpMoProxy_ScheduledTasks_1.0.0.0_localhost_b7c34a7f-dd06-44b2-b888-9e721bb90e7e\remoteIpMoProxy_ScheduledTasks_1.0.0.0_loca…

PS C:\> Get-PSSession -Name WinPSCompatSession # this should return session auto-created by WinCompat; should not be null.

 Id Name            Transport ComputerName    ComputerType    State 
 -- ----            --------- ------------    ------------    ----- 
  2 WinPSCompatSes… Process   localhost       RemoteMachine   Opened

PS. Please try to use the latest PS core build.

[daxian-dbw]

@Francisco-Gamino Perhaps we could edit the title and the description to clarify that this is about validating the PS7 feature.

The issue description was updated. (yay, I still got the permission 😄)
Also, the help doc @anmenaga referred to can be found here (also linked to in the PR description): https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_windows_powershell_compatibility?view=powershell-7

[AnatoliB]

PS. Please try to use the latest PS core build.

We actually need to validate it with PS 7.0. Our primary goal is to understand whether we can/should advertise this when PS7 support in Azure Functions is officially released, as it will be using PS 7.0 (LTS). We can try the latest build as well just in case, but PS 7.0 is the first priority in this context.

[anmenaga]

This is fine.
I said that because since 7.0 GA we made several fixes for some corner cases. They will be part of 7.0 servicing, however at this moment they are only sitting in master.

[AnatoliB]

I said that because since 7.0 GA we made several fixes for some corner cases. They will be part of 7.0 servicing, however at this moment they are only sitting in master.

@anmenaga I see, so they are going to be in a 7.0.* release? This is good to know, thank you!

[Francisco-Gamino]

Thank you all for your input. I will reach out if I have any questions once I start working on this.

[AnatoliB]

We've validated that -UseWindowsPowerShell switch does work in general: for example, it allows using the AzureAD module on Azure Functions with PowerShell 7 (#232 (comment)).

[Francisco-Gamino]

Thanks @AnatoliB for validating this!