In my last post, I discussed the concept of DMTF Management Profiles and in this blog post I’m going to discuss applying them. Standards (particularly adopted ones) enable not only interoperability, but also reuse of tools. WS-Man enables a common remote management protocol. CIM Schema enables consistent models of management elements. DMTF Management Profiles enable consistent implementations of CIM models for a specific management domain. However, these standards are not sufficient for ITPros to easily manage their datacenter because although all the pieces are there, they were not designed to be easy to use (for ITPros).
PowerShell enables ITPros make easily make sense of this complexity, but only if there is an appropriate admin task abstracted cmdlet. In WMF3.0, we added new CIM cmdlets (get-ciminstance, invoke-cimmethod, etc…) that enable managing a remote CIM enabled node (over WS-Man by default), however, these cmdlets still require understanding of CIM, in some cases WS-Man, and certainly the DMTF Management Profile. These cmdlets were targeted more for the ITPro developer.
To solve this problem, I built a PowerShell module that uses the CIM cmdlets (and thus requires WMF3.0) and abstracts the details of CIM and Profiles to (mostly) simple admin task abstracted cmdlets. For the first release of this module, I’m targeting some common admin tasks: Getting hardware information, getting software information, getting and setting power state, getting and setting the boot order, getting the OS status, getting numeric sensors, and getting record logs and log entries.
Here I create two CimSessions, one to a desktop system that has the Broadcom DASH implementation and one to a desktop that has Intel’s AMT implementation. You’ll notice that the two systems listen on different ports. Port 623 is the HTTP port required by DASH conformant implementations. Intel’s AMT supports both the DASH port (623) as well as an AMT specific port. In this example, I illustrate what it would look like to use two different ports.
Now, let’s turn on the first system. Retrieving the power state again, you can see that we were able to remotely turn on that system even though the OS was not running and the hardware was in a sleep (standby) state. The RequestedState showing Offline is a known issue.
Next, let’s gather some inventory information which uses multiple Management Profiles. Here you can see that the default formatting only shows a summary in tabular format while piping the same output to a list view shows all the information returned by the two respective implementations. Also notice that in many cases, I use the CIM values/valuemap data to convert integers to their textual counterparts.
Next, let’s see what software (meaning firmware in the case of hardware) is on these two systems:
Finally, a common operation you would want to do in hardware is to change the boot order. For example, let’s say you wanted to do a one-time network (PXE) boot to install the operating system. Here, we retrieve the current boot sources and configuration. Then we change the boot source to Network and finally retrieve the boot information again to confirm the change will be used:
As you can see, the complexities of CIM and Management Profiles are hidden with the PowerShell module so the ITPro only needs to focus on the tasks they care about without needing to understand the implementation details. The module itself is written as PowerShell script so you can see how everything works. You’ll note that I have many TODOs in the module which means that I will continue to improve upon this module with additional capabilities in the future.
The module is available on TechNet here: PowerShell Out-of-Band Hardware Management Module
Steve Lee [MSFT]
Principal Test Manager
Standards Based Management