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."
Prev. page
[1]
2
next page 
