Extending PowerShell: Modules and Snapins

One of the coolest things about PowerShell is its ability to be extended - just like, in fact, the Microsoft Management Console (MMC). Although PowerShell v2 comes with a built-in set of over 400 commands, many major Microsoft (and third party!) technologies and products ship with extensions to make PowerShell more powerful.

First, be aware that extensions must be installed on your local system in order to be loaded into your local shell (there's a kind of fun exception called Implicit Remoting, but that's beyond what I'll talk about today). Generally speaking, extensions get installed alongside a product's normal administrative tools. So, install Exchange Server 2010's admin tools and you'll get its PowerShell extensions, too.

There are two types of extensions.

First up are snap-ins, or more formally, PSSnapins. These are the "old way" of extending the shell, available in v1 and v2, although you'll still see folks using this method. Snap-ins always have to be installed and registered with the operating system. Here are your key tasks:

  • Get a list of installed snapin names: Get-PSSnapin -registered
  • Load a snapin by name: Add-PSSnapin name
  • Show the commands in a snapin: Get-Command -pssnapin name
  • Show loaded snapins: Get-PSSnapin

Next up are modules, which are the newfangled, v2-only way of extending the shell. These don't always need to be installed - often, they can simply be copied to their destination and used, as they don't require registration. However, some modules do have dependencies - such as items that must be present in the .NET Global Assembly Cache - that mandate some kind of installation routine. Again, they're usually installed along with management tools - install the Win7 Remote Server Admin Toolkit (RSAT), for example, and you'll get all the 2008R2-related modules (and maybe a snapin or two). Key tasks:

  • Get a list of installed snapin names: Get-Module -listAvailable
  • Load a snapin by name: Import-Module name
  • Show the commands in a snapin: Get-Command -module name
  • Show loaded snapins: Get-Module

Note that modules can be referred to simply by name ("ActiveDirectory") if the module is located in one of the two paths that PowerShell automatically searches. Those paths are in your PSModulePath environment variable, and you can see it by getting a directory of the ENV: drive within PowerShell. You can modify that path to add additional locations. You can also load a module by specifying the full path to it, rather than just its name.

Now, let's be clear on something: An "extension" is not another version of PowerShell. It's something that gets loaded into the shell, either by you or some other means. This can be a bit confusing, because many Microsoft products drop an icon onto the Start menu that would make you think there's a special "Exchange" version of PowerShell, and "AD" version of PowerShell, and so on. Not so. For example, in Windows Server 2008 R2, on a domain controller, you'll find a Start menu item named "Active Directory Module for Windows PowerShell." Pull up the properties on that shortcut, and you'll see that all it does is run:

powershell.exe -noexit -command import-module ActiveDirectory

See? All it's doing is launching the normal PowerShell and preloading the ActiveDirectory module. You're free to manually load additional snap-ins or modules - or you could just open a "normal" PowerShell window and import the ActiveDirectory module yourself. You'll get the same results, and capabilities, either way.

Do you have a module or snapin that you rely on frequently? Which one is it? Drop a comment and let me know!

Discuss this Blog Entry 1

Aleksandar (not verified)
on Aug 12, 2010
"First, be aware that extensions must be installed on your local system in order to be loaded into your local shell (there's a kind of fun exception called Implicit Remoting, but that's beyond what I'll talk about today)."

Script modules can be easily run from network share (with a little change to $PSModulePath environment variable). Even a binary module can be used with a help of caspol.exe tool, although I haven't tested that.

More details: http://powertoe.wordpress.com/2010/08/10/corporate-powershell-module-repository-part-1-design-and-infrastructure/



Please or Register to post comments.

What's PowerShell with a Purpose Blog?

Don Jones demystifies Windows PowerShell.

Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×