Can't run winget as a admin

[Jordan-Mesches]

Brief description of your issue

I'm trying to avoid the UAC prompt whilst downloading a package, so I open a elevated terminal and run winget

However I get the following message The system cannot execute the specified program.

But note that it works perfectly fine when it's just a normal terminal.

Steps to reproduce

Open an elevated terminal and run winget?

Expected behavior

Winget works normally, except I don't get any UAC prompts when installing

Actual behavior

I get the following output The system cannot execute the specified program.

Environment

[winget --info]
Windows Package Manager v0.2.2521 Preview
Windows: Windows.Desktop v10.0.19041.572
Package: Microsoft.DesktopAppInstaller v1.11.2521.0

[denelon]

Are you running this in CMD or Windows Terminal? I'm not able to reproduce. Incidentally, there is a newer version of the package manager available. (I don't think it would have any impact on this issue).

[Jordan-Mesches]

Are you running this in CMD or Windows Terminal? I'm not able to reproduce. Incidentally, there is a newer version of the package manager available. (I don't think it would have any impact on this issue).

I'm running it in a elevated cmd, I do have a very rowdy antivirus installed, so it's very possible that could be the issue

[denelon]

@Jordan-Mesches, I don't have any other ideas. Can you temporarily disable the anti-virus and try the installer again? If you don't mind, which anti-virus and settings are you using? It might be good to add to our F.A.Q.s

[trollyanov]

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

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[DrewNaylor]

Ran into this problem myself on some (but not all) installations of Windows 10 across various versions, including I think 2004 and 1909. This seems to affect APPX/MSIX packages in general so it's not just a winget thing and may in fact be a recent Windows bug, as it didn't start happening until a few months ago and I ran into the same issue with Windows Terminal. Not sure if the original poster is elevating from an account with Administrator permissions or not, but I'm not and winget only works when I elevate from that account.

[denelon]

I reopened the bug. This might be an external issue as suggested, but we'll keep this open to remind ourselves to take a look.

[ukedk]

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.

[ghost]

@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).

[denelon]

I added the "Area-External" label.

[denelon]

@ecovio1 let's try to keep things constructive here. I understand the frustration regarding a highly desired feature. I just went and put my 👍 on both of those issues. Anyone else running into this challenge from the perspective of installing packages with the Windows Package Manager might stumble on this issue, and be motivated to show their support as well.

[ukedk]

@ecovio1 thanks for the explanation of the cause. Unfortunately, so much is half-baked (the youth will call it exciting ;)). Perhaps it would be useful to revise the readme, as this is misleading (...When running winget in an Administrator Command Prompt, you will not see elevation prompts) . Due to lack of developer knowledge: probably it is too elaborate to leave the NT Authority\Interactive option out ? I have not seen any compilates outside the official repsiotry so far....

[jorgytim]

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:
#962

[Simpuhl]

So what is the best way to run winget as system/admin using Intune?

[haydenhartland]

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.

[denelon]

To be honest, I'm not sure if an intentional change was made in this case. There are several teams working on different product areas. If I knew, I would share the information. We're looking at several scenarios for remote execution. Yes, we are working with the Intune team on a solution to replace the Store for Business. More information will be coming as we continue to work on that solution. I know how critical it is for administrators to be able to configure and manage their environments. I certainly see how powerful this tool can be in that space. I'm very excited about many of the problems we can help solve here.

[JulianGodd]

Without system execution access this product becomes largely useless for anyone but local admins and then it is a minor convenience where you wonder why you didn’t just install Linux

[gathulb]

This could be a great tool and game changer for Windows in so many ways. A unified deployment and package manager. Definitely needs an open way to remotely manage for admins and integrators. Otherwise someone will just branch it and at some point MSFT will buy them.

[ghost]

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.

@rothgecw Thanks so much for the explanation and sharing your workaround for it.

However, When I run this under NT Authority\System I get Unexpected token 'upgrade' in expression or statement
Am I missing out something ?

[haydenhartland]

As indicated earlier if you are on 1.16 or below this solution works but if you upgrade Winget to .17 or higher it no longer works to run winget in the context of a System account. As for your question the 'upgrade' token I can't help you there.

[ghost]

hmm interesting. I did check the version after your initial response and was on 1.16 and I am actually still on 1.16 and that actually does not work for me for some reason.

[Romanitho]

It seems that AppInstallerCLI.exe was replaced by winget.exe 😅 (for 1.17)

[haydenhartland]

Yes but any release after .16 will not support a direct call to AppInstallerCLI.exe and any call to winget.exe as a system user will fail to execute.

[Romanitho]

I mean "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.*_x64__8wekyb3d8bbwe\winget.exe"

[haydenhartland]

Are you able to run that as a system user cause I am not... Try running it as a system user: psexec -i -s cmd Then try to run it

[Romanitho]

[haydenhartland]

[image: image.png]

[Romanitho]

[haydenhartland]

Mine simply returns with no output are you on a 32 or 64 bit machine?

[haydenhartland]

The directory list is the same output as yours

[Romanitho]

Mine simply returns with no output are you on a 32 or 64 bit machine?

64

[haydenhartland]

Not sure why yours works and mine doesn't. It works fine for me on earlier version but not latest...

[29039]

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).

[Romanitho]

Run as system (if you use sccm or intune for example, or via a scheduled task)

[Romanitho]

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 😅

[KrisAtKingston]

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.

[denelon]

We're working on an In Process COM API the work started with this PR.

It was mentioned in this release.

[cgerke]

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: #962

Some interesting stats on the manifests doing a search of InstallerType across the git repo.

11940 results in 11134 files InstallerType: nullsoft (exe)
6318 results in 4855 files InstallerType: wix (msi)
5931 results in 5387 files InstallerType: inno
5664 results in 3754 files InstallerType: exe
2713 results in 1974 files InstallerType: msi
1004 results in 637 files InstallerType: burn (exe)
811 results in 688 files InstallerType: portable
448 results in 290 files InstallerType: msix
225 results in 217 files InstallerType: zip

[secprentice]

MS needs to make winget work at a system level. As per everyone's comments in: #962

[aclondon]

Appreciate this is a slightly old topic, but if you are running winget using an elevated command prompt, such as:

runas /user:localadmin cmd - this will not work.

You need to use

runas /noprofile /user:localadmin cmd

A bit more details here https://superuser.com/questions/42537/is-there-any-sudo-command-for-windows