Ask an obvious question; get an obvious answer. It's no surprise, then, that 86 percent of survey respondents prefer to have a choice between a GUI and a command-line interface (CLI) for systems administration, depending on the task's difficulty and the scripter's expertise.

Windows PowerShell (formerly code-named Monad) fulfills those preferences because it lets you work from the command line or build a GUI on top of a script. And people are eager for a tool that eases Windows administration: Although 98 percent of respondents use cmd.exe and only 60.5 percent had even heard of PowerShell, a whopping 94.3 percent would be motivated to learn a new command shell and scripting language that would make automating their Windows environment substantially easier.

PowerShell is the brainchild of its architect, Microsoft's Jeffrey Snover. Jeffrey has always been a champion of community involvement in PowerShell's development. Even with PowerShell shipping as part of Microsoft Exchange Server 2007 and announced as part of System Center Virtual Machine Manager, Jeffrey says, "We want people to tell us what they want. We want people to complain. My biggest concern is that people won't complain enough."

Don't worry, Jeffrey. Readers had plenty of questions about PowerShell. They complained about Microsoft's documentation and are concerned about the difficulty of PowerShell's learning curve (which will be the biggest problem, according to experts I've asked). Readers also insisted on lots of examples and sample scripts.

What Is It?
For readers unfamiliar with PowerShell, Jeffrey explained: "It's both interactive and scriptable. It lets you layer admin GUIs on top of CLIs. This is critical because it ensures that customers get the agility to decide whether a problem is best served with a GUI or with a command line. Second, it ensures absolute consistency between those two worlds."

Different levels of expertise demand different capabilities, readers told us. Jeffrey agreed: "We wanted one tool to meet all the needs of various types of scripters, so PowerShell has four distinct feature sets: Beginner scripters do not have to type or even name parameters; just use $args. More sophisticated scripters can name and type arguments and be very formal. Systems programmers can get at any .NET API. PowerShell supports direct access to .NET, WMI, ADSI, ADO, XML, command line, test-based scripting, COM-based scripting, and all that. So customers can truly standardize all their people and all their scripting on a single tool."

What could Microsoft do to make PowerShell easy to adopt? One reader said, "Incorporate it into the next OS release and create documentation detailing the advantages." I noted that Monad was originally supposed to be part of the OS and integrated with everything. Is that still the plan? Jeffrey said, "Eventually. Right now, version 1 will be shipped as a Web download, which allows us to go down level, so it will be on Windows XP and above. Over time it will be native in the OS. It is a commitment, but the plan is not announced yet."

The Documentation Factor
Continuing the theme of documentation, several readers said poor documentation could prevent them from deploying PowerShell. For example, a representative comment was: "The history of Microsoft is one of inadequate documentation about anything, including their scripting languages. They would need to prove they have finally done this right."

Jeffrey believes PowerShell has addressed the documentation factor. "The three things that popped in the survey were documentation, learning, and training. We've been planning to address those since the beginning. With documentation, the first consideration is discoverability. Our \[UNIX-like\] man-style Help system is comprehensive. And \[reacting to customer feedback\], we just agreed to make our man pages even more wonderful. Up to now, you'd request a man page and get everything in the entire reference manual. The signal-to-noise ratio was low. Now, you get one page. Then you can ask for more details and get a two-to-three pager or the full information. It's dramatically simpler. And unlike UNIX man pages, our man pages are like text renderings of Help objects, so you still have Help objects that you can do rich searching on."

What other documentation features address readers' concerns? "Reflection: When you type a command, you get objects. Then you want to discover the capabilities of those objects. So you pipe to Get-Member, which tells you everything about the objects. You start with: What can I type? Type 'Help,' which will tell you what you can type. Once you type something, what can you do with that? Well, you can manipulate it as an object. To learn what the capabilities are, pipe it to Get-Member, and it tells you. Next, you don't want to deal with it as an object, but want to manipulate it with commands. What commands can you use? Again, use the Help system to find all the *-Object commands: Where-Object, Sort-Object, Group-Object, etc." Of course, beginning users will need to know Power-Shell commands in order to get help. For a beginner-level overview of how to script, see "How to Get Started Writing Scripts," Instant-Doc ID 50486.

Jeffrey acknowledges that Microsoft documentation can't do everything. He relies on the community to share its knowledge. "There's a huge amount to explore. Power-Shell is at least as comprehensive as SQL, so we've gone out of our way to put internal, detailed information about how things work in our blog \[http://blogs.msdn.com/powershell\]. Experts in the community now know precisely how PowerShell works. They can use features we put into the code to walk through the steps in all of our algorithms. Also, in terms of external documentation, at least six books are being written or are already written."

Learning Curve
Despite some experts' reservations about PowerShell's complexity, readers seem eager for the challenge: "It will make the command line management easier, but it will require learning a new paradigm. It will be worth the learning curve."

Jeffrey insists, "Most people feel it's pretty easy to get up and running in half an hour. We've produced alias files for the DOS community and the UNIX community to facilitate the transition from existing environments. That greatly eases the adoption. You learn the key concepts, and then you'll just teach yourself the system. That was my experience with VMS. I struggled and thought 'Oh, this isn't UNIX!' I didn't like it. Once I relaxed and tried to understand, it didn't take long. In about 20 minutes, you realize everything in PowerShell has the same syntax. In another 10 minutes, you realize all the commands share a consistent set of parameters and each command supports a subset of those parameters. Then you can manage anything. The key is to get the naming. Our goal was to manage 80 percent of the system with fewer than 50 verbs. It was very hard to do. So learn those verbs. Guess those verbs and you're going to be right."

Samples and Examples
You can find a plethora of CLI and Visual Basic (VB) scripts today, which means you don't have to reinvent the wheel to solve common problems. How will PowerShell address the need for scripts that users can easily adapt for their environment?

Jeffrey replied, "All that previous stuff continues to work. You can invoke a VB script from PowerShell. You don't have to convert that script. And just running a batch script or a VB script from PowerShell makes it two to 10 times more powerful because you can now do traditional UNIX-style scripting: Take its output, parse its output, connect it with other things."

What about native PowerShell sample scripts? "The TechNet Script Center now has a PowerShell scripting environment," Jeffrey pointed out. "Lots of that material is being generated. Our role is encouraging people, making sure they have the information to succeed. That means both having good base documentation, as well as providing in our blog the details of what's really going on."

The Village People
Jeffrey sees community as key to Power-Shell's success. He said, "One joke is that 'it takes a village' to manage a system."

It also takes a village to hone a new tool. "We worked with customers and partners to find the most important things to deliver in version 1. But I learn far more from what you don't like than things you do. A concrete example: Before \[the Microsoft Management Summit last April\], I contacted Greg Ramsey, who was doing a session on scripting for SMS using VBScript. He didn't know about PowerShell, so I asked him to try it. He loved it and incorporated it into his talk and labs. People asked Greg if they should use VBScript or PowerShell. Greg said, 'If you're doing a certain type of activity, definitely use PowerShell. It's much more powerful. But if you're doing another type of activity, use VBScript, because PowerShell's WMI support isn't as good as VBScript's.' Whoa! That's great information. So today we'll be \[adding to PowerShell\] all the necessary \[WMI\] support. We had closed the release down, but we opened it back up \[to address the PowerShell shortcomings Greg identified\]."

The appeal of PowerShell seems obvious. What's not obvious is whether its complexity will allow wide success, especially for administrators who don't do much scripting. Let me know what you think.