In-Depth

The Power of PowerShell

Readers have high praise-and high expectations-for Microsoft's new command-line shell and scripting tool.

• By Joanne Cummings
• 06/01/2007

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, you're golden."

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 with PowerShell."

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 bash shell."

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, not PowerShell."

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 PowerShell support."

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."