winget-cli: Spotify.Spotify does not install or update if winget is running in admin mode

Create issues related to the winget.exe client here

Brief description of your issue

I run winget upgrade --all to upgrade all packages automatically at startup. This has to be run in administrator mode, otherwise I need to manually click “Yes” in User Account Control for every single package that gets updated. However, when winget attempts to upgrade Spotify, the installer complains that it has to be installed using a normal account instead of an Administrator account (see screenshot). This not only means that it won’t update, it also means it will stop the automated update at startup since I have to click “OK” in the dialog box before winget can continue.

Steps to reproduce

Open administrator command prompt / powershell
Type winget upgrade spotify

Note that if Spotify is not already installed, then it also cannot be installed for the first time from admin mode:

Open administrator command prompt / powershell
Type winget install spotify

Expected behavior

Spotify should install or upgrade in admin mode.

Actual behavior

Spotify does not install or upgrade in admin mode.

Environment

Windows Package Manager v1.0.11692
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19043.1165
Package: Microsoft.DesktopAppInstaller v1.12.11692.0

Suggestions for solution

If Spotify has a different installer which works in both normal and admin mode, then that installer should be used by the package.
If the Spotify installer has a flag that allows it to install in admin mode, then that flag should be used by the package.
If winget has an option to run an installer in normal mode even though winget itself was run in admin mode, then this option should be used by the Spotify package.
If winget does not have such an option, then that option should be added!

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 4
Comments: 20 (10 by maintainers)

Most upvoted comments

Ok, the nuance of how a breaking prompt compares to some other refusal error message and how that’s what the final adopted fix was about is not super obvious.

To reword what you said - winget has added a feature that allows for more granular/graceful control over how privilege checks are performed for packages like this, but it is now up to the managers of particular packages (like Spotify) to make use of it to result in sensible and non-frustrating behavior. Does that sound about right?

Probably worth adding determined to not be a bug as described by original reporter somewhere in here for other mortals that come wandering in.

martukas on Mar 26, 2023

Also looking forward to a fix. I want to add something additional: Spotify won’t upgrade while it’s running. Expected behavior: Kill spotify, upgrade and maybe start it if it was opened before (if thats possible).

jlssmt on Oct 22, 2021

@bshoshany we’ve been working on the schema to support this scenario. @jedieaston is calling out the new changes to the schema. As soon as the client can honor this request, we should be able to resolve this issue.

denelon on Sep 7, 2021

Something like that would be the “power user” option, but we still need to know what process or processes to kill.

It reminds me of the good old days with “kill -9”.

taskkill /IM "spotify.exe" /F

jlssmt on Dec 3, 2021

Thanks for your reply! If someone with the right permissions can move it to the other repository, that would be great.

(i don’t know if there’s a friendly way to do that with UAC without impersonation).

I feel like if I’m the administrator, I should be able to do whatever I want… 😃

bshoshany on Sep 6, 2021

I agree with @Trenly and I’ve confirmed the manifest now includes elevationProhibited.

denelon on Aug 8, 2022