Well, it’s been a long time 🙂 I have been out of the game for a while (no blogs since 2023!) because I was taking some time out to do a few things that I really enjoyed, which are ticking along nicely – but unfortunately, bills have a habit of getting in the way, so I am back doing a little bit of work at the moment.
I’ve just recently been extolling the virtues of Chocolatey, and as far as package managers go, I’m sold on it. Package managers allow users to “consume” applications from a repository – whether this be online or hosted by yourself – and are most common in Linux (think apt, yum, rpm, etc.). For Windows, there are a few – winget, scoop, etc. – but Chocolatey is by far the best, IMO.
The thing I find the most useful about package managers is if you can convince your users to use these technologies to install all of their applications, then updating said applications is as easy as running a single scheduled task. Update the repo with the latest version, and then all your endpoints simply pull in the latest version from there without any user intervention. You don’t need to do any packaging, because the likes of Chocolatey provide self-contained packages – even if your application is not a traditional installer, and might just be a bunch of files in a folder.
Also, and this is very obvious as well, you can use a package manager to help spin up systems faster – during the image build, just run a script that pulls in the required applications. You can even use config files and other cool stuff to target installations but that’s probably something for a separate post.
Getting users around to using something like Chocolatey can be difficult, which is why I had the idea of running a simple, no-cost implementation from a file share to get a proof of concept going. Chocolatey’s licensed version has loads of cool features, but for showing the art of the possible, this method should work just fine.
Requirements
- An SMB file share to host the packages, with Users being allowed Read, List and Execute permissions (standard Read should do)
- A staging Windows machine to download the packages onto (the free version of Chocolatey means you’ll have to install the packages somewhere to get them, so this is what this is used for)
- A client Windows machine to actually test the installation of the packages once we have put them in the file share
And that’s it!
Process
On both the staging and the client machine, install the Chocolatey extension so you can actually use the damned thing 🙂
# Install Chocolatey
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
Once this is installed, you can verify it by running choco /? (you may need to re-open the command window)
Next, get the name of the package you want from the Chocolatey online website – https://community.chocolatey.org/packages
In this example, we’ve looked up Google Chrome. The name you need is highlighted in yellow below
Install this package onto your staging machine by running the following command
choco install googlechrome --source=https://community.chocolatey.org/api/v2/ --force --download-only -y
You can check what has been installed via Chocolatey by using the choco list command (the staging machine I pulled the screenshot from has quite a lot of packages installed, but you can see Google Chrome highlighted)
Next, you simply need to copy the Chocolatey install binaries from the staging machine to your file share. Run this command (changing the application folder name from MyFolder as necessary)
Copy-Item -Path "C:\ProgramData\chocolatey\lib\MyFolder" -Destination "\\SERVER\SHARENAME" -Recurse -Force
(Obviously when you are running this command, the user you are running as will need write access to the share)
You can see what the file share will look like below once you have copied some apps over
Pay attention to the contents of the ProgramData\chocolatey\lib folder in case there are any dependencies in there. If an application has a dependency it will download the packages for the dependency also. If these exist (like the ones highlighted below) they will also need copying to your file share repository (as we have already done above)
Once this is done, you have the option of either uninstalling the Chocolatey app from your staging machine or leaving it on there. I prefer to leave it on as you can then use the staging machine to download newer versions and update the repository. It is probably quite easy to automate this so I will add the automation as an update to the blog post when I get around to it.
Next, move to your actual client machine where you are going to consume the Chocolatey packages like a normal user would from the file share repository.
Firstly, we need to stop the Chocolatey extension looking at the online repository and use our file share instead. The online one is always the default.
# Add our new source
choco source add --name="LocalSource" --source="\\SERVER\SHARE" --priority=1
# Remove online source
choco source remove --name="'chocolatey'"
You can then verify your list of sources by running choco source list which should show output like below
Next, you can simply install the Chocolatey-packaged app by using the choco install command
# Install the application
choco install googlechrome -y
This will pull the application from your file share repository and install it onto your client machine.
And that is, quite simply, all there is to it. Your users can now consume applications via the Chocolatey extension that you have put into the file share. You can repeat the above process for as many applications as you require until you have completely filled your repository with as many applications as you think you may need.
Updating is pretty simple also. Just run the below command on your staging machine
# Update all applications on staging machine
choco upgrade all -y
And this will update the c:\ProgramData\chocolatey\lib folder with updated versions of the applications (if available). You can then simply copy these new folders to your file share, and then all your users will be able to update to the latest version. I like to put a Scheduled Task on the client machines that simply runs the above command every time the machine boots up, so if updates are available, just tell the users to reboot (or even run a script you could put on their Start Menu) and the applications will all be updated silently and easily.
One of the caveats to remember with Chocolatey is that it requires admin access on the client end to install the packages, if you want to get around this you would need to invest in the paid version. As most of the user base I install this for are developers or high-end power users, the admin rights is not usually such a contentious issue so this simple method will work quite passably.
I’m quite into Chocolatey at the moment, so expect a few further posts as I get to grips with automating and also digging into some of the cooler features. I’m also going to do similar things for winget and scoop if I can. In the meantime – I guess it’s kinda good to be back, even if it is on a much smaller scale than I was before 🙂 Thanks for reading