Conquering Windows Server 2022: How to Manually Sideload Winget (Without the Microsoft Store)

Ever try to run a simple, modern command on a simplified Server OS?

Recently, I deployed a Windows Server 2022 machine in my Azure tenant and needed to use Winget (the Windows Package Manager) to streamline my environment. It sounds like a standard five-minute task.

Not quite.

Because Server 2022 lacks the Microsoft Store by default, it also lacks the background infrastructure to manage modern app dependencies. What started as a simple command turned into a deep dive into missing UWP frameworks, architecture mismatches, and XML digital licenses.

Instead of doing things the old-fashioned way, I reverse-engineered the deployment process. Here is the step-by-step documentation for manually injecting dependencies and getting Winget running natively on a very basic Server OS.

Step 1: Environment Preparation and Execution Bypass

Before running package installation commands, we need to prepare the PowerShell environment to allow secure web communication and script execution. Open PowerShell as an Administrator and run:

# Force PowerShell to use TLS 1.2 for secure web connections

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12



# Temporarily bypass script execution restrictions

Set-ExecutionPolicy Bypass -Scope Process -Force



# Create and navigate to a working directory

New-Item -ItemType Directory -Force -Path "C:\winget-init"

Set-Location "C:\winget-init"

The Logic: Modern endpoints (like GitHub) strictly require TLS 1.2. Forcing this ensures the connection isn't rejected. Additionally, setting the execution policy to Bypass temporarily lifts Server 2022's strict script restrictions just for this active window.

Step 2: Acquiring the Installation Assets

PowerShell's Invoke-WebRequest can occasionally fail on Azure VMs due to redirects. Downloading the assets manually via a web browser (like Edge) is the most reliable approach.

Navigate to the official Winget releases page:

Github winget releases

1. Locate the release with the green Latest tag.




2. Scroll to the Assets section and download these three items to your C:\winget-init folder:

• DesktopAppInstaller_Dependencies.zip




• Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle




• The XML License file (e.g., e53e159d00e04f729cc2180cffd1c02e_License1.xml).

1. Extract the contents of DesktopAppInstaller_Dependencies.zip into your working folder.

Step 3: Framework & Dependency Injection

The Server OS requires exact architectural dependencies (64-bit/x64) to be installed before the main application. Locate the extracted _x64framework files (specifically VCLibs and UI.Xaml) and install them:

# Install the 64-bit Visual C++ libraries

Add-AppxPackage -Path "C:\winget-init\Microsoft.VCLibs.x64.14.00.Desktop.appx"



# Install the 64-bit UI Xaml framework

Add-AppxPackage -Path "C:\winget-init\Microsoft.UI.Xaml.2.8.x64.appx"

The Logic: Winget is a 64-bit application. If you attempt to install the x86 (32-bit) dependencies, the installation will fail with a 0x80073CF3 conflict error. We are manually fulfilling the prerequisites that the Microsoft Store normally handles.

Step 4: Engine Installation

With the prerequisites in place, install the main application bundle:

Add-AppxPackage -Path "C:\winget-init\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"

Step 5: System-Wide Licensing (The Final Fix)

If you run winget now, it will return a "No applicable app licenses found" error. Because Server 2022 lacks the Store to verify digital entitlements, you must manually inject the XML license into the OS image using DISM.

Add-AppxProvisionedPackage -Online -PackagePath "C:\winget-init\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" -LicensePath "C:\winget-init\e53e159d00e04f729cc2180cffd1c02e_License1.xml"

The Logic: Add-AppxProvisionedPackage provisions the app so that it is officially licensed and available for any user that logs into this server, bypassing the Store verification entirely.

Step 6: Verification and Cleanup

Close your current PowerShell window to refresh the environment variables, open a new session, and run:

winget --version

Once verified, you have successfully built a modern Package Manager environment on a legacy architecture