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 🙂
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? youtu.be/BXSPI9UoB5g
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 ( github.com/IGEL-Community/PSIGEL ) 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!