Install winget on Windows Server 2025, 2022 and 2019, or use Chocolatey

Short answer: WinGet comes with Windows 10 (version 1809 or later), Windows 11 and Windows Server 2025. Windows Server 2022 and 2019 do not include it, and Microsoft does not support it there. On those, try the Repair-WinGetPackageManager cmdlet (unsupported, but it may work), or install Chocolatey with its one-line PowerShell command instead.

# 1. Is winget already there?
winget --version

# 2. If not: Microsoft's bootstrap, via the Microsoft.WinGet.Client module
$progressPreference = 'silentlyContinue'
Install-PackageProvider -Name NuGet -Force | Out-Null
Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-Null
Repair-WinGetPackageManager -AllUsers

# 3. Open a new PowerShell window, then install something
winget install --id Git.Git -e --source winget

The second block is the script Microsoft gives for Windows Sandbox, which has no Microsoft Store either. The rest of this guide covers which Windows Server versions support WinGet, the manual route with the App Installer bundle, the winget commands you will actually use, the errors you meet on a server, and Chocolatey as the dependable alternative on Server 2022 and 2019.

Which Windows Server versions support winget?

WinGet is part of the App Installer package. On desktop Windows the Microsoft Store delivers and updates it; on Windows Server 2025 it arrives through Windows Update. As of October 2026, Microsoft Learn (“Use WinGet to install and manage applications”, last updated July 2026) lists Windows 10, Windows 11 and Windows Server 2025, and the winget-cli project’s README adds the details for older servers:

The README is explicit: Windows Server 2019 and 2022 “can run it experimentally (not supported)”, and because WinGet relies on MSIX packaging, it cannot run on Server Core at all. So on a 2022 or 2019 server winget either installs cleanly or it does not, and nobody at Microsoft will fix it for you. That is why Chocolatey, further down, is the safer default there.

Is winget already installed?

winget --version
Get-AppxPackage Microsoft.DesktopAppInstaller | Select-Object Name, Version

A version string (it starts with v) means you are done. If PowerShell answers with The term 'winget' is not recognized but the App Installer package is listed, the package is installed and only not registered for your account yet. That happens right after the first sign-in on a fresh Windows 10, 11 or Server 2025, because the registration runs in the background. Microsoft’s fix:

Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe

If Get-AppxPackage prints nothing, App Installer is not there at all, which is the normal state of Windows Server 2022 and 2019. Continue with one of the two routes below.

Install winget with Repair-WinGetPackageManager

The Microsoft.WinGet.Client PowerShell module on the PowerShell Gallery contains a cmdlet that downloads the current App Installer and its dependencies and installs them. It needs Windows PowerShell 5.1 or later, so it runs on every supported Windows Server.

1. 1Open PowerShell as Administrator

   Right-click the Start button and choose Windows PowerShell (Admin), or Terminal (Admin) where it exists.

2. 2Install the module

   Install-PackageProvider -Name NuGet -Force first, so the Gallery download does not stop on a prompt. Add -Scope AllUsers to Install-Module if other administrators should have the module too.

   Install-PackageProvider -Name NuGet -Force | Out-Null
   Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery -Scope AllUsers

3. 3Bootstrap WinGet

   Repair-WinGetPackageManager -AllUsers

   -AllUsers installs it machine-wide. Get-Help Repair-WinGetPackageManager -Full lists the other parameters, including -IncludePrerelease for a preview build.

4. 4Open a new window and test

   The winget command is an app execution alias, and a window opened before the install does not see it. In a new window, winget --version should answer.

On Server 2022 and 2019 this is the unsupported case, so the result varies with the build and its updates: it can end with a working winget, or stop with an Add-AppxPackage deployment error that has no official fix. When that happens, do not spend an afternoon on it: use Chocolatey.

The manual route: App Installer bundle plus dependencies

Each release on the winget-cli GitHub page carries the same App Installer package the Store delivers, as Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle, together with DesktopAppInstaller_Dependencies.zip (the framework packages it needs, per architecture) and a licence file. Install the dependencies first, then the bundle:

$ProgressPreference = 'SilentlyContinue'
$dl   = "$env:TEMP\winget"
$base = 'https://github.com/microsoft/winget-cli/releases/latest/download'
New-Item -ItemType Directory -Path $dl -Force | Out-Null

Invoke-WebRequest "$base/DesktopAppInstaller_Dependencies.zip" -OutFile "$dl\deps.zip" -UseBasicParsing
Invoke-WebRequest "$base/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" -OutFile "$dl\AppInstaller.msixbundle" -UseBasicParsing
Expand-Archive "$dl\deps.zip" -DestinationPath "$dl\deps" -Force

# x64 dependencies first, then App Installer itself
Get-ChildItem "$dl\deps" -Recurse -Filter *.appx |
  Where-Object FullName -like '*x64*' |
  ForEach-Object { Add-AppxPackage -Path $_.FullName }
Add-AppxPackage -Path "$dl\AppInstaller.msixbundle"

Add-AppxPackage installs for the account that runs it, which on a Windows VPS is normally Administrator. If Add-AppxPackage refuses the bundle, the README’s wording for 2019 and 2022 (“by extracting the .msixbundle”) points to a last resort: a .msixbundle is a ZIP archive, so copy it to a .zip name, extract the x64 .msix inside it the same way, and run winget.exe from that folder. Treat that as a stopgap: there is no Store and no update mechanism behind it.

The winget commands you actually use

Why --id and -e matter

By default, winget does a case-insensitive substring match on a package’s name, ID and moniker. winget install chrome can therefore hit several packages and stop with Multiple packages found matching input criteria. Please refine the input. --id restricts the match to the ID column of winget search, and -e (--exact) turns the substring match into an exact, case-sensitive one. Together they pick exactly one package, which is what you want in a script.

Fully unattended installs

winget install --id Git.Git -e --source winget --silent --accept-package-agreements --accept-source-agreements

• --silent (-h) suppresses the installer’s own UI. Without it you see the installer’s progress window.
• --accept-package-agreements accepts the package’s own licence terms, so a package with a EULA does not wait for a keypress.
• --accept-source-agreements accepts the terms of the source (the repository), which winget otherwise asks about on first use.
• --source winget skips the msstore source. A server without the Microsoft Store cannot use it anyway, and leaving it in only adds prompts and duplicate results.

winget upgrade --all takes the same flags. Run winget upgrade on its own first to preview the list. Programs that do not report a version are skipped unless you add --include-unknown, and pinned packages are skipped unless you add --include-pinned. winget list shows more than what winget installed: it reads the same entries as Apps & Features, and an Available column marks those with a newer version in the repository.

Common winget errors on a server

For scripts, the Microsoft.WinGet.Client module you installed above is the better interface anyway: Find-WinGetPackage, Install-WinGetPackage, Update-WinGetPackage and Get-WinGetPackage return PowerShell objects instead of text you would have to parse. Logs are in %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir, and winget --logs opens that folder.

How do I install Chocolatey?

Chocolatey is the older Windows package manager, and it runs on Server 2019, 2022 and Server Core installations alike. Per its documentation it needs a supported Windows version, PowerShell, and .NET Framework 4.8 for Chocolatey CLI 2.x; the installer tries to add .NET 4.8 itself if it is missing. Windows Server 2022 ships with 4.8, Server 2019 with 4.7.2, so on 2019 expect the .NET install first and possibly a reboot.

1. 1Open PowerShell as Administrator

   Chocolatey installs into C:\ProgramData\chocolatey and needs elevation.

2. 2Check the execution policy

   Run Get-ExecutionPolicy. If it says Restricted, the command below already bypasses it for this one PowerShell process only.

3. 3Run the install command from chocolatey.org

   Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

   The -bor 3072 part switches on TLS 1.2 for this session, which older .NET defaults leave off. Chocolatey’s documentation recommends reading install.ps1 before running it; on a production server that is worth the minute.

4. 4Open a new window and check

   choco --version

choco search 7zip              # search the community repository
choco install 7zip -y          # install, -y answers every prompt
choco install git notepadplusplus -y
choco list                     # installed packages (local only since Chocolatey CLI 2.0)
choco outdated                 # what has a newer version
choco upgrade all -y           # upgrade everything
choco uninstall 7zip -y

Without -y, Chocolatey stops at every confirmation, which is the most common reason an automated install hangs. Run choco from an elevated window: in a normal one it warns that it is not running from an elevated command shell, and installs that write to Program Files or the machine PATH fail.

winget vs Chocolatey

Both are fine package managers; the deciding factor on a server is the Windows version. On Windows 11 or Server 2025, winget is already there and supported. On Server 2022 and 2019, Chocolatey is the one with a supported install path. You can also run both side by side, but they keep separate records: update each program with the tool that installed it, or the two lists drift apart.

winget and Chocolatey on a Windows VPS

A fresh Windows server is where a package manager pays off most: the first hour is mostly downloading a browser, an editor, 7-Zip, Git and runtimes, and one choco install line replaces all of it. Connect first (the guide to connecting over RDP covers Windows, Mac, Linux and mobile clients), and if the server still has Remote Desktop switched off, follow enabling RDP on Windows Server through the console.

Windows Server 2022 and 2019 can be picked at order time on every VMHeaven KVM plan, and on a Windows VPS you log in as Administrator, so either package manager installs without restrictions. Since both versions are in the “not supported” row for winget, Chocolatey is the one we would set up first there, and winget is worth a try with the Repair cmdlet if you prefer its repository.

Frequently asked