A few months ago, I worked on adapting my automated application packaging script to include Windows Package Manager (WinGet) and Chocolatey as optional sources. The first iteration of my script, relied solely on the Evergreen PowerShell Module to supply the application data and download links.
As you can see in the above video, I use my script by setting it to run every night for several applications using the Evergreen PowerShell Module to check the latest version of each application I care about – if a newer version than the applications I have currently deployed in my environment is available, it would grab the URI provided in the module, download them and then package the applications into Cloudpaging application containers and deploy to my Early Adopters group in a Workpod via Cloudpager.
What I did not realise when working on my initial script that only leveraged the Evergreen module is that I was spoiled by it! When trying to fit Chocolatey and WinGet into my script it became quickly apparent that both tools did not slot in as simply as I had hoped.
Lacking PowerShell Standard Output
The reasons for this is that Chocolatey and WinGet do not output their data in a standard PowerShell output which makes parsing that data in order to make it actionable a lot more difficult.
To use the data provided by these package managers, I needed to find the data I wanted such as name and version, output it using a fixed column width and then format it into a useable format. This was not very difficult but it as not as simple as Get-EvergreenApp GoogleChrome | Select Version. You can see an example of how I handled the output from Chocolatey and WinGet in my script.
Contents of the Repository
The next challenge I faced integrating WinGet was the quality of the content in Windows Package Manager. There can sometimes be duplicate packages or packages with names that are close to matching.
Spoke too soon pic.twitter.com/k8kximZd9n— Guy Leech (@guyrleech) December 17, 2022
As Guy Leech has previously pointed out on Twitter, there can also be packages that just straight up fail to install. In fact, until recently packages there was no supported option to run WinGet in system context but thankfully it appears this is now an option.
While my initial script could be quite flexible, the latest version of my script that works with WinGet should take application ids for the best results. It works with name, id or alias but due to the many duplicates, id seems the best bet, in my opinion. I have also encountered other issues with WinGet such as it returning incorrect versions. That issue persisted for a couple of days. At the time I asked people on Twitter and they did not seem to have the same problem, I put it down to whatever node I was hitting . The version installed using the service was the latest but the version returned in the outputted data was incorrect. Which was a problem for my script as it believed there was only an older version rather than the latest version available. After a couple of days the correct versions were being returned again. When just using Evergreen, I did not have concerns about quality of the data or packages as it was getting the install media directly from the vendors.
The quality of the packages in WinGet also lead me to setup a private repository to test with as my guess is, that is what most large organisations will choose to use, if they use WinGet. Not only can customers have a high confidence in the quality of packages when they put them in a private repository themselves but they can also ensure the data is curated by themselves too.
Using WinGet with a private repository required a lot more effort as setting up a private repository is currently a pretty complicated process and it requires resources created in Azure so this can come at a cost depending on your configuration. If you would like to setup a private repository, check out Niall Jennings’ excellent blog post.
Chocolatey for Quality
I have not tested with a private Chocolatey repository but after reviewing Chocolatey, I feel the quality of the packages in their public repository is of higher quality at the time of writing this article. They appear to have a policy where not every package gets a thorough QA before being made available. They have a trusted developers type of model. If a packager has consistently produced high quality work, their packages get published with a lighter touch verification process. In a large environment, it is possibly customers may prefer to use a private repository with Chocolatey and possibly a hybrid scenario where internally they take the publicly available packages, run it through a discovery and repackaging process and then deploy through a managed deployment tool. This should give higher confidence, greater control and better visibility.
Repackaging vs Installing Straight from a Package Manager
Another reason for taking the approach of using Chocolatey or WinGet to feed a repackaging effort rather than just allowing them to be the engine for deploying and updating applications in an enterprise is the package format challenge. Most applications are EXEs or MSIs. This is XP lifecycle era packaging technology (according to Microsoft’s John Vintzel). Traditional Windows Installers have challenges such as application conflicts, incomplete uninstalls, install related reboots, difficulty with mixed context packages such as user based installs that also require machine level files installed etc. Unfortunately vendors also do not follow best practices when producing their packages. If you do choose to continue to deploy with one of these formats, it should be msi and you should really do a discovery and package the applications to bring them to a higher standard using a product such as Master Packager.
If you want an example of a vendor not following best practices, look no further than Google. The Chrome enterprise MSI is a minefield. They do not use the MSI tables and instead leverage msi as a wrapper to call their own embedded installer. If you want to apply your own changes or controls to the applications you will have to use GPOs (if what you want to change has an available setting) or a Custom Action which is far from ideal! But I don’t want to just pick on Google. Microsoft who own the Windows Installer technology have been guilty of producing garbage packages too. In an ideal world, vendors would embrace MSIX and deliver their applications as containers to avoid conflicts and to containerize files and registry to avoid exposing these to all users and process on the system including intruders.
Tip When Using Package Managers Whilst Packaging
Regardless of using Chocolatey or WinGet, if you do choose to repackage applications using what is available in the repositories, you should be aware that the packages may also contain registry and files unrelated to the applications themselves. This appears to be metadata used by the package managers. You should setup exclusions and continue to monitor packages created with your automated process to update exclusions over time. This is also something that was not a concern with Evergreen as the module just supplied data direct from the vendor source.
Leveraging Chocolatey, and/or WinGet in your PowerShell scripts and automated packaging efforts can be a little difficult, but it is not impossible and both tools can help streamline your overall application packaging and application management process. You are welcome to use my script to achieve this with Cloudpager or you could fork it and modify it for the deployment tool of of your choice.
Personally, I would not choose to deploy and manage ALL of my applications on devices in the enterprise with the native Chocolatey or WinGet tooling as you will want a good level of visibility and control. This is why there is an increased focus on integrating WinGet into Configuration Manager and Intune.
The services could be useful for certain applications that you prefer to be locally installed such as a VPN client by dropping the latest version into a private repository and install using one of the package managers but even then I feel you will want good visibility and control to ensure compliance and handle any failed deployments.
If you choose to look at WinGet for your environment, you could look at third-party product integrations such as PolicyPak’s Software Manager to at least gain some visibility and control when using WinGet.