Winget User vs. System Scopes

Question

Our helpdesk is using winget install via remote PowerShell scripts to deploy updates, but the apps are accidentally installing under the system account profile instead of the logged-in user's profile, breaking app shortcuts. How do we use the --scope switch properly to enforce user-level versus machine-wide application installations?

Answer 1

Hello,

When you use winget install inside a remote PowerShell session, by default the installation context is determined by the account under which the process is running. If your script is executing under the SYSTEM account, the packages will be installed machine‑wide, and shortcuts will be placed in C:\ProgramData\Microsoft\Windows\Start Menu\Programs. That explains why your helpdesk sees apps deployed under SYSTEM instead of the logged‑in user profile.

The --scope switch is what controls this behavior. --scope user forces the package to install into the current user’s profile, with binaries and shortcuts placed under %LOCALAPPDATA%\Programs and %APPDATA%\Microsoft\Windows\Start Menu\Programs. Conversely, --scope machine installs the package for all users, writing into C:\Program Files and the global Start Menu. The critical point is that --scope user only works if the command is executed in the context of the target user session. If you run it remotely under SYSTEM, the “user” scope resolves to SYSTEM’s profile, which is not what you want.

To enforce user‑level installs, you need to run the winget install --scope user <package> command inside the logged‑in user’s context. That can be achieved by using Intune Win32 app deployment with “Install behavior = User” or by invoking the script via a scheduled task or remote management tool that impersonates the user session. If you continue to run under SYSTEM, you should explicitly use --scope machine so that the installation is consistent and shortcuts are placed in the global Start Menu, avoiding the broken shortcut issue.

In short, --scope user is correct for per‑user installs, but only if executed as that user. If you are deploying via remote PowerShell under SYSTEM, you should either change the execution context to the logged‑in user or switch to --scope machine to ensure proper shortcut placement. This distinction is what prevents the mismatch you are seeing.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.