How to Use winget Package Manager on Windows Server 2025

winget — the Windows Package Manager — is Microsoft’s officially supported command-line tool for discovering, installing, upgrading, and removing software on Windows. Introduced in Windows 10 and expanded significantly in Windows 11 and Server 2025, winget leverages a curated community manifest repository on GitHub and supports private sources for enterprise deployments. Unlike third-party tools, winget is developed and maintained by Microsoft, ships as part of the App Installer package, and integrates directly with the Windows Package Manager REST source protocol. For Windows Server 2025 administrators looking to automate software management without installing additional dependencies, winget provides a lightweight, native alternative to Chocolatey and a complement to WSUS for third-party application management.

Prerequisites

Windows Server 2025 with an administrator account
PowerShell 5.1 or PowerShell 7.x
App Installer (Microsoft.DesktopAppInstaller) version 1.20 or later
Internet access to winget.azureedge.net and api.github.com for the community source
Visual C++ Redistributable 2019 (usually pre-installed on Windows Server 2025)

Step 1: Verify or Install winget on Windows Server 2025

On Windows Server 2025, winget is not always pre-installed. The App Installer MSIX package must be present for winget to work. Check availability first:

# Check if winget is available
winget --version
# v1.9.xxxx

# If not found, check for App Installer package
Get-AppxPackage -Name "Microsoft.DesktopAppInstaller" | Select-Object Name, Version

If winget is missing, install App Installer from the GitHub releases page or via PowerShell:

# Download the latest App Installer MSIX bundle from GitHub
$url = "https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"
$dest = "$env:TEMPAppInstaller.msixbundle"

Invoke-WebRequest -Uri $url -OutFile $dest -UseBasicParsing

# Install (requires Developer Mode or sideloading enabled on Server)
Add-AppxPackage -Path $dest

# Verify after install
winget --version

On Server editions without a Microsoft Store, you may need to enable sideloading first:

# Enable sideloading (required for MSIX on Server without Store)
Set-ItemProperty `
    -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionAppModelUnlock" `
    -Name "AllowDevelopmentWithoutDevLicense" `
    -Value 1

Step 2: Search for Packages

The winget search command queries the configured sources (by default, the Windows Package Manager Community Repository) and returns matching packages with their IDs and versions:

# Basic search
winget search nodejs

# Search with exact string match
winget search --name "Node.js" --exact

# Search by publisher
winget search --publisher "OpenJS Foundation"

# Show all fields including source and type
winget search git --include-unknown

Package IDs are the canonical identifier used by all other winget commands. Always use the ID for scripted installs to avoid ambiguity:

# Get the exact package ID before scripting installs
winget search "Visual Studio Code"
# Name         Id                      Version  Source
# Visual Studio Code  Microsoft.VisualStudioCode  1.90.0  winget

Step 3: Install Packages

Use winget install with the package ID for reliable, unambiguous installs:

# Install using package ID (recommended)
winget install --id=OpenJS.NodeJS.LTS -e

# Install a specific version
winget install --id=OpenJS.NodeJS.LTS --version=20.19.1 -e

# Silent install with no UI (for scripts and automation)
winget install --id=Git.Git -e --silent

# Accept all license agreements automatically (required for unattended scripts)
winget install --id=Microsoft.DotNet.Runtime.8 -e --accept-package-agreements --accept-source-agreements

# Install to a custom location (if the installer supports it)
winget install --id=Notepad++.Notepad++ -e --silent --override "/S /D=C:toolsnotepadplusplus"

Step 4: Upgrade Packages

# Upgrade a single package
winget upgrade --id=OpenJS.NodeJS.LTS -e

# Upgrade all packages with available updates
winget upgrade --all

# Upgrade all — unattended, no prompts
winget upgrade --all --silent --accept-package-agreements --accept-source-agreements

# List all packages that have updates available
winget upgrade

# Pin a package to prevent it from being upgraded
winget pin add --id=Oracle.JavaRuntimeEnvironment --version=17.0.11

Step 5: List and Manage Installed Packages

# List all packages winget knows about on this machine
winget list

# List with filtering by name
winget list --name "node"

# Show details about a specific installed package
winget show --id=OpenJS.NodeJS.LTS

# Uninstall a package
winget uninstall --id=OpenJS.NodeJS.LTS -e

# Uninstall silently
winget uninstall --id=Git.Git -e --silent

Step 6: Manage Sources

winget can be configured to use multiple package sources — the community repository, a private REST source, or a local folder-based source:

# List configured sources
winget source list
# Name     Argument
# winget   https://cdn.winget.microsoft.com/cache

# Add a private source (REST source hosted on your infrastructure)
winget source add `
    --name="CorpInternal" `
    --arg="https://winget.corp.example.com/api/v2" `
    --type="Microsoft.Rest"

# Add a community source (GitHub)
winget source add `
    --name="community" `
    --arg="https://github.com/microsoft/winget-pkgs"

# Remove a source
winget source remove --name="CorpInternal"

# Reset all sources to default
winget source reset --force

# Update the local package index cache
winget source update

Step 7: Create a winget Manifest for Custom Packages

To publish a custom application to a private winget source, create a YAML manifest. Manifests follow a versioned schema maintained by Microsoft.

Create the manifest structure:

# Install the winget manifest validation tool
winget install Microsoft.WingetCreate -e --silent

# Scaffold a new manifest interactively
wingetcreate new https://intranet.corp.example.com/packages/MyApp-2.1.0-x64.msi

Example version manifest (Corp.MyApp.installer.yaml):

PackageIdentifier: Corp.MyApp
PackageVersion: 2.1.0
MinimumOSVersion: 10.0.26100.0
InstallerType: msi
Installers:
  - Architecture: x64
    InstallerUrl: https://intranet.corp.example.com/packages/MyApp-2.1.0-x64.msi
    InstallerSha256: A1B2C3D4E5F6789012345678901234567890ABCDEF1234567890ABCDEF12345678
    InstallerSwitches:
      Silent: /quiet /norestart
      SilentWithProgress: /passive /norestart
ManifestType: installer
ManifestVersion: 1.6.0

Validate and publish:

# Validate the manifest against the schema
wingetcreate validate --manifests .Corp.MyApp

# Submit to a private source (REST API call to your winget server)
# The exact method depends on your private source implementation

Step 8: Export and Import Package Lists for Bulk Installs

winget’s import/export feature lets you capture the software state of one machine and reproduce it exactly on another — useful for standardised server images or developer workstation builds:

# Export all installed packages to JSON
winget export --output "C:configserver-packages.json" --accept-source-agreements

# View the exported JSON
Get-Content "C:configserver-packages.json"

# Import and install all packages from the JSON on a new machine
winget import `
    --import-file "C:configserver-packages.json" `
    --accept-package-agreements `
    --accept-source-agreements `
    --ignore-unavailable

The export JSON references packages by ID and version, making it an excellent candidate for committing to a Git repository as an auditable record of server software configuration.

Step 9: Comparing winget, Chocolatey, and WSUS

Understanding when to use each tool prevents overlap and confusion in your environment:

winget: Native Microsoft tool, no additional install needed on modern Windows Server. Best for: standardising third-party application installs on individual servers, import/export machine states, simple upgrade automation. Limited enterprise management features in the free tier.
Chocolatey: Larger community package repository, richer scripting API (chocolateyInstall.ps1), mature Chocolatey for Business features (central management dashboard, internalization/airgap). Best for: enterprises needing a managed internal feed, complex install scripts, air-gapped environments.
WSUS (Windows Server Update Services): Manages only Microsoft product and Windows updates. Not suited for third-party software. Best for: centralised patch management of Windows OS and Microsoft applications (Office, SQL Server, etc.) with bandwidth control and approval workflows.

A typical enterprise pattern: WSUS for all Microsoft/Windows patches, Chocolatey for the managed internal application catalog, and winget for ad-hoc or developer workstation management.

Conclusion

winget on Windows Server 2025 provides a lightweight, natively supported path to command-line package management that does not require any additional tooling beyond the App Installer package. For scripted server builds, automated upgrade cycles, and reproducible machine configurations via import/export, winget is now a first-class option in the Windows Server administrator’s toolkit. When combined with WSUS for Microsoft patch management and Chocolatey for a curated internal enterprise catalog, winget fills the gap for quick, transparent third-party software management — all backed by the Microsoft-maintained community manifest repository and an open, extensible REST source protocol for private deployments.

How to Use Windows Package Manager (winget) on Windows Server 2025