Sources don't update if something that would update the sources (winget show, for example) is run from an elevated CMD window in an account that's not in the Administrators group.

[DrewNaylor]

Brief description of your issue

Doing something that updates winget's sources from an elevated CMD/PowerShell window while logged into a user account that's not in the Administrators group doesn't actually update the sources.

Steps to reproduce

Note: winget will need to be installed in both accounts. Installing it in the account that's in the Administrators group will ask you to re-install, but in reality it's not installed in that account yet. winget may also complain about sources being broken after re-installing and trying to run from the account that's not in the Administrators group, but I haven't noticed this while verifying this issue.

Note 2: There will need to be a "Standard" account (according to what the Windows 10 Settings app calls accounts not in the Administrators group) in addition to an account with Administrator permissions, which is being referred to here as "Admin" to make it shorter.

1. Open an elevated CMD/PowerShell window from the account that's not in the Administrators group.
2. Run winget show > (a text file somewhere that you'll check later)
3. Open a non-elevated CMD/PowerShell window from the same account.
4. Run winget show > (a text file with a different name from the earlier one; you'll check this one later, too).
5. Compare the two text files and notice that the progress bar goes from 0% to 100% in the elevated prompt output, while it gradually increases as expected in the non-elevated prompt output. An example is pasted in the "Actual behavior" section.

Reproduction steps were changed to use ones that may be more easily reproducible.

Expected behavior

The sources should be updated just like they would be if you used a non-elevated CMD/PowerShell window.

Actual behavior

Sources don't actually update even though winget says they were updated. If you do something that updates the sources in a non-elevated window (winget show, for example) then try to do the same thing in the elevated window, it acts as if the sources were updated, even though they weren't updated in the elevated window.

I ran winget show first in the elevated prompt first and directly afterward ran it in the non-elevated prompt, and sent its output to a text file both times. Since it keeps the progress bar in the output, I've pasted them here:

Elevated:

  ██████████████████████████████   383 KB /  383 KB
                                                              

  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  0%
  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  0%
  ██████████████████████████████   383 KB /  383 KB
                                                              

  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  0%
  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  0%

Non-elevated run directly after the elevated one:

  ██████████████████████████████   383 KB /  383 KB
                                                              

  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  0%
  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  0%
  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  1%
  █▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  4%
  █▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  5%
  █▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  6%
  ██▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  7%
  ██▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  9%
  ███▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  10%
  ███▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  12%
  ███▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  13%
  ████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  14%
  ████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  16%
  █████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  18%
  ██████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  23%
  █████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  44%
  ███████████████████████▒▒▒▒▒▒▒  77%
  ███████████████████████▒▒▒▒▒▒▒  77%
  ███████████████████████▒▒▒▒▒▒▒  78%
  ██████████████████████████████  100%

Environment

[winget --info]
Windows Package Manager v0.1.42101 Preview
Windows: Windows.Desktopv10.0.18362.959
Package: Microsoft.DesktopAppInstaller v1.10.42101.0

Any other software? None relevant to this issue.

This was verified in winget v0.1.42101 on my primary desktop.

[megamorf]

You don't actually need to update sources manually. That's being done behind the scenes after the cache has gone stale.
https://github.com/microsoft/winget-cli/blob/master/doc/Settings.md#autoupdateintervalinminutes

[DrewNaylor]

I'm aware of that, but unless it updates for the Admin account at the same time as the standard account, running winget show (package) as admin didn't update the cache for me even though the cache-updating progress bar showed up.

[megamorf]

As for the account issue. If you're running winget with a user that is not member of the Administrators group then that behaviour is expected.

When a user account that is member of the Administrators group logs on, the Explorer and other processes will be started with a standard user access token. That user can then run a process elevated via UAC which grants that process an additional full administrative access token. Both belong to the same user and therefore same user profile.

What you have is a user that is not a member of the Administrators group. That means that user cannot elevate processes. In this case UAC allows you to use another user account that is member of the Administrators group to run that process. In this case you're actually executing a process in the context of a different user and therefore user profile. That means the paths where that foreign process writes to is different from your non-admin user and there is no way of solving this. That's by design

[DrewNaylor]

That makes sense, but the issue is that winget isn't updating the cache when I'm running it elevated from a regular account, while it does update when not running it elevated from the same regular account.

[megamorf]

You really need to be more specific with your statements and re-read my comment that explains how UAC works.

[DrewNaylor]

What I'm trying to say is, the elevated prompt in a standard account isn't updating the cache in the account the elevated prompt is using, while the non-elevated prompt is updating the cache in both the elevated and non-elevated prompts. I re-read the earlier comment more thoroughly and understand that part.

[megamorf]

Please refrain from using the term "standard account" or "regular account" - there is no such thing. Your user account is either member of the Administrators group (default) or it isn't (either deliberate choice or corporate policy). The former can elevate its own processes whereas the latter needs another user account to do that.

From what I understood your scenario is the latter where you use an account with limited permissions (not member of Administrators group) and elevate CMD with a different user account that is member of the Administrators group. Is that correct?

You can run the command whoami /groups to clarify that.

[DrewNaylor]

That is correct. Sorry, I was just going off what Windows 10 calls accounts in the account settings section of the Settings app.

Decided to send winget show's out put to a text file from both the elevated and non-elevated prompts, and it includes the progress bar when it updates its cache, so I'll edit the first post with them if it helps this issue.

[megamorf]

After clarifying your setup the problem is indeed not with elevated permissions (CMD and its child processes having the administrative user token) but that you're simply using winget with two different user accounts.

That behaviour is expected. Here's a more detailed explanation why:

---

Say we have two Windows user accounts:

• LimitedUser (not member of Administrators)
• NormalUser

When I print LimitedUser path variables in PowerShell it gives:

PS> $env:UserProfile
C:\Users\LimitedUser

PS> $env:LocalAppData
C:\Users\LimitedUser\AppData\Local

Now as LimitedUser I want to run PowerShell elevated. A UAC prompt shows up allowing me to run the process as NormalUser. When I run the same commands the output is different:

PS> $env:UserProfile
C:\Users\NormalUser

PS> $env:LocalAppData
C:\Users\NormalUser\AppData\Local

Winget writes to %LocalAppData%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe. That means that depending on whether you ran winget in the first or second example its filesystem interaction was with different user profiles.

There's nothing to fix here - this is by design. Regardless of Windows version the user profile is considered an access boundary. This applies to all processes, e.g. an MSI setup will always write to %TEMP% and applied to your scenario you wouldn't find its files in C:\Users\LimitedUser\AppData\Local\Temp but under C:\Users\NormalUser\AppData\Local\Temp.

[DrewNaylor]

This makes sense regarding file access. Just strange that the progress bar behaves differently when run elevated from a user not in the Administrators group compared to running non-elevated from the same user.

[denelon]

@DrewNaylor, I will dig in a bit deeper to try and clarify exactly what is happening.

[denelon]

I believe @megamorf correctly described the account specific behavior. This looks like an edge case where there were multiple instances of installation for the client. The TTL value is stored based on the installed user(s). Each installed location has it's own reference timestamp for the TTL calculation. I expect the undesired behavior is being network inefficient primarily. We're looking at Delivery Optimization and being Metered Network aware in the backlog. I'm going to reference #151 as a signal to look back at this Issue. The fix for this would likely require some additional engineering to minimize the additional unnecessary downloads for the cache.