Repair-WingetPackageManager not working as expected in system context

[th3nme]

Repair-WingetPackageManager not working as expected in system context

[denelon]

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

[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]

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?