Standards Based Management: DMTF Management Profiles
The investments we’ve made in Windows Server 2012 (and WMF3.0) for standards based management is built around WS-Man as the remoting protocol (HTTP is the transport) and CIM as the model. By themselves, WS-Man and CIM are useful, but may not provide a consistent experience when managing a similar class of devices or management domain. What I mean by this is that the DMTF has provided a very rich set of schema, however, different OEMs may implement different classes, methods, or properties so although they implement the CIM Schema, a management client does not have consistency/predictability and must handle all possible situations.
Management Profiles are a solution to this problem. Management profiles as defined by the DMTF:
“A Profile, which may be specified in documents published by the DMTF or in specifications created by other organizations, defines the CIM model and associated behavior for a particular management domain (including the CIM classes, associations, indications, methods and properties). This provides a unified way of describing the management domain in CIM, which contributes to interoperability and helps with ease of use.
Each profile identifies unambiguously the classes, properties, methods and values that should be instantiated and manipulated to represent and manage a given domain.” –DMTF Management Profiles
What this means is that Profiles provide normative text on how to implement CIM Schema for a specific management domain so that the management client can expect certain behaviors predictably as long as the managed node claims conformance to a specific Profile (or set of Profiles). It should be noted that Profiles are not required to be published/standardized by the DMTF. OEMs are allowed to make custom extensions and expose them through OEM specific Profiles.
One of the key Profiles that make this all work is the Profile Registration Profile. This specific Profile describes how a managed node publishes the Profiles it has implemented so that the initial discovery is a well known workflow:
1. Discover the Interop namespace
2. Find the specific CIM_RegisteredProfile you are interested in primarily by filtering against the RegisteredName (ie, Boot Control) and RegisteredVersion (ie, 1.0.0)
3. Perform a association traversal (which may cross namespaces) to the central class of that Profile (ie, CIM_ComputerSystem) via CIM_ElementConformsToProfile association class
4. Start managing based on details in the specific Management Profile
The two key benefits you get from this:
1. OEMs must implement an Interop namespace (there’s 4 possible allowed variations)
2. By using the cross-namespace association traversal, the OEM can choose whatever namespace(s) it wants to use for their implementation and the management client is oblivious to this implementation detail.
To show how this all comes together, my next blog post (I’m targeting next week) will detail a new PowerShell module I wrote (also to be published next week) that uses this workflow along with implementing use cases defined in specific Profiles exposed as higher level admin task abstraction cmdlets for out-of-band hardware management.
Steve Lee [MSFT]
Principal Test Manager
Standards Based Management