This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

Post holidays, day 7 looks at the shell itself and adding in snap-ins and modules. I have to say that the first time I looked at Powershell was in SQL Server 2008 when there was a “mini-shell”, but I didn’t understand what the difference was. I’m sure I’ve read other explanations, but they didn’t make as much sense. Perhaps because I’m more focused this time on learning PoSh it made sense? Not sure.

In any case. This chapter starts to explain, and emphasize, there is really only one shell for PoSh. This is in contrast to the earlier SQL implementation, but moving forward, everything will be in one shell. The various shortcuts you find for different Microsoft tools and features are the same shell with an “Import-Module” parameter passed in. This is the same way in which the MMC works, and it’s the same way that we often configure other tools, like SSMS and VS, which have add-ins.

That’s interesting, and good to know. This means I can not only customize my PoSh environment, but I can set up custom environments that can be shared on all computers in an organization or group. That is one of the main concerns I’ve had with PoSh. If I change my environment on my laptop to do things, I need to be sure all the places I’ll deploy the scripts to have the same environment.

The chapter also look at snap-ins and modules, which are different. In my earlier work with PoSh, the idea of snap-ins seemed to be a pain, almost like installing Perl on every machine. Snap-ins need to be pre-installed and registered on the computer to be added in. The examples in the chapter load the SQL Server snap-ins, though the chapter mentions that snap-ins are not the way forward. Modules are.

Modules are more like self-contained items that do not need to be installed. They just need to be in the PoSh path (environmental variable) or loaded with the full disk path. If the modules exist in the PoSh environmental variable, then they are auto loaded.

The rest of the chapter is really devoted to some practice with modules and loading them. There are brief sections that look at how you can pre-configure your own environment automatically with a configuration file that allows you to pre-load modules or specify settings. That can be handy, especially as you add a series of modules to your setup. That also seems like something that you might want to deploy to all servers, or all members of a team, in order to ensure that any scripts you have written will run.

Filed under: Blog Tagged: career, powershell, syndicated