-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create WinGet deployment documentation or scripts #4390
Comments
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. |
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.
|
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
|
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. |
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.
The text was updated successfully, but these errors were encountered: