PowerShell Module Full Parity with WinGet CLI

Relevant area(s)

• PowerShell Module
• COM API

Description of the new feature / enhancement

The WinGet PowerShell module (Microsoft.WinGet.Client) should achieve full functional parity with the WinGet CLI. Today, several CLI capabilities have no PowerShell equivalent, blocking adoption by IT administrators and configuration-as-code workflows that rely exclusively on PowerShell (Intune, SCCM, Azure Automation, DSC).

Key gaps include:

• No PowerShell equivalent for \winget configure\ operations (test, validate, show)
• Missing cmdlets for pin management
• No cmdlet for \winget download\
• Missing \winget repair\ support in the module
• No PowerShell equivalent for \winget settings\ management
• Limited source management beyond basic add/remove

Enterprise automation operates in PowerShell-only contexts where shelling out to \winget.exe\ is unreliable (especially in SYSTEM context) or architecturally inappropriate. Full parity unblocks enterprise adoption.

Proposed technical implementation details

Add missing cmdlets using the existing COM API (Microsoft.Management.Deployment):

• \Test-WinGetConfiguration, \Assert-WinGetConfiguration, \Get-WinGetConfiguration\
• \Save-WinGetPackage\ (download)
• \Repair-WinGetPackage\
• \Add-WinGetPin, \Remove-WinGetPin, \Get-WinGetPin, \Reset-WinGetPin\
• \Export-WinGetSettings, \Set-WinGetSetting\
• Enhanced source management cmdlets with full parameter parity

All cmdlets should support SYSTEM context operation for enterprise automation scenarios.

Start by reviewing the existing PowerShell Module and Microsoft.Management.Deployment COM API, since no files or tests are named. Inventory the listed parity gaps and determine which API surfaces support them. Done means the proposed cmdlets and enhanced source management cover the stated CLI capabilities and operate in SYSTEM context.