Peter Seale's weblog

Introduction

I'll try to summarize as succintly as possible:

PowerShell is the first true Windows scripting language. It's not VBScript. I'm sorry that in the past, I've compared PowerShell directly with VBScript as if they were equals; they're totally not. PowerShell can use COM objects like VBScript, but that's about it comparison-wise.

PowerShell is a real language, closer to Perl and Python (and Ruby) than it is to any flavor of VB (excluding VBx--the future, possibly mythical and possibly vaporous, scriptable version).

PowerShell uses the .NET framework with gusto!

PowerShell is also an excellent place to let a quick two-line script rip, or to explore the SharePoint object model in a sort of immediate window (or what the Lisp, Ruby, Smalltalk and Python folk like to call the "interpreter"). It's inline, is the point.

PowerShell pipes objects, not text (though it does pretty well with text too). This "object piping" nonsense is best explained by example (i.e. not here).

UPDATE 2007-08-06: despite my beefed-up introduction above, it's probably wise to go read someone else's introduction.

Step 1: Disable Security

"Secure by default" security measures have proven to be effective, and this next section is in no way disrespectful towards the important strides the industry has made yada yada yada now how do you turn off security so I can run some scripts already? It's easy! Load up the PowerShell prompt and type in:

Set-ExecutionPolicy Unrestricted

This will give you (and potentially, hackers like Boris) the ability to run scripts just like all the viruses used to do with Word macros and HTML application files. To further open security holes, associate .PS1 files with the powershell executable, found in "%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe".

Step 2: Install an IDE

UPDATED 2007-08-06: PowerShell Analyzer is the only PowerShell IDE of which I know. I am not an heavy scripter, so I can't personally justify a money-costing IDE, but you may be interested. As for myself, I'm using a text editor with PowerShell syntax highlighting.  I'm not strongly recommending either one; pick something--anything but notepad!--and go.

Step 3: Wait NaN Months for Documentation

The best online source for information about PowerShell is a tie between a someone calling himself /\/\o\/\/ and the rest of the internet. That's both a tribute to how excellent MOW's information is, and simultaneously an omen warning you how completely lacking everything else is. Also, there aren't any books--

UPDATE 2007-08-06: //\/\O\\/\/ is still the best source of online information, but at least now there's a PowerShell book, including an excellent "just a PDF" eBook I highly recommend buying (available only direct from the publisher). Though the eBook concept may not sound as awesome as you'd think, note that you can navigate with both search and internal hyperlinks--this is why we invented computers in the first place, right? So we can type "CTRL+F, type "[switch] parameter", hit ENTER" and find out what a switch parameter does? Answer: yes, and to answer the question a second time for emphasis: yes, emphatically.

Step 4: Get the PSCX (Community Extensions)

The PowerShell Community Extensions are an excellent collection of useful cmdlets (i.e., "PowerShell libraries" (i.e., "programming stuff" (i.e., "oh forget it--let's just say 'stuff'"))). One of my favorites is the "Set-Clipboard" cmdlet (it outputs directly to the Windows Clipboard)--not that you particularly care about my favorite; discover your own. You'll find at least one indispensable cmdlet among the bunch.

BONUS DOWNLOAD: Try the  world-famous tab expansion engine (read: PowerShell intellisense, at the prompt), developed by none other than /\/\o\/\/, "the better portion of PowerShell content on the internet".

Footnote: Active Directory (ADSI) support is weird

UPDATE 2007-08-06: I've found an excellent summary of PowerShell's ADSI (or Active Directory) support. This page was not the first result on Google when I searched for "PowerShell ADSI", which is nothing less than a crime--a search engine results felony.

The really, really quick summary is that all of the useful methods for working with Active Directory objects are hidden from you. What should be obvious, isn't. What should be discoverable, isn't.

Let's do this by hypothetical example. Not that I've tried this myself! I'm smarter than that. Let's just say that I wanted to find all members of an Active Directory security group (let's just say). Assuming you already have the group object, how would you walk the object hierarchy to pull all members of the group? I'll make it easy and give you three options:

#option 1
$group.member
#option 2
$group.psbase.get("member")
#option 3
$group.psbase.invokeget("member")

If you guessed "oh no it can't be #3," guess what! And if you're not angry enough, let me tell you that the super bonus of this story is that all three options are legal syntax.

Guess how I spent my time today?

UPDATE 2007-08-06: Again, read that excellent PowerShell ADSI article I referenced above. It explains all this and more.