# HPE firmware updates: Part 3 - The Redfish update service

François Donzé's profile photo
François Donzé - Technical consultant, HPE

August 2020
Updates: July 2023, September 2025

## Introduction

In the first two blogs of this three part series regarding HPE firmware updates, I explained the
different objects
involved in firmware updates and how they are packaged, as well as the interaction between these objects when used in different
operating modes.

This third article describes the standard Redfish® update service, including its simple update and Original Equipment Manufacturer (OEM) extension actions, and offers numerous examples and screenshots.

For didactic reasons, cases described in this blog post have been performed with the
Postman
platform for API development with hard-coded resource locations. Writing Redfish scripts with hard-coded locations is definitively a bad practice as explained in this
article
and demonstrated in these
Jupyter Notebooks.
“Well written” public examples in
Python
and
PowerShell
can be found on the Internet.

## The Redfish update service

The Redfish update service contains software and firmware information as well as methods for updating these resources. Located at `/redfish/v1/UpdateService`, it
is populated with five endpoints, which are highlighted in the next screenshot.
Note that this picture shows the output of a request performed against an iLO 5 (version 2.18) implementing
schema version 1.1.1
of the Redfish update service. Later schemas may have different content.

In this article, I will cover these five endpoints in the following order: `SoftwareInventory`, `FirmwareInventory`, `Actions`, `HttpPushUri` and finally the `Oem.Hpe` extension.

![Figure 1: UpdateService properties](/assets/1_rootupdateservice.3428b1c73f4707c62bb487dcee31e934b2acdb87c17c2e600a6a53117df15721.c9c71fb4.png)

Figure 1: UpdateService properties

## Software inventory

From the `SoftwareInventory` endpoint, you can retrieve the collection of HPE software installed in the Operating System (OS). This collection contains the items listed in the iLO Graphical User Interface (GUI), which are shown in the screenshot below.

Since this list comes from the OS, it is mandatory to have the system booted. Moreover, the HPE
Agentless Management Service
(AMS) must be present and started in the OS in order to have a communication link with the iLO through the HPE Channel Interface
(CHIF)
or the host interface
(vNIC).

The following two screenshots show the list of HPE software displayed by the iLO 5 and iLO 7 Graphical User Interfaces (GUIs)
of a Linux server.

![Figure 2: iLO 5 GUI SoftwareInventory](/assets/2_ilogui-softwareinventory.1280ec7dfeb8b64a5929bcf3dc0da151cee1012d6012973d02ee0a3f93e2eeb6.c9c71fb4.png)

Figure 2: iLO GUI 5 SoftwareInventory

br
![Figure 2b: iLO 7 GUI SoftwareInventory](/assets/2b_ilogui-softwareinventory.dd1b6c29b42b3eb2a4d2f9edded32f32deea0dd2bf390309164702e9d5727c64.c9c71fb4.png)

Figure 2b: iLO 7 GUI SoftwareInventory

br
To retrieve the above collection using the `SoftwareInventory` endpoint of the Redfish update service, you have to perform
a `GET` request toward `/redfish/v1/UpdateService/SoftwareInventory`. This gives you the collection of URIs pointing to the details
of each HPE installed software. The next picture shows the five URIs that correspond to the same HPE software present in the above screenshot.
Note that the list of running and installed software present in the iLO GUI is not returned by Redfish.

![Figure 3: SoftwareInventory collection](/assets/3_softwareinventorycollection.5999d855189496a17ab5760d007014a6964059bb60dd05c6b07429d9e1dc0d3e.c9c71fb4.png)

Figure 3: SoftwareInventory collection

To avoid issuing multiple GET requests for retrieving the details of each installed software, you can append the `$expand=.`
OData query
as shown in the next screenshot (note that this screenshot has been truncated
to display only the first item of the collection). The dot (“.”) sign of this
OData query indicates that only the current level of the hierarchy has to be
expanded, not the lower levels. Details concerning the support of OData queries
can be found in the `ProtocolFeaturesSupported` property of the Redfish Service root endpoint (`/redfish/v1`).

![Figure 4: Expanded SoftwareInventory](/assets/4_expandedsoftwareinventory.601d1e0f7464bdabd79407fb66e7e41081034a5feb36e9874a96b340c98c1d0f.c9c71fb4.png)

Figure 4: Expanded SoftwareInventory

A Python example for fetching the software inventory of a server without hard coding its location can be found in the
HPE Python iLOrest library
on GitHub.

## Firmware inventory

Similar to the `SoftwareInventory` resource, the `FirmwareInventory` endpoint contains the collection of all installed firmware in a server. The exact endpoint is `/redfish/v1/UpdateService/FirmwareUpdate` and, with a single `?$expand=.` OData query, you can retrieve all the details of installed firmware on your server.

![Figure 5: Expanded firmware collection](/assets/5_expandedfirmwarecollection.865b1ae146d9d95e4aaf95195dba928cfb91d1090a876d075ea56d6c71ee3485.c9c71fb4.png)

Figure 5: Expanded firmware collection

A Python example to retrieve the firmware inventory of a server (using Redfish) can be found in the
HPE Python iLOrest library
on GitHub.

## Actions

The Redfish update service provides the list of actions that a Redfish client can perform against a server. The Redfish implementation of the server used in this article contains only one action: the `SimpleUpdate` action that can be performed by issuing an HTTP or HTTPS POST request toward the following endpoint: `/redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate`

The `SimpleUpdate` action is a “pull” update, which means that the Redfish server has to pull the firmware update image from the provided URI. Hence, the payload of the request must contain the URI of a firmware file that will be fetched from the network location and flashed instantaneously (iLO firmware) or staged and flashed during next reboot (UEFI/Bios firmware).

The implementation of the `SimpleUpdate` used for the writing of this article allows only HTTP and HTTPS transfer protocols. You can mention the appropriate transfer protocol either in the `ImageURI` resource (next image) or in the `TransferProtocol` parameter (the image following this one).

![Figure 6: Simple update action](/assets/6_simpleupdateaction.5fc00e6071e6a9856f0e3ebed78cab4f96291ae94045583f5eea14aa726c71ff.c9c71fb4.png)

Figure 6: Simple update action

br
![Figure 7: Simple update action with transfer protocol](/assets/7_simpleupdateactionwithtransferprotocol.cd0856a18ffa174518cd70ad38517edfbd2e42f2455d06a64fd88e27e4d7e62f.c9c71fb4.png)

Figure 7: Simple update action with transfer protocol

br
You can monitor the update process by polling the `State` and `FlashProgressPercent` properties part of the `Oem.Hpe` section as shown in the following screenshot.

![Figure 8: Monitoring a simple update](/assets/8_simpleupdateflashpercent.720458a63344b1732eaa893fa24e1c617c94a3ce3803e8867ed3588fc6310f27.c9c71fb4.png)

Figure 8: Monitoring a simple update

Tip
By typing string *Oem.Hpe.States* in the search box of the
Server Management Portal you will get the exhaustive list of
the possible Simple Update states shown in the next figure.

![Figure 9: Simple update possible states](/assets/9_oemhpestates.4320dcab4042a8dbe4923a6627f1376a543ed4e14c6e640625da1ee1ebe1ec31.c9c71fb4.png)

Figure 9: Simple update possible states

br
With iLO 5 firmware 2.30 and higher versions, a successful `SimpleUpdate` returns two pointers in the Task Service: a task location and a task monitor location.
The task location (`/redfish/v1/TaskService/Tasks/22` in the next picture) contains the details of the update and the task monitor location (`/redfish/v1/TaskService/TaskMonitors/22`)
contains the status of the task at the time of the query.

The following two pictures show, respectively, the response of a successful `SimpleUpdate` and the task monitor details including a running task state. Note that the accomplished percentage of the task is not present in the Task Monitor location. It is only mentioned in the `Oem.Hpe` extension properties, as mentioned above.

![Figure 10: Successful SimpleUpdate](/assets/10_successfulsimpleupdate.c5c1e3700928c85a190ce27c581696e17492002d71b2f63b8e33ba7b7320afad.c9c71fb4.png)

Figure 10: Successful SimpleUpdate

br
![Figure 11: Task monitor details](/assets/11_taskmonitordetails.9b10e28f3f987eace68cbe6253420ca26fb0cb29d4e3c0754d103ce82425847c.c9c71fb4.png)

Figure 11: Task monitor details

br
![Figure 12: SimpleUpdate task states](/assets/12_taskstates.2d14b310cdbb7a172ce0b0c6e2c1cb7cc4595128a48bb9e5de5eb8a5a641d7cf.c9c71fb4.png)

Figure 12: SimpleUpdate task states

Important
Only iLO binaries (`.bin`) and UEFI/Bios binaries (`.signed.flash`) can be processed with the `SimpleUpdate` action. If you supply a Smart Component or a firmware package (`.fwpkg`), the response to the POST request will contain a successful return code (`200 OK`). However, the flash operation will never occur and an error record will be posted in the iLO event log, as shown in the following image.

![Figure 13: iLO Event log generated by a SimpleUpdate non-supported file type ](/assets/13_ailoeventlog.0dc89a9ffbc66e21ad1c73e5fe85ec4719bad66d8fac590ef8cf4fd5c471b23c.c9c71fb4.png)

Figure 13: iLO Event log generated by a SimpleUpdate non-supported file type

br
The iLO log record can be retrieved from the `Oem.Hpe` extension of the update service, as shown below.

![Figure 14: Log record generated by a firmware invalid format](/assets/14_simpleupdateinvalidformat.0603e8b3dacb3c15d1bd36ada94b7f39159361ec2a879445eedbe26626cae21f.c9c71fb4.png)

Figure 14: Log record generated by a firmware invalid format

br
### Scripting a SimpleUpdate

There are several possibilities to script a `SimpleUpdate` action. Here are some of them.

The
HPE iLOrest
utility provides the `firmwareupdate` macro command. The command expects the URI of the binary firmware image to flash. The sources of this macro command is public and published on
GitHub.

![Figure 15: iLOrest `firmwareupdate` example](/assets/15_ilorestfirmwareupdate.104674d71664c427318fd4b546dcef0adfef55387a20787242dfea6cd457264c.c9c71fb4.png)

Figure 15: iLOrest `firmwareupdate` example

br
A simple Python script updating an iLO 5 firmware is published in the
HPE Python iLOrest Library
on GitHub. This Python example has been transformed into an
Ansible module.
The associated
Ansible Playbook is also present on the same GitHub repository.

## HTTP Push Update

The HTTP Push Update endpoint (`HttpPushUri`) allows you to embed a firmware update component
in the body of a request and push it to a server. As its name suggests,
it is a “push” update method in contrast to “pull” methods that I just described with `SimpleUpdate`.

The update service schema
version 1.8.1
provides the following description of the `HttpPushUri` property: “*The URI used to perform an
HTTP or HTTPS push update to the update service.
The format of the message is **vendor-specific**.*”

To overcome the loose definition of the `HttpPushURI`, Redfish introduced the `MultipartHttpPushUri` method in version
1.6.0
of the Update Service schema (not yet implemented in the server used for writing this article).

The payload of a POST request to the `HttpPushURI` (Figure 16) is the concatenation of several parts,
including session credentials, parameters, and component signature files (if any), in addition to the firmware file.
Refer to these
cURL and Python examples
for pushing a component with no associated `.compsig` file.

An example showing the build of such a payload with an associated `.compsig` file is published in the
HPE python iLOrest library GitHub repository.

Tips
In figure 16, note the required `sessionKey` **cookie** in the headers of the request.
Refer to this cURL and Python
[examples](/docs/concepts/redfishauthentication/#session-authentication)
to create the session key/token required
in the header of HttpPushUri payload requests.

![Figure 16: HttpPushUri payload](/assets/16_httppushuripayload.fff6e675a2b7a4247ad5978922c4e9088f49f0cb9c86fcff24f6a1321dfb91b9.c9c71fb4.png)

Figure 16: HttpPushUri payload

br
## The update service Oem.Hpe extension

The flexibility of the Redfish standard offers the possibility for computer makers to extend it with
properties not present in the standard or proprietary added-value features, as explained in this
blog post.
HPE has a unique way of managing firmware through the iLO Repository that can only be leveraged by Redfish in its `Oem.Hpe` extension.

The iLO Repository is a persistent storage area for update components. To trigger the installation of a single component or a group of components (install set) already present in the iLO Repository, you just need to add its name to the Installation Queue. Components in this queue are processed according to their specificities and nature. Refer to
Part 1
and
Part 2
of this blog series for component description and to the
HPE API Reference document
for a detailed flow of operations.

The update service `Oem.Hpe` extension is a pull update service like the `SimpleUpdate` service described earlier.
However, it is not limited to instant flash of binary firmware files. It provides all the necessary operations to fully manage the HPE iLO update subsystem.

The list of possible macro actions (i.e. delete *all* `InstallSets`) of this extension is presented below.

![Figure 17: An Oem.Hpe action](/assets/17_oemhpeactions.4d7ae5b0cb2bf704dd20b46c2c21b1839421bc9be8dbcd621c609809dc499895.c9c71fb4.png)

Figure 17: An Oem.Hpe action

br
Micro actions (i.e. delete a specific component in the iLO Repository) are also possible and can be easily identified by analyzing the `Allow` header of GET requests of a specific item. The GET request in the following screenshot retrieves the details of component `9456ccd7` stored in the iLO Repository. The `Allow` header of the response mentions the PATCH and DELETE requests as valid operations against this single component. Hence, if you want to delete this entry, just send a DELETE request to this URI.

![Figure 18: Response's Allow header](/assets/18_allowheader.c48b2af3b44308b4edd09e8e1c24bdecc32b6d60919e62fd9867b025b10df6ec.c9c71fb4.png)

Figure 18: Response's Allow header

br
### ILO Repository management

The ilO Repository (also called Component Repository) end point is returned by the `Oem.Hpe.ComponentRepository` property of the update service.
As of the writing of this document, it is located at: `/Redfish/v1/UpdateService/ComponentRepository`.

![Figure 19: Component repository location](/assets/19_componentrepolocation.4df2af2f20b2393a8ffd1ab8b9802bbf7e3888aefee0d596c8d974c3e82a4bb8.c9c71fb4.png)

Figure 19: Component repository location

br
You can use the `?$expand=.` OData query to retrieve the content of all the components with only one GET request. In the following screenshot, you can see that 23 components are already present in this repository as well as some information concerning the available and used sizes of the repository. For presentation reasons, only the first component is present here.

![Figure 20: Expanded iLO Repository content](/assets/20_ilorepoexpanded.fa501f8214b58f9f6c45f38f1bfba87fc13598abf67b191115c2de1b5700d707.c9c71fb4.png)

Figure 20: Expanded iLO Repository content

br
#### Component upload

To upload a new component to the iLO Repository, you have to send a POST request to the appropriate target mentioned in the Oem Hpe Actions list,
as shown in Figure 21. The body of this request contains the URI of the firmware image (`ImageURI`) to post and the associated signature file location (`CompSigURI`).

Requests of binary and firmware packages with an embedded signature don’t need to contain the `CompSigURI` property.

In addition to the `ImageURI` and `CompSigURI`, you must supply Boolean parameters to specify if you want to keep the component
in the iLO Repository (`UpdateRepository`) and trigger an immediate flash when the upload is complete (`UpdateTarget`).

The following screenshot shows the body of a POST request for components smaller than 32 MiB in size with one associated signature file.

![Figure 21: Payload for the upload of a small firmware](/assets/21_postwebcomponentandcompsig.de551ca99e785f1ce1d5cb6a022dca2b0b421bd0731d3e34147ca5da17b73625.c9c71fb4.png)

Figure 21: Payload for the upload of a small firmware

br
Components larger than 32 MiB (33554432 bytes) cannot be sent as such and must be split into 32 MiB chunks before being uploaded.
More information on these large Smart Components can be found in the security paragraph of the
first part
of this blog series.

On Linux, you can use the `dd` command to perform this split operation. The first command shown below takes component `cp040154.exe` as the input file, reads the first 32 MiB of its content, and writes this content to output file `cp040154.part1`.

The second `dd` command skips the first 32 MiB content of the input file and writes the remaining content to output file `cp040154.part2`.

![Figure 22: Split of a big component](/assets/25_taskmonitor2.3457b14acc9457117019d286f059f5cf265ae80275e6f332ce094753ba90b375.c9c71fb4.png)

Figure 22: Split of a big component

br
Once the component has been split, you need to perform a POST request for each component parts with the associated signature file as shown in the next screenshot.
Note that those POST requests can only be performed sequentially.

In addition to the image URI, component signature URI, and Boolean properties, you have to supply two more parameters for each chunk:
the `ComponentFileName` to use for the reassembled file and the `Section` number indicating the chunk number being posted.
The following picture shows the two POST requests needed to upload Smart Component `cp040154.exe` and associated signature files.
Note that the `ComponentFileName` parameter is identical in the two POST requests.

![Figure 23: Upload parts of a big component](/assets/23_uploadpartsbigcomp.9aa86bc167d6139acc48a33a5c853245688f5a7adfeb06626e9f8c4fa36d945a.c9c71fb4.png)

Figure 23: Upload parts of a big component

br
Similar to a `SimpleUpdate` POST, the response of POSTs to the `AddFromURI` target contains a variety of information,
including a task monitor URI when the iLO 5 firmware is higher than 2.30. This URI is present in both the body and the headers section of the response.

![Figure 24: Task monitor response's header](/assets/24_headertaskmonitor.4d5581951a79989f53fdce68211c238a5a927a9e6fe22043e1721fafd794c0da.c9c71fb4.png)

Figure 24: Task monitor response's header

br
You can poll the `TaskState` property regularly to trigger the upload of the component chunks. The following picture shows a running upload state.

![Figure 25: Another task monitor snapshot](/assets/25_taskmonitor2.3457b14acc9457117019d286f059f5cf265ae80275e6f332ce094753ba90b375.c9c71fb4.png)

Figure 25: Another task monitor snapshot

br
Once the first part of the Smart Component has been successfully POSTed (`TaskState=Completed`), you can send the remaining parts one after the other.

ILO automatically detects the last part and concatenates them all in a file with the name mentioned in the `ComponentFilename` property.

### Installation Queue management

In this section, I will provide you with several examples that explain how to add and delete specific components to the iLO Installation Queue.
The last example shows the cleanup of the entire queue using a single request.

#### Addition of a component in the Installation Queue

You can add the name of a component present in the iLO Repository into the Installation Queue by sending a POST request to the `UpdateService/UpdateTaskQueue` URI.
Note that the term “*Installation Queue*” mentioned in the iLO GUI becomes “*Update Task Queue*” in a Redfish context. However, they refer to the same subsystem.

The following screenshot shows the addition of component `cp040154.exe` in the Installation Queue with three properties:
`Name`, `Filename` and `Command`. The `Name` property is not required,
but it is interesting to provide as it appears as a description in the Installation Queue listing.
The `Filename` property contains the component file name visible in the iLO Repository.
Thus, this property is required. The `Command` property is required as well, as it describes the action to take by the Installation Queue subsystem.

Smart Components are associated to
meta-data
information needed to process their installation.
Hence, no other property is required in the request to better qualify the deployment process.

![Figure 26: Adding a component to the Installation Queue](/assets/26_addsctoqueue.3bcc77c92411488392d75a638ab56ad2ae6c7bea9902d2522acdbb170ec8cddb.c9c71fb4.png)

Figure 26: Adding a component to the Installation Queue

br
Tip
The list of possible values for the `Command` property, shown in the next figure, can be found in the
HPE API RESTful Reference Document
by typing keyword *hpecomponentupdatetask* in the search box. You can as well restrict your search to
a specific iLO generation.

![Figure 27: Command values](/assets/27_commandvalues.dc14d85f5645ca8944220c08079313202d65f06889752329c6963a373dcb4fff.c9c71fb4.png)

Figure 27: Command values

br
The body response of a component addition in the Installation Queue contains the URI of this new item in the list,
as well as many other details. This URI can be used later to review the details or to delete the component from the queue,
as explained in the next paragraph.

![Figure 28: Body response of a component addition to the Installation Queue](/assets/28_responsetoaddsctoqueue.d6c0189b8e365c3558933b6f864124280271f3aaef4c455ff826d3a259b36b43.c9c71fb4.png)

Figure 28: Body response of a component addition to the Installation Queue

br
The following example adds a binary firmware file in the Installation queue. Since this component does not contain any
meta-data describing how to process it, you can mention this information the `UpdatableBy` property. In this particular case,
the component will be processed by the iLO update agent. Refer to the
Part 1
of this article series to learn more about update agents.

![Figure 29: Add a binary firmware to queue and flash it](/assets/29_addbinarytoqueueandflash.7fc6759ca0ac10384b6e5512698b42718d9945c8ec9b3604b18081aab41a0139.c9c71fb4.png)

Figure 29: Add a binary firmware to queue and flash it

br
#### Deletion of a component from Installation Queue

To delete a single component from the Installation Queue, you just have to send a DELETE request toward the component URI in the Installation Queue.

![Figure 30: Deletion of an item in the Installation Queue](/assets/30_deleteiteminqueue.0185e4ebfe1c468b57f274a73d0b61b529867342ff2a2667dd02d9c9251fb3d2.c9c71fb4.png)

Figure 30: Deletion of an item in the Installation Queue

br
#### Removal of all items in the Installation Task Queue

You can remove all items in the Installation Queue with a single POST query toward the `DeleteUpdateTaskQueueItems` target in the `Oem.Hpe` Actions of the Update Service.
The body of this request is empty, as shown in the following image.

![Figure 31: Deleting all items in the Installation Queue](/assets/31_deleteallitemsinqueue.d2e9e214474a27093a30e475b38317fc3648ee37a866a985335c1548c3911d83.c9c71fb4.png)

Figure 31: Deleting all items in the Installation Queue

br
### Maintenance windows management

The ilO update subsystem can trigger updates during a specific maintenance window of time. The management of update tasks and maintenance windows can be done with Redfish calls. In this section, I’ll discuss the following scenarios:

- Creation of a maintenance window
- creation of an update task scheduled in an existing maintenance window
- Deletion of a specific maintenance window
- Deletion of all maintenance windows


#### Creation of a maintenance window

The minimum set of parameters required to create a maintenance window is presented in the following screenshot.

`StartAfter` and `Expire` properties have to follow the ISO 8601 Redfish-extended format detailed in the
DMTF specifications.

![Figure 32: Maintenance window creation](/assets/32_maintenancewindowcreationbody.204ac44ad557e073a62d7c94974e82d0f15c3fabfa2b5188e559798bb6e5859c.c9c71fb4.png)

Figure 32: Maintenance window creation

br
The response of a successful creation of a maintenance window contains various information including its URI and Id.

![Figure 33: Response to a maintenance window creation](/assets/33_maintenancewindowcreationresponse.f4f0593cb86db2369244a0b3399eb40816101404446bdb3a3b8ec233a229814c.c9c71fb4.png)

Figure 33: Response to a maintenance window creation

br
The `Id` can be used when you want to create an update task and schedule it during a specific maintenance window. The following screenshot shows the payload of a request adding filename `cp040154.exe` present in the iLO Repository to the installation queue during maintenance window `7ada2ed8`.

![Figure 34: Adding a component in a maintenance window](/assets/34_addcomponentinmaintenancewindow.5422eb4ed430f6771d8c511ce6e838bd26ce86f3c7428cbe6abb657fcf0cc414.c9c71fb4.png)

Figure 34: Adding a component in a maintenance window

br
The response returns the URI of the task with a `Pending` state as well as other useful information.

![Figure 35: Response to the addition of a component to the maintenance window](/assets/35_addcomponentresponse.2f2fa821671fe5ba5b42a5d5fc78a4d39d00c8cb994c9056b6506f37257fc2f1.c9c71fb4.png)

Figure 35: Response to the addition of a component to the maintenance window

br
#### Deletion of a specific maintenance window

The deletion of a specific maintenance window is pretty straightforward, as you just need to DELETE its URI. If components are scheduled in a deleted maintenance window, their execution is canceled and they appear as such in the Installation Queue (`State=Canceled`).

![Figure 36: Deleting a maintenance window](/assets/36_deletemaintenancewindow.c1b4922726066ec5e66da6a4c4c0a65c6b581d25f5193d6fc7f598c8288647a4.c9c71fb4.png)

Figure 36: Deleting a maintenance window

br
#### Deletion of all maintenance windows

You can delete all the maintenance windows with a single POST request toward the `DeleteMaintenanceWindows` target in the `Oem.Hpe` Actions resource.

![Figure 37: Deleting all maintenance windows](/assets/37_deletemaintenancewindows.ffa86473c32b57599365e9cdf1ffe3feb5c2563397376f0108a8b56280fd8e61.c9c71fb4.png)

Figure 37: Deleting all maintenance windows

br
### Install sets

An install set is a group of components that can be applied to supported servers with a single command.
The HPE update Oem extension allows you to easily manage such groups of components, including the System Recovery Set,
a special install set used to recover from severe issues. Useful documentation concerning install sets and the
System Recovery Set is located in the help page of the Firmware / Install Sets of the iLO graphical user interface,
visible by clicking on the "?" sign in the top right corner of the window.

From the `UpdateService/InstallSets` endpoint, you can create, view, patch, invoke (deploy) and delete install sets.
The schema location describing in detail this resource is mentioned in the headers of GET responses toward this endpoint.

![Figure 38: Install set schema location](/assets/38_installsetschemalocation.4614ad2a84c7c9525976c77bebec3e4fe242dfe1fd4c774ee41cdf9a15c69ef1.c9c71fb4.png)

Figure 38: Install set schema location

br
#### Install set creation

You can create an install Set with a POST request to the install set end point mentioned above and a body similar to the one of the following picture. A `Sequence` array must be present with at least one component referenced by its filename in the iLO Repository.

![Figure 39: Install set creation](/assets/39_installsetcreation.cfff099d25b8a311eb1efd425b03bf3b9cf78467e9a23ab218fcafab666933ec.c9c71fb4.png)

Figure 39: Install set creation

br
In the response of a successful install set creation you will get its`Id,`which can be used to view its details, modify it or delete it.

#### Install set modification

You can modify an install set with a PATCH to its URI and a body similar to the one in the screenshot below.

![Figure 40: Install set modification](/assets/40_installsetmodification.7c2fd3fe0b1589b6fb31a133a7bc016e4ca4fa33be1b52f2f7377c40ac5083b4.c9c71fb4.png)

Figure 40: Install set modification

br
Note that, after its modification, the `Id` (and thus the URI) of the modified install set has changed.
The new `Id` and URI are mentioned in the response body of the PATCH request shown below:

![Figure 41: Patching an install set](/assets/41_patchedinstallsetnewid.026b87e8c2ce3ad432cadc2c8ce81fbcb427255fe294310d74287029dffedf56.c9c71fb4.png)

Figure 41: Patching an install set

br
#### Install set invocation

Existing install sets contain an `Actions` property with, at least, the Invoke action and associated Target URI.

![Figure 42: Install set invocation](/assets/42_invoketargetinstallset.77d72d2ad573f1e3a36c81bce3bd139b0239356d6253279998008c648253e44a.c9c71fb4.png)

Figure 42: Install set invocation

br
You can POST an invoke request to add all the components of the install set in the Installation Queue.
The payload of such a request can contain the properties mentioned in the Install Schema mentioned earlier.
In the following screenshot, the Installation Queue will be cleared before the addition of this install set (`ClearTaskQueue`).
The effective update will occur during the specified maintenance window.

![Figure 43: Body for an install set invocation](/assets/43_bodyofinvokeinstallset.a17755c2c8c7b2ac920f804b681934fe660215197b4c77471eea23004ff0ed8c.c9c71fb4.png)

Figure 43: Body for an install set invocation

br
## Summary

The HPE Redfish update service implementation described in this article explains two pull methods and one push method for updating
firmware on HPE iLO based servers: The simple update, the `Oem.Hpe` pull methods and the Http Push method.
The Redfish data model is constantly changing and other update methods (i.e. the
MultiPartHttpPushURI)
have been published, but not yet implemented, in HPE iLO based servers. However, this lack of implementation does not mean that
those servers are not compliant to the latest Redfish standard. Read the
Getting Started with the Redfish - Part 2
blog for a better understanding of the Redfish standard and its data model versioning mechanism.
Don’t forget to check back the
HPE DEV blog site for more Redfish related articles and tutorials.