search

microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
22.55k stars 1.4k forks source link

Create WinGet deployment documentation or scripts #4390

Open rhj-kinsley opened 2 months ago

rhj-kinsley commented 2 months ago

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:

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 commented 2 months ago

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 commented 2 months ago

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.

rhj-kinsley commented 2 months ago

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 commented 2 months ago

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.