Winget Powershell Cmdlets don't work from SYSTEM context

[byjrack]

Brief description of your issue

Trying to orchestrate Intune machine scoped installs (need to suppress UAC) using winget. Had some success with the winget commandline by adding the WindowsApp install location to PATH, but it's not ideal for scripting. Wanted to give the cmdlets a go now that they are published to gallery and are stabilizing a bit.

I know running the cmdlets from SYSTEM was probably not high on the list, but I know some of the Intune collaboration might benefit until they can create a new scope type that handles the elevated token grant for the logged in user (my use case is biased to Company Portal).

Steps to reproduce

get a shell running under SYSTEM. I used psexec -i -s cmd, but you could simulate using a Intune app or something.

pwsh -mta //needs mta instead of the default sta launch for the COM support
Get-WinGetVersion

Expected behavior

From my user prompt

Get-WinGetVersion
v1.4.11071

If the cmdlets are going to cover SYSTEM a separate codepath to find the latest and add to PATH or set as working directory would be needed. Or I don't know if there is a method in MSIX to manually mount MSIXs to the context LOCALAPPDATA that would work for SYSTEM.

Actual behavior

Get-WinGetVersion: An error occurred trying to start process 'C:\windows\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\winget.exe' with working directory 'C:\windows\system32'. The system cannot find the file specified.

Assumes the MSIX is mounted from ProgramData\WindowsApps to the %LOCALAPPDATA% mount point, but for SYSTEM that isn't the case.

Environment

winget --info
Windows Package Manager v1.4.11071
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19044.3086
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.11071.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

User Settings: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json

[JohnMcPMS]

The SYSTEM support was done by simply replacing the COM object creation, which works great for everything that is implemented via COM...

Get-WinGetVersion and a few other commands are not implemented via COM and so they won't work in SYSTEM right now. This was partially oversight and partially "no one is asking for this yet".

For now, the winget client module version can be used as a proxy for the winget code version. It won't match at all, but it is related in that there is a fixed version mapping AND both module version and winget code version will monotonically increase together (AKA if module2Version > module1Version then code2Version > code1Version). When we release the modules fully I want the module version to be equal to the winget code version, which would always mean that in SYSTEM they would be the same value.

[byjrack]

Got it. Yeah I was having general issues with the other commands as well, but mixed in there was me forgetting that powershell pointed to 5 and pwsh pointed to 7. I chose version arbitrarily as my example, but let me test the others to see if they work as expected.

So install and get are supposed to work as SYSTEM?

[JohnMcPMS]

I don't think anything in here will work:
https://github.com/microsoft/winget-cli/blob/master/src/PowerShell/Microsoft.WinGet.Client/ModuleFiles/Microsoft.WinGet.Client.psm1

And then the version and user settings commands also won't work.

[JohnMcPMS]

I should have actually answered your question as well 😄

So install and get are supposed to work as SYSTEM?

Yes, the mainline package management commands should be working.

[byjrack]

And yeah did some regression testing this morning with correct "pwsh.exe -mta" use and all is well with getpackage, install, upgrade from a small sample in a SYSTEM context. The comexception is handy for catch logic and maps back to the header error list so just need to check that in addition to the installererrorcode. Filtering on source and scope would be helpful, but that's all upstream of the cmdlets in issues like #1155.

So just a bad initial test w version and making sure i was testing using the correct powershell config got me on the right track.