We deploy applications through Company Portal and recently started using WinGet for Git. The PowerShell command runs `winget.exe install --id Git.Git -e --source winget --silent --accept-source-agreements --architecture x64 --scope user`. It works on most computers, but several users receive `0x8a15000f: Data required by the source is missing`. Logs suggest WinGet cannot find or properly access the Microsoft Desktop App Installer package. The failure happens both when the command is launched manually and when it runs through the deployment script.
We have already reset the WinGet sources, removed and reinstalled the Desktop App Installer bundle, and tried a WinGet repair tool. Running WinGet from an elevated PowerShell session usually works, but deploying it as an administrator or installing system-wide through device management has been unreliable. We also recently enabled a policy restricting system app installations to Microsoft Store applications, although testing suggests that policy is not the direct cause.
Has anyone found a reliable fix that can be deployed centrally? We would prefer to keep using WinGet for version management, but can temporarily deploy Git as an MSI if necessary. Reinstalling affected computers would be excessive.
4 Answers
A practical workaround is to deploy Git as an MSI while troubleshooting WinGet. There is no reason to let one broken package block the rest of the software rollout, especially since WinGet can be inconsistent with user and system contexts.
Check the execution context carefully. A user-scope install needs to run as the target user, while a system install should run elevated as SYSTEM. Running an elevated PowerShell window under another administrator account can cause source and package registration problems because WinGet still depends on the interactive user's App Installer and source data. The same command may therefore work manually for one account and fail through a deployment agent.
This error is often related to the Microsoft.DesktopAppInstaller package rather than the application being installed. Deploy App Installer as a system-scoped application through device management, then invoke WinGet using its full path instead of relying on PATH or the user alias. The executable is normally under `C:Program FilesWindowsAppsMicrosoft.DesktopAppInstaller_*winget.exe`. This combination has made both user-scope and system-scope deployments much more reliable.
Updating App Installer through the Microsoft Store has fixed this error on some machines. Open the Store's downloads and updates page, check for an App Installer update, and retry the source operation afterward. For a larger environment, package the current App Installer bundle and deploy it centrally rather than relying on each user's Store session.
Changing the source from `winget` to `msstore` is unlikely to solve the underlying problem. If the source metadata or App Installer registration is missing, both manual and scripted commands can fail until App Installer is repaired or updated.
That also avoids cases where the script runs under a different account and resolves the wrong WinGet executable. Make sure the App Installer version is current on the affected machines.