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: https://github.com/microsoft/winget-cli/discussions/962

[Simpuhl]

I can run winget as a user but not as admin for some reason

[denelon]

https://github.com/microsoft/winget-cli/discussions/962#discussioncomment-736278

[rothgecw]

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.

[raShMan777]

Given you have access to the folder C:\Program Files\WindowsApps you can also create aliases as a workaround:

1. Look for the folder with the current version beginning with Microsoft.DesktopAppInstaller with your system architecture (e.g. x64): C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.16.12701.0_x64__8wekyb3d8bbwe
2. open an elevated PowerShell and open your profile: notepad $PROFILE
3. insert these two aliases while correcting the path (or create whatever alias[es] you want): Set-Alias -Name winget.exe -Value "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.16.12701.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe" -Scope "Local" Set-Alias -Name winget -Value "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.16.12701.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe" -Scope "Local"
4. open a new elevated PowerShell and voilá: `❯ winget.exe Windows Package Manager v1.1.0 Copyright (c) Microsoft Corporation. All rights reserved.

The winget command line utility enables installing applications and other packages from the command line.

usage: winget [] []

… … …`

[haydenhartland]

As of 1.17 calling AppInstallerCLI directly doesn't do anything at least on Windows 11. Has anyone figured out how to call AppInstallerCLI directly or indirectly running 1.17 on Windows 11 from a System user/session?

[rothgecw]

Is the AppInstallerCLI.exe binary simply not there, or is the path just changed? One thing I considered doing to avoid the versioning issue is to use the "pushd" command"

pushd "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
AppInstallerCLI.exe --version

Give this a try using PSExec. Might also get a directory listing just to see what's there:

psexec -s -i cmd.exe

I'm interested to know if something significant changed - I'm still on 1.16 myself. Cheers!

[haydenhartland]

Does 1.16 work on Windows 11?

C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe is where it is located. It is also strange that the old version directories and several files are on that machine in 1.0.42251.0 but the CLI is not in there. They should clean up that crapola... Any way if someone knows what changed or why it doesn't work with this new release or Windows 11 in general I appreciate your insights.

[rothgecw]

I'm on Windows 11, and 1.16 is working. What are the commands you're using? Are you getting any errors? When running as "nt authority\system", what do you get running C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe --version? Just trying to make sense of the problem you're seeing. Cheers!

[haydenhartland]

I have tried several commands

C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe --version

C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe list --accept-source-agreements

All commands I run simply return to the command prompt. If I run it from the user context it is fine but if I run it from the system I get nothing at all - no feedback nothing

[rothgecw]

User context...? How did you manage to run C:\Program Files...\ApInstallerCLI.exe as a user? The permissions on the WindowsApps directory do not permit it. How are you running your commands as system? Just trying to get context. Thanks!

[haydenhartland]

Sorry to be clear...

Running CMD as a Local Admin I can successfully use winget

Running a CMD from psexec -i -s cmd and using the full source path I get nothing

[rothgecw]

Are you using the full path when operating as local admin? If not, where is winget getting called from (where winget)? I'm curious what is in the actual winget directory at that full source path. Have you tried calling dir on "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe"?

[haydenhartland]

"winget" is getting called from C:\User...\AppData\Local\Microsoft\WindowsApps\ when I run it as a local user

And the only location of AppInstallerCLI.exe is in: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe\

There is another Microsoft.DesktopAppInstaller_*_8wekyb3d8bbwe\ directory but it does not contain the AppInstallerCLI.exe file in it

If I run dir on C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe\ it has a bunch of stuff in it including the AppInstallerCLI.exe file although I have not run a diff against the two directories

[rothgecw]

Right, from what I can tell, %localappdata%\Microsoft\WindowsApps\winget.exe appears to be a hard link of some sort that points into %programfile%\WindowsApps\Microsoft.DesktopAppInstaller.... I think I'm good with what you meant there now - thanks!

As for why you're getting no output from calling AppInstallerCLI.exe... I'm a bit stumped. The only thing I can think is perhaps stdout/stderr are being redirected, but they shouldn't be using just the psexec command you listed. What happens if you first pushd "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe", then call AppInstallerCLI.exe within that psexec session?

[haydenhartland]

If I pushd C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe\ from a local Admin account and run AppInstallerCLI I get the same result as if I simply ran winget (All good there)

If I run pushd C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe\ from a system account (psexec -i -s cmd) then when I run AppInstallerCLI the output from the command is nothing just returns to command prompt

If I run powershell and then try to run the AppInstallerCLI as a system user I get AppInstallerCLI.exe is not a recognized blah blah blah

Keep in mind this is only happening when I try to run this 1.17 version so something had to have changed

[rothgecw]

Yeah, sounds like something changed. I'm on Win 11 and 1.16 of winget at work, but I'll check what I have at home and test it out too. Are you on a dev branch of Windows?

What I find really confusing is the versioning. If I run winget -v from any user account on my system, I get "v1.1.12986", which partly matches the versioning in the path "Microsoft.DesktopAppInstaller_1.16.12986.0_x64__8wekyb3d8bbwe". But where'd the "1.16." come from instead of the "1.1."? Further, if you're quick enough with Task Manager, you can find the process "AppInstallerCLI.exe" appear briefly (indeed in the full path), but getting properties for it shows both file and product versions "1.16.2110.25006", and yet if I run AppInstallerCLI.exe -v from system, I only get "v1.1.0". Huh?!

[haydenhartland]

I am running a Preview build of Windows...

If I run winget -v from a user account on that machine I get "v1.2.3131-preview"

I will look into attaching to the AppInstallerCLI.exe to see if I can grab the version info when I run winget as a user

Super frustrating...

[haydenhartland]

It is interesting that Local Service has Read&Execute rights and System has all permissions for C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.3131.0_x64__8wekyb3d8bbwe\

When I look at the process details I see the following:

Not sure what the problem is but seems like a defect to me...

[denelon]

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.

[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