Firmware updates across a fleet of servers sound like routine work—until the number of servers exceeds 50 or 100. At that scale, it is no longer an understanding of the risk but rather the manual effort involved that determines whether a known security vulnerability remains unpatched.
Once you have about 50 servers, firmware updates require a dedicated process: an inventory of all versions, a staging group with representative hardware, a fixed maintenance window, and a prepared rollback plan. Redfish standardizes the update interface across vendors, but does not replace the need to verify which version is suitable for which server type.
Why Manual Firmware Updates Have Their Limits
HPE clearly explains the difference. Manually onboarding more than 100 servers takes hours or even days, whereas the same task can be completed with a single command using iLOrest's bulk automation (HPE, 2026). The reason why firmware maintenance in growing server fleets requires a planned process lies between these two figures.
Updating a single server is quick. You log in to the management interface, upload the new firmware file, start the process, wait, and check the result. With ten servers, you can still do this manually. With a hundred or several hundred servers, this routine turns into a full-time project in its own right, where every manual step is an additional source of error.
per year and per site is what truck-roll costs can reach, that is, the cost of sending technicians to the site in person when no remote access is set up.
Vertiv, 2022
Redfish as a Common Language for Firmware Updates
For automation to work across different manufacturers, a common interface is needed. The DMTF standard Redfish has standardized firmware update services since version 2016.2, usable through the same API structure at every manufacturer that supports it. Anyone running a mixed fleet benefits from this directly. Instead of maintaining a separate update script for each manufacturer, most of the logic can be handled through a single common interface. How the switch from IPMI to that interface works is described in the article on the IPMI-Redfish Migration.
This reduces the maintenance effort required for automation, but does not replace content planning. Each manufacturer releases firmware on its own schedule, with its own release notes and known issues. A common interface does not mean that every firmware version is automatically suitable for every server type.
Update orchestration over long distances
For sites spread out over long distances, there is an additional technical consideration. How much data traffic actually travels over the wide area network (WAN) for an update? SynergyCP, for example, orchestrates provisioning over the WAN in such a way that the actual data traffic remains locally at the site, and only control commands are routed through the central instance (SynergyCP, 2026). For firmware files, which can be several hundred megabytes in size depending on the server generation, this difference makes a significant impact when site connectivity is limited.
The Process from Inventory Count to Rollback
| Step | Contents | What happens without it |
|---|---|---|
| Inventory | Version, hardware generation, and intended use for each server | It remains unclear which systems are still affected by a known vulnerability |
| Staging Group | Test a small, representative subset first | A single error immediately affects the entire fleet |
| Phased Rollout | Group by group, rather than all at once | No stop is possible if any irregularities are detected |
| Rollback Plan | Previous version available; procedure documented via the BMC | A failed update leads to a prolonged outage |
Without an inventory, it is impossible to prioritize or determine which systems are still affected by a known security issue. The staging group should indeed cover all hardware variants currently in use, not just the latest models. A fixed maintenance window is just as essential as the rollback plan.
Retrieve the firmware version for the entire fleetWe provide an inventory across all locations and a recommendation for staging groups and rollout order.
Why a Centralized View Makes All the Difference
Anyone keeping a server fleet centrally in view through KVM Fleet has direct console access at hand when something goes wrong, so that individual outliers can be spotted quickly and dealt with in a targeted way. How the same central view can also be used for day-to-day KVM-over-IP access across multiple locations is described in the article on KVM-over-IP at a fleet-wide scale. Why firmware maintenance is at the same time a security topic is shown in the article on BMC Security.
Frequently Asked Questions
Can firmware updates be performed while the system is running?
Many firmware updates require a server reboot or, at the very least, a brief interruption of the affected component. In redundant systems, a server can be taken offline from the active cluster while others take over the load. For standalone servers without redundancy, a scheduled maintenance window is usually unavoidable.
How can you test a firmware update in advance without putting your entire fleet at risk?
A small staging group with representative hardware is the standard approach. This group receives the update first and runs under observation for a defined period of time before the rest of the fleet follows. It is important that the staging group actually covers the hardware variants currently in use.
What should you do if a firmware update fails?
A prepared rollback plan makes the difference between a brief incident and a prolonged outage. This includes having the previous firmware version on hand, as well as a documented procedure for accessing and resetting the affected server via the BMC, even if the system no longer boots.
The Next Step
torck also rolls out firmware updates for its own server fleet via KVM Fleet, with a staging group and a rollback plan as described in this article. The team in Maxhütte-Haidhof, Vienna, and Rabat knows the sources of error from its own practice. More on this on the Product Page.
German 
English 
French