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
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.
Jeffery Hicks is a Microsoft MVP in Windows PowerShell, Microsoft Certified Trainer and an IT veteran with over 20 years of experience, much of it spent as an IT consultant specializing in Microsoft server technologies with an emphasis in automation and efficiency. He works today as an independent author, trainer and consultant. Jeff writes the popular Prof. PowerShell column for MPCMag.com and is a regular contributor to the Petri IT Knowledgebase and 4SysOps. If he isn't writing, then he's most likely recording training videos for companies like TrainSignal or hanging out in the forums at PowerShell.org.
Jeff's latest books are Learn PowerShell 3 in a Month of Lunches, Learn PowerShell Toolmaking in a Month of Lunches and PowerShell in Depth: An Administrators Guide.
You can keep up with Jeff at his blog http://jdhitsolutions.com/blog, on Twitter at twitter.com/jeffhicks and on Google Plus (http:/gplus.to/JeffHicks)