Lee Holmes - Windows PowerShell Cookbook

Copyright 2008 Lee Holmes

Whenever I think "perspective" and "scripting"which is far too oftenI think Bob Wells. Bob takes his scripting very seriously and has been promoting it inside and outside of Microsoft for years. When I joined the Scripting Guys team, Bob would preach to me about "glue" and "enablers." It took some time before I understood why he was talking about it so often and why finding just the right term for enablers was so important to him. I now know that it's because crisply defining these two concepts establishes a simple, useful framework in which to think about admin scripting. The glue part is the scripting language itselfthe foreachs, ifs , and vars .

It's what you use to orchestrate, or glue together, the set of subtasks you need to do to complete a larger task. The enablers (and, no, we never came up with a better term for them) are the instruments that actually accomplish each of the subtasks.

This table lists the glue and enablers that we, as Windows scripters, have had available to us over the years.

Notice how each new environment lets you work with the enablers of the previous environment. This is important because it lets you carry forward your hard-earned knowledge. Objectively, we can say that WSH scripting is more powerful than batch scripting because it provides access to more enablers. You can automate more tasks because you have access to the additional functionality exposed by automatable COM objects. Less objectively, you could argue that even if you're only going to use command-line tools as enablers, WSH is a better choice than batch because it provides some really useful glue functionality; advances in available enablers make more things possible while advances in glue (sometimes) make things more convenient.

WSH scripting is a pretty capable environment. The WMI and ADSI COM libraries alone provide admins around the world with countless cycles of pain and elation. But there's always that pesky task that you just can't do with WSH, or that requires you to download some tool from some strangely named web site at 2 a.m. when you really shouldn't be making decisions about what to install on your production servers. If only VBScript included the infamous Win32 API among its enablers, then, like those strange creatures known as developers, you could do anything .

Well, in developer land these days, the .NET Framework Class Library (FCL) is the new Win32 API. So, what we really need is a scripting environment that includes the FCL as an enabler. That's exactly what Windows PowerShell does. In fact, Windows PowerShell runs in the same environment as that library and, as a result, works seamlessly with it. I read a lot of press about the object-pipelining capabilities of Windows PowerShell. Those capabilities are very cool and represent an excellent advance in the glue departmentan advance that certainly makes working with the FCL more natural. But the addition of the FCL as an enabler is the thing that makes Jeffrey et al.'s creation objectively more powerful than WSH. And even if you don't run into anything in the FCL that you need right away, it's comforting to know that when you make an investment and develop expertise in this latest environment, you gain access to all the enablers that your developer counterparts currently have or will have in the foreseeable future. It should also be comforting to know that if you spend the time to learn Windows PowerShell, that knowledge should last you as long as the .NET Framework lasts Microsoft.

Windows PowerShell follows in the tradition of WSH by improving on the glue aspect of its predecessor. One of the real pain points of working with COM objects in WSH was finding out what properties and methods were available. Unless you shelled out the bucks for a smart editor, you lost a lot of productivity context switching from writing a script and consulting documentation. Not so when working with objects in Windows PowerShell. Type this at a Windows PowerShell prompt:

It does a scripter good, does it not?

Hopefully my rambling has convinced you that Windows PowerShell is a good thing and that it's worth your time to learn it. Now, why do I think you should learn it by buying and reading this book?

First off, I should tell you that the Windows PowerShell team is a bunch of odd ducks.[] These folks are obsessed. From Jeffrey Snover on down, they are incredible teachers who love and believe in their technology so much that it's difficult to stop them from teaching you! Even among that bunch of quackers, Lee stands out. Have you ever heard the sound an Exchange server makes when it cringes? Well, ours cringe when Lee comes to work and starts answering questions on our internal Windows PowerShell mailing list. Lee has amassed unique knowledge about how to leverage Windows PowerShell to address problems that arise in the real world. And he and O'Reilly have done us a great service by capturing and sharing some of that knowledge in this book.

Windows system admin scripters are the coolest people on the planet. It continues to be a pleasure to work for you and I sincerely hope you enjoy the book.

Dean Tsaltas

Microsoft Scripting Guy Emeritus

In late 2002, Slashdot posted a story about a "next generation shell" rumored to be in development at Microsoft. As a longtime fan of the power unlocked by shells and their scripting languages, the post immediately captured my interest. Could this shell possibly provide the command-line power and productivity that I'd long loved on Unix systems?