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

[bshoshany]

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

1. Open administrator command prompt / powershell
2. 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:

1. Open administrator command prompt / powershell
2. 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!

[jedieaston]

This should be moved to microsoft/winget-cli I think (it can be moved, you don't need to recreate it), but once the changes for #1284 are implemented in the client (the schema changes were added in #1427, specifically here), this should be able to be done.

Hypothetically we'll be able to say RequiresElevation: elevationProhibited in the manifest which will either make winget skip Spotify during winget upgrade --all if it's running as administrator (probably not what you want), or somehow run the Spotify installer without admin rights while being elevated (i don't know if there's a friendly way to do that with UAC without impersonation).

[bshoshany]

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

[denelon]

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

[bshoshany]

@denelon great, thanks for letting me know!

[denelon]

Related To:

• Add messaging to support package specific elevation requirements #1537
• Support installer specific elevation requirements winget-pkgs#29148

[jlssmt]

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

[arbitmcdonald]

+1 for the request. This would be a total game changer.

[denelon]

We've discussed unintended consequences of killing processes. It's not worth the risk to make this a default behavior. We may consider that as a "power user" feature, but today, we don't have a reliable mechanism to know which process or processes are running and what else might break for a user.

[arbitmcdonald]

We've discussed unintended consequences of killing processes. It's not worth the risk to make this a default behavior. We may consider that as a "power user" feature, but today, we don't have a reliable mechanism to know which process or processes are running and what else might break for a user.

Interesting. Could it be perhaps work as an optional switch? --aggressive or --force-upgrade etc

[denelon]

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

[jlssmt]

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

?

[denelon]

Some packages install services and an executable to interact with them. We would need to be enlightened about any processes related to the package. In the case of someone running a plugin for say "OBS Studio" they might be unhappy if they were to run upgrade on OBS Studio and kill some long encoding session they were running from another package that was leveraging it. That's the main kind of reason we are avoiding it.

If we enrich the manifest to include information about all processes, it could be technically possible to kill them, but we don't have anything like that in the manifest today. The other thing we've seen are silent installers that aren't quite smart enough to explicitly stop the program, but the interactive installer mode is.

[Trenly]

@denelon - I believe the elevation setting requirement has been resolved with #2126 and since it wont upgrade while running, that should be tracked by #1786 and closed by #2217 (once merged)

[denelon]

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

[martukas]

This is still a problem:

❯ winget install Spotify.Spotify
The installer cannot be run from an administrator context.

powershell version 7.3.3
winget version v1.4.10173
winget show Spotify.Spotify shows package version " 1.2.6.863.ge7902f05" which is same as on winget.run

[Trenly]

This is still a problem:

❯ winget install Spotify.Spotify
The installer cannot be run from an administrator context.

powershell version 7.3.3 winget version v1.4.10173 winget show Spotify.Spotify shows package version " 1.2.6.863.ge7902f05" which is same as on winget.run

Run the install command in a standard powershell terminal, and not one that was run as administrator

[martukas]

@Trenly I just reread the original ticket text here just to make sure I am not crazy. Isn't the whole point of this issue that this is not correct behavior, when all other packages deal with admin privileges just fine? Your last couple of comments seem to indicate some feature that was added to resolve this rather than closing of ticket with "won't fix"?

[Trenly]

@Trenly I just reread the original ticket text here just to make sure I am not crazy. Isn't the whole point of this issue that this is not correct behavior, when all other packages deal with admin privileges just fine? Your last couple of comments seem to indicate some feature that was added to resolve this rather than closing of ticket with "won't fix"?

The Spotify installer itself prohibits being run in an administrative context, it isnt something that WinGet has control over. Its also not an accurate statement to say that all other packages deal with admin priveleges correctly because I know there are packages that require admin to install but only install to a user context. Just because Spotify is the first example of applications requiring they be run in the user context and not an admin context doesn’t mean other installers don’t also have the same requirement.

The feature already existed to indicate which contexts an installer allows - elevatesSelf, elevationRequired, and elevationProhibited. My previous comments were stating that the installer requirement of elevationProhibited was added to the manifest at winget-pkgs so that the user is informed about the elevation requirement when a Spotify install is requested from an admin context instead of causing the breaking prompt

[martukas]

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.

[florian-obradovic]

This is still a problem:

❯ winget install Spotify.Spotify
The installer cannot be run from an administrator context.

powershell version 7.3.3 winget version v1.4.10173 winget show Spotify.Spotify shows package version " 1.2.6.863.ge7902f05" which is same as on winget.run

Run the install command in a standard powershell terminal, and not one that was run as administrator

I have a similar issue when I try to install Spotify via Intune in user context.
I'm aware that this is not a winget issue itself... It looks like Intune is somehow executing the install script in admin context if the user is in local administrator group, eve if install scope is set to user (in Intune).

`**********************
Windows PowerShell transcript start
Start time: 20240227182432
Username: DOMAIN\florianObradovic
RunAs User: DOMAIN\florianObradovic
Configuration Name:
Machine: VWIN11-KES01 (Microsoft Windows NT 10.0.22631.0)
Host Application: powershell.exe -windowstyle hidden -executionpolicy bypass -command .\install.ps1
Process ID: 6192
PSVersion: 5.1.22621.2506
PSEdition: Desktop
PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.22621.2506
BuildVersion: 10.0.22621.2506
CLRVersion: 4.0.30319.42000
WSManStackVersion: 3.0
PSRemotingProtocolVersion: 2.3
SerializationVersion: 1.1.0.1

---

Transcript started, output file is C:\Users\florianObradovic\AppData\Local_MEM\Log\Spotify.Spotify-install.log
Das Installationsprogramm kann nicht in einem Administratorkontext ausgeführt werden.

---

Windows PowerShell transcript end
End time: 20240227182434
**********************`

[AdreKiseque]

I'm not sure I understand, what's the point of this change? The installation still fails all the same. Why not use the flag to have WinGet install the package without elevation as needed, instead of just spitting an error and moving on?