WMI Object Identifiers and Keys

WMI Object Identifiers and Keys

  • Comments 11

Recently one of MVPs, Darren Mar-Elia (Group Policy Guru from SDMSoftware [which as a set of FREE PowerShell GP cmdlets HERE])  was working with our WMI type accelerators and got the following error:

$ld = '\\sdmlaptop1\root\cimv2:Win32_LogicalDisk.Caption="C:"'

$disk = [WMI] $ld

Cannot convert value "\\sdmlaptop1\root\cimv2:Win32_LogicalDisk.Caption="C:"" to type "System.Management.ManagementObject". Error: "Invalid object path "

At line:1 char:17

+ $disk = [WMI] $ld <<<<

This is a great opportunity to discuss WMI Key properties.  WMI is an awesome piece of infrastructure.  It has a rich object metamodel which includes metadata on properties.  What does that mean?  Think of it as Reflection+++.   It means that you can ask WMI a rich set of questions about the object/type you have.  In this example, you can ask WMI which of the properties of a class can be used as a KEY, in other words as an object identifier. 

[NOTE: These demos are all using the V2 CTP syntax.  If you want to do the same thing on V1, just put the term "psbase." in front of "properties" .  e.g. instead of $c.Properties  you'll type $c.psbase.Properties - jps]

PS>$c=[wmiclass]"win32_logicaldisk"
PS>$c.Properties["caption"]

Name       : caption
Value      :
Type       : String
IsLocal    : False
IsArray    : False
Origin     : CIM_ManagedSystemElement
Qualifiers : {CIMTYPE, MaxLen, read}

PS>$c.Properties["deviceid"]

Name       : deviceid
Value      :
Type       : String
IsLocal    : False
IsArray    : False
Origin     : CIM_LogicalDevice
Qualifiers : {CIM_Key, CIMTYPE, key, MappingStrings...}

Here is a function I wrote to make this a little easier:

function Get-WmiKey
{
  $class = [wmiclass]$args[0]
  $class.Properties |
      Select @{Name="PName";Expression={$_.name}} -Expand Qualifiers |
      Where {$_.Name -eq "key"} |
      foreach {$_.Pname}
}

PS>Get-WmiKey Win32_LogicalDisk
DeviceID
PS>Get-WmiKey Win32_Process
Handle
PS>Get-WmiKey Win32_Service
Name
PS>

So if we believe what this is telling us, it means that the Darren's original string should have used the "DeviceID" property instead of the "Caption".  Let's see if that works.

PS>$ld = '\\jpslap11\root\cimv2:Win32_LogicalDisk.Caption="C:"'
PS>[wmi]$ld
Cannot convert value "\\jpslap11\root\cimv2:Win32_LogicalDisk.Caption="C:"" to type "System.Management.ManagementObject
". Error: "Invalid object path "
At line:1 char:9
+ [wmi]$ld <<<<
PS>$ld = '\\jpslap11\root\cimv2:Win32_LogicalDisk.DeviceID="C:"'
PS>[wmi]$ld

DeviceID     : C:
DriveType    : 3
ProviderName :
FreeSpace    : 18366902272
Size         : 85446352896
VolumeName   : PowerShell Rocks!

As I mentioned, WMI is an awesome technology.  Key properties are just the beginning of it.  Check out the other WMI property qualifiers HERE and start experimenting!

In closing let me say that throughout the history of PowerShell, a small subset of people have looked at it and said, "WMI is dead".  I must tell you that I've never understood what they were talking about.  I LOVE WMI.  PowerShell is a direct outgrowth of the work I did on the WMI command line.  If you've played with our CTP release, you'll see that we are investing very heavily in supporting WMI and making WMI a REALLY GOOD CHOICE for surfacing your management information (you'll see that even more in the next drop of the CTP [ what you'll be able to do with WMI will BLOW YOUR SOCKS OFF - and we'll be doing even more!]).

Cheers!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Leave a Comment
  • Please add 3 and 5 and type the answer here:
  • Post
  • PingBack from http://microsoftnews.askpcdoc.com/?p=2530

  • Doesn't work for me (PS on 64-bit Vista, or on 32-bit XP).

    $c=[wmiclass]"win32_logicaldisk"

    gives me an object of type System.Management.ManagementClass#ROOT\cimv2\Win32_LogicalDisk (per get-member), but $c does not have a member called "Properties".

  • These demos are all using the V2 CTP syntax.  If you want to do the same thing on V1, just put the term "psbase." in front of "properties" .  e.g. instead of $c.Properties  you'll type $c.psbase.Properties

    Jeffrey Snover [MSFT]

    Windows Management Partner Architect

    Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell

    Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

  • Using IActiveScriptSite and  CcmdTarget we can write our own script engine

    for parsing VBscript code.

    like wise How we can write powershell script parsing engine

    using VC++ automation or other technology?

  • Why are you posting V2 syntax when the current version is v1.

    IMO this really diminishes your credibility.

    I have clients coming to me with scripting problems that I know I could do great things in Powershell with, but this whole pushing version 2 before version 1 is even broadly adopted thing is keeping me from taking you guys seriously.

    The v2 stuff should be on the sidelines for now, and the general public stuff should be focused on v1.

    You guys are getting carried away and leaving the flock behind. Gazillions of us are just starting to bring PS1 into our production environments. SLOW DOWN

    And while we're at it, can we fix the bugs in v1 (like missing -LiteralPath in set-acl, and -Path balks at brackets).

  • RADagenais (or whatever they call you )

    This is a Blog and they can post whatever they feel like . Try going to the Powershell usergroup and posting this stuff over there . Maybe ask nicely and people will definitely help you .

    http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.windows.powershell&cat=en_US_3750E87B-4971-4A5C-A537-45F5D7ABBECC&lang=en&cr=US

    Chris

  • I'm sorry if I was rude. I enjoy the blog.

    But I think its a valid point. The whole parade to v2 seems a little ahead of things.

    My comment is addressed to Microsoft in general, this being the main blog for PS by MS.

    My remark about the set-acl bug is irrelevant tho.

    -Rich

  • Will v1 scripts using psbase. still work correctly in v2?

  • If a class has more than one key property, you must specify all of them for this to work:

    PS> Get-WMIKey Win32_Environment

    Name

    UserName

    PS> $pp = '\root\cimv2:Win32_Environment.Name="Path",UserName="<SYSTEM>"'

    PS> [wmi]$pp

    VariableValue              Name                       UserName

    -------------              ----                       --------

    F:\Oracle\product\10.1.... Path                       <SYSTEM>

  • > Will v1 scripts using psbase. still work correctly in v2?

    Correct.

    jps

  • Hello Team!

    Loving Powershell, findint what can be done with ADSI and WMI great but not without its problems. As such I'd like to ask a question. (Appreciate this is probably not the normal place to ask but I am finding it hard to get information on WMI)

    I understand there maybe a bug in V2 where System.Management.ManagementBaseObject (or possibly an array of this object) is treated incorrectly in Powershell.  

    Can you confirm if this is correct?

    (see here for info on this http://www.vistax64.com/powershell/79129-wmi-network-adapter-speed.html - I raised this here for further information to https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=345762)

    Thanks,

    Matt

Page 1 of 1 (11 items)