winget-cli: Doesn't run under WinRM
Brief description of your issue
WinGet can’t be run on a WinRM session. The UWP magic doesn’t seem to understand such a setup and so there are various problems:
- The
wingetcommand can’t be found, despite the WindowsApps directory being in $PATH; - Access is denied (“The system cannot execute the specified program.”) when providing a full path to the executable.
I’m working on a Chef cookbook which adds WinGet as a custom resource (so it can install packages) but at present this can’t be smoothly tested because the call to the winget executable always fails.
Steps to reproduce
- Use
Enter-PSSession,vagrant powershellor the like to open a remote PowerShell session to a host with WinGet installed. - Try to run WinGet.
Expected behavior
- WinGet prints its help output as it does when run in a local terminal
Actual behavior
Typical example output on an interactive session on a local Windows VM created by Vagrant:
[127.0.0.1]: PS C:\Users\vagrant\Documents> winget
Program 'winget.exe' failed to run: A specified logon session does not exist. It may already have been terminated.
+ CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException
+ FullyQualifiedErrorId : NativeCommandFailed
[127.0.0.1]: PS C:\Users\vagrant\Documents> cd $Env:LOCALAPPDATA/Microsoft/WindowsApps
[127.0.0.1]: PS C:\Users\vagrant\AppData\Local\Microsoft\WindowsApps> ls
Directory: C:\Users\vagrant\AppData\Local\Microsoft\WindowsApps
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 20/05/2020 22:57 Backup
d----- 20/05/2020 22:57 Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
d----- 06/02/2020 20:09 Microsoft.MicrosoftEdge_8wekyb3d8bbwe
d----- 20/05/2020 18:10 Microsoft.XboxGamingOverlay_8wekyb3d8bbwe
-a---l 20/05/2020 18:10 0 GameBarElevatedFT_Alias.exe
-a---l 06/02/2020 20:09 0 MicrosoftEdge.exe
-a---l 20/05/2020 22:57 0 python.exe
-a---l 20/05/2020 22:57 0 python3.exe
-a---l 20/05/2020 22:57 0 winget.exe
[127.0.0.1]: PS C:\Users\vagrant\AppData\Local\Microsoft\WindowsApps> .\winget.exe
Program 'winget.exe' failed to run: A specified logon session does not exist. It may already have been terminated.
+ CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException
+ FullyQualifiedErrorId : NativeCommandFailed
[127.0.0.1]: PS C:\Users\vagrant\AppData\Local\Microsoft\WindowsApps>
Environment
Windows Package Manager v0.1.41331 Preview
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.18363.836
Package: Microsoft.DesktopAppInstaller v1.0.41331.0
Links:
Privacy Statement: https://aka.ms/winget-privacy
License agreement: https://aka.ms/winget-license
3rd Party Notices: https://aka.ms/winget-3rdPartyNotice
Homepage: https://aka.ms/winget
Any other software?
- WinRM
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 51
- Comments: 32 (1 by maintainers)
This is a really important one to the community that does Windows automation. Not having remote command execution over WinRM will turn away the PowerShell community and they would actively discourage it’s use. Windows Updates has a similar issue and the workarounds to their issue is really ugly. It’s not something we want to deal with again.
For all the others that are stumbling over this after finding out, that WinGet does not work with HashiCorp Packer / WinRM and can’t be automated (duh, of course…). I tinkered a little working PowerShell script that with the current latest version of WinGet takes every appx dependency and throws all the files into one folder together.
At this point I restart the VM. You could theoretically also just restart the shell, but this way it works afterwards.
Disclaimer: I hope I am able to help others. I know this is all hacky and not the right way to do this. I want this to just work, nothing more. Thanks to @David-Ollivier who gave me the hints in the right direction. Some codelines have been taken from your example.
What an utter disappointment; going through all kinds of hoops to get
wingetto run on Server2019, only to find out that it doesn’t even run in a WinRM session. How does Microsoft envision using this tool? Log in manually on a packer-provisioned VM to install software?!Oh absolutely. For as much as I am pushing for solid integration with PowerShell #221, if you have to choose between that and remote execution, it has to be remote execution. We deal with enough apps that don’t have good PowerShell options that we can mitigate that pain if we have to. But not having execution work over WinRM is much much worse.
From my experience of helping people hack around that limitation for another Windows feature, I can tell you that support requests related to this will be endless. Not only to the community, but also to your team.
This is still an issue and should be a higher priority. Failure to run over a WSMan remoting session is a huge problem.
Do you guys do anything other than whine? If its “not ready”, just…wait until its “ready”. As you have said multiple times, its not like its the only option.
I was wondering if it would run under WinRM. I was thinking about using Ansible with WinRM to use winget…
It is bad enough that the feature has no Powershell Powershell cmdlets, but not working over remoting?
Package management without remoting just makes this toil even less useful.
for those who are not aware. it CAN be run under winrm but the install process is very different: https://github.com/microsoft/winget-cli/issues/256#issuecomment-1416929101
Windows server core is a supported edtion of windows server and has been for many years.
It’s supposed to be managed remotely by console so it’s a very resonable expectation that you can manage it with WinRM and/or SSH.
Winget is (or rather should be) a console package manager. Is a package manager a tool you use to manage your servers ? Yes it is and therefore it is also a very resonable expectation that you can use the MS provided console package manager to manage your server over a remote console and not by loging in to a stripped down GUI
We have been “waiting” for almost four years for this. Something that should have worked from the first release.
You realise that they are very likely entirely separate teams, right? Microsoft isn’t just one big team of people who magically know what and how everything else is going on
We are using it as part of a packer setup for a year now and its been stable. we do use winrm to update winrm as another step after setting it up
I will pretty sure test and validate, but I wouldn’t call this ‘installing’ … it looks more like an adventure
The reality is that this tool was written for devs by devs to make it easier to install their tools. But system admins got all excited expecting this to fill the same package management gap for them, but they have been greatly disappointed because their use cases were never considered and still haven’t been addressed.
I immediately knew this would be a big issue as Microsoft has made this mistake before. I opened this ticket in hopes that they would fix it before release as it would be a barrier to adoption for systems administrators.
Chocolatey is more mature, works well, and even has decent cmdlets. Use it vs a 2nd rate beta power toy!
And this fails using PSExec with an error that the file can’t be found. Even when using the full path winget.exe.
This also fails in an SSH session.
The system cannot execute the specified program.This is a huge blocker.
Does it run over ssh? Even if it does, WinRM needs to work flawlessly too. Not every windows tool can utilize ssh for remoting yet.
EDIT: I know it’s been a while but today I was able to test winget over ssh - it does not work. In cmd the error message is
The system cannot execute the specified program.and in PowerShell it’sProgram 'winget.exe' failed to run: The file cannot be accessed by the system.When I run
Get-Command wingetit tells me the executable isC:\Users\MY_USER\AppData\Local\Microsoft\WindowsApps\winget.exeand winget is installed and working for that exact same useraccount when I login via RDP.