It Takes a Village to Manage a System

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

   Previous  [1]  2  Next