PowerShell primers

All about PowerShell providers and modules

Here's what these commands are, how they work and how to use them in your daily activities.

PowerShell primers

Show More
1 2 Page 2
Page 2 of 2

Introducing modules and snap-ins

The modules feature is where PowerShell gets its ability to address a ton of different products and services from within one shell environment. Adding modules lets PowerShell work with different features, functions and configurations from all sorts of different software, from both Microsoft and from third parties, just by importing modules full of cmdlets and their reference information, or by adding a snap-in. What are modules? What are snap-ins? Let's do some rudimentary definition work up front so we can get it out of the way.

  • Modules are nice, neat containers of PowerShell functionality that extend the namespace and targeting power of PowerShell to other pieces of hardware and software. Modules are the de facto way of enabling PowerShell extensibility these days, and most server products that run on Windows come with modules for extending PowerShell, including all Microsoft server products from 2010 onward (and in some cases even before then).
  • Snap-ins -- or in proper PowerShell terminology PSSnapins -- is basically a set of DLL files that have accompanying XML files that contain configuration information and the text that displays when you ask for help via Get-Help. Snap-ins were part of the first release of PowerShell back in the mid 2000s, and you will see fewer of these types of extensions as time goes in as Microsoft and third parties replace them with modules. So for that reason, in this article I’ll talk just about modules.

Modules

Modules are, at this point, far and away the most common type of PowerShell extensibility feature you will see. Modules are basically containers filled with all of the information PowerShell needs to work with a given piece of hardware or software, including the commands, the libraries necessary to get those commands to work, the help text, and any configuration information that might be required. Modules exist to remedy a lot of the things that make snap-ins sort of unwieldy and difficult to consume and distribute.

PowerShell looks for modules in certain directories on your system. You place the modules in that directory, and that's it; PowerShell handles the rest. You don't have to register them or perform any other steps. There is a PowerShell variable called PSModulePath that contains the directories where PowerShell is going to look for modules on your system, and since there are usually multiple directories to search for modules in, each directory is separated by a semicolon with no spaces. No quotes are required here. How can you, ahem, *get* the *content* of this variable?

```

Get-Content env:PSModulePath

```

You either put paths in this directory, or you add the directory where other modules reside on your system to this path entry, which you can find in the Windows Control Panel. If I were you, I would just move modules into one of the two default directories and worry about other things.

What is particularly nice about modules is that, since they are stored in defined locations that PowerShell knows about in advance, they can be discovered automatically by the shell. So you get the advantage of being able to look for commands and have the help for a bunch of commands in a namespace that may or may not have been explicitly loaded yet, because PowerShell knows to look in *all* of the modules, not just the ones it has actively loaded.

This is how you get the benefit of tab completion and (at least in the Windows PowerShell Integrated Scripting Environment) IntelliSense without having to manually add a zillion modules to your session each and every time you want to run a command.

If you have a module stored somewhere else, which is something that happens rather frequently with third-party PowerShell modules, then you can import the module manually into your session by specifying the full path to the module with the Import-Module command.

```

Import-Module c:\powershell\modules\thirdparty\coffeemaker\

```

Modules can also add providers, which will then allow you, as you know, to walk up and down the configuration structure for a piece of software (or hardware, I suppose). To see whether any new providers were added when you added a module to your session, you can use the standard Get-PSProvider command we talked about in the previous half of the article. You'll see a list of names, capabilities and drives you can use with this new module.

The last word

As I mentioned, my goal for this piece was to show you more of the most important features of PowerShell. You even got to dive in deep into the Registry with your beginner PowerShell skills and turn off an important feature in Windows 10. Well done, ladies and gentlemen! Onward!

Copyright © 2017 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
  
Shop Tech Products at Amazon