We deploy applications through Company Portal and recently started using WinGet for some packages, currently Git. The deployment runs a PowerShell command similar to: Start-Process -FilePath "winget.exe" -ArgumentList "install --id Git.Git -e --source winget --silent --accept-source-agreements --architecture x64 --scope user" -NoNewWindow -Wait. It works on most devices, but several clients now fail with 0x8a15000f: Data required by the source is missing. Logs suggest that WinGet cannot find or properly use the Microsoft Desktop App Installer package. The same issue occurs when affected users run WinGet manually. We have already reset the sources, removed and reinstalled the App Installer bundle, and tried repairing the WinGet package manager. Running WinGet from an elevated PowerShell session usually works, but deploying elevated or system-context installs through Intune has been unreliable. We also recently applied a policy restricting system app installations to Microsoft Store apps, although testing has not clearly linked it to the failures. Is there a reliable repair or Intune-deployable fix, or should we use an MSI or another package manager instead?
5 Answers
The source parameter probably is not the root cause. Changing between the WinGet and Microsoft Store sources may provide a workaround for a particular package, but it will not repair a missing or broken App Installer registration. Also verify whether the script is running as the logged-in user, a local administrator, or SYSTEM; mixing an elevated administrator session with a user-scoped install often causes failures.
The most useful fix reported for this error is deploying Microsoft App Installer as a system Intune application. That ensures the Desktop App Installer and WinGet components exist consistently on the device. It also helps to call winget from its full WindowsApps path instead of relying on PATH resolution, since the executable location can vary by App Installer version. Once App Installer is installed correctly, packages can generally be installed in either user or system scope as long as the script runs in the matching context.
Check the affected machines in the Microsoft Store and update App Installer manually. WinGet is delivered as part of that package, and an outdated or partially registered App Installer can produce this exact source-data error. If Store access is restricted, temporarily allowing the Store or deploying the App Installer package through device management may be necessary.
A practical workaround is to deploy Git with its MSI while troubleshooting WinGet separately. There is no reason to let one unreliable package block the application rollout. WinGet is also very sensitive to execution context: user-scope installs should run as the target user, while system installs need elevation and should be executed from the system context.
If WinGet continues to be inconsistent, Chocolatey, Patch My PC, PDQ, or a vendor MSI may be more predictable for enterprise deployment. WinGet is convenient, but user-scoped installs and Store/App Installer dependencies make it harder to manage uniformly across older or differently configured clients.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures