-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
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:
|
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 |
@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: \
|
It's possible you were running into #4338 there, but that seems to be fixed now. It should work again. |
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
The text was updated successfully, but these errors were encountered: