Doesn't run under WinRM

[thumperward]

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 winget command 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

1. Use Enter-PSSession, vagrant powershell or the like to open a remote PowerShell session to a host with WinGet installed.
2. 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

[KevinMarquette]

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]

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's Program 'winget.exe' failed to run: The file cannot be accessed by the system.

When I run Get-Command winget it tells me the executable is C:\Users\MY_USER\AppData\Local\Microsoft\WindowsApps\winget.exe and winget is installed and working for that exact same useraccount when I login via RDP.

[doctordns]

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]

I was wondering if it would run under WinRM. I was thinking about using Ansible with WinRM to use winget...

[KevinMarquette]

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.

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]

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]

This is still an issue and should be a higher priority. Failure to run over a WSMan remoting session is a huge problem.

[jdhitsolutions]

This also fails in an SSH session. The system cannot execute the specified program.

[jdhitsolutions]

And this fails using PSExec with an error that the file can't be found. Even when using the full path winget.exe.

[djpbessems]

What an utter disappointment; going through all kinds of hoops to get winget to 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]

# Install 7-Zip
mkdir c:\temp
$7zipUrl = "https://www.7-zip.org/a/7z2107-x64.exe"
$7zipPath = "c:\temp\7z2107-x64.exe"
$client = New-Object System.Net.WebClient
$client.DownloadFile($7zipUrl, $7zipPath)
cmd /c "start /wait $7zipPath /S"

# Install Winget
$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
$WinGetPath = "c:\temp\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"
$client = New-Object System.Net.WebClient
$client.DownloadFile($WinGetUrl, $WinGetPath)
mkdir 'C:\Program Files\Winget'
& 'C:\Program Files\7-Zip\7z.exe' x $WinGetPath -o'c:\temp\winget'
& 'C:\Program Files\7-Zip\7z.exe' x "C:\temp\winget\AppInstaller_x64.msix" -o'C:\Program Files\Winget' -y
Set-Alias -Name 'winget' -Value "C:\Program Files\Winget\AppInstallerCLI.exe"

[ghost]

@David-Ollivier

you are basically bypassing AEAs(App Execution Aliases) of MSIX packages..

Although this should work, AEAs of MSIX packages will work after WinRM/SSH/Docker client programs learn to handle them. see https://github.com/microsoft/winget-cli/issues/1474#issuecomment-1011330720 and https://github.com/microsoft/winget-cli/discussions/1838#discussioncomment-1950473

[brettjacobson]

This problem kind of hearkens back to their decision to implement winget in C++ "because PowerShell was not implemented on all the systems they wanted to support." Which basically means they didn't care about automation at all, and this brokenness that this issue represents just shows the team that invented winget did NOT care about automation, which means PowerShell and WinRM, at least in my opinion.

[Masamune3210]

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

[melvinquick]

Has there been any update to this? Still not working via WinRM, so you can't do an Enter-PSSession and use it, you can't use Invoke-Command, and you can't use PSExec. I'd love to use this in an enterprise environment, but without being able to automate it, I'm at a loss.

[David-Ollivier]

Has there been any update to this? Still not working via WinRM, so you can't do an Enter-PSSession and use it, you can't use Invoke-Command, and you can't use PSExec. I'd love to use this in an enterprise environment, but without being able to automate it, I'm at a loss.

I personally use an old version and extract it with my script above. Still working for the moment ;)

[denelon]

We are working on a solution for enterprise scenarios. Intune and other MDM providers will be able to execute commands remotely using system context:

• 215

This same solution will also be part of the work for having native PowerShell support:

• 221

[raboni84]

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.

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.7.1" -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.7.appx" -NewName "Microsoft.UI.Xaml.2.7.zip"
Expand-Archive -Path "$ENV:USERPROFILE/build/Microsoft.UI.Xaml/tools/AppX/x64/Release/Microsoft.UI.Xaml.2.7.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"

At this point I restart the VM. You could theoretically also just restart the shell, but this way it works afterwards.

Write-Output "Installing 7zip"
winget install 7zip.7zip --accept-package-agreements --accept-source-agreements

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.

[piotrminkina]

Same problem with version v1.6.3133. It seems that winget does not handle the situation when a non-interactive session is active.

> qwinsta
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE                                              
>services                                    0  Disc                                                                    
 console           Piotrek                   2  Active                                                                  
 rdp-tcp                                 65536  Listen  

I'm trying to uninstall an unnecessary package:

> winget.exe uninstall --disable-interactivity --accept-source-agreements --exact --silent --force --scope=user "Microsoft Teams"
[...]
Found Microsoft Teams [MicrosoftTeams_8wekyb3d8bbwe]                                                                    
Starting package uninstall...                                                                                                                                                                                                                    

 â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’  0%                        
Uninstall failed with exit code: 0x80070520 : unknown error

The winget logs then shows:

[...]
2023-11-28 23:53:39.604 [CORE] Deployment operation #2: A specified logon session does not exist. It may already have been terminated.

2023-11-28 23:53:39.604 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFA312F0840: (caller: 00007FFA312F1E4C) Exception(3) tid(87cc) 80070520 A specified logon session does not exist. It may already have been terminated.

    Msg:[Operation failed: A specified logon session does not exist. It may already have been terminated.

]

2023-11-28 23:53:39.605 [CLI ] MSIXUninstall uninstaller failed: 2147943712
2023-11-28 23:53:39.605 [CLI ] Terminating context: 0x80070520 at C:\__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\UninstallFlow.cpp:16a

[chwilfing]

Just playing around with an Azure Image Builder for Azure AVD Deployment and the same problem just cost me 2 days of playing around and realizing, .. It's just not working. How does microsoft believe that we replace a community driven chocolatey with this half baked (not) solution?

[doctordns]

Chocolatey is more mature, works well, and even has decent cmdlets. Use it vs a 2nd rate beta power toy!

[David-Ollivier]

Just playing around with an Azure Image Builder for Azure AVD Deployment and the same problem just cost me 2 days of playing around and realizing, .. It's just not working. How does microsoft believe that we replace a community driven chocolatey with this half baked (not) solution?

Another way to get the installer would be to scrap the Winget repos and get the link from the yaml file. Take care, their is a 'Beta' folder sometimes.

Good luck

[Masamune3210]

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.

[chwilfing]

Is this really your believe? we could just stop 'whining' and wait whatever "god" microsoft is creating for us. In the meantime - NOBODY will use it and these tools will die (because nobody showed interest).

Feedback and even if it's 'whining' shows interest, it shows what features are most used, most requested and probably, just probably, somebody at microsoft will hear us whining to fix the issues with a thousend upvotes more than the one some product manager believed would be a good idea. (which it is usually not!)

[chwilfing]

Just playing around with an Azure Image Builder for Azure AVD Deployment and the same problem just cost me 2 days of playing around and realizing, .. It's just not working. How does microsoft believe that we replace a community driven chocolatey with this half baked (not) solution?

Another way to get the installer would be to scrap the Winget repos and get the link from the yaml file. Take care, their is a 'Beta' folder sometimes.

Good luck

Getting the installer doesn't seem to be the problem, running winget through WinRM remoting is just not working (as described in this thread). So installing the current version with the Sandbox Script does work and shows the correct version afterwards, but calling winget to install packages just drops out with error messages and doesn't work at all.

[matsmcp]

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.

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]

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]

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

[chwilfing]

for those who are not aware. it CAN be run under winrm but the install process is very different: #256 (comment)

I will pretty sure test and validate, but I wouldn't call this 'installing' .. it looks more like an adventure

[ITJamie]

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]

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

You're my men! this works perfectly and will use as long as Microsoft is not able to fix this behaviour.

[matsmcp]

for those who are not aware. it CAN be run under winrm but the install process is very different: #256 (comment)

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]

https://github.com/microsoft/winget-cli/issues/256#issuecomment-1416929101

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?