Repair-WingetPackageManager not working as expected in system context

[th3nme]

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

Windows Package Manager v1.6.3133
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.4046
System Architecture: X64

Winget Directories
------------------------------------------------------------------------------------------------------
Logs                               %TEMP%\WinGet\defaultState
User Settings                      %LOCALAPPDATA%\Microsoft\WinGet\Settings\defaultState\settings.json
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
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
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

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled

[github-actions]

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!

Open similar issues:

• Repair-WinGetPackageManager failing due to dependencies (#4228), similarity score: 0.88
• Repair-WingetPackageManager deployment operations not marked as complete (#4116), similarity score: 0.79

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[th3nme]

I can reproduce this on several machines that are currently on 1.5 or 1.6 and not updating to 1.7

[th3nme]

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.

[denelon]

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?

[denelon]

$env:PSModulePath -split ';'

C:\Users\Administrator\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\Windows\system32\WindowsPowerShell\v1.0\Modules

[th3nme]

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

[denelon]

If you run Get-Command -Module Microsoft.WinGet.Client what version of the module is reported?

[th3nme]

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

[th3nme]

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

Winget Directories

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

Links

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

Admin Setting State

LocalManifestFiles Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride Disabled
LocalArchiveMalwareScanOverride Disabled

[th3nme]

PS C:\WINDOWS\system32> Repair-WingetPackageManager -Force -Latest -Verbose
VERBOSE: Creating MTA thread
VERBOSE: WinGet is in a good state.
PS C:\WINDOWS\system32>

[th3nme]

$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>

[denelon]

OK. I believe I've got a clean repro.

[denelon]

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.

[th3nme]

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.

[denelon]

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.

[PckgrTom]

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

[denelon]

@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?