Filtering behaviour between CIM_ and Win32_ classes

PowerShell Help
1

What is the difference in filtering when using win32_ and CIM_ classes.

[221]KVP> Get-CimInstance -ClassName CIM_LogicalDisk -Filter "VolumeName like 'O%'"
Get-CimInstance : Invalid query
At line:1 char:1
+ Get-CimInstance -ClassName CIM_LogicalDisk -Filter "VolumeName like ' ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Get-CimInstance], CimException
    + FullyQualifiedErrorId : HRESULT 0x80041017,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand

[242]KVP> Get-CimInstance -ClassName Win32_LogicalDisk -Filter "VolumeName like 'O%'"

DeviceID DriveType ProviderName VolumeName Size         FreeSpace
-------- --------- ------------ ---------- ----         ---------
C:       3                      OSDisk     254916481024 109464317952
S:       4         \\computer\s OSDisk     254916481024 109464317952
2

No, it’s not a bug. See CIM_LogicalDisk class (CIMWin32 WMI Providers) - Win32 apps | Microsoft Docs.

CIM_LogicalDisk doesn’t have a VolumeName property. That’s why you’re getting an error.

In most cases, the CIM classes are “base classes,” and are designed to be platform-neutral. The Win32_ version is Windows-specific, and adds a lot to the base class.

3

That’s the info in the Doc and filter works perfect for all the documented properties, but how VolumeName is made available in the output ?

[32]KVP> Get-CimInstance -ClassName CIM_LogicalDisk

DeviceID DriveType ProviderName VolumeName Size         FreeSpace
-------- --------- ------------ ---------- ----         ---------
C:       3                      OSDisk     254916481024 109439442944
S:       4         \\computer\s OSDisk     254916481024 109439442944
4

That’s a combination of the repo and the CIM cmdlets doing some funky stuff under the hood to try and “make life easier.” Doesn’t always work out that way. Short answer: Query Win32_ classes when they’re available, CIM_ when not.

5

Yup, that’s what I’ve decided, Thanks DJ for your time.

6

Interesting …but… but… but…

So, even get-Member is a lie, as well as Select-Object??? Oh, the blasphemy. 8^}

Wow, that kind of an ugly proposition, or odd Voodoo magic on retrieval attempts, if one was so inclined not to use the alternative.

    Get-CimInstance -ClassName CIM_LogicalDisk -Filter "DeviceID like 'D%'" | Get-Member -Force


       ---> TypeName: Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_LogicalDisk  VolumeName                   Property     string VolumeName {get;set;}  <---
    ...

    
    Get-CimInstance -ClassName CIM_LogicalDisk -Filter "DeviceID like '%'" | Select-Object -Property VolumeName

    VolumeName
    ----------
    Root      
    Data      
    SDN       
    EVO4TB 


    (Get-CimInstance -ClassName CIM_LogicalDisk -Filter "DeviceID like '%'" | Select-Object -Property VolumeName) -Match 'D.*'


    VolumeName
    ----------
    Data      
    SDN 


    Get-CimInstance -ClassName CIM_LogicalDisk -Filter "DeviceID like '%'" | 
    Select-Object -Property VolumeName | 
    Where-Object -Property VolumeName -Match 'D.*'

    VolumeName
    ----------
    Data      
    SDN
7

Worth noting that the reason VolumeName is still in the output although the CIM class doesn’t have that property is that the cmdlets actually query the CIM class, and then convert it to the equivalent win32 class, adding the properties along the way.