Repository navigation
Doesn't run under WinRM #256
Description
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
Activity
Unify copyrights, tidy for first release
KevinMarquette commentedon May 21, 2020
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.
jantari commentedon May 21, 2020
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.doctordns commentedon May 22, 2020
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.
minusdavid commentedon May 22, 2020
I was wondering if it would run under WinRM. I was thinking about using Ansible with WinRM to use winget...
KevinMarquette commentedon May 22, 2020
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.
rasq commentedon May 26, 2021
OMG, i see thats a next to msix packaging tool software that cannot work from winrm.
At last there is a choco but this schould be fixed a months ago.
jdhitsolutions commentedon Jun 24, 2021
This is still an issue and should be a higher priority. Failure to run over a WSMan remoting session is a huge problem.
jdhitsolutions commentedon Jun 24, 2021
This also fails in an SSH session.
The system cannot execute the specified program.jdhitsolutions commentedon Jun 24, 2021
And this fails using PSExec with an error that the file can't be found. Even when using the full path winget.exe.
djpbessems commentedon Jul 5, 2021
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?!
David-Ollivier commentedon Feb 1, 2022
13 remaining items
matsmcp commentedon Apr 24, 2024
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.
KevinMarquette commentedon Apr 24, 2024
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.
ITJamie commentedon Apr 24, 2024
for those who are not aware. it CAN be run under winrm but the install process is very different:
#256 (comment)
chwilfing commentedon Apr 24, 2024
I will pretty sure test and validate, but I wouldn't call this 'installing' .. it looks more like an adventure
ITJamie commentedon Apr 24, 2024
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
chwilfing commentedon Apr 25, 2024
You're my men! this works perfectly and will use as long as Microsoft is not able to fix this behaviour.
matsmcp commentedon Apr 25, 2024
Goes even further to prove that MS can solve the issue very quickly - it's only the will that is missing.
Would I use this "fix" it for 5000 production servers - maybe not without it being a little better supported ....
however for lab use - H*ll yes. I just verified that it works over SSH too.
jbne commentedon Aug 12, 2024
This workaround works when installing packages from the Winget source, but it does not work when installing from manifest files. Has anyone had any success installing a package using
winget install --manifest?bedalus commentedon Feb 16, 2025
For people who want to use WinGet with Hashicorp Packer, or Azure Image Builder, the solution above still works: https://github.com/microsoft/winget-cli/issues/256#issuecomment-1416929101
The UI.Xaml component https://www.nuget.org/packages/Microsoft.UI.Xaml#readme-body-tab 2.8.7 is more recent. I swapped this in and it worked fine.
For Azure, the BICEP customizer step is:
... customize: [ { type: 'PowerShell' name: 'WinGet workaround for Packer build' runElevated: true inline: [ 'Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072' 'Write-Output "Downloading WinGet and dependencies..."' 'New-Item -Path "$ENV:USERPROFILE" -Name "build" -ItemType "directory" -Force | Out-Null' 'Invoke-WebRequest "https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx" -OutFile "$ENV:USERPROFILE/build/Microsoft.VCLibs.x64.14.Desktop.zip" -UseBasicParsing' 'Expand-Archive -Path "$ENV:USERPROFILE/build/Microsoft.VCLibs.x64.14.Desktop.zip" -DestinationPath "$ENV:USERPROFILE/build/WinGet" -Force' 'Invoke-WebRequest "https://www.nuget.org/api/v2/package/Microsoft.UI.Xaml/2.8.7" -OutFile "$ENV:USERPROFILE/build/Microsoft.UI.Xaml.zip" -UseBasicParsing' 'Expand-Archive -Path "$ENV:USERPROFILE/build/Microsoft.UI.Xaml.zip" -DestinationPath "$ENV:USERPROFILE/build/Microsoft.UI.Xaml"' 'Rename-Item -Path "$ENV:USERPROFILE/build/Microsoft.UI.Xaml/tools/AppX/x64/Release/Microsoft.UI.Xaml.2.8.appx" -NewName "Microsoft.UI.Xaml.2.8.zip"' 'Expand-Archive -Path "$ENV:USERPROFILE/build/Microsoft.UI.Xaml/tools/AppX/x64/Release/Microsoft.UI.Xaml.2.8.zip" -DestinationPath "$ENV:USERPROFILE/build/WinGet" -Force' '$WinGetUrl = ((Invoke-RestMethod -uri "https://api.github.com/repos/microsoft/winget-cli/releases/latest").assets | Where { $_.browser_download_url.EndsWith("msixbundle") } | Select -First 1).browser_download_url' 'Invoke-WebRequest $WinGetUrl -OutFile "$ENV:USERPROFILE/build/Microsoft.DesktopAppInstaller.zip" -UseBasicParsing' 'Expand-Archive -Path "$ENV:USERPROFILE/build/Microsoft.DesktopAppInstaller.zip" -DestinationPath "$ENV:USERPROFILE/build/Microsoft.DesktopAppInstaller"' 'Rename-Item -Path "$ENV:USERPROFILE/build/Microsoft.DesktopAppInstaller/AppInstaller_x64.msix" -NewName "AppInstaller_x64.zip"' 'Expand-Archive -Path "$ENV:USERPROFILE/build/Microsoft.DesktopAppInstaller/AppInstaller_x64.zip" -DestinationPath "$ENV:USERPROFILE/build/WinGet" -Force' 'Move-Item -Path "$ENV:USERPROFILE/build/WinGet" -Destination "$ENV:PROGRAMFILES" -PassThru' 'cmd /c setx /M PATH "%PATH%;$ENV:PROGRAMFILES\\WinGet"' ] } ...bedalus commentedon Feb 20, 2025
Ok, here's a simpler way for Packer, compared to the workaround in my comment above:
... customize: [ { type: 'PowerShell' name: 'WinGet registration' runElevated: true inline: [ 'Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe' '$ProgressPreference = "SilentlyContinue"' 'Add-AppxPackage -Path "https://cdn.winget.microsoft.com/cache/source.msix" -ForceApplicationShutdown -ForceUpdateFromAnyVersion' ] } { type: 'PowerShell' name: 'WinGet commandline examples' runElevated: true inline: [ // Examples 'winget source update' 'winget list --accept-source-agreements' 'winget --info' 'winget install -e --accept-package-agreements --accept-source-agreements --scope machine --silent --force Microsoft.AzureCLI' ...Do what you need, then before SysPrep, assuming you're generalizing to OOBE,
you need to do this first:Read the UPDATE section below first
... { type: 'PowerShell' name: 'Run before SysPrep' runElevated: true inline: [ 'Get-AppxPackage -Name Microsoft.Winget.Source | Remove-AppxPackage' 'Get-AppxPackage -Name Microsoft.DesktopAppInstaller | Remove-AppxPackage' ] } ...The first section registers the DesktopAppInstaller app to the Packer identity that's remoted into the machine. I guess because it hasn't gone through the regular sign-in process, apps don't automatically get registered.
The soure file is required too. I don't know why, but you cannot refresh the catalogue metadata (i.e. winget source update) without first manually obtaining this source.msix file.
I then move to a new customizer section (commandline examples). This is so Packer gets a fresh powershell session with the corrected environment. WinGet commands now work!
Finally, I need to remove the source and the AppInstaller packages which are local to Packer. I'm actually not 100% certain this is required, because SysPrep should remove them. However, it got stuck, and this solved method it for me.
UPDATE
Before sysprep I now inject this at the top of the deprovisioning script (or you could replace the final customizer step and do it inline if you prefer):
This gets rid of all appx packages provisioned to the Packer identity, so you can use this to completely replace the second BICEP section above. This is required before sysprep, or else sysprep fails. It's not just because of the WinGet source or the DesktopAppInstaller, it could be other things you've installed, e.g. Notepad++ etc...
ITJamie commentedon Jun 6, 2025
what are the current steps to setup winget via winrm then currently?
is it only from a specific version of windows iso's?
denelon commentedon Jul 28, 2025
I'd suggest using the
Repair-WinGetPackageManagercmdlet from the Microsoft.WinGet.Client PowerShell module to ensure the latest stable version of WinGet is on the remote system.Given the API has been made public, and this issue should be resolved I'm going to go ahead and close this Issue.