make winget run as admin instead of asking for admin on each installer

[Sakooooo]

Description of the new feature / enhancement

could it be possible to make winget run as admin and then run the installers as admin or user depending on if they need to install to appdata or program files

Proposed technical implementation details

winget is run as admin > winget runs installer either as admin or user based on manifest > install done

[denelon]

@Sakooooo we're doing some work now with the "elevatesSelf" property in the manifest to enlighten ourselves when a package will trigger UAC prompt. We're working on some scenarios where we can logically call a single UAC request for a set of packages to be installed in that context. Some users will not have the ability to elevate, and we need to be able to reason about that particular scenario as well. Interestingly, there are also packages that will not install in admin and we've added "elevationProhibited". In those cases, running in admin will fail, and we need to reason about "de-elevation" to some "appropriate" user account.

[denelon]

This will be necessary to support winget import packages.json or winget upgrade --all or winget install <pkg1> <pkg2> <pkg3>.

[Sakooooo]

on some scenarios where we can logically call a single UAC request for a set of packages to be installed in that context.

so its not possible to have one admin process handle all installers if im not wrong its only when its a set of packages which all need admin can be done like this?

[Sakooooo]

This will be necessary to support winget import packages.json or winget upgrade --all or winget install <pkg1> <pkg2> <pkg3>.

ah cause im having that issue with --all and would like a more hands free experience where i can click one uac prompt and let winget do the rest as i do something else

[mdanish-kh]

ah cause im having that issue with --all and would like a more hands free experience where i can click one uac prompt and let winget do the rest as i do something else

For that you can run PowerShell/CMD as administrator and accept the UAC prompt once and run winget upgrade --all - this would fail for packages that don't allow installation in an elevated context but to be fair those packages are a very small minority

[Sakooooo]

ah cause im having that issue with --all and would like a more hands free experience where i can click one uac prompt and let winget do the rest as i do something else

For that you can run PowerShell/CMD as administrator and accept the UAC prompt once and run winget upgrade --all - this would fail for packages that don't allow installation in an elevated context but to be fair those packages are a very small minority

but couldnt you just spawn the installer process as the user instead of admin from winget? or does that not work in windows

[mdanish-kh]

I'm not sure about possibility, but WinGet is currently not able to elevate (user -> admin mode) or de-elevate (admin -> user mode) based on the requirements of the installer.

Related discussions at #218, #271, #281

[Sakooooo]

oh alright

[chewychewytoo]

What about a scenario where the organization locks down user ability to run anything from winget themselves and only wants admins to be able to run it, period.

[amal3021]

It's because running terminal as admin takes us into admin folder. If you want to run upgrade -r for a standard user account you can just run terminal as admin and then navigate to the user folder using cd command.
Eg: Run as admin: terminal path: C:\Users\Admin (You need to go from here to user as mentioned below)
For a user named John : terminal path: C:\Users\John
Now you'll need to accept the UAC prompt one time only.

[pbanach2002]

After starting PowerShell and entering the winget upgrade --all command, I get the following error:

Failed when searching source: winget
An unexpected error occurred while executing the command:
0x8a15000f : Data required by the source is missing

When I run powershell as a user, everything is fine, only the applocker cuts it.

[samized]

Same here, PowerShell as administrator and winget upgrade --all results in:

An unexpected error occurred while executing the command:
Download request status is not success.
0x80190194 : unknown error

As user everything works fine, except the annoying step to enter administrator login on every install...

[JustMyGithub]

Is there a solution to this now?

Do all manifests have information "elevatesSelf" or "elevationProhibited" by now?

It seems pretty easy then: get admin-rights with one UAC and after all relevent installs/updates are done drop back to user rights - that's all, isn't it? (vice-versa would mean that UAC does not pop-up in the beginning, which is no good usability.)

[denelon]

I don't know if all manifests are correctly identifying "elevationProhibited" or "elevatesSelf". There are hundreds of PRs coming in on most days.

We've done some of the work to make this a bit more graceful with Dev Home via the COM APIs. After we get more data on this, we'll consider some kind of mode to enable lowering to the logged in user for packages that prohibit administrator when running "upgrade --all" as administrator.

For packages that require administration when WinGet is run as a user, the UAC is required for each installer.

[JustMyGithub]

Yes, it is required for each installer, but it would be more conveniant if it was only once and at the beginning of install (so you can leave it unattended afterwards and not come back finding a UAC or an error after timeout)

[denelon]

The original discussion topic was a question about having WinGet logically run elevated and "de-elevate" if needed for a single package install. We've been discussing how that would work, and for Dev Home running WinGet Configuration files, we do have a mechanism to support the behavior of a single UAC and then only those resources needed elevated are run as elevated while everything else is not.

When WinGet is told to "install" a package, it will perform several steps including fetching the manifest to see what the installer requires (assuming the metadata is present and correct). Then it will attempt to download the installer and compare it with the SHA256 hash. Assuming this is all valid, then the installation is triggered. If WinGet is run as "not elevated", and the installer requires elevation then WinGet can prompt for UAC. In some cases, "elevatesSelf", installers will perform their own elevation which might not be triggered until after some initial bootstrapping happens. There really isn't a "one size fits all" type of behavior due to the differences in how installers are built and what they do when they are executed.

[amal3021]

It's because running terminal as admin takes us into admin folder. If you want to run upgrade -r for a standard user account you can just run terminal as admin and then navigate to the user folder using cd command.
Eg: Run as admin: terminal path: C:\Users\Admin (You need to go from here to user as mentioned below)
For a user named John : terminal path: C:\Users\John
Now you'll need to accept the UAC prompt one time only.

[JustMyGithub]

For every packet winget determines whether to elevate or not. simply catch all manifests, sort by elevate /not elevate and elevate the thread/subprocess/... that handles the elevated ones. If an installer does elevate on its own, why is it a problem to do UAC before?
If winget is run as admin, the installer does not self-elevate as well - if winget elevates via UAC before the installer will just act like when winget was started from an elevated shell, wouldn't it?!

[denelon]

What I think you are describing at this point is not the scenario of a "single package install" as mentioned in the original discussion topic (up top). I think you're referring to the behavior when WinGet is acting on a "group" of packages as in "upgrade --all" or "import" or "configure". We're still working on WinGet and this is another improvement on the backlog. Some of this work is already in place via the COM API, and the next step is to add support for the behavior in the CLI and the PowerShell Module.

If it were actually as simple to implement as described, I expect we would have already done it. 😊

There are edge cases where it doesn't work as expected. There are also requirements around the information presented to a user for the UAC notification, and again, it isn't as simple as it might seem on the surface.

[jantari]

I've solved this by starting in a regular unelevated shell and running some winget commands there. Then for the packages that need admin I create an elevated Powershell process, this means one UAC prompt, and connect to it via named pipe IPC from the unelevated shell. Then I can send any winget packages, or really any command at all from the unelevated shell to the elevated shell and it will queue and execute them all with administrator permissions. This avoids any further UAC prompts and I can act as both a standard user and an administrator simultaneously.

However this requires a bit of boilerplate PowerShell scripting and maybe isn't super beginner friendly.

[Daolyap]

The problem with running winget in an elevated instance is that the winget source isn't initialised.

If you open an administrator PowerShell and add the source, you won't have any UAC prompts. You can also add the --silent flag to suppress software GUIs:
Add-AppxPackage -Path "https://cdn.winget.microsoft.com/cache/source.msix"
winget upgrade --all --silent --accept-package-agreements --accept-source-agreements