The Power of PowerShell
Readers have high praise-and high expectations-for Microsoft's new command-line shell and scripting tool.
To know Microsoft's PowerShell is to love it. That's how most readers feel
-- it's just tough getting to that point.
PowerShell 1.0, formerly code-named "Monad" and later "MSH,"
is Microsoft's new object-oriented scripting language and command shell. Readers
say it's a huge improvement over Windows command shell (CMD.EXE), especially
when it comes to being productive when managing Windows environments. Although
the learning curve is a bit high, they say, getting comfortable with the tool
is well worth the time and effort.
"Admins are pretty busy already," says Dmitry Sotnikov, new product
research manager at Quest Software Inc. and a member of the PowerGUI forum.
He has been using PowerShell for more than a year now. "Just learning another
scripting syntax has a steep learning curve, but once you get past that transition,
That's true, says Chris Leonard, senior SQL Server database developer and administrator
at GoDaddy.com, a domain name registrar in Scottsdale, Ariz. Leonard says he
spent several weeks going through PowerShell's user guide at a rate of about
five or 10 pages a night, slowly getting a handle on how it worked and what
it could do.
"It took a while to plow through it, and to port all my other scripts
over to it, but the results are worth it," he says. "Now I use these
PowerShell scripts all day long. It's part and parcel of what I do. I have scripts
that automate the interactions with the database that are very repeatable. If
I need to change a database object, and I need to know which other objects depend
on this one, I can get that straight from the PowerShell prompt."
On Par With Unix and Linux
Windows has never been strong when it comes to scripting, readers say. That
has made administering large Windows environments more difficult than it should
be. PowerShell shines in those typical administrative environments, in which
users are tasked with repetitive tasks that can quickly drive GUI users crazy.
"GUIs are great when you don't know what you're doing or when you want
to do something just once," says John Vottero, partner at MVP Systems Inc.
in Columbus, Ohio. "But when you need to do something more than once and
you want it to be something you can repeat, you need to script it. It's taken
Microsoft a long time to learn that lesson, but they've finally figured it out
Readers have used other scripting tools for Windows, especially the old command
shell (CMD.EXE), but weren't always satisfied with the results. "Historically,
the scripting ability in Windows has always been second class compared to what
you can do in Unix or Linux, with nice shells like Korn shell and bash,"
Leonard says. "In Windows, you're either stuck working with the limitations
of command-shell scripting or you could load something like CygWin and their
Leonard says the biggest difference is that PowerShell's scripting language
is much more robust. Previously, he had tried to use CMD.EXE to script and push
database deployments to multiple servers. He found that as the scripts became
more complex, debugging and maintaining them became nightmarish.
"If I had scripts with dependencies -- like this script has to run before
these other two can run -- I wanted to be able to represent that in some kind
of a control file, and I was really struggling with it," he says. "When
I would go to make enhancements, the code was fragile and easy to break. And
it was tough to figure out why it broke. PowerShell is a big improvement."
The "Aha!" Moment
The differentiator between PowerShell and other scripting tools is that it's
object-oriented and built atop Microsoft's .NET framework. That means PowerShell
scripts aren't just piping around plain ASCII text. Instead, they're actually
scripting entire .NET objects, including all properties and methods.
"You pass information from one command to the next, and it can get pretty
awkward," says Leonard.
Because PowerShell works with complete objects, you can do much more with the
scripts. "Those objects still have their native properties and methods
attached, so if I want the length of that file, I just say 'GET-LENGTH,' and
there it is, boom. I didn't have to figure out where they put it in the display,"
Leonard says. "And I'm free to do anything with the object, not just display
it. That was definitely an 'Aha!' moment."
What makes PowerShell strong, he says, is that it follows conventional programming
constructs. It even has a built-in debugger, which is a huge improvement over
CMD scripts. "If it breaks, I don't have to just stare at my command-shell
script and try to find a syntax error," he says. "I can actually use
the debugger to step through my code like I would in a compiler environment,
almost. Plus, it handles arrays, looping and branching -- all these things you
look for in a full-blown programming language."
Compared to other scripting tools, PowerShell's commands and utilities are
very standardized. This is because it enforces a verb-noun naming convention
for all of its cmdlets (pronounced "command-lets"), the built-in commands
within the scripting tool. "With PowerShell, you don't get to name your
cmdlet," Leonard says. "You have to specify your verb and your noun
and then you get a name, verb-noun, like GET-DRIVE." That level of standardization
ratchets up the performance and efficiencies when using PowerShell, he says.
MVP's Vottero agrees that the standardized commands are powerful and intuitive.
"It's very easy for an end user to pick up on," he says. "If
you want to know how to get a widget, well, the command is probably GET-WIDGET."
Leonard's other "Aha!" moment had to do with PowerShell's ability
to interact with the Windows registry. "PowerShell extends the idea of
a drive, so that things besides file locations can be pointed at by drives,"
he says. "For example, certain pieces of the Windows registry are accessible
as drive letters, much like the C: drive on your computer."
One particularly helpful key in PowerShell is HKLM. "It points to a well-known
location in the registry called HKEY_LOCAL_MACHINE, and that's great,"
he says. "All of the sudden, without leaving the command prompt, I can
navigate into the registry, look things up and script interactions with the
registry just like I'm working with files."
Only a Few Downsides
Early users say the pros far outweigh the cons with PowerShell, but there are
a few missing pieces. For example, it seems to have limited capabilities for
remote machines. "I'm controlling a whole bunch of servers, so it would
be cool if there was some kind of naming syntax that would let me do tasks on
each of my servers," Leonard says. "That could easily streamline our
deployment process when pushing things out across the server farm."
Vottero adds that it's also a bit slow at times. "It's slow, but it's
not so slow that it's not usable," he says, adding that much of what appears
to be PowerShell running slow is really due to the way .NET works. "A directory
search looks slow, but it's the fault of the way .NET hands your directory entries
when you're doing a directory search. It's up to the .NET Framework to fix that,
PowerShell for Everyone
Perhaps the biggest plus to PowerShell is Microsoft's intention to include it
as a unifying component across its product lines. For example, PowerShell is
already included with Exchange 2007 and Systems Center Operations Manager. It
just debuted in beta 3 of Longhorn server. Microsoft has also signaled its intention
to include PowerShell in future versions of Windows.
"That unification is the biggest advantage," Sotnikov says. "I
can use it against Exchange and Operations Manager and [Internet Information
Server] IIS 7 and whatever other applications are going to be released with
Vottero, who's an ISV, says the next version of his product, the JAMS job action
and management system, will require PowerShell. That type of unification and
standardization will act as a catalyst for the Windows third-party marketplace.
"Microsoft's laying down the foundation and saying, 'here's how you do
command-line script-oriented stuff for Windows.' And now everybody can write
to that framework," he says. "Until PowerShell, that was always sort
of up in the air -- everybody kind of invented their own and there was no standard.
Now, when we do stuff that fits into PowerShell, it will work with other ISVs'
stuff that fits into PowerShell. And that means end users can combine everybody's
stuff into whatever they need to do to get their job done."
That's something Windows users have long clamored for. "If I was talking
to Microsoft and the PowerShell guys, I'd say, 'Great job,'" Vottero says.
"Too bad you didn't ship it five years ago."
Getting a Handle on PowerShell
Readers say it takes time to get up to speed on PowerShell. Here
are a few resources to make the process a bit easier.
1. PowerShell User Guide: Unlike many Microsoft products, the user guide
that accompanies PowerShell is actually useful. "I was surprised at what
a decent job the user guide did," says Chris Leonard, senior SQL Server
database developer and administrator at GoDaddy.com, noting that the guide he
uses came with the Release Candidate 1 release. "I recommend it as a very
effective learning tool."
PowerShell in Action: Readers say this
book, written by Bruce Payette, one of the founding members of the Windows
PowerShell team, is informative and entertaining. It provides a quick start
for novice PowerShell users.
3. PowerShell blogs: The Microsoft PowerShell team blogs about the product
and its fine points, and provides some glimpses of what the future holds. Read
their thoughts at www.blogs.msdn.com/powershell.
4. PowerGUI forum: This is a community effort to build a graphical user
interface on top of PowerShell to ease the learning curve and provide for easier
UI-to-command-line transitions. The community is based at http://PowerGUI.org.