Recommendations for managing firmware on thousands of IGEL OS endpoints?

Anyone have any tips/tricks/ideas for managing firmware on thousands of endpoints? How to upgrade them all without killing network bandwidth? I was looking into the buddy update but I worry that I will bring a handful of devices to their knees. I was trying to use views to clump devices together but I can’t seem to apply firmware to a view. Any ideas to automate this would be helpful as well ๐Ÿ™‚

Learn more, read the entire thread inside the IGEL Community o Slack

Are you using Directories?

You can apply the update to the Directory and send the update to a few machines that way. Then run the update on reboot

If I apply the LX firmware and OS firmware at a high level directory. is the UMS smart enough to only apply the relevant firmware? Or should I build out a directory for UDC vs Igel hardware

I would have to test that

Ok, thanks for the advice and feedback.

I would think it would only update the firmware that it can respectfully

I would hope so hah ๐Ÿ™‚ But I didn’t want to assume ๐Ÿ™‚

@member Buddy Update Server is one way to go: perfect but you are right, I wouldnโ€˜t use more then 3 Buddyslaves per Buddymaster (at least not if itโ€˜s a thinclient).

Next one: try to use a separate (s)FTP(s) /HTTPS for serving as a UMS Independant Update source.

Next: creating profiles for this Update Repository (System=>Firmware Update)

Next: create views about what you want to update

Last: through UMS Administration=>Adminstrative Tasks=>Create a job=>Assign Profile to view

Does it make sense to you?

This is very helpful @member

It seems like a logistical nightmare to manage buddy servers. Maybe only use those for low bandwidth sites. We do have SCCM infrastructure setup, maybe we can host the firmware files on those. Thanks for the info ๐Ÿ™‚

One thing SCCM has going for it is phased deployments.. Only deploy to say 10% of devices then when the goal is reached deploy to 10% more etc. Does IGEL have anything like this?

@member on the SCCM part, not at the moment but thatโ€˜s something we should discuss internally!

I think it would be good to have ๐Ÿ™‚ Or at least some method to stagger a deployment.

You are right! It makes absolutely sense, will take it on my list!

What about that?

For the idea of a staged (bit by bit) firmware update:

I did something similar in our infrastructure. Most of our endpoints are connected via wifi, a lot of them via 2,4 ghz. I had to make sure, that there is a contolled number of endpoints per Access point (room in our case) update at once.

I wrote a Powershell script which utilizes my PSIGEL module ( ) to get all online endpoints, grouped them per room, choosed X endpoints and assigned them with a special comment (which at the start of the next run at first has to be deleted). I then created a view for all endpoints with that said comment. After this I created a job for update when shutting down and assigned it to the view.

I could now run the script some minutes before the job started. With that method i could bit by bit update nearly all my endpoints automatically.

For the application of firmwares at a high level:

you can do this with administrative tasks (assign profiles to views). Create a view for each endpoint-firmwareupdate and assign it to a profile with said firmwareupdate.

Continue reading and comment on the thread ‘Recommendations for managing firmware on thousands of IGEL OS endpoints? ‘.  Not a member? Join Here!

Learn more, search the IGEL Knowledge Base

Ask a question or comment on the above message thread?

Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.

Submit a question, or Join Today!

Popular Message Threads

Categories & Tags: