We have another “discussion” open that relates to what everyone is getting at here. Ultimately for this to be useful for anything outside of user-managed personal machines, it is an absolute requirement for winget to be deployable to the system context (i.e. msi or exe, binaries installed to a protected folder like \program files or \windows\system32). Right now we get that using the MSIX delivery mechanism is the newer method and it makes this manageable via the MS Store, but it makes it completely unusable for businesses entirely.

My testing thus far with Winget has me hopeful on how useful this tool can be for installing and updating applications by simply updating manifests in our eventual private repository. Right now though, this tooling is entirely run in the user context, therefore completely unusable as it requires every user on a machine to have this installed, and then requires them be granted administrative permissions on the machine to execute the installers defined in the app manifests. Given today’s security landscape and the various breaches in the past 6 months alone, I see many business partners locking things down and controlling administrative access much more tightly, so having this tooling available under the “system” context is going to be critical towards gaining adoption beyond home users and hobbyists.

Here is a link to our other discussion regarding this: https://github.com/microsoft/winget-cli/discussions/962

Installed winget for a user without admin rights. I run cmd (run as admin) or powershell (run as admin). Winget was not found

@ukedk winget has nothing to do here, It is the same reason you can’t run MSIX packages from SSH logins. all store apps/MSIX packages require NT Authority\Interactive login.

after several years, MSIX is still a no-op half backed thing for usecases like this. you can tell MSIX devs to enable to not require NT Authority\Interactive login.

@denelon , since the issue is open and AFAIK winget team is not responsible for this, is winget team considering for a MSI release or MSIX is gonna mature up ?

PS: Project Reunion MSIX proposal : Add per-machine storage support to MSIX. MSIX tech community issue : Machine Wide Provisioning (Install for All Users).

Winget would be such a usefull tool for system deployment IF it was able to run as system.

Having it Per user based seems such a missed opertunity.

I have started to work on a process to run everyday to update apps as system and notify connected user https://github.com/Romanitho/Winget-autoupdate i’m not a dev, but it works 😅

I ran into this issue today.

I think that the problem was that I was logged in as a Standard User, and I had run powershell.exe as an Admin user (different username) and that Admin user had not been logged into the Desktop before and therefore never had the opportunity to get winget from the Windows Store.

I think that overall having winget as part of the Microsoft Store & per-user installation is an absolutely horrible idea for a use-case like this, and it would be better to have it baked into Windows itself.

I usually use Chocolatey, which is awesome. But unfortunately there is a particular package which is only on winget (or manual download).

We have an automation tool where I work that I’d hoped to use WinGet to help manage our lab workstations. I encountered the same problem, but actually have a solution (at least for systems 20H2 and higher that have WinGet installed).

Windows Apps are actually stored under C:\Program Files\WindowsApps. In the case of WinGet, I am calling it using:

"C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.16.12653.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe" upgrade --all -h --accept-package-agreements --accept-source-agreements

Let me know if you have any questions or find this doesn’t work for you. This is now a game changer for us!

Additional Clarifications:

As far as I know this only works under the System account. Windows Apps are something I don’t quite understand, but as far as I can tell, standard user accounts can only access those directories as part of the Modern Apps framework, and administrators only browse that directory level. The permissions are… odd. I’m using the Windows File Manager since I can run it as admin and use it to pull up properties. I suppose you could do the same using the built-in Administrator account with File Explorer.

If you use the command where winget, you’ll find it located under your %localappdata%\Microsoft\WindowsApps\winget.exe, but if you browse that WindowsApps directory, it’s full of 0-byte files. These are some sort of link (hard links I think). Using junction.exe from SysInternals, it reports this file as "UNKNOWN MICROSOFT REPARSE POINT". But my thought is that these point to provisioned APPX packages. As a user, I believe you can only get to the actual C:\Program Files\WindowApps by calling the link created under your profile’s WindowsApps directory. But the System profile lacks the WindowsApps directory, hence the reason you can’t simply call “winget”. However, System does have full access to C:\Program Files\WindowApps, thus it works.

MS needs to make winget work at a system level. As per everyone’s comments in: https://github.com/microsoft/winget-cli/discussions/962

The Windows Package Manager is delivered with the App Installer. Our build system typically uses the least significant digits for identifying builds. If you run winget --info you should see in the output which version of Windows Package Manager, App Installer, and Windows. There are cases where builds with changes targeted to App Installer also update the version of the Windows Package Manager. I know this is super confusing, but it’s a necessary part of how we build the product today.

As the App Installer is delivered as an MSIX, there are boundaries for how the app is registered and used. This is why the remote calls and administrator calls behave differently than for other programs. This is an intentional part of the security boundaries for running MSIX packages. We are still evaluating remote execution and administrator execution scenarios.

Demetrius (denelon): So to be clear, there was a work-around in prior versions but you shut that path down to improve security [is that correct?]. It would be nice to have the option to enable this function like you do with other features. As a suggestion for remote execution you could use a token or paired key model that is registered so at least an organization owner or something could provide rights for this. This is all very standard for the MDM world and it seems like you guys are headed in that direction for traditional Windows and that is great. Honestly, System Admins should be able to run this and there really isn’t a great reason to shutdown the path on this unless there is a Local or Group Policy that says ‘no can do’

Thanks for responding this helps me to stop banging my head on this since it sounds like the update shut this down. If this was a defect that was introduced let us know if it was intentional it is better to let everyone know that you simply tightened up the implementation to shut this down.

on Win10 20H2 and winget v0.3.11201 same issue: on elevated cmd “The system cannot execute the specified program.” It would be nice if there would be a self compiled exe without the appxbundle but I am afraid that this is probably not technically possible. If I can provide someone with more information…thx.