The RESTful API for iLO 4 and iLO Chassis Management Module is a programming interface enabling state-of-the-art server management. This document contains helpful information about how to interact with the RESTful API. The RESTful API uses the basic HTTP operations (GET, PUT, POST, DELETE, and PATCH) to submit or return a JSON formatted resource to or from a URI on iLO 4 or Moonshot iLO Chassis Management Module.

With modern scripting languages, you can easily write simple REST clients for RESTful APIs. Most languages, like Python, can transform JSON into internal-data structures, like dictionaries, allowing for easy access to data. This enables you to write custom code directly to the RESTful API, instead of using intermediate tools such as HPE’s HPQLOCFG or CONREP.

This document has been updated with examples from iLO 4 version 2.30 firmware.

The RESTful API was first released with iLO 4 2.00 on HPE Gen9 servers. The RESTful API also functioned as the starting point for the new Redfish 1.0 DMTF standard (see http:// www.dmtf.org/standards/redfish).

Since the introduction of the RESTful API, a number of changes were introduced into the Redfish standard by the DMTF SPMF members. At a high level, the changes include:

• Use of OData annotations throughout the data to communicate meta-data
• Revision of Error structures
• Removal or Rename of certain JSON properties
• Use of different collection schema
• Use of a different set of entry-point URIs (/redfish/v1/ vs. /rest/v1)

iLO 4 2.30 is Redfish 1.0 conformant while remaining backward compatible with the existing RESTful API. Moving forward, the RESTful API will become the iLO 4 enhanced implementation of Redfish. While conforming to the Redfish 1.0 standard, the RESTful API is extended with HPE-specific features such as BIOS configuration. You should plan to update your client code to confirm to the Redfish standard. iLO will eventually remove any properties that do not match the Redfish schema definitions (while preserving the OEM extensions.) iLO 4 2.30 achieves Redfish 1.0 conformance and backward compatibility by:

1. Mirroring the resource model at both /redfish/v1/ and /rest/v1.
2. Returning both compatibility and Redfish properties by default.
3. Returning only Redfish conformant properties (with HPE extensions) if the Redfish-required OData header is included in the request (OData-Version: 4.0).

Representational State Transfer (REST) is a web service that uses basic CRUD (Create, Read, Update, Delete, and Patch) operations performed on resources using HTTP commands such as POST, GET, PUT, PATCH, and DELETE. The RESTful API is designed using a REST architecture called HATEOS (Hypermedia as the Engine of Application State). This architecture allows the client to interact with iLO through a simple fixed URL (rest/v1) and several other top-level URIs documented in the iLO Data Model. The rest of the data model is discoverable by following clearly identified “links” in the data. This has the advantage that the client does not need to know a set of fixed URLs. When you create a script to automate tasks using the RESTful API, you only need to hardcode this simple URL and design the script to discover the REST API URLs that are needed to complete a task.

To learn more about REST and HATEOAS concepts, see:

• http://en.wikipedia.org/wiki/Representational_state_transfer
• http://en.wikipedia.org/wiki/HATEOAS

The RESTful API is becoming the main management interface for iLO 4 and Moonshot iLO Chassis Management Module-based HPE servers. Its feature set will become larger than the existing iLO XML API (RIBCL) and IPMI interfaces. Using the RESTful API, you can take full inventory of the server, control power and reset, configure BIOS and iLO settings, fetch event logs, as well as many other functions.

The RESTful API follows the trend of the Internet in moving to a common pattern for new software interfaces. Many web services in a variety of industries use REST APIs because they are easy to implement, easy to consume, and offer scalability advantages over previous technologies. HPE OneView, OpenStack, and many other server management APIs are now REST APIs. Most HPE Management software offerings, as well as the entire Software Defined Infrastructure, are built upon REST APIs.

The RESTful API has the additional advantage of consistency across all present and projected server architectures. The same data model works for traditional rack-mount servers, blades, as well as newer types of systems like Moonshot. This advantage comes because the data model is designed to self-describe the service’s capabilities to the client and has room for flexibility designed in from the start.

NOTE: If an error occurs, indicated by a return code 4xx or 5xx, an ExtendedError JSON response is returned. The expected resource is not returned.

The RESTful API for iLO is available on HPE ProLiant Gen9 servers running iLO 4 2.00 or later with the iLO Standard license, although some features in the data might not be available without an Advanced license. The RESTful API for Moonshot iLO Chassis Management Module is available on Moonshot servers running iLO Chassis Manager 1.30 or later and does not require a license. To access the RESTful API, you need an HTTPS-capable client, such as a web browser with the Postman REST Client plugin extension or CURL (a popular command line HTTP utility).

Although not a requirement, you can use the HPE RESTful Interface Tool with the RESTful API. This command line tool provides a level of abstraction and convenience above direct access to the RESTful API. For details see: https://github.com/HewlettPackard/python-proliant-sdk. Also, HPE published example Python code that implements a number of common operations in a RESTful API client. This code can be downloaded at https://github.com/HewlettPackard/python-proliant-sdk. In some cases the examples in this document may refer to examples in the Python code with this notation:

If you prefer not to implement a client in Python, this serves as a good pseudocode implementing the logic required to perform an operation.

Let’s perform our first GET operation using the RESTful API. We will do an HTTP GET on the iLO HTTPS port, typically port 443 (although it could be different if you have previously configured iLO to use another port). Your client should be prepared to handle the HTTPS certificate challenge. The interface is not available over open HTTP (port 80), so you must use HTTPS.

Our GET operation will be against a resource at /rest/v1 (without a trailing slash): • Correct: GET https://myilo/rest/v1 • Incorrect: GET https://myilo/rest/v1/

It is best to perform this initial GET with a tool like the CURL or the Postman REST Client mentioned above. Later you will want to do this with your own scripting code, but for now it’s useful to see the HTTP header information exchanged using a browser.

NOTE: This tutorial contains pseudocode for accessing resources in the RESTful API on iLO. To best follow this code, we highly recommend you perform the operations in the Postman REST client or CURL so you can easily see how the data structures match the pseudocode. The same principles illustrated here also apply to Moonshot iLO Chassis Management Module.

CURL is a command line utility available for many Operating Systems that enables easy access to the RESTful API. CURL is available at http://curl.haxx.se/. Note that all the CURL examples will use a flag –insecure. This causes CURL to bypass validation of the HTTPS certificate. In real use iLO should be configured to use a user-supplied certificate and this option is not necessary. Notice also that we use the –L option to force CURL to follow HTTP redirect responses. If iLO changes URI locations for various items, it can indicate to the client where the new location is and automatically follow the new link.

When you perform a GET operation, you receive a response JSON object. Take a look at this JSON object and the HTTP headers returned above. The first lines are the response HTTP headers identifying the content. Following that is the JSON response in compressed form. Even though it looks messy, JSON is highly structured and can be “pretty-printed” into easy to read documents.

The first detail to notice is a couple of the response headers. The ETag header is a digest of the JSON content. ETag handing is an advanced topic, so we will ignore it for now, except to say that the string value of an ETag is not intended to be parsed by the client. It is an opaque string and iLO might change its ETag generation algorithm in a future version.

The second interesting header is the Allow header. Allow is supplied on all GET operations by the RESTful API and indicates which HTTP operations are allowed on this resource. You will 10 Get started using the RESTful API notice that only GET is allowed against /rest/v1. This means it is a read-only object because you cannot use PATCH, PUT, or DELETE (the modification operations.) On many resources, you will discover that the interface supports PATCH. PATCH is specifically intended to update an existing object instead of replacing it (like PUT would.) This enables you to PATCH a partial object and not worry that you are removing any properties you omitted.

Here is the full version of the above JSON response (edited for length):

In JSON, there is no strong ordering of property names, so iLO may return JSON properties in any order. Likewise, iLO cannot assume the order of properties in any submitted JSON. This is why the best scripting data structure for a RESTful client is a dictionary: a simple set of unordered key/value pairs. This lack of ordering is also the reason you see embedded structure within objects (objects within objects). This allows us to keep related data together that is more logically organized, aesthetically pleasing to view, and helps avoid property name conflicts or ridiculously long property names. It also allows us to use identical blocks of JSON in many places in the data model, like status.

Notice that the JSON response has a property named Type with a value of "ServiceRoot.1.0.0”. Type is very important in the RESTful API. It is the key to understanding what all of the other properties in the object mean. Resources that have the same type follow the same _schema definition _(meaning that like-named properties mean the same thing.)

Type includes a name (“ServiceRoot”) as well as version information (“1.0.0”). Version information is formatted as major.minor.errata. Future iLO firmware releases will certainly expand the data included in its various resources, so as a client, you should be prepared to see different versions of a Type. Anything but a major version is backward compatible, so a new property added to an object might result in minor Type increments (for example, Chassis.1.0.0 becomes Chassis.1.1.0). Moving to a major version change (for example, Chassis.2.0.0) is a breaking change without any guarantee of backward compatibility.

The initial releases of the RESTful API contained many resources of type version 0.9.5 where major version is 0. However, as of iLO 4 2.30 many types are transitioning to version 1.0.0. We have maintained backward compatibility with previous versions of iLO 4, so this type changes from 0 to 1 do not indicate breaking changes in this case but a maturing of the RESTful API data model.

If the server is managed by HPE OneView, information about the HPE OneView instance is included in this root resource. See the property at JSON pointer path /rest/v1#/Oem/Hp/Manager/0/IPManager . The content of this sub-object includes a reference back to the HPE OneView server.

**NOTE: **If the server is managed by HPE OneView, many of the settings are specifically configured for HPE OneView use. Use care in modifying any properties in the RESTful API directly when the server is managed by HPE OneView as it might result in the server being out of sync with HPE OneView’s view of the system for some time.

Finally, let’s take a look at the links property. In the RESTful API, the navigation of the data is included in the data itself, not in the spec, and can therefore adapt as needed to different servers over time without the specification changes. This is called a hypermedia API where the navigation is built into the data (like web pages). The links property contains the pointers to other related resources. Inside the links objects are various defined relationship types, like Systems, Managers, Chassis, or Sessions. Each of these contain a property called href that is the URI of the related resource. A relationship type (for example, Systems) distinguishes the various links by what they navigate to. For instance, Systems navigates to a collection of ComputerSystem resources.

The RESTful API does not define all of the URIs to various items, like temperatures or power supplies on a server. You cannot assume the BIOS version information is always at a particular URI. This is more complex for the client, but is necessary to make sure the data model can change to accommodate various future server architectures without requiring specification changes. As an example, if the BIOS version is at /rest/v1/Systems/1, and a client assumed it is always there, the client would then break when the interface is implemented on a Moonshot with 180 compute nodes, each with its own BIOS version. Defining pointers to specific features in the specification makes the RESTful API too rigid. For this reason, only a select few URIs are published and guaranteed to be stable starting points. Client code must not assume anything about the URIs that you see in the data model. You must treat them as opaque strings or your client will not interoperate with other implementations of the RESTful API.

Do not hardcode URI parsing templates in your client. Instead, you should start at /rest/v1 or one of the fixed entry point URIs below and crawl the data model using the defined relationship types and find instances of types that interest you.

Redfish: Redfish uses the @odata.id property to indicate a link to another resource. These links may be in a “Links” section (for related resources) or in the root object itself (for child resources.) Note that Redfish uses a “Links” (capital L) vs. “links” for the compatibility RESTful API. iLO will render either Links or links based upon the presence or absence of the OData-Version HTTP header in the request.

The following URIs are fixed in the data model and client software may start with any of these as it accesses the RESTful API.

• /rest/v1 The root resource.
• /rest/v1/Systems The collection of compute nodes.
• /rest/v1/Chassis The collection of chassis.
• /rest/v1/Managers The collection of management processors (iLO).
• /rest/v1/Sessions
  The Session management API.
• /rest/v1/Registries The collection of Registries. */rest/v1/Schemas The collection of Schema. Let’s look at some of the links:

This is a link to the system node collection. Systems are compute nodes (the terminology came from DMTF) with, for example, CPUs, memory, expansion slots, power management, and BIOS version. A DL or BL server has a single compute node in the Systems collection while Moonshot might have up to 180 items in the collection. You should think of the System link as your portal into the logical view of the server or servers. The collection of Systems is documented to be /rest/v1/Systems.

This is the physical view. A Chassis should be thought of as a physical container. The Chassis relationship type is a link to the collection of Chassis. On a ProLiant DL/ML/BL server, this will be a collection of one chassis. A Moonshot Chassis collection might include the cartridges, as well as the enclosure (as cartridges are a type of chassis.) Perform your first REST API operation 13 Chassis are containers that often have power supplies, temperature sensors, and have a physical location. Chassis contain logical computer nodes (systems) but can also contain another chassis (consider: a Moonshot chassis contains cartridges that are another kind of chassis, each containing nodes). Also, there is no 1:1 relationship between chassis and systems to accommodate multi-node systems and systems that spread across more than one chassis. The collection of Chassis is documented to be /rest/v1/Chassis.

This is a link into the iLO 4 or Moonshot iLO Chassis Management Module itself for iLO management tasks traditionally done with RIBCL. For example, network settings, license administration, and iLO firmware management. The collection of Chassis is documented to be /rest/v1/Managers.

The following shows the error displayed on GET /rest/v1/Systems when no authentication is attempted:

To add Basic Authentication in Postman:

1. Click the Basic Auth tab.
2. Enter the Username and Password.
3. Click Refresh headers. Result: This generates the Basic Authentication Base64 hash.
4. Click Send.

To add Basic Authentication to a CURL command line, add the following parameter: -u username:password For example:

If you perform a GET on any other resource other than the root /rest/v1 resource, you receive an HTTP 401 (Forbidden) error indicating that you don’t have the authentication needed to access the resource. The RESTful API allows you to use HTTP Basic Authentication if you wish for one-time operations. This is one reason the Postman plugin or CURL is so useful. These tools can easily insert the correct base64 encoding for basic authentication credentials into your requests.

For more complex multi-resource operations, you should log in and establish a session. To log in, iLO has a session manager object at the documented URI /rest/v1/Sessions. To create a session we need to POST a JSON object to the Session manager:

POST /rest/v1/Sessions with the required HTTP headers and a body containing { "UserName": "username", "Password": "password" } IMPORTANT: You must include the HTTP header Content-Type: application/json for all RESTful API operations that include a request body in JSON format.

If the session is created successfully, you receive an HTTP 201 (Created) response from iLO. There will also be two additional HTTP headers.

Once you can log in, you may now traverse the entire data model. Because the model is linked together by href links, it is easy to create a client that can crawl the entire model by simply iterating on each object (with recursion for sub-objects and arrays) looking for hrefs within links objects.

Note that even though you start at a well-known URI, the data model is not, strictly speaking, a tree because there can be cross references throughout the data model (for example, from chassis to system and vice versa), so you will need to build a dictionary of visited URIs as you crawl the model to avoid infinite traversal. As you GET a URI, add it to this dictionary, and then if you see that URI again, do not perform another GET. As additional advice, you should keep the visited dictionary URI keys as lowercase, for example, tolower(). URIs in the data model should use consistent lowercase and uppercase conventions, but bugs happen, and if there is inconsistency in casing, keeping the dictionary keyed as lowercase URI strings protects the traversal algorithm. As you crawl the data model, you will notice a large number of objects are of type Collection.

Collections are a frequently used type of object in the RESTful API. Collections always have a generic type of Collection (which means they all conform to the same schema and share the same property names). Collections are very versatile and are distinguished by a property called MemberType that indicates the type of the members it collects. The MemberType only specifies down to the type name and major version, allowing mixing of minor versions of the same type in the same collection.

Collections are very flexible in implementation and can present members in several different ways. The two basic data structures in a collection: the links to the members of the collection (/links/Member array) and the Items array. Depending on how the collection is implemented, you might see either the Members or Items array omitted from a collection:

A description of each form follows:

• Form 1: is a fully modifiable collection that requires you to iterate by using the GET command for each href in the Member array. This is the most flexible and generic form, but is less efficient because it requires more HTTP operations to fully iterate. Collections of this form might allow POST to create items, and the child resources might allow DELETE to remove items. The children might allow PATCH to modify items. This form of a collection is used with Sessions and Accounts for which creation and deletion of members are supported and iteration of the collection is less important.
• Form 2: is a variant of Form 1 and includes an Items array that contains either a subset or the full item representation in the collection object itself, as well as a link to the child resource. If the subset of the member is well chosen by the implementer, you might peek at collection members by looking at the top-level information in the Items array, and decide to do a separate GET for items of interest (drill down). This increases scalability by enabling the client to better determine which children to GET. The Items array representation does not need to be fully compliant with the MemberType schema because it might omit items to save space. The Items array does not replace the child resource, but provides a peek at the key differentiating data.
• Form 3: is for read-only collections (for example, PCI Devices or Slots) where item creation, deletion, or modification is not needed. There are no child resources and there might not be a links section. The Items array carries entire schema-compliant members. The advantages are size efficiency, no links section, and no need to iterate using separate GET operations. This is ideal for things that are best represented as read-only arrays. To iterate collection in the RESTful API see collection() in the Python example code—this is a Python generator function that returns each collection member using the yield keyword.

ComputerSystems represent compute nodes in the data model. A ProLiant DL rack server may have a single compute node while a fully loaded Moonshot chassis may contain 180 compute nodes. For an example of how to iterate all the ComputerSystem resources in the data mode:

Chassis represent physical or virtual containers for compute resources. For instance, a ProLiant DL rack server has a single chassis representing the metal container of the server. Chassis resources describe the physical aspects of the server. For an example of how to iterate all the Chassis resources in the data mode: **NOTE: **Python: See ex29_get_PowerMetrics_Average() in the Python example code.

After you GET a chassis object, you can see the attributes, including ChassisType, shared properties from the system (for example, AssetTag), and dimension information. The ChassisType is overloaded to a variety of things, so Chassis can be within another Chassis. For example, a blade chassis is within a blade enclosure chassis, which is within a rack—also considered a chassis. The contains and <contained/code> by relationships are in the links section of the chassis object.

The Manager resource represents iLO 4 itself. For an example of how to iterate all the Manager resources in the data mode: Python: See ex7_find_iLO_MAC_address() in the Python example code.

**NOTE: **The top level loop using the collection iteration function with /rest/v1/Managers. After you GET the iLO object, including Manager, you can see the attributes, including Model and Firmware information and links to various iLO services. Services include the license service, network service, and iLO NIC information and configuration resources.

Each resource type has a schema file that defines the form of the object, allowed properties, required properties, types, and other information. The data model uses the draft 4 JSON Schema standard to do this. For more information, see: http://json-schema.org. To download a package for Python schema validation see: https://github.com/Julian/jsonschema. Packages are available for other languages to validate resources against the corresponding schema. This is part of the strategy to leverage industry-standard tool chains. Schema defines the class of resource and each instance of the class might implement a subset of the available properties. A client must be aware that not every property in the schema is implemented in every instance. Omissions might be the result of one or more of the following:

• The property might not apply to a specific HPE server model.

**NOTE: **Each property is identified as readonly = true or readonly = false. This indicates that a PATCH operation can be performed on the property, but only if the resource has an Allow header that allows PATCH. Two resources might share the same Type but have different Allow headers, that allow or disallow a PATCH operation, even for properties that are readonly = false .

There are two methods, online and offline, for finding the schema defines the data in the RESTful API. Online, means the schema information is available by performing a GET operation to iLO. Offline means the schema files are available on the HPE ProLiant Support Pack DVD.

The HPE Service Pack for ProLiant (SPP) contains a folder called hp_restful_api which contains several ZIP files consisting of the schema and registries of the RESTful API. Within this .zip file is a structure identical to the structure found in the RESTful interface on iLO except that you begin the search by reading either /Schemas/index.json or /Registries/index.json. The format of these two index.json files matches the SchemaFile.0.9.5 format of the iLO resources referenced by /rest/v1.Schemas/href. In addition, the SPP contains a .zip file of the published schemas and registries for the UEFI BIOS of each supported ProLiant server. Those .zip files are named as hp-rest-classes-bios-P89-1.00_07_11_2014.zip, where the P89 is the ROM family name (for each ProLiant system), and the 1.00-07_011_2014 is the ROM version and date. To download the offline schema and registry .zip files, see: www.hpe.com.

Resources in the RESTful API are typed by name and version (e.g.“ServiceRoot.1.0.0"). This provides enough information to identify not only the correct schema but also the precise version. There are cases where the precise schema version may not be available either online or offline (for example a BIOS update may use a newer schema than iLO presents in its schema repository.) For this reason it is necessary for client code to perform some form of best match when searching schemas. For instance, a resource may be of type <“HpBaseConfigs.1.1.0”/code> and the only schema available is “HpBaseConfigs.1.0.3” or vice versa.

In order to facilitate best match, the following guidance is offered:

1. A schema file (offline in a folder) is typically named for the schema with a .json extension, but this is not the official name of the schema. The official name base name of the schema is included in the title property of the schema object. Additionally, because of some type renames in Redfish, sometimes an old name of the schema is available in an oldtitle property.

2. The major version of a schema, along with the name, defines a compatible family of schema. For example, EthernetInterface.2.x.y is not necessarily compatible with EthernetInterface.1.x.y. The exception is version 1 should be considered forward compatible with version 0 schema because the version 0 to 1 transition is a maturing of the initial versions of the schema.

3. Higher minor and errata version numbers indicate forward compatible differences. For example, EthernetInterface1.1.1 is a superset of EthernetInterface.1.0.0, so if a client is only using 1.0.0 property definitions, the client may use the 1.1.1 schema as easily as the 1.0.0 schema. However, if the client needs to use properties new to 1.1.1, the new data is not present in a resource of type 1.0.0.

One possible _best-match _schema algorithm might attempt to calculate the mathematical difference between the version of a resource and all candidate schema, and choose the schema with the smallest difference.

This section contains examples to complete a specific task using the REST API for iLO.

Python is a popular language for REST API development and includes powerful tools for rest queries. The following is a simple example of a python query to the ServiceRoot resource:

images/Accessing the RESTful API for iLO using Python.PNG

This is a simple request example that shows the basic libraries involved and how to properly form the request. There are many additional parameters that can be used to tighten or loosen the security around SSL and the certificate verification process. The httplib documentation provides a more robust picture of the libraries capabilities. Beyond the built-in libraries like httplib, there are many other popular libraries available for Python to perform REST operations. The requests library is one of the most popular HTTP python libraries available today, and is also well suited for REST API development. To see a more complete set of how to use Python with the RESTful API, review the set of examples at https://github.com/HewlettPackard/python-proliant-sdk .

The examples in this section are not applicable to Moonshot servers running iLO Chassis Manager.

NOTE: The RESTful API for iLO can be used to change BIOS settings on HPE ProLiant Gen9 servers or later.

To GET the current BIOS configuration: The RESTful API for iLO enables a UEFI BIOS configuration. BIOS is a system-level entity on current architectures. The link to the BIOS configuration is from the computer system node object. SystemCollection = GET /rest/v1/Systems For each item in SystemCollection.links.Member # this is a collection System = GET item.href
BIOS = GET System.Oem.Hp.links.BIOS.href

The result of the GET BIOS operation is in a flat object. You cannot use PATCH to update a property value. You can only perform GET operations on this resource.

The current configuration object for BIOS is read only. This object contains a link to a Settings resource that you can perform a PATCH operation on, which is the pending settings. If you <GET/code> the <Settings/code> resource, you will see that it allows PATCH commands. You can change properties and then PATCH them back to the Settings URI. Changes to settings do not take effect until the server is reset. Before the server is reset, the current and pending settings are independently available. After the server is reset, the pending settings are applied and you can view any errors in the SettingsResults property on the main object. Using two separate resources offers the following benefits:

• Enables offline components (for example, BIOS) to process changes to settings in a deferred manner.
• Allows current and pending values to remain available for review until the offline component processes the pending settings.
• Avoids the need for complex job queues.

The BIOS current configuration object contains a link to a separate read-only object, the BaseConfigs, which list the BIOS default settings.

You can GET the BIOS BaseConfigs resource: SystemCollection = GET /rest/v1/Systems For each item in SystemCollection.links.Member # this is a collection System = GET item.href
BaseConfig = GET BIOS.links.BaseConfigs.href BIOS = GET System.Oem.Hp.links.BIOS.href

Notice that BaseConfigs contains an array of default sets (or base configuration sets). Each base config set contains a list of BIOS properties and their default values. The default base config set contains the BIOS manufacturing defaults. It is possible for BaseConfigs to contain other sets, like default.user for user custom defaults.

The BIOS resources are formatted differently than most other resources. BIOS resources do conform to a schema type as all objects do. However, BIOS settings vary widely across server types and BIOS revisions, so it is extremely difficult to publish a standard schema defining all the possible BIOS setting properties. Furthermore, it is not possible to communicate some of the advanced settings such as inter-setting dependencies, and menu structure in json-schema. Therefore, BIOS uses an Attribute Registry.

When you GET the BIOS configuration object, observe that it still has the basic structure including a Type. However, it also has a property called AttributeRegistry. This property points to a registry file. This file contains a set of data for each BIOS setting (for example, PowerProfile) including menu structure information, any dependencies with other settings, and other information.

To find the BIOS Attribute registry resource:

SystemCollection = GET /rest/v1/Systems For each item in SystemCollection.links.Member # this is a collection System = GET item.href
BIOS = GET System.Oem.Hp.links.BIOS.href AttributeRegistryName = the value of the "AttributeRegistry" property in BIOS object RegistryCollection = GET /rest/v1/Registries
For each item in RegistryCollection.links.Member # this is a collection Registry = GET item.href If Registry.Schema beginswith AttributeRegistryName For each language in Registry.Location If language.Language == "en" # or choose another AttributeRegistry = GET language.Uri.extref

Due to their size, BIOS Attribute Registries are compressed JSON resources (gzip), so the returned HTTP headers indicate a content-encoding of gzip. The REST client will need to decompress the resource. This is done automatically when using a web client (like the Postman plugin).

• Attributes: List of BIOS attributes (settings) and their meta-data, including: **Type of each BIOS attribute (enum, string, numeric, or Boolean).
• Possible values for enum type attributes.
• Display strings (localized to the registry language) for the attributes and their possible values.
• Help text and warning text (localized). *Location and display order information, including menu hierarchy for an attribute. *Value limits, including maximum, minimum, and step values for numeric attributes, and minimum and maximum character lengths, as well as regular expressions for string attributes. *And other meta-data.

The BIOS Attribute Registries contains three top-level arrays:

• Menus: Array containing the BIOS attributes menus and their hierarchy. This can be used (for instance) to build a user interface that resembles the local BIOS Setup, or to group properties that are related such as ProcessorOptions and UsbOptions.
• Dependencies: Array containing a list of dependencies of BIOS attributes on this server. This includes inter-setting dependencies that might cause one BIOS setting to change its value or its ReadOnly property based on the value of another BIOS setting.
• BaseConfigs: Array containing a list of default manufacturing settings of BIOS attributes. This is equivalent to reading the BaseConfigs resource and parsing the object named default. Update the BIOS passwords example To change the Administrator and Power On passwords, you must change two properties for each password:
• Administrator password: Set AdminPassword to the new password and OldAdminPassword to the old password.
• Power On password: Set PowerOnPassword to the new password and OldPowerOnPassword with the old password. If you the old password is not set, you must use a blank string ("") for the old password property.

1. Iterate through /rest/v1/Systems and choose a member ComputerSystem. Result = {ilo-ip-address}/rest/v1/Systems/1/BIOS
2. Find a link in the Oem/Hp/links called Bios and note the BiosURI.
3. GET BiosObj from BiosURI and note that it only allows GET (this is the current settings).
4. Find a link in BiosObj called Settings and note this URI.
5. Create a new JSON object with the AdminPassword and OldAdminPassword property changed to {"AdminPassword":"@Pa$$w0rd", "OldAdminPassword":""}.
6. Update the BIOS settings. You only need to send the updated AdminName property in the request body. PATCH {ilo-ip-address}/rest/v1/Systems/1/BIOS/Settings When the server is reset, the BIOS settings are validated and adopted.

• Minimum required session ID privileges: Configure

Updating the BIOS Settings Example

1. Iterate through /rest/v1/Systems and choose a member ComputerSystem. Result = {ilo-ip-address}/rest/v1/Systems/1/BIOS

2. Find a link in the Oem/Hp/links called Bios and note the BiosURI. 3. GET BiosObj from BiosURI and note that it only allows GET (this is the current settings). 4. Find a link in BiosObj called Settings and note this URI. 5. Obtain the BIOS settings using the URI from step 4. GET {ilo-ip-address}/rest/v1/Systems/1/BIOS/Settings 6. Create a new JSON object with the AdminName property changed to {"AdminName":"Joe Smith"}. 7. Update the BIOS settings. You only need to send the updated AdminName property in the request body. PATCH {ilo-ip-address}/rest/v1/Systems/1/BIOS/Settings 8. Obtain the BIOS settings to verify you made the change to the AdminName property. GET {ilo-ip-address}/rest/v1/Systems/1/BIOS/Settings When the server is reset, the BIOS settings are validated and adopted.

• Minimum required session ID privileges: Configure Enabling BIOS UEFI Secure Boot example

1. Iterate through /rest/v1/Systems and choose a member ComputerSystem. Find a child resource of type HpSecureBoot that allows PATCH operations (there might be more than one but for this exercise, just choose the first one). {ilo-ip-address}/rest/v1/Systems/1/SecureBoot
2. Obtain the secure boot settings. GET {ilo-ip-address}/rest/v1/Systems/1/SecureBoot
3. Create a new JSON object with the SecureBootEnable property changed to {"SecureBootEnable":true}.
4. Update the secure boot settings. You only need to send the updated SecureBootEnable property in the request body. PATCH {ilo-ip-address}/rest/v1/Systems/1/SecureBoot When the sever is reset, the boot settings are validated and adopted.

The BIOS Settings resource supports a special feature that allows you to revert BIOS settings to default for the selected resource. This is accomplished by performing the PATCH or PUT operation on a special property in the BIOS settings object: {"BaseConfig": "default"}. This can be combined with other property sets to first set default values and then set specific settings all in one operation.

NOTE: The BaseConfig property might not already exist in the BIOS or BIOS Settings resources. To determine if the BIOS resource supports reverting the settings to default, GET the BIOS BaseConfigs resource, and view the Capabilities property.

• Minimum required session ID privileges: Configure Revert BIOS UEFI settings to default example

1. Iterate through /rest/v1/Systems and choose a member ComputerSystem. Find a child resource of type HpBios that allows PUT operations (there might be more than one but for this exercise, just choose the first one). {ilo-ip-address}/rest/v1/Systems/1/BIOS/Settings
2. Obtain the BIOS UEFI settings. GET {ilo-ip-address}/rest/v1/Systems/1/BIOS/Settings
3. Change or add the BaseConfig property to {"BaseConfig":"default"} in the response body.
4. Update the BIOS UEFI settings. PUT {ilo-ip-address}/rest/v1/Systems/1/BIOS/Settings When the sever is reset, the BIOS UEFI settings are reverted to default. NOTE:

• You might also view the default values for BIOS settings by finding the resource type HpBaseConfigs. {ilo-ip-address}/rest/v1/Systems/1/BIOS/BaseConfigs
• BaseConfig can be combined with other property values to first reset everything to default and then apply some specific settings in one operation.

The iSCSI Software Initiator allows you to configure an iSCSI target device to be used as a boot
source. The BIOS current configuration object contains a link to a separate resource of type HpiSCSISoftwareInitiator. The BIOS current configuration resource and the iSCSI Software Initiator current configuration resources are read-only. To change iSCSI settings, you need to follow
another link to the Settings resource, which allows PUT and PATCH operations.

The iSCSI target configurations are represented in an iSCSIBootSources property, that is an array of objects, each containing the settings for a single target. The size of the array represents the total number of iSCSI boot sources that can be configured at the same time. Many mutable properties exist, including iSCSIBootAttemptInstance, which can be set to a unique integer in the range [1, N], where N is the boot sources array size. By default, this instance number is 0
for all objects, indicating that the object should be ignored when configuring iSCSI.

Each object also contains two read-only properties--StructuredBootString and UEFIDevicePath, which are only populated after the target has been successfully configured as a boot source. More information about each property is available in the corresponding schema.

The iSCSI initiator name is represented by the iSCSIInitiatorName property. An additional read-only property, iSCSINicSources, is only shown in the iSCSI current configuration resource. This property is an array of strings representing the possible NIC instances that can be used as targets for iSCSI boot configuration. To confirm which NIC device each string corresponds to, it is recommended to cross-reference two other resources:

• A resource of type HpBiosMapping can be found through a Mappings link in the BIOS
  current configurations resource. Within its BiosPciSettingsMappings property is an
  array of mappings between BIOS-specific device strings (such as the NIC source string) and
  a CorrelatableID string that can be used to refer to the same device in non-BIOS contexts.

* A collection of HpServerPciDevices may be found through a PCIDevices link in the ComputerSystem resource. The specific PCI device corresponding to the NIC instance can be found by searching for the CorrelatableID that will usually match a UEFIDevicePath. Once the HpServerPciDevice resource is found, you have access to all the human-readable properties useful for describing a NIC source.

Changing the iSCSIBootSources and iSCSIInitiatorName settings can be done through PATCH operations, very similar to how HpBios settings are changed. However, whereas all BIOS settings are located in a single flat object, iSCSI settings are nested into arrays and sub-objects. When doing a PATCH operation, use empty objects ({}) in place of those boot source objects that
you do not want to alter.

Example 1 Configuring the iSCSI Software Initiator example This example covers a situation where you have configured two iSCSI boot sources, and you would like to edit some existing settings, and add a third source.

1. Iterate through /rest/v1/Systems and choose a member ComputerSystem. Find a child
   resource of type HpiSCSISoftwareInitiator that allows PATCH operations. {ilo-address}/rest/v1/Systems/1/BIOS/iSCSI/Settings
2. Inspect the existing iSCSIBootSources array. You need to inspect the iSCSIBootAttemptInstance property of each object to find the boot sources you are prefer to change. Existing example resource: {
   "iSCSIBootSources": [
   {
   "iSCSIBootAttemptInstance": 1,
   ...
   },
   {
   "iSCSIBootAttemptInstance": 2,
   ...
   },
   {
   "iSCSIBootAttemptInstance": 0,
   ...
   },
   {
   "iSCSIBootAttemptInstance": 0,
   ...
   }
   ],
   ...
   }
   
3. Create a new JSON object with the iSCSIBootSources property.
   {
   "iSCSIBootSources": [
   {},
   {
   "iSCSIConnectRetry": 2
   },
   {
   "iSCSIBootAttemptInstance": 3,
   "iSCSIBootAttemptName": "Name",
   "iSCSINicSource": "NicBootX",
   ...
   },
   {}
   ]
   }
   

Use an empty object in the position of instance 1 to indicate that it should not be modified. Use an object in the position of instance 2 containing the properties that should be modified--all omitted properties will remain unmodified.

To add a new boot source, find any position of instance 0 and replace it with an object containing all the new settings, and most importantly, a new unique value of iSCSIBootAttemptInstance.

4. Change the iSCSI software initiator settings. PATCH {ilo-address}/rest/v1/Systems/1/BIOS/iSCSI/Settings

This UEFI boot structured name string is unique and represents each UEFI boot option in the system.
Software can identify and manipulate devices using the string's fixed format as defined in this
specification. Software can assume that the string unique for each boot device in the UEFI BootOrder.
The UEFI boot structured name string is divided into sections separated by `.' characters, using the
following format: <DeviceType>.<Location>.<Instance>.<Sub-instance>.<Qualifier> *** DeviceType**: The first section describes the device type (For example, HD, CD, NIC, and PCI.).

• Location: The second and the third section together describes the location of the device (For
  example, Slot.7 or Emb.4).
  
• Instance: The third section is used with the Location section to describe the device location (for example, the slot number or embedded instance number).
• Sub-instance: The fourth section is optional, and is used as a sub-instance number in case of multiple boot options using the same instance. For example, this can be the port number for
  a multi-port NIC.
• Qualifier: The fifth section is optional, and describes the logical protocol (for example, IPv4,
  IPv6, and iSCSI). The Structured Boot String information is part of the BootSources[]property in the HpServerBootSettings object and the StructuredName property in the HpServerPciDevice object.

The BIOS current configuration object contains a link to a separate read-only resource of type HpServerBootSettings that lists the UEFI Boot Order current configuration. This is the system
boot order when the system is configured in the UEFI Boot Mode. The UEFI Boot Order current
configuration resource contains a BootSources property, which is an array of UEFI boot sources. Each object in that array has a unique StructuredBootString, among other properties that identify that boot source.

The UEFI boot order list itself is represented in a separate PersistentBootConfigOrderproperty that is an ordered array of boot sources, each referenced by its StructuredBootString. In addition, a DesiredBootDevices property lists a separate ordered list of desired boot sources that might not be listed in the BootSources property. This is useful for configuring boot from a specific SCSI or FC LUN or iSCSI target that might have not
been configured (and discovered by BIOS) yet.

As with the BIOS current configuration resource, the UEFI Boot Order current configuration resource is read only (as evident by the allow header, which do not list PATCH as an allowed operation). To change the UEFI Boot Order, you need to follow the link to a separate Settings resource that you can perform a PATCH operation on that contains the pending UEFI Boot Order settings, and Examples using the RESTful API for iLO update that PersistentBootConfigOrder and/or the DesiredBootDevices properties in that Settings resource. The settings remain pending until next reboot, and the results are reflected back in the SettingsResults property in the UEFI Boot Order current configuration resource. Update that PersistentBootConfigOrder and/or the DesiredBootDevices properties in that Settings resource. The settings remain pending until next reboot, and the results are reflected back in the SettingsResults property in the UEFI Boot Order current configuration resource.

• Minimum required session ID privileges: Configure Changing UEFI boot order example

1. Iterate through /rest/v1/Systems and choose a member ComputerSystem. Find a child resource of type
   HpServerBootSettings that allows PATCH operations (there might be more than one but for this exercise, just
   choose the first one). {ilo-ip-address}/rest/v1/Systems/1/BIOS/Boot/Settings
2. Obtain the UEFI boot order. GET {ilo-ip-address}/rest/v1/Systems/1/BIOS/Boot/Settings
3. Create a new JSON object with the PersistentBootConfigOrder property and change the boot order.
4. Change the UEFI boot order. You only need to send the updated PersistentBootConfigOrder property in the request body. PATCH {ilo-ip-address}/rest/v1/Systems/1/BIOS/Boot/Settings

When the sever is reset, the new boot order is validated and used.

If you have enabled a BIOS administrator password, you must supply extra information upon a
BIOS Settings PATCH or PUT operation. The PATCH or PUT operation must include an extra HTTP header:

Reseting all BIOS and boot order settings to factory defaults

1. Iterate through /rest/v1/Systems and choose a member ComputerSystem. Find a child resource of type
   HpBios that allows PATCH operations (there might be more than one but for this exercise, just choose the first one). {ilo-ip-address}/rest/v1/Systems/1/BIOS/Settings
2. Obtain the BIOS and boot order settings. GET {ilo-ip-address}/rest/v1/Systems/1/BIOS
   
3. Create a new JSON object with the RestoreManufacturingDefaults property and change the value to yes.
4. Reset the BIOS and boot order settings. You only need to send the updated RestoreManufacturingDefaults
   property in the request body. PATCH {ilo-ip-address}/rest/v1/Systems/1/BIOS

Server power control is a system-node-level entity, not a chassis-level control. For example, you
can turn on one node in a multi-node chassis. You control power by performing an HTTP operation
on a computer system node object. For more information about computer system node objects see Computer System.

Some operations in the interface are not truly RESTful GET, PUT, POST, DELETE, or PATCH. They are called custom actions and are performed with an HTTP POST containing a specific request
payload. Typically, actions are defined when the action you want to perform is not adequately
represented by the properties available in the type. For example, a power button is not readable,so you cannot GET the status of the power button. In this case, pressing the power button is an action. Actions are POST operations with an Action property that names the action to perform and zero or more parameter properties.

• Minimum required session ID privileges: Configure Resetting a server example

1. Iterate through /rest/v1/Systems and choose a member ComputerSystem that allows POST operations. {ilo-ip-address}/rest/v1/Systems/1
2. Construct an Action object to submit to iLO. {"Action":"Reset","ResetType":"ForceRestart"}
3. Change the Action and ResetType properties to {"Action":"Reset","ResetType":"ForceRestart"}.
4. Reset the server. POST {ilo-ip-address}/rest/v1/Systems/1 The server resets and reboots.
   

Error messages appear in several places in the RESTful API for iLO.

• An immediate response to an HTTP operation.
• A SettingsResult in the data model where other providers, such as BIOS, processed the
  settings at some point and want to communicate status in the model.

All error cases use a basic error JSON structure called ExtendedError (ExtendedInfo in
Redfish), which has a Type of ExtendedError.0.9.5. The most important property in
ExtendedError is MessageID, a string containing a lookup key into a message registry.

MessageID helps to keep the iLO service small by keeping much of the explanatory text for an
error out of the code. Instead, iLO supplies an ExtendedError response, where the MessageID
provides enough information so that you can look up more details from another file. For example, if you POST to the iLO license service to install an iLO license, but you supply an
incorrect key string, iLO responds with an error similar to the following: HTTP response 400
{
"Type": "ExtendedError.0.9.5",
"MessageID": "iLO.1.0.InvalidLicenseKey"}

HTTP response 400 is the standard RESTful API response to an error. In the example above, the error is easy to understand, but some errors are not easy to understand. To display a more
meaningful error message, parse the string iLO.0.9.InvalidLicenseKey into the following components:

• iLO.0.9--This is the base name of the message registry to consult. Look for a matching registry file.
• InvalidLicenseKey--This is the lookup key into the message registry.
  

The search returns a result similar to the following: "InvalidLicenseKey":{
"Description": "The supplied license key is not valid.",
"Message": "The supplied license key is not valid.",
"Severity": "Warning",
"NumberofArgs": 0,
"ParamTypes": [],
"Resolution": "Provide a valid license key."
}

Many error messages can also return parameters. These parameters might be plugged into the
strings in the registry to form detailed messages tailored to the instance of the error message

When developing a client for the RESTful API, be sure to not code based upon assumptions that are not guaranteed. The reason avoiding these assumptions is so important is that implementations may vary across systems and firmware versions, and we want your code to work consistently.

The RESTful API is a hypermedia API by design. This is to avoid building in restrictive assumptions to the data model that will make it difficult to adapt to future hardware implementations. A hypermedia API avoids these assumptions by making the data model discoverable via links between resources.

The client should not interact with a URI as if it will remain static. Only specific top-level URIs (any URI in this sample code) can be assumed as static.

All URIs, with the exception of known top-level URIs, must be discovered dynamically by following
the href links in the data model. Clients should not make assumptions about the URIs for the resource
members of a collection. For instance, the URI of a collection member will NOT always be /rest/v1/.../collection/1, or 2. On Moonshot a System collection member might be
/rest/v1/Systems/C1N1.

Although the resources in the data model are linked together, because of cross link references
between resources, a client may not assume the resource model is a tree. It is a graph instead, so
any crawl of the data model should keep track of visited resources to avoid an infinite traversal
loop.
A reference to another resource is any property called href (@odata.id in Redfish) no matter
whereit occurs in a resource. An external reference to a resource outside the data model is referred to by a property called
"extref". Any resource referred to by extref should not be assumed to follow the conventions of the
API.

Type Names and Versions
Each resource has a Type property with a value of the format Typename.x.y.z where:
·

• x = major version - incrementing this is a breaking change to the schema.
  
• y = minor version - incrementing this is a non-breaking additive change to the schema.
  
• z = errata - non-breaking change. . For example alternate description text, spelling fixes, and
  so forth.
  

When POSTing to create a resource (e.g. create an account or session), a successful response
includes a Location HTTP header indicating the resource URI of the newly created resource. The
POST may also include a representation of the newly created object in a JSON response body
but may not. Do not assume the response body, but test it. It may also be an ExtendedError
object.

All clients must correctly handle HTTP redirect (e.g. 308, 301, and so on.) iLO 4 will use redirection
as a way to alias portions of the data model and to migrate the data model to the Redfish specified
URIs (for example, /redfish/...).

In the future some operations may start asynchronous tasks. In this case, the client should recognized
and handle HTTP 202 if needed and the Location header will point to a resource with task
information and status.

The json-schema available at /rest/v1/Schemas governs the content of the resources, but keep
in mind:

• not every property in the schema is implemented in every implementation.
  
• some properties are schemed to allow both null and another type like string or integer.
  Robust client code should check both the existence and type of interesting properties and fail
  gracefully if expectations are not met.

Clients should always be prepared for:

• Unimplemented properties (for example, a property doesn't apply in a particular case)<
• Null values in some cases if the value of a property is not currently known due to system
  conditions
  
• HTTP status codes other than 200 OK. Can your code handle an HTTP 500 Internal Server
  Error with no other info
• URIs are case insensitive
  
• HTTP header names are case insensitive
  
• JSON Properties and Enum values are case sensitive
  
• A client should be tolerant of any set of HTTP headers the service returns
  

Starting with iLO 4 2.30, iLO now features a new event subscription service that enables you to
subscribe to receive notifications when the REST data changes or when certain alerts occur. These
notifications are in the form of HTTPS POST operations to a URI of your choice.
The event service is located in the data model at /rest/v1/EventService. This resource includes a
link to a collection of subscriptions (called EventSubscriptions located at
/rest/v1/EventService/EventSubscriptions).

In order to receive events, you must provide an HTTPS server accessible to iLO's network with a
URI you designate as the target for iLO-initiated HTTPS POST operations.
Construct a JSON object conforming to the type ListenerDestination (see example) and
POST this to the collection indicated by the EventSubscriptions link at
/rest/v1/EventService/EventSubscriptions. If you receive an HTTP 201 Created
response, a new subscription has been added. Note that iLO does not test the destination URI
during this phase, so if the indicated URI is not valid, this will not be flagged until events are emitted
and the connection to the destination fails.

Much of the above content depends entirely upon your needs and setup:

• Destination must be an HTTPS URI accessible to iLO's network.
  
• EventTypes in the example is everything but you could remove types from the array.
  
• HttpHeaders gives you an opportunity to specify any arbitrary HTTP headers you need for
  the event POST operation. Note that the subscription is readable via GET to an authorized
  iLO user.
  
• Context may be any string.
  

Consult the ListenerDestination schema for more details on each property. The subscription
will automatically expire after the TTL information specified and must be renewed.

HPE ProLiant Gen9 servers could possibly experience a RESTful API error during system boot that
results in inability to configure the BIOS settings using the RESTful API and you can use this
workaround to resolve it. In addition, the following persistent error message might display during
system boot (POST) and is logged to the Integrated Management Log: 335 RESTful API Error- RESTful API PUT request failed (HTTP: Status Code = 404)

With iLO firmware v2.20 or later, you can reset the REST API. You do this through the
RESTful API using any 3rd party REST web client, the HPE RESTful interface tool, or from the HPE
Embedded UEFI shell restclient command.

Procedure 1 Resolution 1: resetting the RESTful API using a 3rd party REST web client: 1.Execute a POST operation to the resource at URI <ilo-ip>/rest/v1/managers/1 with
the following JSON in the request body.

2.Restart the server. For more information on how to use a 3rd party REST web client, see Managing HPE Servers Using
the RESTful API at http://www.hpe.com/info/restfulapi.

1. Download and install the HPE RESTful Interface Tool. For more information on using this tool,refer to http://www.hpe.com/info/resttool.
2. Copy and paste the following JSON into a text file and save it as hprest_tool_clear_api.json.

3. Start the hprest tool. hprest
   
4. Log in to iLO. hprest> login <ilo-ip>
   
5. Run the following command, pointing to the hprest_tool_clear_api.json file. hprest> rawpost hprest_tool_clear_api.json
6. Restart the server.

Procedure 3 Resolution 3: resetting the RESTful API using the HPE Embedded UEFI Shell
restclient command

1. Enter the Embedded UEFI Shell. For more information, refer to the HPE UEFI Shell User Guide
   at http://www.hpe.com/servers/proliant/uefi.
   

2. Copy and paste the following JSON into an ASCII text file save it as clear_api.json on
   FAT formatted USB media.
   

3. Attach the USB media to the server.
4. Turn on the server and boot to the HPE Embedded UEFI Shell.
   
5. At the UEFI shell prompt, use the partitions command to find the file system that corresponds
   to the USB media. For example, FS0, FS1, and so on.
   
6. To switch to the file system, type the file system name (for example, shell>FS0: ).
   
7. Execute the following command:
   Fs0:> restclient ­m POST ­uri "/rest/v1/managers/1" ­i clear_api.json
   
8. Restart the server.
   

Procedure 4 Resolution 4: Resetting the RESTful API using the iLO SSH CLI

1. Open an SSH connection with iLO, log in using an account with administrator privileges. For
   more information, see the HPE iLO 4 Scripting and Command Line Guide at http://www.hpe.com/info/iLO.
   
2. At the CLI prompt, execute the command oemhp_clearRESTAPIstate. Note that this
   command might take a few seconds to complete.
   
3. Restart the server.
   

The following table lists the additional REST API functionality available for Gen9 servers running
iLO 4 2.30 as compared to Gen8 servers running iLO 4 2.30.

• For live assistance, go to the Contact Hewlett Packard Enterprise Worldwide website:
  http://www.hpe.com/assistance
  

• To access documentation and support services, go to the Hewlett Packard Enterprise Support Center website:
  http://www.hpe.com/support/hpesc
  

• Technical support registration number (if applicable)
  
• Product name, model or version, and serial number
  
• Operating system name and version
  
• Firmware version
  
• Error messages
  
• Product-specific reports and logs
  
• Add-on products or components
  
• Third-party products or components
  

• Some software products provide a mechanism for accessing software updates through the product interface. Review your product documentation to identify the recommended software update method.
  
  To download product updates, go to either of the following:
  
• Hewlett Packard Enterprise Support Center Get connected with updates page:
  http://www.hpe.com/support/e-updates
  Software Depot website:
  http://www.hpe.com/support/softwaredepot
  
  
• To view and update your entitlements, and to link your contracts and warranties with your profile, go to the Hewlett Packard Enterprise Support Center More Information on Access to Support Materials page: http://www.hpe.com/support/AccessToSupportMaterials
  
• IMPORTANT: Access to some updates might require product entitlement when accessed through the Hewlett Packard Enterprise Support Center. You must have an HP Passport set up with relevant entitlements.
  

• HPE ProLiant Gen9 Server Management: http://www.hpe.com/servers/proliantgen9/docs
  
• HPE UEFI: http://www.hpe.com/info/ProLiant/servers/docs
  
• HPE Service Pack for ProLiant: http://www.hpe.com/servers/spp/documentation
  
• HPE iLO 4: http://www.hpe.com/info/ilo/docs
  
• HPE iLO University videos: http://www.hpe.com/info/ilo/videos
  
• HPE Systems Insight Manager: http://www.hpe.com/info/hpsim
  
• HPE Onboard Administrator: http://www.hpe.com/info/oa
  
• HPE VMware Vibs Depot: http://vibsdepot.hpe.com/
  
• Hewlett Packard Enterprise Information Library: http://www.hpe.com/info/enterprise/docs
  
• Hewlett Packard Enterprise Support Center: http://www.hpe.com/support/hpesc
  
• Contact Hewlett Packard Enterprise Worldwide: http://www.hpe.com/assistance
  
• Subscription Service/Support Alerts: http://www.hpe.com/support/e-updates
  
• Software Depot: http://www.hpe.com/support/softwaredepot
  
• Customer Self Repair: http://www.hpe.com/support/selfrepair
  
• Insight Remote Support: http://www.hpe.com/info/insightremotesupport/docs
  
• Serviceguard Solutions for HP-UX: http://www.hpe.com/info/hpux-serviceguard-docs
  
• Single Point of Connectivity Knowledge (SPOCK) Storage compatibility matrix: http://www.hpe.com/storage/spock
  
• Storage white papers and analyst reports: http://www.hpe.com/storage/whitepapers
  

RESTful API Data Model Reference
HPE iLO 4 Scripting and Command Line Guide
HPE iLO 4 Release Notes
HPE UEFI System Utilities User Guide
HPE ProLiant Gen9 Troubleshooting Guide, Volume I: Troubleshooting
HPE iLO Federation User Guide
HPE Service Pack for ProLiant Quick Start Guide

Hewlett Packard Enterprise customer self repair (CSR) programs allow you to repair your product. If a CSR part needs to be replaced, it will be shipped directly to you so that you can install it at your convenience. Some parts do not qualify for CSR. Your Hewlett Packard Enterprise authorized service provider will determine whether a repair can be accomplished by CSR.
For more information about CSR, contact your local service provider or go to the CSR website: http://www.hpe.com/support/selfrepair

Remote support is available with supported devices as part of your warranty or contractual support agreement. It provides intelligent event diagnosis, and automatic, secure submission of hardware event notifications to Hewlett Packard Enterprise, which will initiate a fast and accurate resolution based on your product’s service level. Hewlett Packard Enterprise strongly recommends that you register your device for remote support.
For more information and device support details, go to the following website: www.hpe.com/info/insightremotesupport/docs

Hewlett Packard Enterprise is committed to providing documentation that meets your needs. To help us improve the documentation, send any errors, suggestions, or comments to Documentation Feedback ([email protected]). When submitting your feedback, include the document title, part number, edition, and publication date located on the front cover of the document. For online help content, include the product name, product version, help edition, and publication date located on the legal notices page.