Windows Package Manager on Windows Server

[denelon]

Many users have asked about support for Windows Package Manager on Windows Server. We've had several Issues created surrounding Windows Server, and a few discussions created. The most limited environment is Server Core with no Desktop Experience. I'm expecting we will have some work on the Windows Package Manager side to build a distribution without the App Installer since the App Installer has GUI components.

• Winget command missing from server 2019 #144
• Support for Windows Server 2016 (1607) #211
• winget support for supported Windows Server, Azure Stack HCI editions #702
• Missing winget.exe on server 2019 install #754
• install winget on Server SKU [No applicable app licenses found] #776
• winget.exe not running on Server 2019 #1251
• WinGet installation on Windows Server 2019 #1321
• The Microsoft Store source is added even if the Microsoft Store isn't available. #1558
• [FEATURE] Add support installation on Windows Server 2022 #1929
• [FEATURE] Add support installation on Windows Server 2022 #1955
• Missing winget.exe on server 2019 install #1954
• Installation Guide for LTSC (and Server OS) #1781
• Installation Guide for LTSC (and Server OS) #1956
• WinGet on Windows Server Core #4319

I would like to gather some customer feedback on the use cases for adding Windows Package Manager to Windows Server SKUs.

My ask is to keep the comments limited to specific use cases / business reasons / business requirements. If you see your exact scenario covered, please don't add a "+ 1" comment or a "me too" comment. Just add your 👍 to the comment. If you do have a slightly different use case or reason, please add it.

---

Related Issues:

• Strict Microsoft package signature validation #1438
• Program 'winget.exe' failed to run: The file cannot be accessed by the system.At line:1 char:1 [Running Virtual Machine via SSH] #1474

---

edited: 08/05/2024

Update:

WinGet is currently in the Windows Server 2025 Insider Preview builds.

[cvoigt]

classic jump servers come to mind where win32 apps are likely required and would benefit from automatic updating

[cvoigt]

terminalservers where a package manager would make provisioning and updating of non-virtualized applications easier and faster

[cvoigt]

winget could serve as a trusted source in scenarios where servers run application guard/allow-list scenarios

[cvoigt]

simplification of deployment/update method for applications between client and server OS.
(e.g.: if you already use winget for application deployment/updates in configmgr on client OS then it's easy to re-use those for deployment on server OS as well)

[eponerine]

Not everyone wants to pay for Chocolatey ;)

[gdunn]

Not everyone can. They start at 1000 machines :(

[alexmags]

Chocolatey (for business) starts at 100 licences (not 1000) for $1,600.00 / year
Or free if you don't need support and GUI tools.
https://chocolatey.org/pricing

[awakecoding]

Can you please add my past issue "Strict Microsoft package signature validation" to the list? One of the things that would make winget more friendly for Windows Server usage is if it could provide a guarantee that when installing Microsoft packages, they actually come from Microsoft (rather than just trust the winget repos) it would make it close-enough to built-in Windows features you can enable, especially for things like Windows Admin Center. It would also make it possible to validate the trust of origin with an offline cache.

[denelon]

Done. 🙂

[christian-korneck]

Windows Client and Windows Server behave the same in many ways. Imho something that works on a Windows client (like an install command in a batch/powershell script) shouldn't break on a Windows Server and vice versa (unless related to hard feature differences).

Example: As a developer I might want to install pkg-config via something like <packagemanager> pkgconfig-lite. I want to install it on my workstation (which might be a virtual workstation running on a Windows Terminal server on a Windows Server SKU). And I might want to install it also on ephemeral CI/CD runners that might also be based on a Windows Server SKU due to licensing reasons (i.e. when an entire hypervisor server is licensed with Windows Server Datacenter Edition or because it's a Windows container). And maybe my colleague wants to do exactly the same (= running the same commands and scripts) on his/her physical Windows 10 laptop.

[artisticcheese]

Using inside windows containers to install applications

[jhuseman]

This would be great! A single line at the top of a dockerfile for any dependency that isn't already available as a windows container.

[Geogboe]

I think this is very necessary! Package managers really simplify building container images. Without using one, keeping packages in a container up to date when rebuilding images is extremely tedious and error prone.

[lippertmarkus]

To quickly prepare a Windows Server node to be added to a Kubernetes cluster by installing all the prerequisites with WinGet:

winget install containerd
winget install kubelet
winget install kubeadm

[P0w3rChi3f]

tl;dr - Not every environment has access to Azure or the internet.

I have worked in secure environments that are "off line" or do not have an internet connection. I currently work as an incident responder, and we have a flyaway kit that doesn't get connected to the internet. The best solution I came up with was building a ProGet (https://inedo.com/proget) server to host all my chocolatey packages. I chose this route because when I looked at getting an on-prem winget solution, I learned winget needed access to Azure (correct me if I am wrong). With ProGet I can build the VM on my local computer and then upload it to our flyaway kit. This allows us to install tools to our analyst VMs in the kit as we need them.

[P0w3rChi3f]

It would need to be an on-prem solution for our flyaway kit. Our kit typically doesn't have an internet connection, so we typically use products that can be used without the internet or host our own version. For example, we use GitLab loaded with all of our favorite Github tools, we host our own Linux repos. I have also worked in several secure sites where this is the case. We have to build things outside of the office, then go through a process of bringing electronics/hard drives, etc., into the building. In other words, cloud is not a thing unless it is an on-prem cloud.

[denelon]

So more like this:

• Build an on premeses solution for secure environments winget-cli-restsource#158

[RMITBLOG]

I can give you 10 example enterprise customers needing this

[alexmags]

+1 for no internet access for servers. Chocolatey from DFS fronted file share repo

[fabiang]

Btw there IS a Winget package server implementation written in Go: https://github.com/jantari/rewinged

[codejake]

I would like this functionality so that:

1. I could easily install various libraries and utilities for scripts on server. And there dependencies.

2. As winget matures, install server software (daemons) and keep all this up to date and keep dependencies managed.

[alexmags]

Train ops and Devs on just one package manager. Ensure software installs equally well on both desktop and server OS. Required for Citrix/terminal servers, servers running automated client software tests, servers operating client software as part of robotic process automation.

[alexmags]

Reduce the time required to provision servers for development teams by ensuring the otherwise manual steps of installing and configuring operations software is automated. Package management agents such as antimalware, backup, vulnerability scanning, patch management, health monitoring. Also package OS configuration scripts for versioning and dependency management such as adding/removing optional OS features. Without this server configuration is manual and error prone requiring manual Q&A checks and rework. Devs twiddle their thumbs waiting for replacement test servers. Or waste time manually cleaning up a test server rather than getting a fresh clean one (re)provisioned.

[alexmags]

Assume servers have zero or limited internet access. Be able to roll out software to thousands of servers without exhausting the datacenters' shared internet connections. Be able to use local repos.

[FreeJAC]

Any Cloud or On-Prem setup (Citrix, VMWARE, Parallels, AVD, RDSH etc. take your pick) where user apps and Single User O/S and/or Multi-User O/S are involved, Package Manager and (Winget) should support equally. That said, I do not see a need for supporting Server O/S without Desktop Experience since it is highly unlikely there is ever user apps on those systems. As a matter of fact, our shop doesn't even bother with Server O/S with no DE even for use cases that it makes the most sense. Nobody wants to be bothered with it and just prefer having the DE installed for ease of use and familiarity.

[Xaeroxe]

Ran into this again. I wanted to automatically install PowerShell, but couldn't use winget because this code sometimes runs on Windows Server.

[denelon]

We're working on some mechanisms to be able to run and upgrade WinGet on Windows Server. The challenge is typically the Microsoft Store not being available on Windows Server, and no UI for Windows Server Core. WinGet still has a dependency on XAML.

[jkohutOMF]

It would seem like it would make sense to start small, build a process, and then expand it. For example, two pieces of software that MANY Windows Admins need to install and update are Java and Tomcat. I think both of these products are available as Azure add ons/images. Well, it would be great if there was a package manager that could be made available as a Windows Update (WSUS) environment. This would be similar to Windows Server having the ability to update Adobe Flash (installed as option to Desktop Experience).
Having Java and Tomcat as installable and updatable components (from within the company network) would satisfy many security related issues that companies face. Also, the more of this thing can be refined, then it would set up more companies to migrate workloads to Azure with more automation experience.

[matsmcp]

To add to this list.
We have GDPR compliance requirements that means no US based or US owned cloud services what so ever.
We also have disconnected environments in locations without any internet connection.

I think I have said it before - in my eyes the first part of the fix is to remove the need of AppX and instead provide a true exe binary.
That will fix the Winrm/SSH/psexec issue. It can also be installed on "anything" with just about any installation tool to.

add A truly local Restservice that can be run on an IIS (IE no requirement for an azure only DB ......) it would become a usable tool.

[alexchandel]

Right now, I'm attempting to deploy several packages across a couple dozen servers (all with Desktop Experience installed). This isolated system is far too small for any centralized management system. winget would make this task and future work trivial.

[denelon]

We've done some of the work in the PowerShell modules to help get WinGet set up in different environments (without needing the Microsoft Store). Take a look at Microsoft.WinGet.Client and Microsoft.WinGet.DSC PowerShell modules to see what's in place currently.

https://www.powershellgallery.com/packages?q=Microsoft.WinGet

The current challenges are associated with the dependencies needed.

[alexchandel]

Any documentation on these, or installation guides? I get:

> Find-WinGetPackage openssh
Find-WinGetPackage : Could not find Windows Runtime type 'Microsoft.Management.Deployment.PackageFieldMatchOption'.
At line:1 char:1
+ Find-WinGetPackage openssh
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Find-WinGetPackage], TypeLoadException
    + FullyQualifiedErrorId : System.TypeLoadException,Microsoft.WinGet.Client.Commands.FindPackageCmdlet

[denelon]

They are still in preview. Can you create a new issue with some additional detail of how you got the module and what version of PowerShell you executed this in?

[blakeduffey]

Use case - Azure Devops Onprem Build Server (which requires all sorts of junk like node, java, Visual Studio, etc, etc.)

I was using chocolatey but some of their projects are orphaned

As an example - this was orphaned until very recently: https://community.chocolatey.org/packages/zulu8#versionhistory

[tristanbarcelon]

Same thing I've been doing for 5 yrs or so, but using scripts I've developed. It would be great if winget could step in and do this for me.

[branpurn]

Is it out of scope to support Windows Server for Windows Package Manager install of certain Windows Store applications? ex., I would appreciate the latest versions of Notepad, Snipping Tool... but installing it (and similar store apps),

PS C:\> winget install 9MZ95KL8MR0L
Found Snipping Tool [9MZ95KL8MR0L] Version Unknown
This package is provided through Microsoft Store. winget may need to acquire the package from Microsoft Store on behalf of the current user.
Agreements for Snipping Tool [9MZ95KL8MR0L] Version Unknown
Version: Unknown
Publisher: Microsoft Corporation
Publisher Url: http://windows.microsoft.com
Publisher Support Url: https://go.microsoft.com/fwlink/?linkid=2023133
Description: Quickly annotate screenshots, photos and other images with your pen, touch, or mouse and save, paste or share with other apps.
License: ms-windows-store://pdp/?ProductId=9MZ95KL8MR0L
Privacy Url: http://go.microsoft.com/fwlink/?LinkID=521839
Copyright: (c) Microsoft Corporation
Agreements:
Category: Utilities & tools
Pricing: Free
Free Trial: No
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
Seizure Warning: https://aka.ms/microsoft-store-seizure-warning
Store License Terms: https://aka.ms/microsoft-store-license


The publisher requires that you view the above information and accept the agreements before installing.
Do you agree to the terms?
[Y] Yes  [N] No: y
An unexpected error occurred while executing the command:
0x803fb104 : unknown error

[tristanbarcelon]

I've tried a module called winget-install from PSGallery but it's not working predictably. More times than not, it would succeed installing winget and its dependencies but unfortunately receive an error executing winget command from command line with or without an intervening reboot after installation. I have a unicorn setup of Windows Server with an older version of winget installed and working. Any attempts to update this one to any of the newer releases breaks it so I usually have to reinstall the old working msixbundle file.

[denelon]

That's not a Microsoft produced module. I haven't looked at it to see if it's suitable for use in all cases.

[tristanbarcelon]

Yes, definitely not, but was hoping to learn a thing or two trying to bootstrap winget onto Server. This was the repo https://github.com/asheroto/winget-installer and ps module is called winget-installed in PSGallery.

[denelon]

We've been making progress on getting support for WinGet on Windows Server. There are a couple of different fronts here. One is the update mechanism for servicing WinGet on Windows Server. This will be a long lead time workstream as it requires OS changes.

The other front is the "Repair-WinGetPackageManager" cmdlet for installing App Installer (containing WinGet) and the dependencies. This work is progressing well.

[tristanbarcelon]

@denelon, does support for Windows Server only begin with 2022 or is 2019 included?

[tristanbarcelon]

@denelon, where can we find Repair-WingetPackageManager cmdlet? Is this cmdlet being planned for Microsoft.WinGet.Client module?

[denelon]

It's already in the Microsoft.WinGet.Client module:

get-command -Module Microsoft.WinGet.Client

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Function        Add-WinGetSource                                   0.2.1      Microsoft.WinGet.Client
Function        Disable-WinGetSetting                              0.2.1      Microsoft.WinGet.Client
Function        Enable-WinGetSetting                               0.2.1      Microsoft.WinGet.Client
Function        Get-WinGetSettings                                 0.2.1      Microsoft.WinGet.Client
Function        Remove-WinGetSource                                0.2.1      Microsoft.WinGet.Client
Function        Reset-WinGetSource                                 0.2.1      Microsoft.WinGet.Client
Cmdlet          Assert-WinGetPackageManager                        0.2.1      Microsoft.WinGet.Client
Cmdlet          Find-WinGetPackage                                 0.2.1      Microsoft.WinGet.Client
Cmdlet          Get-WinGetPackage                                  0.2.1      Microsoft.WinGet.Client
Cmdlet          Get-WinGetSource                                   0.2.1      Microsoft.WinGet.Client
Cmdlet          Get-WinGetUserSettings                             0.2.1      Microsoft.WinGet.Client
Cmdlet          Get-WinGetVersion                                  0.2.1      Microsoft.WinGet.Client
Cmdlet          Install-WinGetPackage                              0.2.1      Microsoft.WinGet.Client
Cmdlet          Repair-WinGetPackageManager                        0.2.1      Microsoft.WinGet.Client
Cmdlet          Set-WinGetUserSettings                             0.2.1      Microsoft.WinGet.Client
Cmdlet          Test-WinGetUserSettings                            0.2.1      Microsoft.WinGet.Client
Cmdlet          Uninstall-WinGetPackage                            0.2.1      Microsoft.WinGet.Client
Cmdlet          Update-WinGetPackage                               0.2.1      Microsoft.WinGet.Client

[denelon]

WinGet is not currently supported on Windows Server. We're still working through the gaps, and we will update as we make progress.

[Karl-WE]

Dear @denelon would you mind to link #702 to the OP?
Maybe we can create a separate section linking to working scripts for unsupported implementation?

[tristanbarcelon]

This repo seemed the most promising of all the scripts I've tried but I need to try it on more VMs. The one I tried this module on already runs Server 2022 and has a functional winget cli version installed using method from https://www.andreasnick.com/112-install-winget-and-appinstaller-on-windows-server-2022.html. All attempts I've made to install newer dependencies and cli break the older winget version. I would need to try this on a brand new VM.

[denelon]

I added:

• winget support for supported Windows Server, Azure Stack HCI editions #702

[Karl-WE]

Hi everyone, in mids of many comments this is so far the best implementation to deploy winget on Windows Server (still unsupported by MSFT)

Thanks to @TheBigBear for mentioning it on Lior Kamrats gist

https://github.com/asheroto/winget-install

Sidenode: we are seeing some progress, as Windows Terminal will be the default console on Windows Server 2025 (currently Windows Server vNext Insider)

#1781 #1956 #1321

[jantari]

This is another important issue for using winget on Servers:

#3617

All servers in a given organization would run the same version of winget/AppInstaller to ensure reliable deployments and compatibility with internal sources, so after an accidental update it must be possible to undo the damage and downgrade the package. Currently this is not possible.

EDIT: Downgrading winget is actually possible which is nice, only removing/uninstalling doesn't work as reported in #3617

[florelis]

It is possible to downgrade the package using Add-AppPackage -ForceUpdateFromAnyVersion and pointing it to the older version of the .msixbundle

[jantari]

Thanks, but that is the per-user Add-AppxPackage cmdlet. Servers are usually multi-user systems, but even if it was only one user and LocalSystem that makes 2 total. So the uninstall / downgrade has to be possible for all users using the *-AppxProvisionedPackage cmdlets. It would be a nightmare to have different versions of winget for every user.

[denelon]

WinGet ships in App Installer which is an MSIX-based package. This only supports a single version of the package for the device.

[jantari]

That would be contrary to everything else I've learned so far about Appx/MSIX, so I went ahead and verified this in a VM. It appears the answer again isn't a simple yes or no.

Here are some observations I made on Windows 10 22H2:

1. An MSIX package, and winget speficially, can definitely be installed for one user whilst simultaneously not being installed for another. This isn't the same as different versions, but it's still a difference in state of availability.
2. You are correct in that winget / DesktopAppInstaller specifically can apparently only be present in one version at a time. If the Store updates the App for one user, it is updated for all users nearly instantly. If one user downgrades it, it is downgraded for everyone.
3. This makes me question the purpose I had learned for the -AppxPackage vs -ProvisionedAppxPackage set of cmdlets. Pretty much everywhere, the common "knowledge" is that -AppxPackage are user-specific operations and -AppxProvisionedPackage affects all users. Even the Microsoft docs on Add-AppxPackage use the singular "Adds a signed app package to a user account." in the description. But apparently this is only true in some cases (more later in bulletpoint 5)
4. Interestingly, a standard user account is able to both update and downgrade winget / DesktopAppInstaller for all users. This feels like a first to me, installing or manipulating system-wide software installs had always been restricted to administrators previously (e.g. MSI, write access to ProgramFiles, ProgramData etc.)
5. Whilst this behavior of only allowing one version of the app to be present is true for winget / DesktopAppInstaller specifically, this does not apply to MSIX based packages in general (as I interpreted your comment). For example, I was easily able to install different versions of Microsoft XMLNotepad in parallel for different users, by downloading the msixbundle files, opening powershell as various different users and installing a different version in each powershell window, every time with Add-AppxPackage -Path .\file.msixbundle -Verbose and later verifying with Get-AppxPackage -Name *XmlNotepad* -AllUsers:
   

So honestly, I have no clue anymore. It is clearly possible for MSIX-packaged apps to coexist in different versions for different users. On my work computer, my main account even has 3 different versions of some StoreExperienceApp installed simultaneously for that one user! But apparently DesktopAppInstaller is special and doesn't allow this, but anyone can up- and downgrade it globally at will. You can also pre-provision a version of DesktopAppInstaller with Add-AppxProvisionedPackage and that works, but what is the difference then vs just using Add-AppxPackage?

I realize these questions aren't yours to answer, but since winget is tied to DesktopAppInstaller which is tied to MSIX, all of the unsolved confusion around the MSIX deployment model affects it too. There is no way I am the only person here who just learned that an innocent Add-AppxPackage (a cmdlet that had historically only affected the current user) from a non-admin user affects the entire machine without any special parameters, warnings or permissions.

Also, I'm sorry for dismissing the Add-AppPackage -ForceUpdateFromAnyVersion advice, clearly that will actually work as unexpected in the case of DesktopAppInstaller.

[florelis]

On the difference between Add-AppxPackage and Add-AppxProvisionedPackage:

My understanding is that a package can be installed in the system (or "staged"), without it being "registered" for a given user. When a staged package is registered for a user, some steps happen that make the package be available for that specific user (e.g., showing up on Start Menu).

Add-AppxPackage will stage a package and then register it for the current user. If the package is already staged on the machine, then it only needs to be registered for the current user without having to put down any files on the filesystem.

Add-AppxProvisionedPackage will stage a package, and then register it for all users.

See Preinstalling package apps

But that understanding is all also based on the idea that each PackageFamilyName can only have one version in the machine at a time, which goes against what you said on point 5, so I may be wrong or missing some details.

[Karl-WE]

I would like to cheer up this whole discussion. The latest developments like dependencies, PowerShell Support, ADMX support, the speed and control of the pkgs when submitting new pkgs until they become available (few technical dependent exceptions), ability to downgrade winpkg etc. etc. is really fantastic.

This all is so motivating I have convinced a customer to deal with winget, even yet unsupported to implement a software patchmanagement on their 80 VMs running WS 2019 and WS 2022.

hope this isn't pushing the limit too hard but looking into the appx-based things coming in Windows Server vNext, it is stunning how compatible Windows Server will become to these kinds of packaged applications from Microsoft.

A feature next to a possible official announcement of winget in Windows Server vNext (works fantastic in deployment and function), would be the earlier proposed and reposted (post split) "nala - pimped apt replacement - like UI improvement" now found in #4057 .

[denelon]

@Karl-WE I can't thank you enough for showing your support here. We are actively engaged with the Windows Server team. Believe me, if we get the green light I'll be shouting to the hills about it. We're currently running some compatibility tests to see if we have any dependency challenges, as well as how we would enable a servicing mechanism for Windows Server. The current mechanism of using the Microsoft Store just isn't a reality on Windows Server today, and we're looking for some creative alternatives.

I recently added Microsoft.AppInstaller to the community repository, so at least for those who are experimentally running WinGet on Windows Server, they can get updates via `winget upgrade Microsoft.AppInstaller (assuming they are on a late enough version to get past the CDN migration we recently went through).

[Karl-WE]

Keep listening Demitrius ;). You are most welcome about the support; it will benefit so many, all the best for hopefully last few puzzles to solve.

[jantari]

btw for anyone else who revisits this discussion weekly, this is the current (September 2024) state of winget-cli on Server:

Windows Server OS	Runs	Is Supported
Server 2022 Core	✅	❌
Server 2019 Core	❌	❌
Server 2022 Core + AppCompatibility FoD	✅	❌
Server 2019 Core + AppCompatibility FoD	✅	❌
Server 2022 Desktop	✅	❌
Server 2019 Desktop	✅	❌

imo winget being "supported" or not on Server OS is just a formality, so far all my issues reproduce on supported client OS as well, but what's unfortunate is that it doesn't work on Server Core as of now (some commands like winget source list will run, but most important ones like winget install won't).

UPDATE: It does work on Server 2022 Core!

[jantari]

Oh my god, I fricking did it!

winget (install) works on Windows Server 2022 Core! (not 2019 Core, yet)

Short version (how to get it working)

1. Copy Windows.Globalization.dll out of the System32 directory on a machine with the Desktop Experience or with the AppCompatibility FoD installed and put it into your winget program directory next to winget.exe.

2. Create a symlink to Windows.Globalization.dll in the same directory called Windows.System.UserProfile.dll:

   cd '<YourWingetDirectory>'
   New-Item -Name 'Windows.System.UserProfile.dll' -ItemType SymbolicLink -Value 'Windows.Globalization.dll'

3. Edit your winget settings (per-user!). The settings file is either at:

   • %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json or
   • %LOCALAPPDATA%\Microsoft\WinGet\Settings\settings.json or
   • %LOCALAPPDATA%\Microsoft\WinGet\Settings\defaultState\settings.json

   Add the following snippet to the file:

       "installBehavior": {
           "preferences": {
               "locale": [ "en-US" ]
           }
       },

   or with more/other languages if you want:

       "installBehavior": {
           "preferences": {
               "locale": [ "en-US", "another-language", ... ]
           }
       },

   so that the final settings.json looks, for example, like this:

   {
       "$schema": "https://aka.ms/winget-settings.schema.json",
   
       // For documentation on these settings, see: https://aka.ms/winget-settings
       // "source": {
       //    "autoUpdateIntervalInMinutes": 5
       // },
       "installBehavior": {
           "preferences": {
               "locale": [ "en-US", "de-DE" ]
           }
       },
   }

That's all! Really! Your typical commands like:

& "C:\Path\To\Your\winget.exe" install --id "Neovim.Neovim" --source your-source --silent --scope machine --accept-source-agreements --accept-package-agreements --disable-interactivity

will now finish successfully! 🥳 🎉 🎉 🎉

Longer version (how I found this out!)

Normally when you try to run winget install on Server 2022 Core you get the error:

UnexpectedErrorExecutingCommand
0x80040154 : Class not registered

and winget exits with -2147221164 (which is also 0x80040154 aka REGDB_E_CLASSNOTREG aka Class not registered).

The requirement for Windows.Globalization.dll I saw in ProcessMonitor when winget searched for it but couldn't find it shortly before it quit with an error. After adding that, I still ran into Class not registered errors at later points of the install attempts though.

Running the same winget install command with --verbose-logs on normal Server 2022 (Core) and on Server 2022 with Desktop Experience and comparing the logs we can see where the winget command on Server Core fails while the command from Server GUI continues. Everything is roughly identical until:

Server 2022 Core verbose log

 ...
 [REPO] Did not find pin Package=[Neovim.Neovim] Source=[rewinged]
 [CLI ] Search result size: 1
 [CLI ] Found one app. App id: Neovim.Neovim App name: Neovim
 [CLI ] Market Filter created with market: US
-[FAIL] WindowsPackageManager.dll!00007FFE5B1AD2F9: LogHr(1) tid(874) 80040154 Class not registered


-[CLI ] Caught winrt::hresult_error: 0x80040154 : Class not registered
-[FAIL] WindowsPackageManager.dll!00007FFE5B2AA9F3: LogHr(2) tid(874) 80040154 Class not registered


-[CLI ] Failure loading resource file with error: -2147221164
 <END OF THE LOG, WINGET EXITED AT THIS POINT>

Server 2022 with Desktop Bloat Experience verbose log

 ...
 [REPO] Did not find pin Package=[Neovim.Neovim] Source=[rewinged]
 [CLI ] Search result size: 1
 [CLI ] Found one app. App id: Neovim.Neovim App name: Neovim
 [CLI ] Market Filter created with market: US
+[CLI ] Locale Comparator created with Required Locales: [] , Preferred Locales: [en-US] , IsInstalledLocale: 0
+[CLI ] Architecture Comparator created with allowed architectures: [X64, X86, Neutral]

Searching through the source code for a while, I found the spot where these last two log messages ("Market Filter created with market" and "Locale Comparator created with Required Locales") must be coming from. Somewhere in between there is where the critical error must be happening on Core. I found:

1. The "Market Filter" message comes from the Create() method here:

   winget-cli/src/AppInstallerCLICore/Workflows/ManifestComparator.cpp

   Lines 729 to 737 in 180a8d7

   	MarketFilter(Manifest::string_t market) : details::FilterField("Market"), m_market(market)
   	{
   	AICLI_LOG(CLI, Verbose, << "Market Filter created with market: " << m_market);
   	}
   	static std::unique_ptr<MarketFilter> Create()
   	{
   	return std::make_unique<MarketFilter>(Runtime::GetOSRegion());
   	}

   This code is really simple and appears to run successfully on Server Core too, since we still get that log entry.
2. The "Locale Comparator" message comes from, what I think is a constructor, here:

   winget-cli/src/AppInstallerCLICore/Workflows/ManifestComparator.cpp

   Lines 579 to 590 in 180a8d7

   	LocaleComparator(std::vector<std::string> preference, std::vector<std::string> requirement, bool isInstalledLocale) :
   	details::ComparisonField("Locale"), m_preference(std::move(preference)), m_requirement(std::move(requirement)), m_isInstalledLocale(isInstalledLocale)
   	{
   	m_requirementAsString = Utility::ConvertContainerToString(m_requirement);
   	m_preferenceAsString = Utility::ConvertContainerToString(m_preference);
   	AICLI_LOG(CLI, Verbose,
   	<< "Locale Comparator created with Required Locales: " << m_requirementAsString
   	<< " , Preferred Locales: " << m_preferenceAsString
   	<< " , IsInstalledLocale: " << m_isInstalledLocale);
   	}
   	static std::unique_ptr<LocaleComparator> Create(const Execution::Args& args, const Repository::IPackageVersion::Metadata& metadata)

3. Looking for places in the code that create both a "MarketFilter" and a "LocaleComparator" right after one another (there's just 1-2 milliseconds between the log messages), I found:

   winget-cli/src/AppInstallerCLICore/Workflows/ManifestComparator.cpp

   Lines 788 to 793 in 180a8d7

   	AddFilter(MarketFilter::Create());
   	// Filter order is not important, but comparison order determines priority.
   	// TODO: There are improvements to be made here around ordering, especially in the context of implicit vs explicit vs command line preferences.
   	AddComparator(InstalledTypeComparator::Create(installationMetadata));
   	AddComparator(LocaleComparator::Create(context.Args, installationMetadata));

This must be it! Either the line in between (AddComparator(InstalledTypeComparator::Create(installationMetadata));) or AddComparator(LocaleComparator::Create(context.Args, installationMetadata)); itself must be causing the crash. The InstalledTypeComparator thingie looked very simple again and not much crash potential there I think, but LocaleComparator::Create was a bit more juicy. There is some stuff here about user locale and language preferences, things that don't really matter as much without a GUI so may not be implemented on Core I thought. The log message "Locale Comparator created ..." is printed in, what I again think is a constructur, and the only place inside LocaleComparator::Create where that is called is here:

winget-cli/src/AppInstallerCLICore/Workflows/ManifestComparator.cpp

Lines 636 to 639 in 180a8d7

	if (!preference.empty() || !requirement.empty())
	{
	return std::make_unique<LocaleComparator>(preference, requirement, isInstalledLocale);
	}

We can see this is only called when either some preference or some requirement is NOT empty. From the log message from the GUI server we can see the "Required Locales: []" being empty, so I doubt that is a problem, but what about the preference? It is retrieved just a few lines before, and it finally gave me the clue I needed:

winget-cli/src/AppInstallerCLICore/Workflows/ManifestComparator.cpp

Lines 629 to 633 in 180a8d7

	preference = Settings::User().Get<Settings::Setting::InstallLocalePreference>();
	if (preference.empty())
	{
	preference = Locale::GetUserPreferredLanguages();
	}

It is getting some user-setting from winget, and only if that is not set will it attempt to get a preference from the OS (which is possibly what fails on Server Core!). Seeing this I remembered that winget has a settings file! And this digging all turned out to be correct, and this last little if is why winget install just works when you manually set a language (locale) preference in your settings.json file 😄 😄 😄

---

I hope this helps everyone, enjoy finally being able to use winget on Windows Server (unless you're on 2019 Core, sorry!) and inside Docker and everything! @denelon 🕺 🎉

EDIT: updated the steps to take with the Windows.Globalization.dll info. Please share if these steps worked for you too.

[RMITBLOG]

Great Job!! and thanks for sharing

[fabiang]

Wow, thank you very much for your efforts. Anyone has a Docker image ready?

[JohnMcPMS]

I looked into it and this API does appear to not be present in Server Core (meaning this error from our call to it is expected). That of course depends on my ability to map from the internal identifier to the marketing name, which should not be considered infallible.

I think at this point we could confidently wrap the implementation of Locale::GetUserPreferredLanguages to prevent the error from escaping. The default state would be that locale was not included in the installer selection if the call failed.

This is a good workaround in the interim.

[jantari]

I have to make a late follow-up to this post; what I observed above isn't incorrect but I have just deployed a new, untouched Server 2022 Core and made some additional observations. The VM I had used for the troubleshooting above wasn't "clean" because I had already experimented a bunch trying to get winget to run, so here's my new (re-)discoveries:

winget depends on Windows.Globalization.dll. This library isn't present on Server Core 2022, you have to copy this file out of System32 from a machine with the Desktop Experience or with the AppCompatibility FoD installed and put it into your winget program directory next to winget.exe.

Just adding this file has already allowed winget on my new, vanilla Server 2022 Core VM to install some packages, however another package was still failing to install with the dreaded Class not registered error. I don't know exactly what exact code paths were taken here, but some troubleshooing revealed that the issue was caused by winget not understanding that an API it tried to use (Windows.System.UserProfile.GlobalizationPreferences) is actually also provided by the aforementioned Windows.Globalization.dll despite the namespaces not matching up. Winget kept trying to find Windows.System.UserProfile.dll, which I don't think is winget's fault but just default fallback behavior from Windows for DLL discovery.

On my GUI systems there's a registry key (HKLM\SOFTWARE\Microsoft\WindowsRuntime\ActivatableClassId\Windows.System.UserProfile.GlobalizationPreferences) that I believe is responsible for pointing apps to the correct DLL to use for that type (there's a DllPath key there that points to C:\Windows\System32\Windows.Globalization.dll), however I wasn't sure what kind of side-effects it would have to manually create this key on my Server Core system and I wasn't able to get it to appear naturally by running regsvr32.exe Windows.Globalization.dll, so what I ended up doing was creating a symlink in the winget program directory named Windows.System.UserProfile.dll that links to the Windows.Globalization.dll in the same location:

This workaround makes winget find the correct DLL it's looking for under the wrong name without having to edit global registry keys or system directories which could confuse and break other applications.

Now, interestingly, after applying these two fixes I currently do NOT need to set my locale preference using the winget settings.json file on this system to be able to install all the software I want. However I would still recommend performing all three fixes (copying over Windows.Globalization.dll, creating the symlink, setting the locale preference in settings.json) as they're harmless and winget goes through lots of different code paths during installations, calling locale/language APIs many different places and I've seen Class not registered failures related to that at many different stages of the install and show flows by now.

I'll add an EDIT to my post above and also copy-paste this info to #4319. I really do hope we can officially fix Server Core compatibility soon, it's so effing silly that a CLI package manager depends on Desktop Experience APIs, especially when noone in their right mind wants do deploy Desktop Servers...

[denelon]

Hey everyone,
WinGet is in Windows Server 2025 Preview Build 26063.
"Announcing Windows Server Preview Build 26063"

[denelon]

I thought we already had an issue out there to get a default locale from somewhere else (rather than the desktop experience shell) for the Server scenario without desktop experience.. I can't seem to find it. Go ahead and create a feature request to address this issue. WinGet needs a locale before calling the "msstore" REST source, as well as when doing installer selection.

[Karl-WE]

@denelon could winget call the locale same as PowerShell? GET-WINUILanguage or (get-computerinfo).OS language, or even a more native way?

As for Windows Server Core packages.

Here are my thoughts on this:
I would suggest a whitelisting method that comes via new items in manifest like
CoreOSCompatibility for Windows Server / Azure Stack HCI, WS DCtr Azure Edition Core Installation mode compatibility
and
CoreOSFoDCompatibility for Core Installation mode plus requirement of FoD.
Winget might fetch and install this FoD as a dependency package.

If they are absent winget will refuse to install it with a respective error.

That said installers like msi or Inno are rarely blocking, rather the installed app might not be executed or working correctly or as expected. Thus whitelisting could be effective.

Most of dotnet apps work fine on Server Core.

Great examples are Macrium Backup GUI, GScopy Enterprise shell and GUI, SetACL Studio or SQL Server setup with the respective UI setup mode parameter.

These are showcases we can use GUI based Apps on Server Core even without FoD.

The state of FoD presence could be checked via PowerShell or in more complicated Syntax via Dism same as the "needsreboot" flag for the feature or installer requirement.

A very welcomed scenario for winget a CoreOSCompatibility whitelisting item would be MS C++ redist 2015-2023.
They often require (security) updates and fixes , but don't usually come via Windows Updates or Windows Update Optional Updates, and they serve as dependency for C++ written x86/x64 Apps on Windows Server Core installation option.
Example Exchange Server and tons of other apps.

What do you think about it?

[denelon]

I've been thinking about extending the enumeration for platform to cover "Windows Server" use cases.

WinGet does have a notion of "Windows Features", but those were originally targeted for Desktop rather than Server. I think we're going to have several options to consider here, and since manifests are open-source it will take some time to get the right ones updated and validated.

[jantari]

@denelon actually I think I found the issue you though of: #4319 right? Maybe you can add it to the list of Windows Server related issues in your OP for easier reference. I will add some of my thoughts in a comment there.

[denelon]

I added it. Thanks for locating the Issue :)

[SPerju]

👍

[sjansen1]

Just installed winget ui from https://github.com/marticliment/WingetUI/releases and found that is works on servers, it detects installed software and update it via winget but without winget command line installed. Awesome.

[kflanagan]

Using tools that are not SCCM, it will let us greatly simplify and streamline software distribution for Servers.
Currently for Linux the distribution tool can just "yum install -y Some-Cool-Package", so long as it's part of the RHEL repo it installs the right version in seconds.
I'd like to replicate this for Windows servers. This would save us from many hours of download files, crate powershell script to install, configure distribution tool to download those and run the script.