Repository navigation
Winget fails to open source package in elevated session using admin account that cannot log on locally #698
Description
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.appxbundleOnce 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
Activity
denelon commentedon Jan 12, 2021
That's an interesting scenario. We will have to look into the problem to see if there is a fix or a workaround.
KirkMunro commentedon Jan 12, 2021
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:
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 usewingetelevated, 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 forwingetto allow it to be used more easily for all users?KirkMunro commentedon Jan 12, 2021
I should note that even with this workaround you cannot install certain products using
winget. For example, in an elevated session, if you invokewinget install Microsoft.Terminalwhen 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 commentedon Feb 22, 2021
I've tried this workaround but I still can't get winget working in a runas/elevate as another account scenario.
Xenixium commentedon Jan 8, 2022
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 commentedon Mar 17, 2022
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\ADMINI
1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 32022-03-17 13:37:54.044 [CORE] Started applying motw to C:\Users\ADMINI
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\ADMINI
1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix1\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 32022-03-17 13:38:01.771 [CORE] Started applying motw to C:\Users\ADMINI
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 commentedon Mar 20, 2022
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:
WinGet-2022-03-21-00-28-49.091.log
vandiere commentedon Mar 29, 2022
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 commentedon Nov 5, 2022
This is a serious problem that has not been solved yet!!!
savaged commentedon Oct 20, 2023
It would be helpful to see how you "opened the session of the same administrator account and I used winget"
Corrige lo que falló en la prueba real, y agrega la marca del técnico