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. 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. 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 Locate the release with the green Latest tag. 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). Extract the contents of DesktopAppInstaller_Dependencies.zip into your working folder. 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. With the prerequisites in place, install the main application bundle: Add-AppxPackage -Path "C:\winget-init\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" 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. 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