Click here a full PDF version of this document (NOTE: content below is a copy which may be formatted differently from the original PDF)

Introduction

For system administrators, updating firmware on a system can be irksome, time consuming, and can cause costly downtime. Many update methods require the administrator be onsite as well as remote, and often require that an operating system be installed before the update can commence.  In contrast, however, Dell™ iDRAC with Lifecycle Controller on PowerEdge™ servers makes firmware updates easy.

Dell iDRAC with Lifecycle Controller allows you to update your firmware remotely within a web user interface using an internet browser. If you happen to be onsite, you can also update the firmware using the Lifecycle Controller (LC) (type <F10> during boot at the system console). This method can also be run remotely using the iDRAC remote console application. 

A third option discussed here is a remote firmware update feature using a Common Information Model (CIM) method based on the DMTF standard through the Web Services for Management (WSMAN) protocol, a network transport service that enables the user to access a number of CIM style data access and methods supported by the target platform. The WSMAN protocol is transmitted through an SSL-encrypted HTTP connection. The server listens on firewall-friendly port 443, but can be configured to use a different port number. 

Remote Firmware Update Using WSMAN

Figure 1.            Firmware Update Schematic

Firmware update through WSMAN is performed remotely, and may be executed either directly or by the staged mechanism based on the component that is being updated. In the case of direct updates, the update package is downloaded from a repository (Item 3 in Figure 1) and applied without having to reboot the host machine. In staged updates, on the other hand, the update package is downloaded onto the iDRAC (Item 2 in Figure 1) and scheduled for application following a host reboot. The host reboot can be scheduled for immediate or later implementation using the Lifecycle Controller. This method can be used effectively to minimize downtime of the system during peak times.

While the firmware update using the WSMAN protocol uses a programming interface, the other update methods are interactive, and provide a user interface. Essentially, you can incorporate the update process into any application.  Since the WSMAN client is implemented in different programming languages, this can be very useful. More useful, however, is that you can immediately put this method into use using a couple of popular WSMAN client command line interfaces (Item 1 in Figure 1). The client system and the system hosting the repository can be in the same physical hardware.

Windows offers the WinRM CLI as well as more the capable Powershell WSMAN client, while Linux provides the open source OpenWSMan CLI—slowly becoming a standard component in Linux distributions. If your version of Linux does not already have it, download it from www.sourceforge.net.   Windows and Linux tools afford different options, but both have similar WSMAN client capabilities.

The data model and operations through WSMAN are defined by the DMTF standard CIM profile specifications. An inventory of existing firmware levels, defined in the “Software Inventory Profile” specification, as well as a basic knowledge and understanding of WSMAN, CIM, and Profile specifications are a prerequisite to conducting a successful firmware update. 

Dell iDRAC with Lifecycle Controller offers two types of update: updating to a newer firmware version, or rolling back to an older firmware version. The latter type is possible because iDRAC caches a copy of the previous firmware.

Determine Your Firmware Inventory

Prior to performing an update, you must know the existing firmware level to make an informed decision about whether to update or not.  In addition to this, the update profile specification requires that you must first be able to discover the device you are trying to update to determine whether or not it is possible to update at all, as well as acquire a unique firmware identification.

To discover current firmware levels and discover what firmware can be updated, perform a WSMAN enumerate command on CIM_SoftwareIdentity class using the CIM namespace “root/dcim”. This is the namespace to be used from here on.

<n1:DCIM_SoftwareIdentity>

  <n1:BuildNumber>0</n1:BuildNumber>

  <n1:DeviceID>1639</n1:DeviceID>

  <n1:ElementName>Broadcom NetXtreme... (Embedded 1-1)</n1:ElementName>

  <n1:InstallationDate>2010-07-24T21:04:16Z</n1:InstallationDate>

  <n1:InstanceID>DCIM:INSTALLED:PCI:14E4:1639:0237:1028:5.2.7</n1:InstanceID>

  <n1:MajorVersion>5</n1:MajorVersion>

  <n1:MinorVersion>2</n1:MinorVersion>

  <n1:RevisionNumber>7</n1:RevisionNumber>

  <n1:Status>Installed</n1:Status>

  <n1:SubDeviceID>0237</n1:SubDeviceID>

  <n1:SubVendorID>1028</n1:SubVendorID>

  <n1:VendorID>14E4</n1:VendorID>

  <n1:VersionString>5.2.7</n1:VersionString>

</n1:DCIM_SoftwareIdentity>

When looking at the result set of CIM_SoftwareIdentity enumeration, the first property of interest is the ElementName. It is a friendly description of the device of interest, embedded Broadcom network interface in the example in Figure 1. The second property of interest is the Status. Look for an instance where the value of Status is Installed. Next, examine the values of the rest of properties and determine whether you want or need to update this device.  Once you decide to update the device, save the value of InstanceID property. You will need this later.

Get the Proper Update Package

The next step is to download the proper update package.  The only supported update package is the “Update Package for Windows”. Download a later version of the firmware device of interest from support.dell.com. Dell recommends that you update firmware in small steps.  For example, update a firmware level from 5.2.7 to 5.3.0 but not from 5.2.7 to 5.4.0, versions which are almost one and a half revisions apart.  Dell also recommends that you update firmware level in groups. For example, update a level for BIOS, iDRAC, LC, NIC and RAID together before doing a second level update. That is, do not update BIOS two levels, followed by NIC with three levels, and so on.

Begin the Update Process

Once you know which device to update and you have identified and downloaded the proper update package, you are ready to begin the update process.

Figure 2.            Firmware Update Process

Transfer the Update Package to Lifecycle Controller

Once you have downloaded the update package, initiate the update process by transferring the package to Lifecycle Controller. The term “transfer” in this context may be referred to as “download” as well as “install”. The transfer (Item 1 in Figure 2) is accomplished by invoking the InstallFromURI() method of an instance of DCIM_SoftwareInstallationService class. The method input has two arguments. First is the URI property that instructs the method of transfer. Second is the Target property that contains the endpoint reference or EPR that represents the attribute instance to operate on.

You used enumerate in the previous sections to get an inventory of device firmware levels. You will use  the same class instances for the install method, although you will need to add the EPR enumeration mode and rerun the command.

Supported Methods for Transferring DUP Packages into iDRAC

FTP

This transfer mode has the following parts with user-provided values in yellow highlighted caps:

ftp://IPADRESS/LOCATION/DUPFILENAME

Example SOAP body for the InstallFromURI method:

<p:InstallFromURI_INPUT xmlns:p="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/DCIM_SoftwareInstallationService">

   <p:URI>ftp://192.168.0.111/DUPS/R620_BIOS_WIN_0.3.18.EXE</p:URI>

   <p:Target xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"

                   xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">

      <a:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>

      <a:ReferenceParameters>

         <w:ResourceURI>

            http://schemas.dell.com/wbem/wscim/1/cim-schema/2/DCIM_SoftwareIdentity

         </w:ResourceURI>

         <w:SelectorSet>

            <w:Selector Name="InstanceID">DCIM:INSTALLED#741__BIOS.Setup.1-1</w:Selector>

         </w:SelectorSet>

      </a:ReferenceParameters>

   </p:Target>

</p:InstallFromURI_INPUT>

HTTP

This transfer mode has the following parts with user-provided values in yellow highlighted caps:

http://IPADRESS/LOCATION/DUPFILENAME

Example SOAP body fragment for the InstallFromURI method:

...

<p:URI>http://192.168.0.111/DUPS/R620_BIOS_WIN_0.3.18.EXE</p:URI>

...

TFTP

This transfer mode has the following parts with user-provided values in yellow highlighted caps:

tftp://IPADRESS/LOCATION/DUPFILENAME

Example SOAP body fragment for the InstallFromURI method:

...

<p:URI>tftp://192.168.0.111/DUPS/R620_BIOS_WIN_0.3.18.EXE</p:URI>

...

CIFS Share

This transfer mode has the following parts with user-provided values in yellow highlighted caps:

cifs://USER:PASSWORD@IPADRESS/LOCATION/DUPFILENAME;mountpoint=MOUNTNAME

The USER value shall include the domain membership of the user. If running from command line, enclose the entire string in quotes so that it does not interpret reserved characters such as semi-colon.

Example SOAP body fragment for the InstallFromURI method:

...

<p:URI>cifs://WORKGROUP\Administrator:delldell@192.168.0.111/Inetpub/ftproot/diags/DIAGS_APP_LX_R214000.EXE;mountpoint=C$</p:URI>

...

NFS Share

This transfer mode has the following parts with user provided values in yellow highlighted caps:

nfs://IPADRESS/LOCATION/DUPFILENAME;mountpoint=MOUNTNAME

If running from command line, enclose the entire string in quotes so that it does not interpret reserved characters such as semi-colon.

Example SOAP body fragment for the InstallFromURI method:

...

<p:URI>nfs://192.168.0.111/DUPS/DIAGS.EXE;mountpoint=/var/ftp/diags</p:URI>

...

Monitor the Transfer

The response SOAP packet from the InstallFromURI method invocation request contains information about the operation status and Job detail if successful. The operation status is reported through the MessageID and Message properties. When successful, an instance of CIM_ConcreteJob class is provided in the response. A “Job” represents an action or operation that is currently executing in the server that will complete at a later time. The state of execution and the eventual completion status are reported by an instance of CIM_ConcreteJob class.

When the call to InstallFromURI is successful, the Job instance returned contains the Job ID from the InstanceID property that you will use to monitor the update execution (Item 2 in Figure 2). The initial state should be “new”.  You may continue at a certain interval to poll the status by performing a get on the Job instance. The interval may be tweaked due to varying configuration and environment.

Direct or Staged Update

Based on the mode of transfer, Lifecycle Controller will attempt to download the specified update package (Item 3 in Figure 2).  Once the transfer starts the status changes to downloading. Continue to monitor the status until it becomes downloaded. 

Depending on the device, the update may be applied right after the download; we use the term direct update to describe this. For a direct update, the status becomes complete when applied successfully (Item 30 in Figure 2), and you can stop here.

Scheduling the Update Execution

If the update is staged, the execution of the update must be scheduled or it will not be applied. The staged execution requires a restart of the system. Do this by invoking the CreateRebootJob() method from an instance of DCIM_SoftwareInstallationService class (Item 4 in Figure 2).  Take note of the reboot ID from the InstanceID property; you’ll use this later.

Next, invoke the SetupJobQueue() method from an instance of DCIM_JobService class where you provide the JobID you got from the transfer step, the RID you got from the reboot request, and the start time (Item 5 in Figure 2). The time may be some time in the future, or specify the value TIME_NOW to start immediately.

Monitor the Staged Update

Start monitoring the update from the time you specified in the previous step. First, monitor the reboot job. Simply issue a get operation on the RID you got from the previous step and wait for the status reboot completed (Item 6 in Figure 2).

Upon reboot, the update package will be applied during the System Services session in UEFI. This may take several minutes depending on the device. You may continue to monitor the update job until the status becomes complete (Item 7 in figure 2). The next steps allow you to verify the update by checking the firmware version reported by Lifecycle Controller, or you can stop here.

After the update completes, the system reboots from System Services at least once. During this time, you need to monitor the status of Remote Services by invoking the GetRSStatus() method from an instance of DCIM_LCService class. This is a two-step process. First monitor the RS status until it achieves reloading status (Item 8 of Figure 2). Thereafter, monitor the RS status until it becomes ready (Item 9 of Figure 2).  Now, you should be able to enumerate CIM_SoftwareIdentity class. Search the instances for the device you just updated. You should find Installed in the Element property signaling the update is finished.

How about a Rollback Update?

Lifecycle Controller stores a copy of previously installed firmware package of selected devices. It provides a rollback update capability which updates a device’s firmware to the previous version. To perform the rollback, invoke the InstallFromSoftwareIdentity() method from an instance of DCIM_SoftwareInstallationService class.  This method is unlike InstallFromURI() method in two aspects. First, it does not require a URI since there is no update package from which to transfer or download. The update package is already present in LC.  Second, the Target reference is an instance of DCIM_SoftwareIdentity that has a status of Available.

There is no transfer step upon invoking the InstallFromSoftwareIdentity() method. If the update is Direct, it will be applied immediately and you can stop and verify.  Otherwise, you can proceed to the “Scheduling the Update Execution” step discussed in previous section.

Example SOAP body for the InstallFromSoftwareIdentity method:

<p:InstallFromSoftwareIdentity_INPUT xmlns:p="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/DCIM_SoftwareInstallationService">

   <p:Target xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"

                   xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">

      <a:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>

      <a:ReferenceParameters>

         <w:ResourceURI>

            http://schemas.dell.com/wbem/wscim/1/cim-schema/2/DCIM_SoftwareIdentity

         </w:ResourceURI>

         <w:SelectorSet>

            <w:Selector Name="InstanceID">DCIM:AVAILABLE:NONPCI:159:3.0.0</w:Selector>

         </w:SelectorSet>

      </a:ReferenceParameters>

   </p:Target>

</p:InstallFromSoftwareIdentity_INPUT>

Device Support Matrix

This table shows staged update and rollback support for each device that can be updated through WSMAN.

Further Information

Web Services for Management (WSMAN)

Learn more about Firmware Inventory defined by the Dell CIM profile specification

Learn more about Firmware Update defined by the Dell CIM profile specification 

Learn more about Job Control as defined by the Dell CIM profile specification 

WSMAN Interface Guide for Linux 

WSMAN Interface Guide for Windows 

WSMAN command line open source for Linux (Openwsman)

WSMAN command line for Windows (Winrm)

All about Lifecycle Controller in iDRAC

Example scripts for Linux and Windows

Summary

Dell iDRAC with Lifecycle Controller gives you the “power to do more” with your time, efficiently, securely, and simply through standards-based WSMAN protocol and standards-based CIM data model. Updates can be applied independent of the host operating system. The entire process can be done remotely through the network with SSL encryption. The update process is based on a standards-based protocol and model which is readily scriptable on Windows and other operating systems with additional installation. Since it is standards-based, you can easily integrate the update workflow with console applications or any application with WSMAN client library support. The actual update execution can take place immediately or at a later scheduled time of your choosing.  Reduce your downtime, be efficient, and take control of your firmware.

THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND.

© 2011 Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell.

Dell, the DELL logo, and the DELL badge, and PowerEdge are trademarks of Dell Inc. Windows is a registered trademark of Microsoft Corporation in the United States and/or other countries. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell Inc. disclaims any proprietary interest in trademarks and trade names other than its own.

November 2011, Rev 1.0