Winget fails to open source package in elevated session using admin account that cannot log on locally

[KirkMunro]

Brief description of your issue

I'm trying to setup winget on a new laptop, but I'm running into the following error:

Failed to open the source; try the 'source reset' command if the problem persists.
An unexpected error occurred while executing the command:
0x8a15000f : Data required by the source is missing

Steps to reproduce

My laptop was installed by the corporation with Windows 10 Enterprise. My account does not have local admin rights, but I also have an admin account that I can use for elevation. The admin account does not have the right to log on locally -- it is only for elevation purposes.

To install winget, I have to sideload it because I do not have access to the store. I signed up my account for the preview flight ring for the app installer, downloaded the appxbundle for the latest winget package, and then set it up by doing the following in PowerShell:

# From an elevated PowerShell session (my local admin account):
Add-AppxProvisionedPackage ./Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.appxbundle
Add-AppxPackage ./Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.appxbundle

# From a non-admin PowerShell session (my login account):
Add-AppxPackage ./Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.appxbundle

Once this is set up, from my login account in a non-elevated PowerShell session I can use winget as expected; however, if I am in an elevated session using my admin account, winget always returns the error shown above.

I have reset the source as the error recommends, but the problem persists.

I have also used Get-AppxPackage to see what packages are installed for each of the two accounts. I can see a Microsoft.Winget.Source package for the logon user account, but not for the admin account. I presume that is the crux of the problem -- that the elevation account does not have a Microsof.Winget.Source package, and that winget cannot work without it.

Please advise how I can get this set up properly in my work environment.

Expected behavior

winget should work properly in both my login account as well as in an elevated session that leverages my admin account.

Actual behavior

winget only works properly in my login account.

Environment

[winget --info]
Windows Package Manager v0.2.3162 Preview
Windows: Windows.Desktop v10.0.18363.1256 (version 1909)
Package: Microsoft.DesktopAppInstaller v1.11.3162.0

[denelon]

That's an interesting scenario. We will have to look into the problem to see if there is a fix or a workaround.

[KirkMunro]

I seem to have found a workaround for this, by reading through this related discussion about Windows Terminal (which also has challenges as a UWP app and run as admin in this scenario).

By running the following command in an elevated Windows PowerShell session, I am able to get the source package registered for the admin user account that cannot log on locally:

Add-AppxPackage -Register 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2021.112.1815.519_neutral_8wekyb3d8bbwe\AppManifest.xml' -DisableDevelopmentMode

Once that command completed, I was able to see the Winget source appx package in the list of packages for the elevation account, and I was also able to use winget search ..., winget install ..., etc. That doesn't solve my problem with Windows Terminal that is identified in the other thread, but it does allow me to use winget elevated, so as a workaround it seems solid.

The workaround shouldn't be necessary for a Windows package management tool though. On the Terminal thread, that team identified the benefits they were getting from distribution as a UWP packaged app. Are you realizing the same benefits to the point that you feel UWP and distribution via the store is the best vehicle for winget? Or would it be worth considering other distribution mechanisms for winget to allow it to be used more easily for all users?

[KirkMunro]

I should note that even with this workaround you cannot install certain products using winget. For example, in an elevated session, if you invoke winget install Microsoft.Terminal when working in a scenario like the one I highlighted at the top of this post, that installation will fail because the elevated user account is not logged in, and Microsoft.Terminal is a modern app that requires the user to be logged in to properly install it for that user.

[thespad]

I've tried this workaround but I still can't get winget working in a runas/elevate as another account scenario.

[Xenixium]

I have the same issue and found a workaround.

For my case, I have the issue when I run winget with a command prompt with elevated privileges with another user who is an administrator account (the account with which I logged in is not an administrator).

To work around the issue I opened the session of the same administrator account and I used winget which worked correctly, after that I tried the scenario described above and it works, but it is likely that it is only temporary .

Hope this helps you to find a solution to this issue.

[clownwilleatme]

I am also facing this issue when trying to deploy the latest stable version of winget (1.2.10271.0) onto an Azure VM using a PowerShell custom script extension. The Azure custom script extension runs under the context of the local system user which cannot install AppX packages. To work around this I am trying to elevate to a domain admin user using PSExec, but at that point I run into the same issue described here.

Here is the relevant snippet from the winget verbose logs when running 'winget source update --verbose-logs':

2022-03-17 13:37:51.635 [REPO] Named source to be updated, found: winget
2022-03-17 13:37:54.042 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2022-03-17 13:37:54.043 [CORE] Downloading to path: C:\Users\ADMINI1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2022-03-17 13:37:54.044 [CORE] Started applying motw to C:\Users\ADMINI1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2022-03-17 13:37:54.065 [CORE] Finished applying motw
2022-03-17 13:37:54.065 [CORE] WinINet downloading from url: https://winget.azureedge.net/cache/source.msix
2022-03-17 13:37:54.397 [CORE] Download request status success.
2022-03-17 13:37:54.397 [CORE] Download size: 3363134
2022-03-17 13:37:55.491 [CORE] Download completed.
2022-03-17 13:37:55.492 [CORE] Starting AddPackage operation #0: file:///C:/Users/ADMINI~1/AppData/Local/Temp/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msix SkipSmartScreen: 1
2022-03-17 13:37:55.494 [CORE] Begin waiting for operation #0
2022-03-17 13:37:55.494 [CORE] Begin blocking for operation #0
2022-03-17 13:37:58.261 [CORE] Deployment operation #0: Deployment Add operation with target volume C: on Package Microsoft.Winget.Source_2022.317.115.719_neutral__8wekyb3d8bbwe from: failed with error 0x80073D19. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.
2022-03-17 13:37:58.261 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFBA5AE657A: (caller: 00007FFBA5AE6C09) Exception(1) tid(c9c) 80073D19 An error occurred because a user was logged off.
Msg:[Operation failed: Deployment Add operation with target volume C: on Package Microsoft.Winget.Source_2022.317.115.719_neutral__8wekyb3d8bbwe from: failed with error 0x80073D19. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.]

2022-03-17 13:37:58.273 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(53)\WindowsPackageManager.dll!00007FFBA5C402B1: (caller: 00007FFBA5B3BC7C) LogHr(1) tid(c9c) 80073D19 An error occurred because a user was logged off.
Msg:[D:\a_work\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFBA5AE657A: (caller: 00007FFBA5AE6C09) Exception(1) tid(c9c) 80073D19 An error occurred because a user was logged off.
Msg:[Operation failed: Deployment Add operation with target volume C: on Package Microsoft.Winget.Source_2022.317.115.719_neutral__8wekyb3d8bbwe from: failed with error 0x80073D19. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.]
]

2022-03-17 13:37:58.273 [REPO] Source add/update failed, waiting a bit and retrying: winget
2022-03-17 13:38:01.769 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2022-03-17 13:38:01.770 [CORE] Downloading to path: C:\Users\ADMINI1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2022-03-17 13:38:01.771 [CORE] Started applying motw to C:\Users\ADMINI1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2022-03-17 13:38:01.777 [CORE] Finished applying motw
2022-03-17 13:38:01.777 [CORE] WinINet downloading from url: https://winget.azureedge.net/cache/source.msix
2022-03-17 13:38:02.107 [CORE] Download request status success.
2022-03-17 13:38:02.107 [CORE] Download size: 3363134
2022-03-17 13:38:03.220 [CORE] Download completed.
2022-03-17 13:38:03.222 [CORE] Starting AddPackage operation #1: file:///C:/Users/ADMINI~1/AppData/Local/Temp/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msix SkipSmartScreen: 1
2022-03-17 13:38:03.222 [CORE] Begin waiting for operation #1
2022-03-17 13:38:03.222 [CORE] Begin blocking for operation #1
2022-03-17 13:38:04.112 [CORE] Successfully completed #1
2022-03-17 13:38:04.114 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(301)\WindowsPackageManager.dll!00007FFBA5B46181: (caller: 00007FFBA5B4502A) LogHr(2) tid(c9c) 80071130 Fast Cache data not found.

The key part of this issue is the error 80073D19 An error occurred because a user was logged off. which is preventing the Microsoft.Winget.Source package from being installed for the elevated admin user.

Overall, this seems like a pretty big limitation for winget as it cannot be automatically installed and used for software deployment in Azure VMs until this issue is resolved or winget is natively baked into the OS. Instead of using the custom script extension in Azure I guess winget could potentially be installed via DSC or some other manner, but that seems overly complex and to me feels like it defeats the simplicity that winget is meant to provide.

Any thoughts or potential workarounds would be appreciated.

[ol-audatis]

I have a similar issue. We are using a privileged AzureAD User (who has the role of Device Administrator) to run PowerShell with elevated rights.
I get the error:
Failed to open the source: winget
An unexpected error occurred while executing the command:
0x8a15000f : Data required by the source is missing

This is what the verbose log file look like:

2022-03-21 00:28:49.099 [CLI ] WinGet invoked with arguments: 'install' 'Notepad++.Notepad++' '--silent' '--accept-source-agreements' '--log' 'verbose'
2022-03-21 00:28:49.099 [CLI ] Found subcommand: install
2022-03-21 00:28:49.099 [CLI ] Leaf command to execute: root:install
2022-03-21 00:28:49.101 [CLI ] Executing command: install
2022-03-21 00:28:49.101 [REPO] GetCurrentSourceRefs: Source named 'microsoft.builtin.desktop.frameworks' from origin Default is hidden and is dropped.
2022-03-21 00:28:49.101 [REPO] Default source requested, multiple sources available, adding all to source references.
2022-03-21 00:28:49.101 [REPO] Adding to source references msstore
2022-03-21 00:28:49.101 [REPO] Adding to source references winget
2022-03-21 00:28:49.101 [REPO] Source past auto update time [5 mins]; it has been at least 9 mins
2022-03-21 00:28:49.102 [REPO] Source past auto update time [5 mins]; it has been at least 9 mins
2022-03-21 00:28:50.235 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2022-03-21 00:28:50.236 [CORE] Downloading to path: C:\Users\LOCALA\~1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2022-03-21 00:28:50.236 [CORE] Started applying motw to C:\Users\LOCALA\~1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2022-03-21 00:28:50.241 [CORE] Finished applying motw
2022-03-21 00:28:50.241 [CORE] WinINet downloading from url: https://winget.azureedge.net/cache/source.msix
2022-03-21 00:28:51.236 [CORE] Download completed.
2022-03-21 00:28:51.242 [CORE] Starting AddPackage operation #0: file:///C:/Users/LOCALA~1/AppData/Local/Temp/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msix SkipSmartScreen: 1
2022-03-21 00:28:51.245 [CORE] Begin waiting for operation #0
2022-03-21 00:28:51.245 [CORE] Begin blocking for operation #0
2022-03-21 00:28:51.395 [CORE] Successfully completed #0
-2022-03-21 00:28:51.396 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(301)\WindowsPackageManager.dll!00007FFE45230E91: (caller: 00007FFE4522FD3A) LogHr(1) tid(62bc) 80071130 Die Schnellcachedaten wurden nicht gefunden.

2022-03-21 00:28:51.403 [REPO] Multiple sources available, creating aggregated source.
2022-03-21 00:28:51.403 [REPO] Adding to aggregated source: msstore
2022-03-21 00:28:51.403 [REPO] Sending http GET request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/information
2022-03-21 00:28:51.840 [REPO] Response status: 200
2022-03-21 00:28:51.840 [REPO] Sending http GET request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/information
2022-03-21 00:28:51.904 [REPO] Response status: 200
2022-03-21 00:28:51.904 [REPO] Adding to aggregated source: winget
2022-03-21 00:28:51.907 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2022-03-21 00:28:51.907 [REPO] Package not found Microsoft.Winget.Source_8wekyb3d8bbwe
-2022-03-21 00:28:51.908 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(205)\WindowsPackageManager.dll!00007FFE452304A1: (caller: 00007FFE45225CAE) Exception(1) tid(62bc) 8A15000F 
-2022-03-21 00:28:51.908 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(540)\WindowsPackageManager.dll!00007FFE45332447: (caller: 00007FFE4512BA7D) LogHr(2) tid(62bc) 8A15000F     Msg:[D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(205)\WindowsPackageManager.dll!00007FFE452304A1: (caller: 00007FFE45225CAE) Exception(1) tid(62bc) 8A15000F ] 
-2022-03-21 00:28:51.908 [REPO] Failed to open available source: winget
2022-03-21 00:28:51.911 [REPO] Sending http POST request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/manifestSearch
2022-03-21 00:28:52.277 [REPO] Response status: 200
2022-03-21 00:28:52.283 [CLI ] Caught wil::ResultException: D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(205)\WindowsPackageManager.dll!00007FFE452304A1: (caller: 00007FFE45225CAE) Exception(1) tid(62bc) 8A15000F

WinGet-2022-03-21-00-28-49.091.log

[vandiere]

We used Privileged accounts to run Admin functions and my privileged account can not log in as a user. It's impossible to run the winget commands with this setup. My logged-in account has no admin rights to install apps and the admin account doesn't see the Winget executable when I use an elevated PS window. This is definitely an issue MS needs to resolve in order to make Winget function in a more secure scenario.

I have also used Get-AppxPackage to see what packages are installed for each of the two accounts. I can see a Microsoft.Winget.Source package for the logon user account, but not for the admin account. The elevation account does not have a Microsof.Winget.Source package, and that winget cannot work without it. My issue is just about the same as the OP.

[VAllens]

This is a serious problem that has not been solved yet!!!

[savaged]

I opened the session of the same administrator account and I used winget

It would be helpful to see how you "opened the session of the same administrator account and I used winget"