winget path issue?

  • Thread starter Thread starter Brutser
  • Start date Start date
B

Brutser

Guest
When I opt to include updates Microsoft.UI.Xaml.2.8 and the Windows Package Manager (app installer, winget), then I notice the following behavior:

Logged in to Windows 11 as Standard User:

- When opening the terminal as Standard User, winget command works as expected.
- When open the terminal as Administrator, winget cannot be found
Code: 
winget : The term 'winget' is not recognized as the name of a cmdlet, function, script file, or operable program.

Logged in to Windows 11 as Admin User and both options work fine.

Most likely has something to do with PATH variables not configured correctly? But I believe this is the default behavior after including those updates and a clean Win11 23h2 install, so something must be fixed?
 
Here's the technical point that confuses winget users: winget is a non-UWP app which is bundled inside the DesktopInstaller UWP app.

Rather than providing a standalone Win32 app which could install AppX packages (like the DISM command), MS decided to include winget as a program within DesktopInstaller so it could be downloaded via Windows Store. The problem is Store apps don't have explicit execution paths, but register their own AppId's which Windows maps to specific application folders.

For example, it's not uncommon to have different versions of the same app exist side-by-side. While you could use an explicit path to find winget.exe, Windows normally uses the AppId metadata provisioned into your user profile.

Normal users, including those that belong to the Admin group, have user profiles which get updated. The built-in Administrator user or SYSTEM identify isn't in the same group, and doesn't get provisioned. Therefore it doesn't know where winget lives.

When executed from Post-Setup (After logon), winget command have Admin rights but they run under your user profile.

One workaround for scripting winget commands as Administrator, is to figure out the current DesktopAppInstaller folder (which includes the specific build version) and call it directly.

https://call4cloud.nl/2021/05/cloudy-with-a-chance-of-winget/#part3
 
garlin Thanks for the explanation! I was not really trying to script anything, but rather noticed this after installation on a virtual machine.
But then it's still not expected, because MyUser (the standard user) opens an elevated terminal, authenticates as MyAdmin user (the admin user), then you would expect winget to be available - as the user profile is updated for this user like you said.
Also confirmed when opening the terminal as MyAdmin user and having winget to work.
Am I wrong?

Edited: the problem was that MyAdmin did not get provisioned yet, exact like you explained, after opening MyAdmin account for the first time, the elevated terminal for MyUser also worked fine.

Solved!
 
You must log in or register to reply here.
Back
Top