Type Accelerators: A Useful But Undocumented Feature in PowerShell 1.0

If you never heard of the [wmi], [wmiclass], and [wmisearcher] type accelerators, you're not alone. The online documentation that comes with Windows PowerShell doesn't mention them. And if you search the Microsoft website, you'll find references to them in some "Hey, Scripting Guy!" columns and in a few blogs, but that's it.

So what are type accelerators and why should you care about them? As you probably know, PowerShell uses the Windows .NET Framework, which is why the .NET Framework is required to install PowerShell. Type accelerators let you more easily access .NET classes in PowerShell code. In the case of the [wmi], [wmiclass], and [wmisearcher] type accelerators, you can more easily access several classes in the .NET Framework's System.Management namespace, which is used by Windows Management Instrumentation (WMI). Other type accelerators let you access different .NET namespaces and their classes. (To learn more, see the box "More Types of Type Accelerators.") Because you can more easily access the .NET classes, you can sometimes reduce the amount of code you need to type. But perhaps more important, you can easily gain access to the .NET classes' properties and methods, some of which aren't accessible through PowerShell's Get-WmiObject cmdlet.

The [wmi] type accelerator provides a way to more easily access the ManagementObject class, which represents a WMI object. You provide a path to a specific WMI object and the [wmi] type accelerator returns that object. You can use this type accelerator instead of using the Get-WmiObject cmdlet with the -filter parameter. For example, suppose you want to access the object representing Task Scheduler on your computer. Using the Get-WmiObject cmdlet, you can run the statement

Get-WmiObject -class Win32_Service –filter "name='Schedule'"

Using the [wmi] type accelerator, you'd run

[wmi] 'Win32_Service.Name="Schedule"'

Figure 1 shows the results of both statements.

Figure 1: Results of the Get-WmiObject and [wmi] statements

As you can see, you get the same information with either statement, but the [wmi] type accelerator statement requires less typing (albeit not much, especially if you use an alias for the Get-WmiObject cmdlet).

If you want to quickly find information not in the default display, you can use a statement such as

([wmi] 'Win32_Service.Name="Schedule"').description

As with most good things, there is a caveat. To use the [wmi] type accelerator, you need to know the exact path to the object, which the __PATH property contains. You can customize and use the following code to find a path for a WMI object in the root\cimv2 namespace:

$colItems = Get-WmiObject -class "<class_name>" | sort "Name"
foreach ($objItem in $colItems) {Write-Host $objItem.Name, $objItem.__Path}

In this code, you need to replace <class_name> with the name of the class that contains the WMI object you're seeking. (Don't include the angle brackets when you specify the class.)

This path-finding code returns the name and path for all the WMI objects in the specified class, so you'll need to search through the names to find the object of interest. Next to the name will be the path. The part of the path you need to use with the [wmi] type accelerator appears after the colon.

For example, if you want to find a path for the WMI object representing the Spooler service in the Win32_Service class, you'd run the code

$colItems = Get-WmiObject -class "Win32_Service" | sort "Name"
foreach ($objItem in $colItems) {Write-Host $objItem.Name, $objItem.__Path}

In the output, you'll find the entry

Spooler      \\<computername>\root\cimv2:Win32_Service.Name="Spooler"

where <computername> is your computer's name. In this case, the part of the path you'd use with the [wmi] type accelerator is Win32_Service.Name="Spooler".