Open th3nme opened 3 months ago
Hi I'm an AI powered bot that finds similar issues based off the issue title.
Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!
Note: You can give me feedback by thumbs upping or thumbs downing this comment.
I can reproduce this on several machines that are currently on 1.5 or 1.6 and not updating to 1.7
I've also verified the same behaviour on a machine with a very old DesktopAppInstaller that didn't even include winget and it reports that winget is healthy when it's not even present.
Which version of the Microsoft.WinGet.Client module is being used, and is there any chance older versions of that module are in the module path?
$env:PSModulePath -split ';'
C:\Users\Administrator\Documents\WindowsPowerShell\Modules C:\Program Files\WindowsPowerShell\Modules C:\Windows\system32\WindowsPowerShell\v1.0\Modules
Hi @denelon ,
Every time I run it on a new machine I am using this to pull the latest:
Install-PackageProvider NuGet -Force Set-PSRepository PSGallery -InstallationPolicy Trusted Install-Module Microsoft.Winget.Client -Confirm:$False -Force -AllowClobber Import-Module -Name Microsoft.Winget.Client Repair-WingetPackageManager -Force -Latest -Verbose
If you run Get-Command -Module Microsoft.WinGet.Client
what version of the module is reported?
PS C:\WINDOWS\system32> Get-Command -Module Microsoft.WinGet.Client
CommandType Name Version Source
Cmdlet Add-WinGetSource 1.7.10661 Microsoft.Winget.Client Cmdlet Assert-WinGetPackageManager 1.7.10661 Microsoft.Winget.Client Cmdlet Disable-WinGetSetting 1.7.10661 Microsoft.Winget.Client Cmdlet Enable-WinGetSetting 1.7.10661 Microsoft.Winget.Client Cmdlet Export-WinGetPackage 1.7.10661 Microsoft.Winget.Client Cmdlet Find-WinGetPackage 1.7.10661 Microsoft.Winget.Client Cmdlet Get-WinGetPackage 1.7.10661 Microsoft.Winget.Client Cmdlet Get-WinGetSettings 1.7.10661 Microsoft.Winget.Client Cmdlet Get-WinGetSource 1.7.10661 Microsoft.Winget.Client Cmdlet Get-WinGetUserSettings 1.7.10661 Microsoft.Winget.Client Cmdlet Get-WinGetVersion 1.7.10661 Microsoft.Winget.Client Cmdlet Install-WinGetPackage 1.7.10661 Microsoft.Winget.Client Cmdlet Remove-WinGetSource 1.7.10661 Microsoft.Winget.Client Cmdlet Repair-WinGetPackageManager 1.7.10661 Microsoft.Winget.Client Cmdlet Reset-WinGetSource 1.7.10661 Microsoft.Winget.Client Cmdlet Set-WinGetUserSettings 1.7.10661 Microsoft.Winget.Client Cmdlet Test-WinGetUserSettings 1.7.10661 Microsoft.Winget.Client Cmdlet Uninstall-WinGetPackage 1.7.10661 Microsoft.Winget.Client Cmdlet Update-WinGetPackage 1.7.10661 Microsoft.Winget.Client
PS C:\Users\nephraim> winget --info Windows Package Manager v1.5.2201 Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19045.4046 System Architecture: X64 Package: Microsoft.DesktopAppInstaller v1.20.2201.0
Logs %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag… User Settings %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett… Portable Links Directory (User) %LOCALAPPDATA%\Microsoft\WinGet\Links Portable Links Directory (Machine) C:\Program Files\WinGet\Links Portable Package Root (User) %LOCALAPPDATA%\Microsoft\WinGet\Packages Portable Package Root C:\Program Files\WinGet\Packages Portable Package Root (x86) C:\Program Files (x86)\WinGet\Packages
Privacy Statement https://aka.ms/winget-privacy License Agreement https://aka.ms/winget-license Third Party Notices https://aka.ms/winget-3rdPartyNotice Homepage https://aka.ms/winget Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale
LocalManifestFiles Disabled BypassCertificatePinningForMicrosoftStore Disabled InstallerHashOverride Disabled LocalArchiveMalwareScanOverride Disabled
PS C:\WINDOWS\system32> Repair-WingetPackageManager -Force -Latest -Verbose VERBOSE: Creating MTA thread VERBOSE: WinGet is in a good state. PS C:\WINDOWS\system32>
$env:PSModulePath -split ';'
C:\Users\Administrator\Documents\WindowsPowerShell\Modules C:\Program Files\WindowsPowerShell\Modules C:\Windows\system32\WindowsPowerShell\v1.0\Modules
PS C:\WINDOWS\system32> $env:PSModulePath -split ';' C:\WINDOWS\system32\config\systemprofile\Documents\WindowsPowerShell\Modules C:\Program Files\WindowsPowerShell\Modules C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules C:\Program Files (x86)\Sharegate\ C:\Program Files\MicrosoftManagedDesktop\Powershell C:\Program Files\Citrix\Telemetry Service\ PS C:\WINDOWS\system32>
OK. I believe I've got a clean repro.
I'm building a set of WinGet Configurations and PowerShell scripts to demonstrate the various approaches to bootstrapping WinGet and running WinGet in the system context. There are several scenarios that do not work and a few that do. This is due to the differences between packaged and unpackaged applications as well as the differences between WinGet CLI and the PowerShell modules. Differences between Windows PowerShell and PowerShell 7 also affect the outcome.
The Repair-WinGetPackageManager was designed to bootstrap the WinGet CLI for a logged-on user (not necessarily the system context).
These will all be made available, and they will need a SKU of Windows with the Windows Sandbox enabled.
My use case is installing / repairing Winget via an Intune script. Currently there isn't a good way to ensure the Desktop App Installer is getting updated properly so I have a wide range of Winget versions in my environment and the main issue I have encountered is the --installer-type option not being supported in old versions, so I am seeing a lot of deployment failures purely because of the Winget version spread on my devices.
I have tried a couple of ways to invoke a store apps update but that is also inconsistent.
The following PowerShell command will "stage" the App Installer when run in the system context (assuming the MSIX packages are available on the system).
This also assumes WinGet 1.7 is the desired version with the dependencies on VCLibs and UI.Xaml.
Add-AppxProvisionedPackage -Online -PackagePath "C:\Sandbox\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" -SkipLicense -DependencyPackagePath ("C:\Sandbox\Microsoft.VCLibs.x64.14.00.Desktop.appx", "C:\Sandbox\Microsoft.UI.Xaml.2.8.x64.appx")
I've been working on a Windows Sandbox configuration to use as an example to show this working under nt authority/system, but in Windows Sandbox the WDAGUtilityAccount is also logged in so the package is actually "registered" for the currently logged in user.
I've been testing this out too and getting the same result regardless of SYSTEM or USER:
User:
Winget Version installed is 1.2.10691
@PckgrTom if you add "-Force -Latest" it should upgrade to the latest stable version. Without those arguments/parameters, the cmdlet is just making sure the current version installed is in a good state. Can you do this and add the "Get-WinGetVersion" output to the statements afterwards?
Which version of the Microsoft.WinGet.Client PowerShell module is present on these systems?
Brief description of your issue
Running "Repair-WingetPackageManager -Force -Latest" in the system context reports back that Winget is in a good state even though it is not up to date or in some instances, working at all. This is important as Intune and SCCM etc. run scripts in the system context not elevated admin. If I run the same command as admin it repairs / updates Winget as expected.
Steps to reproduce
.\PsExec.exe -i -s powershell Repair-WingetPackageManager -Force -Latest -Verbose
Expected behavior
Expect Winget to be repaired / updated from v1.6.3133 to latest
Actual behavior
VERBOSE: Creating MTA thread VERBOSE: WinGet is in a good state.
Environment