This document 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.
This document contains the detailed steps of common workflows to perform various tasks utilizing
winRM or WSMAN. The PYTHON scripting language was used to provide a software development kit
(SDK) for Lifecycle Controller (LC) API methods. Two primary objectives are addressed: first, that
workflows documentation provides guidance to established, known, working API methodologies, and
second, that corresponding PYTHON sample scripts are separately provided. After invoking these
scripts, the output log can be used to provide approximate timing on a particular system configuration,
as well as raw winRM or WSMAN input and output.
1.2 Using the Sample Scripts
Refer to the appendix for a full text README.
Getting started:
1) Install Python 2.4 to 2.6
2) Download scripts folder to desired location; no installation necessary
Running a script:
1) cd to scripts directory
2) python recite.py (opens command prompt of application)
3) set $IP 12.34.56 (Enter actual IP)
4) log whateverfilename.log w (may use any name for filename)
Note: A .win file is simply a text file containing calls to the recite PYTHON script.
Other commands:
-help (lists all available commands)
-set (list current IP, username, password, etc.)
Notes:
File output will be placed in scripts directory
1.3 Improving winRM Enumeration Performance
When an enumeration command is executed, the default WinRM configuration gets only 20 instances at
a time and therefore slows down the system drastically. Changing the WinRM configuration to allow a
greater number, such as 50, will reduce the time taken by the enumeration operations.
Also see section 3.9 for using CQL filters on enumerations.
Execute the following command to get instances in groups of up to 50.
Additionally, increasing the allotted maximum envelope size and timeout can also increase
performance.
winrm set winrm/config @{MaxEnvelopeSizekb="150"}
winrm set winrm/config @{MaxTimeoutms ="60000"}
Other optional WinRM configuration commands are listed below for convenience. To get the current
WinRM configuration settings, execute the following command.
winrm g winrm/config
By default, the client computer requires encrypted network traffic. To allow the client computer to
request unencrypted traffic, execute the following command:
winrm s winrm/config/Client @{AllowUnencrypted="true"}
TrustedHosts is an array that specifies the list of remote computers that are trusted. Other computers
in a workgroup or computers in a different domain should be added to this list.
Note: The computers in the TrustedHosts list are not authenticated.
Execute the following command to allow all computers to be included in TrustedHosts.
winrm s winrm/config/Client @{TrustedHosts="*"}
Basic authentication is a scheme in which the user name and password are sent in clear text to the
server or proxy. This method is the least secure method of authentication. The default is True.
Execute the following command to set client computer to use Basic authentication.
winrm s winrm/config/Client/Auth @{Basic="true"}
1.4 Feature Discovery Procedure
There are four steps recommended to determining the feature set on a given system.
b. The output from above will list all available and installed firmwares and corresponding
firmware versions. Examining the version of these firmwares, such as Lifecycle
controller and iDRAC, can be used to determine the feature set
1.5 Profile Revision Number Explanation
Profile revision numbers are a key metric in determining the available feature set. Examples of
discovering, or obtaining, profiles are covered extensively in this document along with example output.
The example shown below is for the LC Management profile. Discovering a particular profile on a
system is a three step process.
1) Enumerate the DCIM_LCRegisteredProfile class to view all available profiles
2) Search the RegisteredName field for the desired profile
3) Search for the RegisteredVersion field, which is the characteristic used to identify the
Increments in the major change field indicate that the profile is not backward
compatible.
Increments in the minor change field indicate that one or more new methods
have been added.
Increments in the errata field indicate that one more defects have been fixed.
1.6 Lifecycle Controller and Lifecycle Controller 2
Nomenclature
This section describes the new terminology associated with the new generation of hardware and
Lifecycle Controller firmware (including iDRAC). The new hardware platform is generically referred to
as 12G and all corresponding Lifecycle Controller firmware will be LC2 with accompanying sub releases
(i.e. 1.0.0, 1.1.0, etc.). The table below summarizes both the past and current generational
nomenclature.
NOTE: Data within table is for illustration purposes only.
After the job is complete in Automated Task Application (previously SSM), the job status is immediately
updated in the job store. The job is moved immediately to the Completed state once it is complete in
the Automated Task Application. As seen in the timeline diagram above, after the job is Completed,
the sync happens in the configDB, and then the RS status goes to Reloading state. After all the required
populators are refreshed successfully, the RS status goes to Ready state. The user/console can see the
new values only when the RS status goes to the Ready state.
1.7.2 GetRemoteServicesAPIStatus and job status
The introduction of the new GetRemoteServicesAPIStatus method alleviates the ambiguity of the
GetRSStatus method regarding when the system is ready.
Figure 2. Typical Life Cycle of a 12G Configuration Job
Note: Dotted lines denote the old behavior. Bold red lines denote the new behavior in 12G.
After the job is complete in the Automated Task Application, those jobs that require a refresh – jobs
that have message IDs –JOB_SUCCESS and JOB_COMPLETED_ERROR will be kept in RUNNING state till
the new sync comes in and the Data Manager is moved to READY state.
Jobs that don’t require a refresh will be moved to complete immediately once the job is complete in
the Automated Task Application.
NOTE: Dotted lines denote the old behavior. Bold red line denotes the new behavior in 12G.
The existing 11G workflows expect the RS status to be in RELOADING state once the job is marked
COMPLETED. So to maintain the compatibility with the 11G workflows, the RS status is artificially held
in the RELOADING state for 90 seconds even though it is actually READY. This time limit was provided
by the console team.
The recommended algorithm is to schedule jobs such that MinBandwidths are first reduced, and then
increased. Essentially, delta values need to be sorted, and jobs scheduled in that order.
Consider the following example:
Current: 25, 25, 25, 25
Target: 30, 30, 20, 20
Since 20, 20 are both reducing values from 25, they should be scheduled first. This makes space for
increasing the other values. Next, values being increased can be scheduled – 30, 30.
A more complex example:
FQDD: 1, 2, 3, 4
Current: 5, 5, 50, 40
Target: 40, 50, 5, 5
Deltas: -35, -45, 45, 35
Order of job FQDDs: 3, 4, 1, 2
MinBandwidth limitations are documented in the Simple NIC Profile in section 6.7.
Blade cloning consists of a pull, enumerating attributes, and a push, applying attributes. The pull
command is a basic enumeration command using the DCIM_iDRACCardAttribute class.
Applies to: LC2+
Script: iDRACClonePull.win
A) The remote service must be in a “ready” state before executing any other WSMAN
commands. The GetRSStatus() method or the GetRemoteServicesAPIStatus() method may
be used depending on the version of the LC Management registered profile.
B) ENUMERATE the DCIM_iDRACCardAttribute class (same as DCIM_iDRACCardEnumeration
class) and store the results to be pushed. See section 2.2 for a definition of ENUMERATE .
The blade cloning push requires an extended WSMAN timeout of 120 seconds, versus the default of 60
seconds. This is needed because of the numerous amounts of attributes that need to be applied.
Below are Windows (winRM) and Linux (wsman) examples that apply all the iDRAC attributes. Replace
[IP_ADDRESS], [USER_NAME], and [PASS_WORD] with the actual IP address, username, and password.
An issue exists when setting NIC String parameters, such as IscsiInitiatorName, using the NIC menu
(usually entered via ctrl-s) from a non-blank value to a blank value.
As a result, when the NIC is used for operations that utilize this parameter, such as iscsi boot, the
operation will be unsuccessful because it will use the old value instead of the one displayed through
WSMAN.
The work around for this scenario is to not set any NIC String parameters to a blank value.
3.4 Determine NIC Card
There are two different ways to determine the model/type of a NIC card:
The following behavior describes a situation where setting certain iDRAC attribute(s) causes another
iDRAC attribute to automatically and simultaneously change.
Setting any of the following Telnet attributes causes the SerialRedirection attribute to become
Enabled.
Change the Telnet attributes prior to setting the SerialRedirection.Enable attribute. Or, if using
input XML, have the Telnet attributes before the SerialRedirection.Enable attribute.
3.7 Never Unplug Hardware During Updates
Users should not unplug any hardware during critical remote enablement (RE) updates. This may result
in unexpected behaviors.
As an example, unplugging a USB key during critical updates may cause a Red Screen of Death (RSOD).
3.8 Express Versus Enterprise iDRACs
There are four levels of iDRAC licensing as follows:
1) Basic
2) Express (Monolithic)
3) Express for blades(Modular)
4) Enterprise
One method of determining the level on a system is to perform an enumeration of the
DCIM_iDRACCardView class. Example results are shown for reference.
Monolithic:
DCIM_iDRACCardView
FQDD = iDRAC.Embedded.1-1
FirmwareVersion = 1.00.00
GUID = 3132334f-c0b7-3480-3510-00364c4c454
IPMIVersion = 2.0
InstanceID = iDRAC.Embedded.1-1#IDRACinfo
LANEnabledState = 1
LastSystemInventoryTime = 20120302092309.000000+000
LastUpdateTime = 20120305233206.000000+000
Model = Enterprise
PermanentMACAddress = 78:2b:cb:54:54:11
ProductDescription = This system component provides a complete set of remote management
functions
for Dell PowerEdge servers
SOLEnabledState = 1
FirmwareVersion = 1.00.00
GUID = 3132334f-c0b7-3480-3510-00364c4c454
IPMIVersion = 2.0
InstanceID = iDRAC.Embedded.1-1#IDRACinfo
LANEnabledState = 1
LastSystemInventoryTime = 20120121022852.000000+000
LastUpdateTime = 20120124015120.000000+000
Model = Express for Blades
PermanentMACAddress = d0:67:e5:f4:2f:97
ProductDescription = This system component provides a complete set of remote management
functions for Dell PowerEdge servers
SOLEnabledState = 1
3.9 CIM Query Language (CQL) Filters
The CIM Query Language (CQL) is a query language for the Common Information Model (CIM) standard
from the Distributed Management Task Force (DMTF). It was designed to perform queries against the
CIM objects in a database.
3.9.1 CQL filter benefits
The two most distinct advantages of using CQL filters when performing enumerations are:
The response time of enumerations will be accelerated as only the desired data is returned,
not the full data set.
The workload on the network will be decreased as less bandwidth will be consumed per
enumeration as the amount of data being returned is less. This is more applicable to networks
that may have many systems that performing enumerations at or about the same time.
3.9.2 How to perform CQL enumerations using RECITE
Section 1.2 describes how to setup and run scripts using the RECITE PYTHON environment. Running
CQL filters requires running the CQL command directly from the RECITE command line. No scripts exist
because of the infinite number of use cases.
3.9.3 CQL filter example that enumerates all NIC attributes for a particular
The FQDD in the example below will be unique to a particular user’s system. The NIC FQDDs of the
system can be obtained by running the GetNICViews() command from the RECITE command line.
3.10 Ordering of iDRAC Attributes to set or apply (11Generation
vs 12Generation)
Users need to correctly set the order in which iDRAC, System, and LC attributes are applied. Incorrect
ordering of attributes may result in an error, if dependencies are violated. The DisplayOrder field of
each attribute along with the applicable references in profiles, provide direction as to the appropriate
ordering.
An example would be to create an iDRAC user account. On 11G systems, the iDRAC would
automatically re-order the the attributes before setting/applying them to create and enable a user
account. However, due to the expansion of attributes in 12G systems as well as to avoid the
anticipating the user’s intent, re-ordering of attributes was removed.
The correct order for setting iDRAC attributes when enabling a user account on both 11G and 12G is as
follows:
This ordering is applicable to both ApplyAttributes() and SetAttributes() iDRAC methods. Use the
reverse order when clearing/disabling the account.
3.11 How to Determine if Server is 11Generation vs
12Generation
In order to determine if a server is 11G or 12G irrespective of the license present on the server, the
recommendation is to look at “LifecycleControllerVersion” property from DCIM_SystemView. If this
property is not shown or the value is 1.x.y then it is 11G system. If the value is 2.x.y then it is 12G.
Section 31.4 of this document describes the workflow for enumerating the DCIM_SystemView class.
3.12 Using Special Characters in Usernames
For 11G systems, usernames may not contain the characters: <, >, ‘, /.
For 12G systems, usernames may not contain the characters: /,\, @, ., !.
When an iDRAC user has angle brackets for the username or password, they must use double quotes
around the brackets when trying to execute any WSMAN commands.
3.13 Obtaining Updated System Inventory
Use the following procedure below to refresh stale inventory or to ensure the inventory has the
most up to date information. Collect System Inventory on Restart (CSIOR) is the mechanism which
checks and updates the inventory. CSIOR is run, when enabled, during the boot process.
Applies to: LC1.3.0+
A) [LC1.5.0+] The Lifecycle Controller remote service must be in a “ready” state before
executing any other WSMAN commands. The GetRSStatus() method or the
GetRemoteServicesAPIStatus() method may be used depending on the version of the LC
Management registered profile.
B) Ensure CSIOR attribute is enabled
See Section 31.3 to Check and enable Collect System Inventory on Restart (CSIOR)
NOTE: If an operating system has been installed, the system will boot into it. It
may be desired to wait until the OS boot is complete before performing a graceful
shutdown.
D) [LC1.5.0+] The Lifecycle Controller remote service must be in a “ready” state before
executing any other WSMAN commands. The GetRSStatus() method or the
GetRemoteServicesAPIStatus() method may be used depending on the version of the LC
Management registered profile.
When the system is ready, the inventory is updated
3.14 How to Determine if the System is Blade, Tower, or Rack
Dell has been officially using “M”, “T” and “R” letters in the Model name to distinguish between
“Modular”, “Tower” and “Rack” server respectively for the past couple of generations.
Getting the SystemGeneration attribute can be achieved by viewing the SystemView class. Section
31.4 of this document describes the workflow for enumerating the DCIM_SystemView class.