PowerShell Primer

A few times in the last few weeks I've been asked if it's worth learning PowerShell. My answer is always “yes”. Rather than repeat myself too often I thought I'd make a post out of it.

But first, an apology. I met a chap at vBeers in London about 6 weeks ago. His background was more UNIX than Windows but he recognised that PowerShell was something that he'd have to learn a bit about. At the time I did promise to send him a few useful links to get started. As you might have guessed, I didn’t do it.

So… Jeff, I'm sorry.

For the benefit of Jeff and anyone else, here are some places to start when it comes to PowerShell and also PowerCLI (VMware’s extension cmdlets to PowerShell for managing their products).

PowerShell is based on Microsoft’s .NET Framework. It is said that anything you can do or code in .NET you can also do in PowerShell. I have to say that it’s a hell of a lot easier if there’s already a cmdlet for what you want to do already but fortunately there are cmdlets for just about everything it seems.

What is a cmdlet?

A cmdlet (pronounced normally as “command-let”) is the term that Microsoft adopted for commands in PowerShell. Cmdlets are like “df” or “rm” in UNIX or “copy” or “dir” in Windows – they do something. Like normal commands, cmdlets take input variables and have various switches depending on their function. Like a Transformer though, there is more to them than meets the eye.

Options and input variables can be explicitly specified or can be positional (i.e. you don’t always have to tell the cmdlet what piece of information you're giving it – some can work it out for themselves).

Cmdlets have a specific naming format. They come in the form of an adjective followed by a noun or object. For example, “get-help”.

Cmdlets primarily handle objects. This is best explained by example. Take the command:

[ps]get-childitem c:windows[/ps]

It is roughly equivalent to “dir c:windows” – it gets every child item of c:windows – but each item it returns is treated as an object rather than being just echoed to the screen.

But because we haven’t done anything with those objects, they have been converted to text and formatted and displayed on the console. But what if we passed those objects on to another command?

What is the pipeline?

Anyone who has scripted before will probably be familiar with the concept of piping. In UNIX, for example:

[text]cat logfile.txt | grep horse[/text]

This first part of this command echos (or displays) the content of the file “logfile.txt”. Rather than being displayed though, the output of the command is passed to a second command (grep) which searches the text for the string “horse” and displays any matching lines.

Piping is achieved in exactly the same way in PowerShell but with a significant difference: PowerShell cmdlets pass objects across the pipeline, not just data. Again, an example is needed.

Looking at the data we got back from Get-ChildItem above, each object (or result) had the same properties associated with it. What if we wanted to manipulate or work with just one of those properties in another command – LastWriteTime for example. In UNIX or Windows batch scripts we'd have to use some sort of complicated regular expression to identify a single property of every file or directory. In PowerShell though, we can easily pick one (or more) property to use in another command. For example, let's sort the results above by LastWriteTime:

[ps]get-childitem c:windows | sort-object LastWriteTime[/ps]

Here the results of get-childitem are passed to sort-object and the results are sorted by LastWriteTime. This can be done so easily because the results are passed as objects and not just as data.

Is it just a bunch of new command line tools?

PowerShell is not just a command line language. Yes it can be used for day-to-day tasks but it also offers more conventional programming constructs like loops and functions (subroutines) and some fairly complex scripts can be created very easily. It doesn’t just have to be used at the command line either. There are several ISEs / script editors available that help format scripts, offer autocomplete, integrated help, debugging and variable inspection functionality and, incredibly, are free!

Currently in vogue, and rightly so, is PowerSE.

Does it just work with Windows?

Microsoft have been building PowerShell into most of their products for some time now. Among the first to extend the core set of cmdlets available were the Microsoft Exchange 2007 team. VMware, Citrix, NetApp, EMC and Quest are among other vendors who have taken the bull very firmly by the horns and built their own snapin to go on top of PowerShell.

Some Resources

So where do you start?

1. Make sure you have PowerShell installed.
2. Possibly download PowerSE or something similar. At the very least use a text editor that does PowerShell syntax highlighting.
3. Download any snapins that you want to use: PowerCLI for VMware as an example.

From there, as with many things, the best way to learn is to experiment and / or dissect the work of others to help with understanding. A word of caution though, be careful when comes to experimenting on production systems!

There are a few other resources that I can highly recommend if you're at all serious about learning and using PowerShell. In no particular order:

• This tutorial on the Computer Performance website goes through the basics of the language and its syntax with plenty of good examples and techniques to re-use.
• Jonathan Medd is a Microsoft MVP in recognition of his knowledge about PowerShell. His blog is regularly updated with lots of useful articles. (And I'm not saying nice things about him just because I met him for lunch earlier!) He also co-hosts the Get-Scripting podcast and co-wrote a book with PowerCLI guru Alan Renouf (amongst others) on using PowerShell to manage VMware vSphere. He has a number of useful links and book recommendations on his blog that I won’t repeat here, it’s best that you just go there.
• Alan Renouf’s blog updates are always worth reading. Also, Alan himself has hopped over the fence from being only a user of PowerShell and PowerCLI to being VMware’s Technical Marketing Architect for PowerCLI – he’s helping to make it better in ways you probably can’t imagine.

Finally, google is your friend. There are so many other clever people out there and most of them share their considerable knowledge and experience freely. Never be afraid to reach out to anyone. As long as your question or problem is sensible and you've already expended effort to solve it yourself then most people will help if they can. A quick bit of searching will normally answer your question or solve your problem.