PowerShell, like most Microsoft technologies, gives us more than one way to do the same thing. Sometimes that’s good news: it’s nice to use software that can compensate for differences in style from one user to another. Other times, it creates an issue. Sometimes one way to do something is less effective than another — sometimes in subtle ways. The wrong choice might add a few extra seconds to a job that takes a few minutes and many minutes to a job that might take hours. Those small changes add up over time. Which question do you want your boss to ask: “How does she manage to get everything done with time to spare?” or “Why is he always running behind schedule?”

I loved my freshman year high school Spanish class. I would have done okay had I been left to my own devices, but by luck, I had two of my best friends sitting on either side of me in that class, and we developed a friendly rivalry over our grades in the class. Competition pushed us to excellence far better than any of us could have pushed ourselves alone. Microsoft has capitalized on that desire to compete in a perennial competition called the Scripting Games. Competitors have a week to submit a solution to the challenge, posting it to www​.PoshCode​.org, which hosts the competition again this year. Each entry is then evaluated by a panel of judges. Prizes are awarded for the top-scoring scripters in a beginner and advanced division, and additional prizes are awarded randomly to participants, with an increased chance of winning as you participate in greater numbers of challenge events.

Microsoft just released the second CTP (that’s Community Technology Previews) of the forthcoming PowerShell 3.0. The version that comes on your Windows 7 clients and your Windows Server 2008 R2 servers is the 2.0 release, so Microsoft is giving the PowerShell community an opportunity to kick the tires on the new version before it goes prime-time. There are some great new features in there, but some of them make me worry that I may soon need to turn in a job application at AAA A1 Taxi Company.

Let’s review what we’ve seen about PowerShell pipeline behavior before we get to the grand finale of this extended discussion.

As you look at the help file for your favorite cmdlets, you’ll notice (if you’re using –full) that many of the parameters of those cmdlets provide support for pipeline input. Most of them, though, don’t accept pipeline input “ByValue” – they accept it “ByPropertyName”. This means that when an object is passed to this cmdlet on the pipeline, a “ByPropertyName” parameter of the cmdlet watches that incoming object to see if the object has a property with the exact same name as that parameter. If there’s an exact match, the value of that object’s property is applied to that parameter. Hoo, boy. Example time.

So you’ve got a Service object in your hands – maybe you ran something like Get-Service “Print Spooler”. So now what? Well, one logical thing to do might be to restart that service (perhaps to fix a stuck print queue). There’s a cmdlet for that, called Restart-Service. The principle of pipelining says that I should be able to just feed the Print Spooler service object to the Restart-Service cmdlet. It turns out that works.

PowerShell 2.0 embraces and extends an old idea in command-line administration — the pipeline. Understanding what can be done with this powerful feature is a key to being effective in the new, bold world of command-line administration of Windows systems.

Virus protection? PowerShell? Well… sort of.

An old Internet joke from way back involves the so-called Amish Virus. ‘Infection’ by the Amish Virus can be diagnosed when you open an email and see this:

Thou hast just received the Amish Virus.
As we haveth no technology nor programming experience, this virus worketh on the honour system. Please delete all the files from thy hard drive and manually forward this virus to all on thy mailing list.
We thank thee for thy cooperation.
 — The Amish Computer Engineering Dept.

The subtle humor of this long-standing joke lies in the fact that the author of the ‘virus’ is so technology averse that you have to damage yourself and others with it manually – the virus is not going to automate any of that for you. Of course, few recipients of such an email would go through the effort of doing something so obviously destructive. Common sense quickly argues against deleting valuable files or taking deliberate steps to infect friends with a damaging virus.

Is there anybody out there? Are we alone in the universe? Are my computers online? PowerShell 2.0 can tell you! (At least that last one.)

So the boss emails you a list of computers and wants you to check if each of them are available on the network. You could open a command prompt, type PING and the first name, wait for a response, PING the second, ad nauseum. If there’s two names on the list, fine. How many on this list? 183. Yuck! Sounds like a job for… PowerShell!

When we left off, I’d found the date and time of the last Restore Point taken on this machine. And luckily, since this data is coming out of WMI, I can extract the name of the computer I’m running this on from the same object. WMI helpfully supplies a ‘__Server’ property with its objects (note: that’s two underscore characters, not one). So with a little finagling, we get this cute little one-liner (cutting out that awkward ForEach-Object).