Condividi tramite

Return of the Jedi... err I mean WMI

  • Articolo

A sneak peak at new stuff in WMI in Windows 7.

(Continuation of WMI - The story so far

)

 

WMI, Powershell - how well do they gel?

 

Jeffrey Snover mentioned in the Powershell blog a long time back (https://blogs.msdn.com/powershell/archive/2006/06/26/647038.aspx ) that a veteran MVP remarked to something in the lines of "if you want to do reporting use Windows Powershell because it is very powerful but if you want to get things done use vbscript...” Although this was in context of particularly invoking wmi methods through Powershell, the statement does highlight that the WMI-Powershell story was not complete.
Well not anymore (or so we would like to believe)! With the WMI related enhancements in Windows 7 or (Powershell CTP 3), there is no reason to prefer vbscript anymore.

What we have now in the box are
1. New commandlets like - set-wmiinstance, invoke-wmimethod, remove-wmiobject
2. WMI events have finally made their debut.
3. All cmdlets have an async mode now.
4. We have polished the WMI adapter some more.
5. get-wmiobject has received some upgrades like new class search feature…

Management Profile Support (and reindeers)

WMI now supports Management Profiles - umm what's a management profile?

 

dmtf.org defines it like -

 

"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."

 

Well when I saw this definition for the first time it made me think of a reindeer. What is the most effective way to explain what a reindeer is to someone who hasn’t seen it? - Showing him a picture of reindeer. In the same way, the best way to understand the concept of management profile is to check out a profile.

Suppose you want to collect an inventory of installed BIOS, firmware, drivers and related software. In this case what you know is "The information you want", what you do not know is "where is this information in the big bad world of WMI?” In situations like these Management profiles come to your rescue. Information needed in a particular management domain is first published in the form of a management profile (like software inventory profile in our example) by dmtf or other domain specific standards body. Then this profile is implemented and registered in WMI.

With this you don't need to know the answer to the "where is the information" question. You just get to the profile you are interested in and all the WMI classes related to that profile are already associated to the profile. In essence Management profiles solve the problem of discoverability in the CIM world.

 

How does this all work? We'll tackle that in another post while talking about a profile which comes in-box in Windows 7 - Power Management profile.

 

The importance of being CIM (compatible)

 

We have tweaked a few things in WMI to make us compatible with the latest CIM schema.

Why is CIM relevant? Well, our view of the management space is something on the lines of (diagram below) –

 

Then there are small nuggets like networking classes now work in server core etc which we hope willhelp some of the folks relying on WMI to manage stuff (stuff stands for whatever coolest buzzword you can think of like datacenter :) )

 

 The posts which follow later will drill down and elaborate on individual items.

 

 Kapil Mathur [MSFT]

 

CIM.png

Comments