TL;DR: winget install for Microsoft Store apps fails under SYSTEM because Store packages are per-user, so the working pattern is to run the install inside the logged-in user session, then verify success with MSIX-native checks rather than the registry, according to Fleet.
Editorial analysis by NHI Mgmt Group, based on content published by Fleet: “Put Microsoft Store apps in Windows self-service with winget”.
Key questions
Q: Why do Microsoft Store app installs fail when run from endpoint management tools?
A: They fail because the Microsoft Store app model is user-scoped, while many endpoint tools execute scripts as SYSTEM or another device-level context.
Q: What should security and IT teams do first when winget cannot install a Store app?
A: First confirm whether the app is meant to be installed per user or provisioned machine-wide.
Q: What are the signs that a Windows Store app deployment is using the wrong verification method?
A: A common sign is that the installer appears to run successfully, but the app does not show up in the registry-based uninstall view.
Practitioner guidance
- Define the installation scope before packaging Store apps Classify each app as per-user or machine-wide before writing the deployment script, because the install mechanism changes completely between winget in a user session and Appx provisioning as SYSTEM.
- Move winget execution into the logged-on user session Use a short-lived scheduled task owned by the console user so winget runs where the Microsoft Store accepts it, rather than trying to force SYSTEM-context installation.
- Validate installs with Get-AppxPackage Treat the MSIX package list as the source of truth and use Get-AppxPackage -AllUsers to confirm that the package exists after the task completes.
Bottom line: Microsoft Store apps expose a control gap between device-level automation and user-scoped installation, and that gap is why SYSTEM-context winget runs fail.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →