Elevation where the user does not have administrative access

[markembling]

I'm not sure whether what I'm dealing with here is a bug, expected behaviour, or somewhere in the middle, so I'm starting this simply as a question with the hope that someone will know the answer and have perhaps a better idea of what this issue actually is.

I have a .winget file which wants to install both user-scoped application packages, and Visual Studio 2022 which uses the securityContext: elevated directive to specify that admin elevation is required. However this doesn't actually work and I end up with output similar to the following:

VSComponents🛡
  Loading the module for the configuration unit failed because it requires administrator privileges to run.
Script [AddCustomUserPSModulePath]

I think the reason for this is because the environment it is being used in is one where the primary user account is not an administrator and therefore it makes sense that it cannot elevate. I have a separate user account used for administrative operations (such as manually running the VS installer/modification process). But obviously this is a separate account.

It seems like WinGet cannot trigger a UAC prompt which can elevate as a different user (prompting for admin username/password). I also cannot (or more accurately, do not want to) run the entire winget process as that admin user, as then all the user-scoped packages in the file will be installed for that user, rather than my regular account.

I guess my question is whether there's anything I can do to mitigate this, or whether this is a feature request (i.e. can winget do this in future). Or really anything else I should know, consider, or look into?

[denelon]

This would be a feature request, and it likely isn't just WinGet that would need to be able to support a different account for elevation. There are probably some other OS primitives that would need to exist for something like this to work. I'd also expect some edge cases to show up for packages being installed for the current user that require an "NT Service" (which requies elevation to install).

[markembling]

Most things do seem to do it that way, which is what confused me. For example, the Visual Studio installer needs to run as admin and the elevation process happens as expected but asks for admin credentials (which, when provided, then means the installer presumably runs as admin within that user's context). That behaviour seems pretty standard across the board, which is why I was a little surprised WinGet didn't do it that way.

But I'm definitely no expert on UAC. And having an environment where the main account in use can't elevate definitely seems to be the underlying cause - I'm not sure how commonplace this actually is...

[DakotaB75]

You can handle non-admin + admin package installs in WinGet using a simple elevation check. Relauch the script with UAC if the current user is not admin:

if (-not ([Security.Principal.WindowsPrincipal]([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Start-Process powershell "-NoProfile -File `"$PSCommandPath`"" -Verb runas; exit
}
winget install <PackageId> -e

This ensures user-scoped packages install under the current account, while system-scoped packages get proper admin elevation.
Docs: WinGet CLI | Windows UAC

I will try to work on a pull request to add an integrated installation wizard with elevation for this scenario...