WMI Data Types

WMI uses its own data types that differ from the data types used by PowerShell.

When WMI Data Types Matter

When you read data from WMI and output it in reports, you do not need to care much about data types because numbers look the same when outputted as text.

As soon as you process WMI output, though, correct data types matter. Both PowerShell and WMI can understand each other only when they understand how to interpret the data. Problems can occur both ways:

• When you call WMI methods and send arguments that use PowerShell data types, WMI may not interpret the data correctly. Make sure you convert your arguments to the exact data types the WMI method expects to receive.
• When PowerShell processes data received from WMI, it may not recognize the WMI data types. Make sure you convert the received WMI data to the corresponding PowerShell data types where appropriate.

Here is an example that illustrates the problem and ways to work around it:

Translating WMI Codes to Friendly Text

WMI information is often coded and uses numeric values instead of meaningful text.

For example, the WMI class Win32_ComputerSystem contains the property AdminPasswordStatus. When you look up this property, you learn that this property returns the hardware security settings for the administrator password status. The information uses the data type [UInt16] (unsigned 16-bit integer). The reference also returns a PowerShell hashtable to translate the values into text:

$AdminPasswordStatus_map = @{
      0 = 'Disabled'
      1 = 'Enabled'
      2 = 'Not Implemented'
      3 = 'Unknown'
}

You can now take the value returned by WMI and use it as a key to read the friendly text from the hashtable. However, when you ignore data types, this won’t work, and PowerShell just returns “nothing”:

# example returns the current admin password status
# this example contains an error and returns "nothing"

# this hashtable translates the codes to
# meaningful friendly text:
$AdminPasswordStatus_map = @{
      0 = 'Disabled'
      1 = 'Enabled'
      2 = 'Not Implemented'
      3 = 'Unknown'
}

# get instance of Win32_ComputerSystem
# representing the current computer:
$computer = Get-CimInstance -Class Win32_ComputerSystem 

# query the property AdminPasswordStatus
# it yields a numeric value
$rawValue = $computer.AdminPasswordStatus  

# translate raw value to friendly text
# this yields empty information because PowerShell uses the
# data type [Int32] (signed 32-bit integers)
# while WMI sends the numeric value
# using the data type [UInt16] (unsigned 16-bit integers)
# so PowerShell cannot find the key in its
# hashtable and returns nothing:
$friendlyName = $AdminPasswordStatus_map[$rawValue]

# output value
"Admin Password Status: $friendlyName"

This problem occurs because hashtable keys are type-sensitive. PowerShell cannot find a [UInt16] typed key in the hashtable because numbers automatically use the type [Int32] in PowerShell.

The solution is trivial, though: convert the WMI value into the appropriate PowerShell type so that it matches the types of the hashtable keys:

# example returns the current admin password status
# this example converts the returned WMI value
# into the appropriate PowerShell data type:

$AdminPasswordStatus_map = @{
      0 = 'Disabled'
      1 = 'Enabled'
      2 = 'Not Implemented'
      3 = 'Unknown'
}

$computer = Get-CimInstance -Class Win32_ComputerSystem 
$rawValue = $computer.AdminPasswordStatus 

# convert the raw value to type [Int]: 
$friendlyName = $AdminPasswordStatus_map[[Int]$rawValue]

# output value
"Admin Password Status: $friendlyName"

Now the code works and may look like this:

Admin Password Status: Not Implemented

“Not Implemented” is one of the available return values and indicates that your security hardware does not provide the requested information.

Mapping PowerShell and WMI Data Types

Here is a quick table of type mappings that you can use to convert WMI data types to PowerShell data types (and vice versa):

WMI Data Type Description

This is a detailed description of all WMI data types, including the covered range of numbers.

UInt8

BYTE MIN: 0 MAX: 255

Unsigned 8-bit integer value (positive numbers only). The equivalent PowerShell data type is [Byte] ([System.Byte]).

# converts value 132 to SInt32:
$UInt8 = [Byte]132

# check result type (System.Byte):
$UInt8.GetType().FullName

UInt16

UINT16 MIN: 0 MAX: 65,535

Unsigned 16-bit integer value (positive numbers only). The equivalent PowerShell data type is [UInt16] ([System.UInt16]).

# converts value 43105 to SInt32:
$UInt16 = [UInt16]43105

# check result type (System.UInt16):
$UInt16.GetType().FullName

UInt32

UINT32 MIN: 0 MAX: 4,294,967,295

Unsigned 32-bit integer value (positive numbers only). The equivalent PowerShell data type is [UInt32] ([System.UInt32]).

# converts value 43105 to SInt32:
$UInt32 = [UInt32]43105

# check result type (System.UInt32):
$UInt32.GetType().FullName

UInt64

UINT64 MIN: 0 MAX: 17,179,869,184 GB

Unsigned 64-bit integer value (positive numbers only). The equivalent PowerShell data type is [UInt64] ([System.UInt64]).

# converts value 43105 to SInt32:
$UInt64 = [UInt64]43105

# check result type (System.UInt64):
$UInt64.GetType().FullName

SInt8

SBYTE MIN: -128 MAX: 127

Signed 8-bit integer value (negative and positive numbers). The equivalent PowerShell data type is [SByte] ([System.SByte]).

# converts value 53 to SInt32:
$SInt8 = [SByte]53

# check result type (System.SByte):
$SInt8.GetType().FullName

SInt16

INT16 MIN: -32,768 MAX: 32,767

Signed 16-bit integer value (negative and positive numbers). The equivalent PowerShell data type is [Int16] ([System.Int16]).

# converts value 53 to SInt32:
$SInt16 = [Int16]53

# check result type (System.Int16):
$SInt16.GetType().FullName

SInt32

INT32 MIN: -2,147,483,648 MAX: 2,147,483,647

Signed 32-bit integer value (negative and positive numbers). The equivalent PowerShell data type is [Int32] ([System.Int32]).

# converts value 53 to SInt32:
$SInt32 = [Int32]53

# check result type (System.Int32):
$SInt32.GetType().FullName

SInt64

INT64 MIN: –8,589,934,592 GB MAX: 8,589,934,592 GB

Signed 64-bit integer value (negative and positive numbers). The equivalent PowerShell data type is [Int64] ([System.Int64]).

# converts value 53 to SInt32:
$SInt64 = [Int64]53

# check result type (System.Int64):
$SInt64.GetType().FullName

Real32

SINGLE MIN: -3.02231436889259E+23 PB MAX: 3.02231436889259E+23 PB

32-bit floating-point value (negative and positive numbers). The equivalent PowerShell data type is [Single] ([System.Single]).

# converts value 53 to SInt32:
$Real32 = [Single]53

# check result type (System.Single):
$Real32.GetType().FullName

Real64

DOUBLE MIN: –1.59667224762778E+293 PB MAX: 1.59667224762778E+293 PB

64-bit floating-point value (negative and positive numbers). The equivalent PowerShell data type is [Double] ([System.Double]).

# converts value 53 to SInt32:
$Real64 = [Double]53

# check result type (System.Double):
$Real64.GetType().FullName

Boolean

BOOL MIN: $false MAX: $true

Unsigned XXX-bit integer value (negative and positive numbers). The equivalent PowerShell data type is [Bool] ([Boolean], [System.Boolean]).

# converts value 0 to SInt32:
$Boolean = [Bool]0

# check result type (System.Boolean):
$Boolean.GetType().FullName

In PowerShell, the values 0, NULL, and Empty Strings evaluate to $false. Anything else evaluates to $true.

# assign anything to $anyvalue:
$anyvalue = 'test it'

# always either $false or $true
[bool]$anyvalue

# always either "0" or "1"
[byte][bool]$anyvalue

DateTime

DATETIME MIN: Jan 1, 0001 MAX: Dec 31, 9999

Represents absolute date and time or a timespan (interval). The equivalent PowerShell data type for date and time is [DateTime] ([System.DateTime]). For intervals, the datatype [TimeSpan] ([System.Timespan]) is used.

WMI represents date and time internally in a string-based format: yyyymmddHHMMSS.mmmmmmsUUU. Cmdlets like Get-CimInstance automatically convert WMI datetime and intervals to the proper .NET types [DateTime]/[TimeSpan].

# converts value 53 to SInt32:
$DateTime = [DateTime]53

# check result type (System.DateTime):
$DateTime.GetType().FullName

You may be forced to do the conversion manually when you call internal WMI methods and need to submit information as parameter, or when you work with the deprecated cmdlet Get-WmiObject.

# convert WMI DateTime to PowerShell DateTime:
$dateTime = "20190408141835.999999-420"
[System.Management.ManagementDateTimeConverter]::ToDateTime($dateTime)

# convert WMI Interval to PowerShell Timespan:
$interval = "00000120125232:124150:000"
[System.Management.ManagementDateTimeConverter]::ToTimeSpan($interval)

# Convert PowerShell DateTime to WMI DateTime:
$today = Get-Date
[System.Management.ManagementDateTimeConverter]::ToDmtfDateTime($today)

# Convert PowerShell Timespan to WMI Interval:
$timespan = New-TimeSpan -Hours 12 -Minutes 8
[System.Management.ManagementDateTimeConverter]::ToDmtfTimeInterval($timespan)

Char16

CHAR

The equivalent PowerShell data type is [Char] ([System.Char]).

# converts value 35592 to SInt32:
$Char16 = [Char]35592

# check result type (System.Char):
$Char16.GetType().FullName

String

STRING

The equivalent PowerShell data type is [String] ([System.String]). Strings can store text of unlimited length. WMI typically limits the length of strings depending on the property where it is used.

# converts value 35592 to SInt32:
$String = [String]35592

# check result type (System.String):
$String.GetType().FullName

Arrays

When a data type is marked as Array, then the property can contain any number of values. In most scenarios, you need to process the values separately, or convert them to a string.

Examples

# get instance
$bios = Get-CimInstance -Class Win32_BIOS

# dump content of property "BIOSCharacteristics"
$bios.BIOSCharacteristics

# get instance
$bios = Get-CimInstance -Class Win32_BIOS

# convert array elements of property "BIOSCharacteristics" to string:
$delimiter = ", "
$text = $bios.BIOSCharacteristics -join $delimiter

Maximum Length (String)

In PowerShell, strings have no length limit. In WMI, most properties with a string value do have a size limit.

For example, the property BuildNumber exposed by the WMI class Win32_BIOS is of type string with a maximum length of 64 characters.

For you, the length information is mostly of informal use because most WMI properties are read-only. Occasionally, properties do allow to be changed, though.

Changing String Values

When you assign a new value to a writeable property, you need to make sure the new value does not exceed the maximum length.

# get all instances of "Win32_LogicalDisk" 
# and list the "VolumeName" property:
Get-CimInstance -Class Win32_LogicalDisk |
  Select-Object -Property Caption, VolumeName

# access the drive you want to rename:
$drive = Get-CimInstance -ClassName Win32_LogicalDisk -Filter 'Caption="E:"'

# assign the new name, and remember the maximum length of 32 characters:
$drive.VolumeName = 'MyUSBStick1'

# write back the changes. Only now will WMI check your changes for validity,
# and if the new name is valid, assign it to the drive(s) you selected:
$drive | Set-CimInstance

# select the drive(s):
$wql = 'Select * From Win32_LogicalDisk Where Caption="E:"'

# define the property changes using a hashtable:
$changes = @{
	VolumeName='MyNewLabel'
}

# send changes to WMI:
Set-CimInstance -Query $wql -Property $changes