08 March 2013 CI Team

Powershell offers to ways to expand CmdLet’s or Providers: SnapIns and Modules. But what is the difference?


Snapins Modules
Model from PS 1.0 Variante – “old” Introduced with PS 2.0
Defined in Assemblies Defined in Assemblies or in Scripts
Complex deployment via Installutil Moduls in the file system


Snapins: the old way

Snapins (like for example WebAdministration PSSnapin in the era of Windows Server 2008) are the old way which could be used in the first version of Powershell.

Disadvantages of this method:

- The PSSnapins have to be written in a .NET language and have to be available as an Assembly (there are some Sample Codes for the production of PSSnapIns in MSDN)

- The Assemblies have to be installed with a installutil.exe


What PSSnapins are installed on my system?

You will find all installed Snapins on the CmdLet “Get-PSSnapin-registered”:



Where are the PSSnapins saved? Of course in the registry!

The registration of the PSSnapins happens in the Registry:




What CmdLets are responsible for the administration of the PSSnapins?

Get-PSSnapIn –registered: delivers all available PSSnapIns
Add-PSSnapIn [name]: adds the PSSnapIn to the PowerShell Session
Get-Command –pssnapin [name]: adds CmdLets to the PSSnapin (has to be added via add to the session in the beginning)

All in all you should not create Snapins anymore – but they are still in use and therefore this explanation.


PowerShell modules – the new world

The modules get established with the second version of PowerShell and they offer a lot more opportunities without the need for registration in the registry.

Where are the modules saved?

If the only task is to import a module via the module-name with Import-Module usually it takes a look into the folders which are defined in the environment variable $env:psmodulepath:


Otherwise it is also possible to define a certain pad to Powershell modules at the Import-Module.

Note: In Powershell 3.0 all available modules are activated automatically in the session and you don’t have to load them with the Import-Module.


What modules are “installed”?

You will find a list on “Get-Module –ListAvailable”:



What is the “ModuleType”?

Other then PSSnapins modules can consist of simple scripts, a workflow, an assembly or a manifest. Therefore is the definition of the ModuleType:

A module whose members are defined within an assembly (
.dll extension), such as a snap-in or a class library that contains cmdlet classes. This field is introduced in Windows PowerShell 2.0.

A cmdlets-over-objects module (
.cdxml extension).

A module that is defined by a module manifest file (
.psd1 extension) whose ModulesToProcesskey is empty. This field is introduced in Windows PowerShell 2.0.

A module whose members are defined within a script module file (
.psm1 extension). This field is introduced in Windows PowerShell 2.0.

A workflow module (
.xaml extension).

From this MSDN article.


What does such a module look like? Let’s have a look at the “WebAdministration” module

The “WebAdministration”-Module (to administrate the IIS) is located in the usual “WindowsPowershell” folder and it contains some files:


The .psd1 file is the Module Manifest and in fact what is important:

Author='Microsoft Corporation'
CompanyName='Microsoft Corporation'
Copyright='© Microsoft Corporation. All rights reserved.'

The main functionality of the Powershell module is in the Microsoft.IIS.PowerShell.Provider.dll CLR 4.0 GAC.


How do I write a Windows Powershell Module?

After all the development of .NET based Powershell Modules is quite similar to the old Snapins:

How to Create a Powershell 2.0 Module and Cmdlet with Visual Studio 2010 (Screencast included)

A good reference is also Windows Azure CmdLets.


How do I register new modules?

The CmdLets for the registration of modules is also similar to the Snapins:

Get-Module -ListAvailable
Import-Module name
Get-Command -module name