About the PowerShell WMI Extensions module

Expose WMI classes as rich PowerShell commands with detailed documentation and manage local and remote systems using WMI via the wmix module for PowerShell.

The PowerShell WMI Extensions module is a project that I wish I had started as soon as PowerShell 2.0 was released in 2009. It has been in development since late 2011, after I had been working on my pspx module for many months, and it is one of the most ground-breaking modules I have ever produced. The purpose of this module is simple: to auto-generate advanced functions that look and feel like cmdlets, complete with rich parameters, help documentation, examples, remoting support, security customizability support, and everything that you would expect from top-notch PowerShell commands by harvesting the rich data that is stored inside WMI, reducing as much as possible (or ideally eliminating) the need to dig through WMI documentation or to use more complicated WMI cmdlets to manage your infrastructure.

WMI is a very broad and powerful management interface that has been exposed to PowerShell since it was first released. Unfortunately, the manner in which this rich management interface was exposed to PowerShell was through a very small set of generic commands. Figuring how to use these generic commands to manage WMI is challenging at best. None of the documentation embedded in WMI is exposed. Objects returned from the WMI cmdlets don't look or behave the same as objects returned from .NET classes. WMI management classes are not easily discoverable. WMI contains many classes that you will never need to know about or think about, and this large pool of classes makes it difficult to find what you are looking for. These opportunities, and many more, were the inspiration behind the wmix module.

Installation


The module can be installed by downloading and running the MSI package (recommended) or by downloading a ZIP file and setting up the module yourself.

By default the MSI package will install the module under your Documents folder in the following location:

%USERPROFILE%\Documents\WindowsPowerShell\Modules\wmix

However, you can choose to install the module in another location if you prefer.

The ZIP file contents need to be manually extracted to one of the paths that is included as part of the PSModulePath environment variable. Typically users will unzip the contents of the ZIP file into the following folder:

%USERPROFILE%\Documents\WindowsPowerShell\Modules *
  • Note that if the directory does not exist then you need to manually create it if you aren't using the MSI package.

It is also worth mentioning that you must also manually install all software identified in the prerequisites below. Future releases should take care of this for you, but for now make sure to install the prerequisites before you load the module (although the module is designed such that it will inform you if anything is missing when you try to use it).

PowerShell Compatibility


Windows PowerShell 2.0
Windows PowerShell 3.0 (this module has been verified as working on the release preview)

Prerequisites


PowerShell Proxy Extensions

Getting Started


To check if the module is installed correctly, invoke the following PowerShell command:

PS > Get-Module -Name wmix -ListAvailable

ModuleType Name                      ExportedCommands
---------- ----                      ----------------
Manifest   wmix                      {}

If you don't see the above result then the module was not installed correctly.

Once you have verified that the module was installed correctly, load it by invoking Import-Module.

PS > Import-Module wmix

When you first import the wmix module, you will be asked if you want wmix to create a WMI command library for you. Accepting this will cause a progress window will appear and wmix will interrogate WMI on your local system, creating a new, dynamic module called wmifx. Wmifx is a module containing hundreds of commands that expose the richness of WMI as consistent and easily discoverable commands complete with parameters, objects complete with properties and methods, and help documentation. These commands can be used to manage local and remote systems, and they expose much of the same connection- and security-related parameters that are exposed on the *-WMIObject cmdlets.

If you decide that you don't want the module created for you by default, you can create it yourself (or extend it if you want to add commands to it) by using the Update-WmiFunctionLibrary command. With this command you can interrogate WMI on the local system as well as on remote systems, giving you complete coverage over WMI in your environment from one module while masking most of the complexities that are encountered when working with WMI.

It is recommended that you allow wmix to create the initial wmifx module for you by default.

With the module import now complete, you can see the new commands that are available to use by invoking this command:

PS > Get-Command -Module wmix | Format-Table CommandType,Name

CommandType     Name
-----------     ----
Function        Get-WmiClass
Function        Update-WmiFunctionLibrary

Also, since a the dynamic wmifx module was generated, you can import it using the following command:

PS > Import-Module wmifx

With the wmifx module loaded, you can see the commands that it contains by using this command:

PS > Get-Command -Module wmifx | Format-Table CommandType,Name

CommandType     Name
-----------     ----
Function        Get-1394Controller
Function        Get-ApplicationService
Function        Get-AutochkSetting
Function        Get-BaseBoard
Function        Get-Battery
Function        Get-Binary
Function        Get-BIOS
Function        Get-BootConfiguration
Function        Get-Bus
Function        Get-CacheMemory
Function        Get-CDROMDrive
Function        Get-ClassicCOMClass
Function        Get-ClassicCOMClassSetting
Function        Get-ClusterShare
Function        Get-CodecFile
Function        Get-CommandLineAccess
Function        Get-ComponentCategory
Function        Get-ComputerSystem
Function        Get-ComputerSystemProduct
Function        Get-Condition
Function        Get-CurrentProbe
Function        Get-DataFile
Function        Get-DCOMApplication
Function        Get-DCOMApplicationSetting
Function        Get-Desktop
Function        Get-DesktopMonitor
...


Now that your command library is loaded, you can get help on any of these commands by using Get-Help:


PS > Get-Help Get-BIOS

NAME
    Get-BIOS

SYNOPSIS
    Gets instances of Win32_BIOS Windows Management Instrumentation (WMI) class. The Win32_BIOS class represents the at
    tributes of the computer system's basic input/output services (BIOS) that are installed on the computer.


SYNTAX
    Get-BIOS [[-Name] [<String[]>]] [[-SoftwareElementID] [<String[]>]] [[-Property] [<String[]>]] [[-SoftwareElementSt
    ate] [<UInt16[]>]] [[-TargetOperatingSystem] [<UInt16[]>]] [[-Version] [<String[]>]] [-JobName [<String>]] [-Search
    Property [<Hashtable>]] [-ComputerName [<String[]>]] [-Impersonation [<ImpersonationLevel>]] [-AsJob [<SwitchParame
    ter>]] [-Filter [<String>]] [-EnableAllPrivileges [<SwitchParameter>]] [-ThrottleLimit [<Int32>]] [-Credential [<PS
    Credential>]] [-Authority [<String>]] [<CommonParameters>]


DESCRIPTION
    The Get-BIOS command gets instances of Win32_BIOS WMI class.

    The Win32_BIOS class represents the attributes of the computer system's basic input/output services (BIOS) that are
     installed on the computer.

    The ComputerName parameter can always be used to specify a remote computer.
...



You can also invoke any of the WMI commands you like:


PS > Get-OperatingSystem

SystemDirectory : C:\Windows\system32
Organization    :
BuildNumber     : 7601
RegisteredUser  : Windows User
SerialNumber    : 54321-678-9876543-12345
Version         : 6.1.7601


Today this module only generates Get-* commands for WMI on local and remote systems. I'm working on adding generation of actionable commands as well (Set-*, Rename-*, Remove-*, etc.) and I will post that update once I have it ready. I'm also looking at how I can make this module support both WMI remoting as well as PowerShell 2.0 remoting so that you would be able to use the commands through WinRM and a much smaller hole in a firewall.

With this information under your belt, I encourage you to experiment with this module and share your feedback on the Discussion board. Let me know what you think! Also, if you encounter any problems, please log them using the Issue Tracker.

Thanks for giving wmix a try!

Kirk "Poshoholic" Munro

Last edited Jul 19, 2012 at 2:48 PM by poshoholic, version 20