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!
