Getting Started with Windows PowerShell

If asked to call out the single major difference between Windows and UNIX--and let's leave calls of "uptime" for the laugh track, please--I guess I'd have to go with the command line. UNIX was built with a command-line interface (CLI) as the default, whereas the CLI in Windows is decidedly an afterthought. Windows, instead, puts the GUI first.

Much of that difference has more to do with timing than anything else. Windows simply came of age in the era that began with the Macintosh; UNIX, of course, predates the GUI. Today, most experienced UNIX administrators are CLI experts of some sort, able to rattle off complex scripts in their sleep, though of course most are beholden to curious CLI environments and even particular text editors. It's all part of the culture.

On the Windows side, most administrators are familiar with the admin tools that ship in Windows and with various Microsoft and third-party management tools. Truly experienced Windows administrators are at least passingly familiar with the Windows CLI, and various scripting environments. But they've been hobbled by the unsophisticated nature of the MS-DOS-based CLI in Windows and the fact that it hasn't been seriously updated in more than a decade.

Well, no more. Microsoft has created a new CLI, the Windows PowerShell (previously code-named Monad) that offers a best-of-both-worlds compromise between the power of UNIX CLIs and the discoverability and usability of Microsoft .NET-based programming languages. PowerShell, put simply, is the CLI done right. And if you're looking to enhance your administrative toolset and, ultimately, your marketability, this is something you'll want to look into.

Like many Microsoft technologies these days, PowerShell has been developed outside of any major Microsoft products, but it will ultimately be integrated into various products and, eventually, Windows itself. In the meantime, you can download a near-final version of PowerShell and install it on various Windows Server 2003 versions (including the x64 versions and R2), Windows Vista, and Windows XP. It requires .NET Framework 2.0.

Although PowerShell should ship as a standalone product by the end of the year, its first major appearance will be as part of Microsoft Exchange Server 2007. As I've discussed before in Windows IT Pro UPDATE, Microsoft has engineered Exchange 2007 as if it were a UNIX server. The management GUI is a subset of what's available from the PowerShell-based command-line tools. Amazing.

PowerShell might still be included as part of Longhorn Server, currently due in the second half of 2007. Presumably, it will be included in post-Vista Windows client and server systems.

Here's why PowerShell is exciting. First, it's consistent and logical. Say what you will about .NET, but the .NET Framework is a model of consistency, and PowerShell takes the same approach with its own .NET-based language (complete with all the arithmetic operators, assignment operators, variables, methods, and other features one would expect of a scripting or software-development language) and object-oriented namespaces. PowerShell improves on UNIX CLIs by offering consistent output: Everything that provides output in PowerShell is predictable, making it easier to build complex scripts. PowerShell is also discoverable. If you don't know the properties of a particular method, for example, PowerShell can display in-place lists of those properties so you can find the right one. And it supports Tab-completion of keywords.

Next week, we'll look at some specific PowerShell examples. In the meantime, here are a few resources to get you started:

Microsoft PowerShell Team Blog

Windows PowerShell (includes RC1 download)

Exchange 2007 Script Center

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.