Prof. Powershell

There's a Module for That: Extending PowerShell's Commands

Don't just stick with the commands that Microsoft provides -- extend the commands in PowerShell.

• By Jeffery Hicks
• 04/17/2012

One of the appealing features of Windows PowerShell is that it can be extended. You are not limited to the commands that Microsoft ships. You can load additional commands and functionality via a module. Many other Microsoft product teams and 3rd party vendors deliver PowerShell solutions for their products via modules, sometimes for free! Even the PowerShell community offers a wealth of free modules. That's the beauty of a module: anyone can create one!

A module is really nothing more than a PowerShell script with a .psm1 file extension, although they can include binary code, typically delivered in a dll file. In today's lesson I want to give you some basics on the module mechanism. First, you can run the Get-Module command to see what is loaded in your current session:

PS C:\> get-module

It is very possible you'll get nothing. But that simply means nothing is loaded in your session. We need to ask PowerShell to tell us what modules are available:

PS C:\> Get-Module -ListAvailable

You might see some listed as a manifest type and others as a script. All that really means is that the former includes a manifest file (.psd1) that specifies details and module requirements. PowerShell gets this collection of objects by checking an environmental variable:

PS C:\> $env:PSModulePath

User modules are found in ...\Documents\WindowsPowerShell\Modules and system modules in $pshome\Modules. Some products may modify this variable. For example, I have the Intel vPro module installed so PowerShell also looks at C:\Program Files\Intel Corporation\PowerShell\Modules.

The module file, usually either .psm1 or .psd1, resides in a subfolder with the same name. For example, I have the excellent HyperV module installed. See the path and filename?

PS C:\> get-module hyperv -ListAvailable | format-list ModuleBase,Path

ModuleBase : C:\Users\Jeff\Documents\WindowsPowerShell\Modules\HyperV
Path : C:\Users\Jeff\Documents\WindowsPowerShell\Modules\HyperV\HyperV.psd1

This trips a lot of people up. Make sure the module and subfolder name are the same. When I want to use this module, I can import it:

PS C:\> Import-Module HyperV

If you have a module file in another folder outside of $env:PSModulePath, you can still import it if you specify the path:

PS C:\> import-module S:\PSVirtualBox

To discover what the module can do, we can ask the Get-Command cmdlet:

PS C:\> get-command -Module HyperV

CommandType   Name                 Definition
-----------   ----                 ----------
Alias         Add-NewVMHardDisk    Add-VMNewHardDisk
Function      Add-VMDisk           # .ExternalHelp MAML-VMDisk...
Function      Add-VMDrive          # .ExternalHelp MAML-VMDisk...
Function      Add-VMFloppyDisk     # .ExternalHelp MAML-VMDisk...
Function      Add-VMKVP            # .ExternalHelp MAML-VMConf...
...

I can use any of these commands as long as the module is loaded in my PowerShell session. Once I close my session the module is removed. If I want to always have this module available, I simply add the Import-Module command to my PowerShell profile. If you want to unload a module manually, you can do this:

PS C:\> Remove-Module HyperV

If you are looking for some modules to try out, the Hyper-V module can be downloaded at http://pshyperv.codeplex.com/. In fact, you can find a number of PowerShell projects at CodePlex. You can also search PoshCode.org as well as my blog, including an ISE add-on to add a menu for managing modules. Remember that many modules are delivered as scripts so your execution policy will apply.

PowerShell 3 handles modules differently and dynamically. But I'll cover that in a future lesson.