Day-5: PowerShell Modules & PSSnapin

Introduction

One of the PowerShell's primary Strengths is its extensibility. As Microsoft continues to invest in PowerShell, it develops more and more commands for products like Exchange, SharePoint Server, System Center Family, SQL Server and so on. Typically when you install these product's Management tools, you also get a graphical management console of some kind and one or more extensions for Windows PowerShell.

How IT Works

You all are familiar with the graphical Microsoft Management Console (MMC), same management team within Microsoft develops both the MMC and PowerShell Modules (or Snap-in) for particular MMC. When you open a new, blank MMC console you add Snap-in like DNS, Active Directory Users and Computer.   

PowerShell works in almost exactly the same way. Install the management tools for a given product, doing so will give you any related PowerShell extensions, and it may even create a product specific management she.

These Product specific shells have been a huge source of confusion. I want to clearly state that there is only one Windows PowerShell. There isn't a separate PowerShell for Exchange or Active Directory, it's all a single shell. Let's take an example of Active Directory Shell. 

Fig 1.1 Property Dialog Box

On a System, with Active Directory Users and Computer MMC console installed, you can find the icon for Active Directory Module for Windows PowerShell under Administrative Tools. If you right-click the icon and select properties, you will see a dialog box will appear like Fig 1.1. You can see the target field, which will be this,

%windir%\system32\windowsPowerShell\v1.0\powershell.exe -noexit -command import-module ActiveDirectory

When you open this shell, from Administrative tools, it redirects you to PowerShell.exe and runs a specific command Import-module ActiveDirectory. Now we could think of open normal PowerShell console, and run the same command yourself to get the same functionality.

The same holds true for every product specific "management shell" You'll find Exchange, Sharepoint, SQL server 2012, you name it. Examine the properties of those products and you'll find that they open the normal PowerShell.exe and pass a command-line parameter to either import module. add a snap-in or load a preconfigured console file.

Exception Case - SQL Server 2008 and SQL Server 2008R2, is a specially compiled version PowerShell that runs only the SQL server extensions called mini-shell.

PowerShell v3 has two kinds of extensions: Modules and Snap-in. We will first look at Snap-in first

Finding and Adding: Snap-ins

The proper name of PowerShell Snap-in is PSSnap-in, which distinguish these from snap-ins for the graphical  MMS. A PSSnapin generally consists of one or more DLL files. accompanied by additional XML files that contain configuration settings and help files. PSSnapins have to be installed and registered in order for PowerShell to know they exist.

You can get a list of available snap-in by running below command.

Get-PSSnapin -registered

This tells us that we have one Span-in installed and available, but not loaded. You can view a list of loaded Snap-in by running below command.

Get-PSSnapin

To load a Snap-in in the shell, run below command.

Add-PSSnapin  WDeploySnapin3.0

Once a snapin loaded in PowerShell Console, you'll want to figure out what it added to the shell. A PSSnap-in can add cmdlets, PSDrive provider( will be covering this topic in upcoming blogs ) or both to shell. In the video below I have shown how to work with PSSnapins.

Finding and Adding: Modules

PowerShell v3 and v2 support a second type of extension called a Module. Modules are designed to be a little self-contained, and somewhat easier to distribute. but they work similarly to PSSnapin.

Modules don't require advance registration, Instead PowerShell automatically looks for certain paths to load the path to find modules. The PSModulePath environment variable defines the paths where PowerShell defines the paths where PowerShell looks for the modules. 

get-content env:psmodulepath

C:\Users\Ankit Sharma\Documents\WindowsPowerShell\Modules;
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\;

From the above command result, you can see there are two default location, one in the operating system folder, where system modules live, and one in the document folder, where you can add any personal modules.

Why is the PSModulePath is important? because the module placed in those locations can be automatically detected and loaded by PowerShell console. In the below figure it is shown that how we can edit the default PSModulePath value on the system.

In the below video, I have shown how to get modules and load in the console.

So, in this blog, I have guided you how PSSnapin & Module works in PowerShell. In my next blog, I will introduce you all to below topics.

1. PowerShell Objects