Create WinGet deployment documentation or scripts

[rhj-kinsley]

Brief description of your issue

There seems to be a lack of clear and defined documentation regarding the proper deployment and bootstrapping of WinGet using PowerShell on new machines. The main issue lies with the latest Windows 10/11 ISOs that Microsoft currently ships to manufacturers; WinGet doesn't work out-of-the-box on new deployments using those images and errors out. This is due to the version of the App Installer MSIX package shipping with those ISOs being outdated and not functioning as expected. See issue:

• Broken winget after installing Windows 11 and all its updates #3832

I've been using a PowerShell script of my own to bootstrap/repair WinGet utilizing the Microsoft.WinGet.Client module on new deployments. It seems to work well enough, but I would still prefer clear guidance on whether this is best practice or not.

This is the distilled version of the deployment script I use to repair and bootstrap WinGet.

#Requires -RunAsAdministrator

# Install NuGet package provider to install Microsoft.WinGet.Client module
Install-PackageProvider -Name NuGet -Force

# Install Microsoft.WinGet.Client module
Install-Module -Name Microsoft.WinGet.Client -Repository PSGallery -Force

# Repair WinGet package manager
Repair-WinGetPackageManager -Latest

[stephengillie]

I usually update the App Installer through the Microsoft Store. I'm not sure, but that might be the quickest way to get WinGet going on new installs. It's part of the update process for my VMs, installing all updates from the Microsoft Store, Windows Update, and Defender.

[denelon]

The process you outlined is exactly what we're aiming for. There are still some gaps with how exactly this functions in the system context vs. a logged in user context. There are also gaps on ARM64.

• Repair-WingetPackageManager not working as expected in system context #4271
• Microsoft.WinGet.Client PowerShell Module failing to load on Arm64 in PowerShell 7.x #4169
• Repair-WingetPackageManager deployment operations not marked as complete #4116
• Repair-WinGetPackageManager outputs noise in PowerShell transcripts #4005
• System Context #3049

[rhj-kinsley]

Gotcha @denelon, and just to be more specific in my case I wish to bootstrap/repair WinGet machine-wide from a full local administrator context, not necessarily from SYSTEM context.

Also, should I add the AllUsers scope flag to the cmdlets just to be more precise in their intent? Finally, is the -Force and -Latest flag recommended in this situation with Repair-WinGetPackageManager? For example.

#Requires -RunAsAdministrator

# Install NuGet package provider to install Microsoft.WinGet.Client module
Install-PackageProvider -Name NuGet -Scope AllUsers -Force

# Install Microsoft.WinGet.Client module
Install-Module -Name Microsoft.WinGet.Client -Repository PSGallery -Scope AllUsers -Force

# Repair WinGet package manager
Repair-WinGetPackageManager -AllUsers -Latest -Force

[denelon]

WinGet being delivered via the App Installer MSIX means "AllUsers" doesn't exactly behave the way it would for an MSI. It should have any negative impact but might not necessarily be required.

The "Latest" argument essentially means grab the newest stable version rather than to just "repair" the current version.

I honestly don't remember why "Force" is required (it's probably an edge case we might hit), so that will likely also stay.

For completeness, there is an "Allow Prerelease" for users who want a preview build rather than stable, but for broad deployment use cases, I wouldn't recommend that one without the user fully understanding the implications of installing a prerelease version of WinGet on a large number of devices.