One of the first big roadblocks I ran into while trying to deploy IGEL thin clients throughout our environment was trying to keep them up to date. I have quite a few remote locations with less than ideal bandwidth between them. Pushing an update over the WAN to 30+ devices would’ve taken hours and killed our WAN link. IGEL has a buddy update system which I looked into first (https://kb.igel.com/igelos/en/buddy-update-23501837.html).
With the buddy update, you create a list of buddy “masters” that you push the update to normally (over the WAN in my case). These masters then act as update servers for other devices on their same subnet. This worked okay, but since my remote locations utilize multiple subnets, I would’ve been managing multiple buddy servers. Coupled with the fact that the thin client only has so much power and can serve only a few clients at a time, this solution was less than ideal. So I started looking into other solutions such as FTP/HTTP servers.
We also host FTP servers at each site, which I looked into utilizing next. And while this solution worked, it was much less automated that I liked and I am going to skip the details of that. We already have an SCCM distribution point at all of our remote locations, I wanted to find a way to use this to our advantage. What is an SCCM DP other than a glorified web server? This should theoretically work perfectly for hosting update content.
I started by making a standard package in SCCM, I only needed a content package, so this worked better than an “Application”. Either download and extract your firmware update to your desired source folder, or copy the contents of the desired firmware from the ums_filetransfer directory. One of the benefits of SCCM is that it is a reliable content distribution network. I just need to manage the source folder. Each time I want to roll out a new version of IGEL OS, I just copy in the new files to the content folder, update the version in the package for reference and select “Update Distribution Points”. Then all my sites reliably have the new update content without needing to change any profiles on the IGEL side.
Simple right? Now I have a webserver hosting my package with all the update files. Now I need to point my IGEL to this location. I created a new update profile, selected HTTP, entered my server name and then updated the path to the new package that I just created.
Since IGELs are not SCCM clients, by default they will not be able to access the content on the webserver. The easiest way around this is to edit the configuration of your DP within SCCM and select “Allow clients to connect anonymously”. For obvious security reasons, depending on the content hosted on your DP, this may not be the best solution for you. You can also go into IIS and enable Windows authentication. At which point you can add the user name and password of a service account to your IGEL profile.
From here, you need to ensure you have your package distributed to your DPs and deploy your Update Profile to a thin client. Now when you attempt to start a firmware update on your IGEL, it should reach out to its local distribution point configured in it’s profile for the update content.
I have not yet tested the scenario when the DPs are configured for HTTPS communication. This would add a bit of complexity since the client would now need a certificate for communication rather than a package access account. When I get a chance to test this scenario, I will update the blog accordingly.