Summary: Microsoft Scripting Guy, Ed Wilson, talks about creating custom type data to control the way a WMI class displays.
Hey, Scripting Guy! Yesterday, you said you could create custom type data to control the way the Win32_Volume WMI class reports back. How would one go about doing that? I looked on the Internet, and to be honest, it looks like it is basically impossible.
—AT
Hello AT,
Microsoft Scripting Guy, Ed Wilson, is here. I love this time of the year. All the windows are open, the azaleas are in bloom, and I am upstairs with my Surface Pro 3, a cup of orange-cream green tea, and a slice of artisan cheese. I also scored some organic grapes, and they are so sweet that I needed to add nothing to my tea this morning.
AT, you are right. Yesterday in Comparing CIM and WMI in PowerShell, I began talking about comparing the results of Get-Volume with the Win32_Volume WMI class.
Obviously, if all of my systems are running Windows 8.1, there is no reason to mess around with using the WMI class. But if that is not the case, it makes sense to make things a bit easier to use.
Create custom type data
I want to be able to update the type data for the Win32_Volume WMI class. There is no custom type data, so I need to create something. Luckily, beginning with Windows PowerShell 3.0, this is super easy. I simply use the Update-TypeData cmdlet. The hard parts are figuring out the type name that I am going to use and figuring out how to accomplish the task.
From yesterday’s article, we know that the Win32_Volume WMI class does not have any custom type data. However, the Win32_Bios WMI class does. So I need to see how the Win32_Bios WMI class type data is named:
PS C:\> gcim Win32_BIOS | Get-TypeName
CimInstance#root/cimv2/Win32_BIOS
PS C:\> gwmi win32_bios | Get-TypeName
ManagementObject#root\cimv2\Win32_BIOS
But I want the full name, so I use a wildcard character to retrieve it. This is shown here:
PS C:\> "*win32_bios*" | Get-TypeData | select typename
TypeName
--------
System.Management.ManagementObject#root\cimv2\Win32_BIOS
Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_BIOS
It appears that all I need to do is change the name of the WMI class on the end of the string. I decide my new type data name will be the following:
Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_Volume
This type data will control the way data returns from the Get-CimInstance cmdlet. I am not going to bother to create type data for the Get-WmiObject cmdlet, because this methodology requires Windows PowerShell 3.0 or later; therefore, the Get-CimInstance cmdlet would be available anyway.
As a test, I decide to create default properties. I use the Update-TypeData cmdlet, and I specify the type name and the default properties. I store the type name in a variable named $dataType. The second command is one long command. The command is shown here:
$dataType = "Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_Volume"
Update-TypeData -TypeName $DataType `
-DefaultDisplayPropertySet DriveLetter, DriveType, Label, FileSystem, FreeSpace, ` Capacity
As shown here, when I use Get-CimInstance to query Win32_Volume, only the selected properties return:
PS C:\> Get-CimInstance win32_volume
DriveLetter : C:
DriveType : 3
Label : SSD
FileSystem : NTFS
FreeSpace : 53269737472
Capacity : 159486308352
DriveLetter : E:
DriveType : 3
Label : HybridTerrabyte
FileSystem : NTFS
FreeSpace : 392849973248
Capacity : 1000068870144
DriveLetter :
DriveType : 3
Label : Recovery
FileSystem : NTFS
FreeSpace : 24080384
Capacity : 314568704
If I attempt to update the type data, an error occurs. Here is the error message I receive:
PS C:\> E:\Data\ScriptingGuys\2015\HSG_4_13_15\CreateTypeDataForVolumeClass.ps1
Update-TypeData : Error in TypeData
"Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_Volume": The member DefaultDisplayPropertySet is already present.
At E:\Data\ScriptingGuys\2015\HSG_4_13_15\CreateTypeDataForVolumeClass.ps1:11 char:1
+ Update-TypeData -TypeName $DataType `
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Update-TypeData], RuntimeException
+ FullyQualifiedErrorId : TypesDynamicUpdateException,Microsoft.PowerShell.Commands.UpdateTypeDataCommand
I first need to remove the type data, and then I can update it. This command is shown here:
"Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_Volume" |
Get-TypeData | Remove-TypeData
Add a script property
I see that the output from the drive type is coded. So, I look up the WMI class on MSDN, and add a script property to decode the numeric output. To do this, I use a simple Switch statement:
Switch ($this.psbase.CimInstanceProperties["DriveType"].value)
{
0 {"Unknown"}
1 {"No Root"}
2 {"Removable"}
3 {"Local Disk"}
4 {"Network Disk"}
5 {"Compact Disk"}
6 {"RAM Disk"}
}
I keep my default property set, and I add a ScriptProperty named DriveType. The script block for the Switch statement and to translate the value goes in the –Value parameter. I use $this to gain access to the value from the WMI class property. The revised command is shown here:
$dataType = "Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_Volume"
Update-TypeData -TypeName $DataType `
-DefaultDisplayPropertySet DriveLetter, DriveType, Label, FileSystem, FreeSpace, Capacity `
-MemberType ScriptProperty -MemberName DriveType -Value {
Switch ($this.psbase.CimInstanceProperties["DriveType"].value)
{
0 {"Unknown"}
1 {"No Root"}
2 {"Removable"}
3 {"Local Disk"}
4 {"Network Disk"}
5 {"Compact Disk"}
6 {"RAM Disk"}
}
}
Now when I use Get-CimInstance to query the Win32_Volume WMI class, it comes back with nicely formatted output. This is shown in the following image:
But it gets better! Because the custom type system works on all instances of the data type, it even works on remote systems. So I update the type data on my local computer, and when I query a remote computer (that has not been updated), the data is properly formatted. It is way cool. This technique is shown here:
PS C:\> $dataType = "Microsoft.Management.Infrastructure.CimInstance#root/cimv2/Win32_Volume"
PS C:\> Update-TypeData -TypeName $DataType `
>> -DefaultDisplayPropertySet DriveLetter, DriveType, Label, FileSystem, FreeSpace, Capacity `
>> -MemberType ScriptProperty -MemberName DriveType -Value {
>> Switch ($this.psbase.CimInstanceProperties["DriveType"].value)
>> {
>> 0 {"Unknown"}
>> 1 {"No Root"}
>> 2 {"Removable"}
>> 3 {"Local Disk"}
>> 4 {"Network Disk"}
>> 5 {"Compact Disk"}
>> 6 {"RAM Disk"}
>> }
>> }
>>
PS C:\> gcim Win32_Volume
DriveLetter :
DriveType : Local Disk
Label : System Reserved
FileSystem : NTFS
FreeSpace : 331784192
Capacity : 366997504
DriveLetter : C:
DriveType : Local Disk
Label :
FileSystem : NTFS
FreeSpace : 124714565632
Capacity : 135996108800
DriveLetter : D:
DriveType : Compact Disk
Label :
FileSystem :
FreeSpace :
Capacity :
PS C:\> gcim Win32_Volume -CimSession dc1
DriveLetter : C:
DriveType : Local Disk
Label :
FileSystem : NTFS
FreeSpace : 125529444352
Capacity : 135810510848
PSComputerName : dc1
DriveLetter :
DriveType : Local Disk
Label : Recovery
FileSystem : NTFS
FreeSpace : 62734336
Capacity : 314568704
PSComputerName : dc1
DriveLetter : D:
DriveType : Compact Disk
Label :
FileSystem :
FreeSpace :
Capacity :
PSComputerName : dc1
AT, that is all there is to using Windows PowerShell to create custom type data to control the display of a WMI class. CIM Week will continue tomorrow when I will talk about more cool stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy