Windows PowerShell for IT administrators

This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

“Go away or I will replace you with a very small shell script”

[T-shirt slogan from an attendee at tonight’s Windows PowerShell for IT administrators event.]

I’m back in my hotel room having spent the evening at one of Microsoft UK’s TechNet events and this time the topic was Windows PowerShell for IT administrators. I’ve written previously about PowerShell (back when it was still a beta, codenamed Monad) but tonight’s event was presented by Richard Siddaway from Perot Systems, who is not only an experienced infrastructure architect but also leads the PowerShell UK user group and thinks that PowerShell is one of the best pieces of technology ever (maybe a touch OTT but it is pretty powerful).

The event was demo-heavy and I didn’t grab all of the example commands (Richard plans to publish them on the user group website this week) so this post concentrates on what PowerShell can (and can’t) do and I’ll link to some more examples later.

What is PowerShell?
According to Microsoft, PowerShell is the next generation shell for Windows that is:

As interactive and composable as BASH/KSH.
As programmable as Perl/Ruby.
As production-oriented as AS400 CL/VMS DCL.

In addition to the attributes described above, PowerShell is extensible with snapins, providers and scripts. The provider model allows easy access to data stores (e.g. registry, Active Directory, certificate store), just as if they were a file system.

Scripting is accomodated in various forms, including text (Microsoft’s interpretation of the traditional Unix scripting model), COM (WSH/VBScript-style scripting), Microsoft.NET or commands (PowerShell cmdlets, emitting Microsoft .NET-based objects). As for the types of data that PowerShell can manipulate – it’s extensive, including flat files (CSV, etc.), .NET objects, XML (cmdlets and .NET), WMI, ADSI, ADO/ADO.NET and SQL.

So, PowerShell is a scripting interface with a heavy interface on Microsoft.NET – are programming skills required?
Not really. As Richard described, just because you can use native .NET code doesn’t mean that you should; however the more that you know, the more you can do with PowerShell.

Basically, simple scripts will need some .NET functions such as [STRING] and [MATH] and advanced scripts can use any .NET object but cmdlets provide an excellent administrative and scripting experience and are easier to work with – writing .NET code can be thought of as a safety net for when something isn’t possible using another method, rather than as a first port of call.

Where can I get PowerShell?
Although it a core element of the Windows Server System, providing automation and integration capabilities across the various technology platforms, PowerShell is a separate download for Windows XP (SP2)/Server 2003 (SP1 or later, including R2)/Vista and will be included within Windows Server 2008. Note that PowerShell is not supported on Windows 2000.

How can I learn to use PowerShell?
PowerShell’s documentation includes a getting started guide, a user guide, a quick reference guide and help text. Microsoft Switzerland has also produced a short Windows PowerShell book that’s available for download free of charge, there are plenty of other books on the subject and a “young but keen” community of administrators exists who are discovering how PowerShell can be put to use; however it’s probably best to just get stuck in – practice some ad-hoc development:

Try things out in an interactive shell.
Stitch things together with utilities and put the results in a script file (then realise that the tools are unsuitable and restart the process).
Once happy with the basic concepts, generalise the code (e.g. parameterise it) and clean it up (make it production-quality).
Once tested, integrate the PowerShell scripts with the infrastructure to be managed and then share scripts with the community.

One more thing – remember that it’s better to have many small scripts that each do one thing well than to have a behomoth of a script that’s very inflexible.

Is there anything else I should know before getting started?
There are a few concepts that it’s worth getting to grips with before launching into PowerShell:

Cmdlets are a great way to get started with PowerShell. Based on a verb-noun naming, they each provide specific functionality (e.g. get-help and make the resulting code self-describing (hence suprisingly easy to read).
The pipeline (think Unix or MS-DOS) – allows the output of one instruction to be fed into the next using the | symbol; however, unlike Unix/MS-DOS, .NET objects are passed between instructions, not text.
There is a text-based help system (cf. man pages on Unix-derived operating systems).
PowerShell is not case-sensitive (although tab completion will sometimes capitalise cmdlets and parameters); however it’s worth understanding that whilst double quotes (" ") and single quotes (' ') can be used interchangably, variables enclosed in double-quotes are resolved to their value, whereas the single-quote variant is treated as a variable.

There are also some issues to be aware of:

The default installation will not run scripts (not even the user’s profile) and scripts need to be enabled with set-executionpolicy.
There is no file association with PowerShell (for security reasons), so scripts cannot be run automatically or via a simple double-click. Scripts do normally use the .ps1 extension and although PowerShell will recognise a command as a script without this, using the extension helps PowerShell to work out what type of instruction is being issued (i.e. a script).
There is no capacity for remoting (executing code on a remote system) but workarounds are possible using .NET and WMI.
The current working directroy is not on the path (as with Unix-derived operating systems), so scripts are launched with .\scriptname.ps1. Dot sourced scripts (e.g. . . \scriptname.ps1) run in the context of the shell (rather than in their own context).
Although PowerShell supports use of the entire Microsoft.NET framework, not all .NET assemblies are loaded – some may need to be specified within a script.

Are there any other tools that work with PowerShell?
Various ISVs are extending PowerShell. Many of the tools are currently available as trial versions although some are (or may become) commercial products. Examples include: