Category: Blog

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.

The authors note this is an optional chapter, one that isn’t necessarily one you need to read. After going through it, I’m not sure I agree, especially as I’m not completely sure I grasp all the contents, though I do think they will be handy.

When you pipe output from one command to another in Unix, it’s really a text stream. Just as it would be written to stdout, it’s sent to the next command. That means your commands need to handle text as inputs.

In PoSh, if I understand this, that’s not the case. The inputs into commands are through parameters for the most part. That means that the output from one command, which is a collection of objects, needs to be accepted in the next. For many commands, that doesn’t quite work.

There are two methods of sending in parameters. One is input ByValue, which is a parameter binding method. In this method, PoSh looks at the type of parameter being sent in, in essence the object type (or data type) and matches to a parameter if the parameter accepts pipeline input. Not all do, and you need to read the HELP for a command to see which parameters accept pipeline input. That seem mis-named to me. It’s ByType, not ByValue in my mind, but I’m certainly not a PoSh expert.

The other way is ByPropertyName, which is as it implies, by name. The object coming in has its name matched with the parameters of the command on the other side of the pipeline.  That makes more sense, though there are times that the names don’t match.

That’s where you can then create custom properties with the Select-Object syntax that creates name/value pairs from your input. It looks like handy, not too complex, but cumbersome syntax. I’ll have to play with this more as I had to work through some exercises and carefully watch my parens and braces (opening and closing) as I typed in some commands.

One thing that frustrated me slightly with these exercises is that a bunch of them looked at multiple machines, and I don’t have a domain at the present time with matching credentials. I couldn’t figure out (easily) how to connect to another machine with custom credentials for Get-Process and Get-Service, but I also was running short of time this lunch, so I skipped.

The lab was analysis without using PoSh, since many people reading the book might not be admins on a domain. I got most of the answers right, but not always the explanation. I certainly think I need to play with this more, and that means I’ll stand up a domain here soon that I can use. I need to do that anyway.

The custom properties, along with the introduction of parens for order of operations, make this a must read chapter for me. I think the authors shouldn’t caveat this one at all.

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.

What are objects? I’ve always found that to be a hard question to answer if I’m talking to someone that doesn’t understand how to program. The explanation here is simple, relating each row of results to an object, and the entire result as a collection. It’ s a little simplistic, but it works for Powershell. The whole idea, really, is to understand that these objects have types (each field or column) and those types matter because they affect what we can do with the output of each part of a PoSh process.

Get-Member is the big introduction here, to help you find out what the properties and methods are for these objects. I have the feeling this is handy because when things don’t work right and you are debugging, Get-Member (or gm) is probably very handy. The other commands that are introduced here and are handy are the SortObject (or Sort) and Select-Object (or Select). These are easy concepts for me, because the way they work, with multiple columns and ascending or descending (-desc) are very similar to SQL Server.

Overall, it’s a short chapter, but I feel like it’s starting to be more useful. I can pick and choose, easily, which columns I want, sort them, and find the various ways I can interact with an object. The lab was easy, feeling more like writing simple T-SQL queries than anything else.

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.