Winget pin add (AppID) --blocking fails to prevent app upgrade when scripts runs as SYSTEM

[JuhaszBalint2]

Brief description of your issue

As the title says, a few of my apps I did NOT want to be upgraded still got upgraded by "winget upgrade --all" even tho I had run "winget pin add (AppID) --blocking", this command's success was confirmed by "winget pin list" command, they all got pinned by "blocking".

Steps to reproduce

Run winget pin add (AppID) --blocking run a winget upgrade --all script as SYSTEM look at the log file: it will say, for example, that PowerISO got upgraded even tho I made sure to block it by the aforementioned commands and the list showed the block

Expected behavior

Winget pin add (AppID) --blocking should completely prevent any version upgrades whatsoever.

Actual behavior

Winget pin add (AppID) --blocking does NOT prevent ALL app versions from being upgraded

Environment

Windows Package Manager v1.7.10861
Windows: Windows.Desktop v10.0.22631.3374
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.22.10861.0

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• Winget as SYSTEM fails to upgrade certain packages (#4332), similarity score: 0.75

Closed similar issues:

• Winget PIN Didn't Prevent Winget UPGRADE (#3484), similarity score: 0.79

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[Trenly]

@JuhaszBalint2 - I suspect this is because pins are applied per-user, meaning that when you apply a pin as SYSTEM, the package is only pinned for SYSTEM. When you apply a pin as a user, it is pinned for only that user and not for SYSTEM

Unless you have a specific need for it, I would highly recommend avoiding using the SYSTEM context

[JuhaszBalint2]

@JuhaszBalint2 - I suspect this is because pins are applied per-user, meaning that when you apply a pin as SYSTEM, the package is only pinned for SYSTEM.

Unless you have a specific need for it, I would highly recommend avoiding using the SYSTEM context

I do have a specific need for it hence my use

I forgot I'd applied the pin script in the user context. Is that why?

[Trenly]

I do have a specific need for it hence my use

I forgot I'd applied the pin script in the user context. Is that why?

Yes. If you applied the pin in the user context then the pin only exists for that user.

Can you explain a bit more about your specific need to run as SYSTEM? @denelon is working on documenting what the current behaviors are and understanding what you’re trying to accomplish will help him

[Trenly]

[Policy] Issue-Docs [Policy] Area-User-Interface

[JuhaszBalint2]

I do have a specific need for it hence my use I forgot I'd applied the pin script in the user context. Is that why?

Yes. If you applied the pin in the user context then the pin only exists for that user.

Can you explain a bit more about your specific need to run as SYSTEM? @denelon is working on documenting what the current behaviors are and understanding what you’re trying to accomplish will help him

Basically I deploy software onto my workstations and upgrade them via winget and chocolatey. In an ideal environment including my homelab, I do NOT want the end-user to be met with UAC prompts or any pop-ups of any sort whatsoever. I want my environments locked down to the max yet still perfectly usable for the optimal end-user experience and security.

[JuhaszBalint2]

[Policy] Issue-Docs [Policy] Area-User-Interface

Btw winget pin add (ApID) --blocking --scope machine isn!'t working. Is there something that will apply the blocking pin as SYSTEM?

[Zulgrib]

Pinning should be managed by an admin for the machine, meaning it shouldn't be per user. Software are installed machine wide after all.