Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Winget as SYSTEM fails to upgrade certain packages #4332

Open
JuhaszBalint2 opened this issue Mar 31, 2024 · 4 comments
Open

Winget as SYSTEM fails to upgrade certain packages #4332

JuhaszBalint2 opened this issue Mar 31, 2024 · 4 comments
Labels
Area-User-Interface Issue related to user interface Context-System Related to system context (nt authority/session 0) Issue-Docs It's a documentation issue that really should be on MicrosoftDocs

Comments

@JuhaszBalint2
Copy link

Brief description of your issue

As the title states, I've noticed that when my script - that fires off Winget Upgrade as NT AUTHORITY\SYSTEM- is run, the log that it creates doesn't show this issue yet it does exist. So when thru my script I run the winget client in the SYSTEM context, it fails to recognize app packages it could upgrade, and that which it would upgrade if I were to run it in the USER context.

Does this make sense? I'm running the winget client as SYSTEM as a scheduled task thru the powershell script I wrote, the logs don't show any issues whatsoever, and of course, this scheduled task returns 0x0 so it does run and complete successfully every single time it's run - once daily. And it does find and upgrade some packages - in the SYSTEM context - but not all, and this is my problem.

The reason why I'm running it in the SYSTEM context is because I don't want to fire off any UAC prompts, any pop-ups, any prompts whatsoever for the end-user; I want it to work as a scheduled task completely silently in the background without the end-user ever noticing it in the first place.

Can I please get some input on this?

Steps to reproduce

I wrote a script that ran winget as NT AUTHORITY SYSTEM

I wrote another one that ran winget as USER

Expected behavior

NT AUTHORITY SYSTEM should discover ALL packages that can be upgraded.

Actual behavior

NT AUTHORITY SYSTEM fails to even discover some packages that can be upgraded

Environment

Windows Package Manager v1.7.10861
Windows: Windows.Desktop v10.0.22631.3296
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.22.10861.0
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage Issue need to be triaged label Mar 31, 2024
Copy link

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:

Closed similar issues:

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

@Trenly
Copy link
Contributor

Trenly commented Apr 1, 2024

I suspect that this is due to some applications being installed in the USER scope and not the machine scope.

When running as the SYSTEM user, any application information stored in a specific user profile isn’t accessible to WinGet. When looking for applications that are installed, WinGet will check the registry for application information in both the Local Machine and the current user. When running as SYSTEM, any applications installed in a specific user scope won’t be visible to SYSTEM as their information is under that specific users UID and not the SYSTEM users UID

@microsoft-github-policy-service microsoft-github-policy-service bot added Area-User-Interface Issue related to user interface Issue-Docs It's a documentation issue that really should be on MicrosoftDocs and removed Needs-Triage Issue need to be triaged labels Apr 1, 2024
@denelon denelon added the Context-System Related to system context (nt authority/session 0) label Apr 1, 2024
@JuhaszBalint2
Copy link
Author

@denelon What have you done? My script broke... It used to work flawlessly but as of today it no longer does. Is this an update of the backend that's behind this bug?

My log:

\
|
/

\
|
/

\
|
/

\
|
/

\
|
/

\
|
/

\
|
/

\
|
/

\

ÔľłÔľłÔľłÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺ 1024 KB / 9.71 MB
ÔľłÔľłÔľłÔľłÔľłÔľłÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺ 2.00 MB / 9.71 MB
ÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺ 3.00 MB / 9.71 MB
ÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺ 4.00 MB / 9.71 MB
ÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺ 5.00 MB / 9.71 MB
ÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺ 6.00 MB / 9.71 MB
ÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺ 7.00 MB / 9.71 MB
ÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľĺÔľĺÔľĺÔľĺÔľĺÔľĺ 8.00 MB / 9.71 MB
ÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľĺÔľĺÔľĺ 9.00 MB / 9.71 MB
ÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľłÔľł 9.71 MB / 9.71 MB

Failed in attempting to update the source: winget

@jantari
Copy link

jantari commented Apr 2, 2024

Failed in attempting to update the source: winget

It's possible you were running into #4338 there, but that seems to be fixed now. It should work again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User-Interface Issue related to user interface Context-System Related to system context (nt authority/session 0) Issue-Docs It's a documentation issue that really should be on MicrosoftDocs
Projects
None yet
Development

No branches or pull requests

4 participants