-
Notifications
You must be signed in to change notification settings - Fork 53
Validate PS7 Import-Module -UseWindowsPowerShell
in Azure Functions cloud environment
#444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@rjmholt has something for this I believe... Or at least has expertise. Also cc @SteveL-MSFT @joeyaiello |
@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? |
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. |
@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. |
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 |
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 |
The main goal of this issue is to validate This would be an important scenario for our customers in order to use modules that are not PSCore compliant. |
@joeyaiello @rjmholt I want to emphasize this:
The goal is not to create and validate a comprehensive compatibility list. The goal is to validate that the @Francisco-Gamino Perhaps we could edit the title and the description to clarify that this is about validating the PS7 feature. |
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 |
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. |
The issue description was updated. (yay, I still got the permission 😄) |
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. |
This is fine. |
@anmenaga I see, so they are going to be in a 7.0.* release? This is good to know, thank you! |
Import-Module -UseWindowsPowerShell
in Azure Functions cloud environment
Thank you all for your input. I will reach out if I have any questions once I start working on this. |
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)). |
Thanks @AnatoliB for validating this! |
Uh oh!
There was an error while loading. Please reload this page.
Need to validate PowerShell 7 module compatibility feature (
Import-Module -UseWindowsPowerShell
) in Azure FunctionsThe text was updated successfully, but these errors were encountered: