{"id":6671,"date":"2015-04-14T00:01:00","date_gmt":"2015-04-14T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2015\/04\/14\/comparing-cim-and-wmi-in-powershell\/"},"modified":"2019-02-18T10:29:54","modified_gmt":"2019-02-18T17:29:54","slug":"comparing-cim-and-wmi-in-powershell","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/comparing-cim-and-wmi-in-powershell\/","title":{"rendered":"Comparing CIM and WMI in PowerShell"},"content":{"rendered":"

Summary<\/b>: Microsoft Scripting Guy, Ed Wilson, talks about comparing CIM and Windows PowerShell.<\/span>\n\"Hey, Hey, Scripting Guy! When I query using a CIM function, I get back different stuff than when I query WMI. I don’t get it. Can you help?\n—BW\n\"Hey, Hello BW,\nMicrosoft Scripting Guy, Ed Wilson, is here. Yesterday in Working with Volumes in CIM<\/a>, I began talking about WMI and CIM. Let’s continue by looking more in depth at what happens with Get-Volume<\/b> and Win32_Volume<\/b>.\nAnyone who has done a lot of work with WMI and with Windows PowerShell knows about types and type data. For example, when I query the WIN32_BIOS WMI class, only a certain amount of information returns. This is shown here:<\/p>\n

PS C:> Get-WmiObject win32_Bios<\/p>\n

SMBIOSBIOSVersion : Hyper-V UEFI Release v1.0<\/p>\n

Manufacturer      : Microsoft Corporation<\/p>\n

Name              : Hyper-V UEFI Release v1.0<\/p>\n

SerialNumber      : 6591-2614-0518-3297-7423-5669-65<\/p>\n

Version           : VRTUAL – 1\nIf I want to look at more in-depth information, I can pipe the output to the Format-List<\/b> cmdlet, and it will return all of the information, as shown here:<\/p>\n

PS C:> Get-WmiObject win32_Bios | fl *<\/p>\n

PSComputerName        : C1<\/p>\n

Status                : OK<\/p>\n

Name                  : Hyper-V UEFI Release v1.0<\/p>\n

Caption               : Hyper-V UEFI Release v1.0<\/p>\n

SMBIOSPresent         : True<\/p>\n

__GENUS               : 2<\/p>\n

__CLASS               : Win32_BIOS<\/p>\n

__SUPERCLASS          : CIM_BIOSElement<\/p>\n

__DYNASTY             : CIM_ManagedSystemElement<\/p>\n

__RELPATH             : Win32_BIOS.Name=”Hyper-V UEFI Release<\/p>\n

                                   v1.0″,SoftwareElementID=”Hyper-V UEFI Release v1.0″,
                                  SoftwareElementState=3,TargetOperatingSystem=0,Version=”VR<\/span>TUAL – 1″<\/span><\/p>\n

__PROPERTY_COUNT      : 27<\/p>\n

__DERIVATION          : {CIM_BIOSElement, CIM_SoftwareElement, CIM_LogicalElement, CIM_ManagedSystemElement}<\/span><\/p>\n

__SERVER              : C1<\/p>\n

__NAMESPACE           : rootcimv2<\/p>\n

__PATH                : \\C1rootcimv2:Win32_BIOS.Name=”Hyper-V UEFI Release
      
                                v1.0″,SoftwareElementID=”Hyper-V UEFI Release v1.0″,<\/span><\/p>\n

                                 SoftwareElementState=3,TargetOperatingSystem=0,Version=”VR<\/span>TUAL – 1″<\/span><\/p>\n

BiosCharacteristics   : {3, 9, 15, 16…}<\/p>\n

BIOSVersion           : {VRTUAL – 1, Hyper-V UEFI Release v1.0, EDK II – 10000}<\/p>\n

BuildNumber           :<\/p>\n

CodeSet               :<\/p>\n

CurrentLanguage       :<\/p>\n

Description           : Hyper-V UEFI Release v1.0<\/p>\n

IdentificationCode    :<\/p>\n

InstallableLanguages  :<\/p>\n

InstallDate           :<\/p>\n

LanguageEdition       :<\/p>\n

ListOfLanguages       :<\/p>\n

Manufacturer          : Microsoft Corporation<\/p>\n

OtherTargetOS         :<\/p>\n

PrimaryBIOS           : True<\/p>\n

ReleaseDate           : 20121126000000.000000+000<\/p>\n

SerialNumber          : 6591-2614-0518-3297-7423-5669-65<\/p>\n

SMBIOSBIOSVersion     : Hyper-V UEFI Release v1.0<\/p>\n

SMBIOSMajorVersion    : 2<\/p>\n

SMBIOSMinorVersion    : 4<\/p>\n

SoftwareElementID     : Hyper-V UEFI Release v1.0<\/p>\n

SoftwareElementState  : 3<\/p>\n

TargetOperatingSystem : 0<\/p>\n

Version               : VRTUAL – 1<\/p>\n

Scope                 : System.Management.ManagementScope<\/p>\n

Path                  : \\C1rootcimv2:Win32_BIOS.Name=”Hyper-V UEFI Release<\/p>\n

                        v1.0″,SoftwareElementID=”Hyper-V UEFI Release v1.0″,
                        SoftwareElementState=3,TargetOperatingSystem=0,Version=”VR<\/span>TUAL – 1″<\/span><\/p>\n

Options               : System.Management.ObjectGetOptions<\/p>\n

ClassPath             : \\C1rootcimv2:Win32_BIOS<\/p>\n

Properties            : {BiosCharacteristics, BIOSVersion, BuildNumber, Caption…}<\/span><\/p>\n

SystemProperties      : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY…}<\/p>\n

Qualifiers            : {dynamic, Locale, provider, UUID}<\/p>\n

Site                  :<\/p>\n

Container             :\nThe default properties that are displayed are the result of type data for the specific WMI class. I can find this by using the <\/span>Get-TypeData<\/b> cmdlet. Here is an example that tells me that I do, in fact, have specific type data for the WMI class:<\/span><\/p>\n

PS C:> “*win32_bios*” | Get-TypeData<\/p>\n

TypeName                                Members                                <\/p>\n

——–                                ——-                               <\/p>\n

System.Management.ManagementObject#r… {}                                    <\/p>\n

Microsoft.Management.Infrastructure…. {}              \nI can look at this in more detail, by piping the results to the Format-List<\/b> cmdlet:<\/p>\n

S C:> “*win32_bios*” | Get-TypeData | fl * <\/span><\/p>\n

TypeName                        : System.Management.ManagementObject#rootcimv2 Win32_BIOS<\/span><\/p>\n

Members                         : {}<\/p>\n

TypeConverter                   :<\/p>\n

TypeAdapter                     :<\/p>\n

IsOverride                      : False<\/p>\n

SerializationMethod             :<\/p>\n

TargetTypeForDeserialization    :<\/p>\n

SerializationDepth              : 0<\/p>\n

DefaultDisplayProperty          :<\/p>\n

InheritPropertySerializationSet : False<\/p>\n

StringSerializationSource       :<\/p>\n

DefaultDisplayPropertySet       : System.Management.Automation.Runspaces.PropertySetData<\/span><\/p>\n

DefaultKeyPropertySet           :<\/p>\n

PropertySerializationSet        : <\/span><\/p>\n

TypeName                        : Microsoft.Management.Infrastructure.CimInstance#root\/cimv2\/Win32_BIOS<\/span><\/p>\n

Members                         : {}<\/p>\n

TypeConverter                   :<\/p>\n

TypeAdapter                     :<\/p>\n

IsOverride                      : False<\/p>\n

SerializationMethod             :<\/p>\n

TargetTypeForDeserialization    :<\/p>\n

SerializationDepth              : 0<\/p>\n

DefaultDisplayProperty          :<\/p>\n

InheritPropertySerializationSet : False<\/p>\n

StringSerializationSource       :<\/p>\n

DefaultDisplayPropertySet       : System.Management.Automation.Runspaces.PropertySetData<\/span><\/p>\n

DefaultKeyPropertySet           :<\/p>\n

PropertySerializationSet        : \nBut, what I really want to look at is DefaultDisplayPropertySet<\/b>. This property is what governs the properties that return by default when I query the Win32_Bios<\/b> cmdlet. So, I look at the property:<\/p>\n

PS C:> (“*win32_bios*” | Get-TypeData).defaultdisplaypropertyset<\/p>\n

ReferencedProperties                                                          <\/p>\n

——————–                                                          <\/p>\n

{SMBIOSBIOSVersion, Manufacturer, Name, SerialNumber…}                      <\/p>\n

{SMBIOSBIOSVersion, Manufacturer, Name, SerialNumber…}     \nIt is one more level to get the ReferencedProperties<\/b>. This is shown here:<\/p>\n

PS C:> (“*win32_bios*” | Get-TypeData).defaultdisplaypropertyset.referencedproperties<\/p>\n

SMBIOSBIOSVersion<\/p>\n

Manufacturer<\/p>\n

Name<\/p>\n

SerialNumber<\/p>\n

Version<\/p>\n

SMBIOSBIOSVersion<\/p>\n

Manufacturer<\/p>\n

Name<\/p>\n

SerialNumber<\/p>\n

Version\nIf you look closely, you will see that there are two sets of the same five properties. This is because I have two instances of type data. One is for WMI the other is for CIM.<\/p>\n

PS C:> (“*win32_bios*” | Get-TypeData).typename<\/p>\n

System.Management.ManagementObject#rootcimv2Win32_BIOS<\/p>\n

Microsoft.Management.Infrastructure.CimInstance#root\/cimv2\/Win32_BIOS\nAt the beginning of this post, I used Get-WMIObject<\/b> to query Win32_Bios<\/b>. As shown here, if I use Get-CimInstance<\/b>, the output is the same:<\/p>\n

PS C:> Get-CimInstance Win32_BIOS<\/p>\n

SMBIOSBIOSVersion : Hyper-V UEFI Release v1.0<\/p>\n

Manufacturer      : Microsoft Corporation<\/p>\n

Name              : Hyper-V UEFI Release v1.0<\/p>\n

SerialNumber      : 6591-2614-0518-3297-7423-5669-65<\/p>\n

Version           : VRTUAL – 1\nWhat about Win32_Volume<\/b> and Get-Volume<\/b>? Well, we have a completely different WMI namespace. I can discover this by looking at the TypeName<\/b> from Get-Member<\/b>:<\/p>\n

PS C:> Get-Volume | gm<\/p>\n

   TypeName: Microsoft.Management.Infrastructure.CimInstance#ROOT\/Microsoft\/Win<\/p>\n

dows\/Storage\/MSFT_Volume<\/p>\n

Name                      MemberType     Definition                            <\/p>\n

—-                      ———-     ———-                           <\/p>\n

Clone                     Method         System.Object ICloneable.Clone()     <\/p>\n

Dispose                   Method         void Dispose(), void IDisposable.Di…<\/p>\n

Equals                    Method         bool Equals(System.Object obj)       <\/p>\n

GetCimSessionComputerName Method         string GetCimSessionComputerName()   <\/p>\n

GetCimSessionInstanceId   Method         guid GetCimSessionInstanceId()       <\/p>\n

GetHashCode               Method         int GetHashCode()                    <\/p>\n

GetObjectData             Method         void GetObjectData(System.Runtime.S…<\/p>\n

GetType                   Method         type GetType()                       <\/p>\n

ToString                  Method         string ToString()                    <\/p>\n

DriveLetter               Property       char DriveLetter {get;}              <\/p>\n

FileSystem                Property       string FileSystem {get;}             <\/p>\n

FileSystemLabel           Property       string FileSystemLabel {get;set;}    <\/p>\n

ObjectId                  Property       string ObjectId {get;}               <\/p>\n

Path                      Property       string Path {get;}                   <\/p>\n

PSComputerName            Property       string PSComputerName {get;}         <\/p>\n

Size                      Property       uint64 Size {get;}                   <\/p>\n

SizeRemaining             Property       uint64 SizeRemaining {get;}          <\/p>\n

DriveType                 ScriptProperty System.Object DriveType {get=switch…<\/p>\n

HealthStatus              ScriptProperty System.Object HealthStatus {get=swi…\nNotice, that the TypeName<\/b> is a CimInstance<\/b>, like one of the types for the Win32_Bios<\/b> class. But notice that this also is in Root\/Microsoft\/Windows\/Storage WMI namespace. This namespace is why Win32_Volume<\/b> does not work on a computer running Windows 7, even though it may have Windows PowerShell 4.0 installed.\nIf I look for type data related to *volume*<\/b>, I find four different types—but only one that is related to MSFT_Volume and none related to Win32_Volume. This is shown here:<\/p>\n

PS C:> (“*volume*” | Get-TypeData).TypeName<\/p>\n

System.Management.ManagementObject#rootcimv2Win32_VolumeQuotaSetting<\/p>\n

Microsoft.Management.Infrastructure.CimInstance#root\/cimv2\/Win32_VolumeQuotaSetting<\/span><\/p>\n

Microsoft.Management.Infrastructure.CimInstance#MSFT_Volume<\/p>\n

Microsoft.FailoverClusters.PowerShell.ClusterSharedVolume\nWhen I query Get-Volume<\/b>, I get a nice clean output:<\/p>\n

PS C:> Get-Volume<\/p>\n

DriveLetter FileSystemLabel FileSystem  DriveType  HealthStatus SizeRemaining  Size<\/p>\n

———– ———– ———-  ———  ———- ———-       —-<\/p>\n

C                       NTFS        Fixed      Healthy     108.53 GB  126.48 GB<\/p>\n

E           NEW VOLUME  FAT32       Fixed      Healthy       1.52 GB    1.99 GB<\/p>\n

            Recovery    NTFS        Fixed      Healthy      59.83 MB     300 MB<\/p>\n

D                                   CD-ROM     Healthy           0 B        0 B\nBut, if I query Win32_Volume<\/b>, I get back the WMI class, but not any formatted data. This is true even if I use Get-CimInstance<\/b>. This is shown here:<\/p>\n

PS C:> Get-CimInstance win32_volume<\/p>\n

Caption                      : C:<\/p>\n

Description                  :<\/p>\n

InstallDate                  :<\/p>\n

Name                         : C:<\/p>\n

Status                       :<\/p>\n

Availability                 :<\/p>\n

ConfigManagerErrorCode       :<\/p>\n

ConfigManagerUserConfig      :<\/p>\n

CreationClassName            :<\/p>\n

DeviceID                     : \\?Volume{a6325fa1-0f39-432c-a6db-e6388000463a}<\/span><\/p>\n

ErrorCleared                 :<\/p>\n

ErrorDescription             :<\/p>\n

LastErrorCode                :<\/p>\n

PNPDeviceID                  :<\/p>\n

PowerManagementCapabilities  :<\/p>\n

PowerManagementSupported     :<\/p>\n

StatusInfo                   :<\/p>\n

SystemCreationClassName      :<\/p>\n

SystemName                   : C1<\/p>\n

Access                       :<\/p>\n

BlockSize                    : 4096<\/p>\n

ErrorMethodology             :<\/p>\n

NumberOfBlocks               :<\/p>\n

Purpose                      :<\/p>\n

Automount                    : True<\/p>\n

BootVolume                   : True<\/p>\n

Capacity                     : 135810510848<\/p>\n

Compressed          &nb<\/p>\n","protected":false},"excerpt":{"rendered":"

Summary: Microsoft Scripting Guy, Ed Wilson, talks about comparing CIM and Windows PowerShell.  Hey, Scripting Guy! When I query using a CIM function, I get back different stuff than when I query WMI. I don’t get it. Can you help? —BW  Hello BW, Microsoft Scripting Guy, Ed Wilson, is here. Yesterday in Working with Volumes […]<\/p>\n","protected":false},"author":596,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[385,3,4,45],"class_list":["post-6671","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-cim","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":"

Summary: Microsoft Scripting Guy, Ed Wilson, talks about comparing CIM and Windows PowerShell.  Hey, Scripting Guy! When I query using a CIM function, I get back different stuff than when I query WMI. I don’t get it. Can you help? —BW  Hello BW, Microsoft Scripting Guy, Ed Wilson, is here. Yesterday in Working with Volumes […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/6671","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/596"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=6671"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/6671\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=6671"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=6671"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=6671"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}