Add support for SYSTEM account when using Winget PowerShell Module

[PckgrTom]

Description of the new feature / enhancement

Hello,

I have been following along with the development of the PS Module and I can now see that it's working for PS 7 and PS5.1 however it does not work when running PowerShell with the SYSTEM account:

This would be really good it it worked as Microsoft Intune relies heavily on using the SYSTEM account deploying applications and scripts. At the very least it would be great if the Get-WinGetPackage was working as I would use this in my detection scripts.

Proposed technical implementation details

I don't have the technical details, just to emulate how it's working now but for SYSTEM.

[asheroto]

Not sure if still valid, but see https://github.com/microsoft/winget-cli/discussions/962

[Trenly]

I think a big part of the question here is "How should the SYSTEM context work?"

For example - take the Get-WinGetPackage cmdlet. This effectively is the same as running winget list <query>. However, the list command only shows applications available in the current user context. For SYSTEM that would mean either applications installed machine-wide or only for the SYSTEM user. That then brings forward the questions around "Why isn’t WinGet detecting this app is installed?? I installed it using WinGet, but its not detecting it!" - In fact, I know there are already two or three open issues with this exact question - all because the applications were installed to a specific user context and not the machine context. On the flip side, if the user-scoped applications for all users were listed, that would cause other questions around "How do I know which users it is or is not installed to?" or "I never installed this, why is it showing as installed?" (especially when applications exist on one user account but not another).

Another great question - "What does it mean to install an application from system context?" Does this mean all SYSTEM context installs should be machine scoped? How would SYSTEM install to a specific user scope other than the current SYSTEM user? Is it valid to have applications installed and only available for the SYSTEM user? Certainly machine scoped installs make sense, but all the small details are what introduce complexity.

WinGet was not originally built for use in the SYSTEM context, so these are all questions that need to be thought through and (more importantly) documented. I'm sure the examples of listing and installing packages are just a small portion of what needs to be captured. Sinilar questions likely exist around what it means to uninstall from a SYSTEM context, or managing sources from SYSTEM, setting admin settings, and more. Nothing that's impossible to overcome, but there is a large scope of discussion that needs to happen around what the expected behaviors should be

[Policy] Context System

[PckgrTom]

Not sure if still valid, but see #962

I'm really interested more in the Winget PS module working over the Winget CLI. I already have all the functionality working for Winget CLI in the system context.

[PckgrTom]

@Trenly I think SYSTEM context should work with the expectation that IT Admins understand what it can and can't do. For instance it should be a known limitation that it will only be used for installing System wide apps that require local admin for installation and that user targeted apps would be installed via the user. When uploading scripts or wrapping scripts in Intune you have the option of selecting SYSTEM or User and the context so it's a matter of knowing when SYSTEM is appropriate.

My main interest in having the PS Module working is the improvements it brings to scripting and automation.

[Trenly]

@Trenly I think SYSTEM context should work with the expectation that IT Admins understand what it can and can't do. For instance it should be a known limitation that it will only be used for installing System wide apps that require local admin for installation and that user targeted apps would be installed via the user. When uploading scripts or wrapping scripts in Intune you have the option of selecting SYSTEM or User and the context so it's a matter of knowing when SYSTEM is appropriate.

My main interest in having the PS Module working is the improvements it brings to scripting and automation.

I don't disagree, was just pointing out that the documentation around what is expected to happen is lacking, and that unless you're an IT Admin who uses WinGet often and knows what it can and can't do, there's all sorts of questions and weird behavior that gets raised. An IT Admin who is new to WinGet may not understand all the ways that it behaves, especially when in SYSTEM context

[PckgrTom]

@Trenly I think SYSTEM context should work with the expectation that IT Admins understand what it can and can't do. For instance it should be a known limitation that it will only be used for installing System wide apps that require local admin for installation and that user targeted apps would be installed via the user. When uploading scripts or wrapping scripts in Intune you have the option of selecting SYSTEM or User and the context so it's a matter of knowing when SYSTEM is appropriate. My main interest in having the PS Module working is the improvements it brings to scripting and automation.

I don't disagree, was just pointing out that the documentation around what is expected to happen is lacking, and that unless you're an IT Admin who uses WinGet often and knows what it can and can't do, there's all sorts of questions and weird behavior that gets raised. An IT Admin who is new to WinGet may not understand all the ways that it behaves, especially when in SYSTEM context

OK that's fair. Just curious, is the functionality actually there for the PS Module and SYSTEM? Can it be unblocked? That would then help understand the limitations more. We could start to build a best practice around using Winget and system. Since my platform Pckgr relies heavily on the System account using Winget I can help with sharing what I know.

[SorenLundt]

Could you please add a feature to run in system context? I'm working on Winget-Wrapper, where I currently run the winget exe directly and parse its output into variables. It works well, but parsing information becomes tricky on different systems or languages. Running the module under system context would make things much simpler!

[denelon]

@SorenLundt take a look at the Microsoft.WinGet.Client PowerShell module. It's designed to output PowerShell objects rather than text which would be much easier to automate against.

[PckgrTom]

e under system context would make things much simpler!

I think they are doing a similar thing to me and converting the output of Winget CLI into variables as you can still use the Winget CLI as system.

[timcanning]

We have wanted winget to run as system from the start so that we can run Installs via RMM, ScreenConnect etc and this would also be helpful woth the powershell module.

[DannyJanmaat]

It's working if directly from "$Env:programfiles\WindowsApps"

First download the prerequisites, see : https://learn.microsoft.com/en-us/windows/package-manager/winget/

Add the packages as provisioned packages via Add-AppxProvisionedPackage so they will be available.

Test the install of the Winget packages via psexec under System account.

PowerShell script with params.

I made an executable via module ps2exe. Created the Intune package.

Intune : .\executable.exe -param1 -param2 -switch

Use only packages from https://winget.run/

I made an very advanced script for this so apps also are installed during deployment, and upgraded if upgrade available. Some packages don't work while installed via User context. This is at the moment the only way to install Winget packages via System account.

[EmpireConsultants]

It's working if directly from "$Env:programfiles\WindowsApps"

First download the prerequisites, see : https://learn.microsoft.com/en-us/windows/package-manager/winget/

Add the packages as provisioned packages via Add-AppxProvisionedPackage so they will be available.

Test the install of the Winget packages via psexec under System account.

PowerShell script with params.

I made an executable via module ps2exe. Created the Intune package.

Intune : .\executable.exe -param1 -param2 -switch

Use only packages from https://winget.run/

I made an very advanced script for this so apps also are installed during deployment, and upgraded if upgrade available. Some packages don't work while installed via User context. This is at the moment the only way to install Winget packages via System account.

@DannyJanmaat any chance could you elaborate in more detail or post your script???

[zagee1]

You can run Winget.exe from WindowsApps folder with SYSTEM account: cd C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.23.1911.0_x64__8wekyb3d8bbwe .\winget.exe