Why Can't PowerShell Be the Windows Command Prompt?

LOS ANGELES - Over the past two years, tracking the official status of Windows PowerShell with respect to Windows Server has been, to put it delicately, a juggling exercise. During PDC 2005, for instance, reporters were given official indications from two Microsoft sources that the radically enhanced command line-based management tool would be shipped with the next edition of Windows Server, and would not be shipped with Windows Server, on the same day.

So when recent statements were made by Microsoft officials that PowerShell would be shipped with Windows Server 2008 and included with the new public Beta 3, our initial reaction was preceded by the phrase, "Yeah, right." Although the tool is freely available for download and it has been received by veteran admins with open arms, whether it gets shipped with the operating system itself is actually a more important matter than it may seem on the surface.

It may affect, for instance, whether future certification tests for admins will include PowerShell as an alternative, and it impacts whether the tool is officially supported in response to customer inquiries. It could change how people are trained to manage Windows, and how long that training would actually require.

Last year, when Microsoft revealed the development of Server Core - an optional Windows Server setup that omits the graphical environment in favor of a command prompt, for use in limited server roles - admins wondered whether the command prompt in question would be based on old-world DOS or new-world PowerShell.

The answer was disappointing, but the reasons were sound: PowerShell is a managed application, based on the .NET Framework which, for now, requires the graphical environment. So Server Core's command line would be CMD.EXE.

But is that the way things will stay? At WinHEC, BetaNews asked Windows Server 2008 product director Iain McDonald (one of its developers, as opposed to a product manager who works in marketing) about his goals for PowerShell in Server Core.

Admitting that this was his personal preference and not that of his division, McDonald responded to a question from BetaNews, "Personally -- this is biased -- if I could set the direction of it, I would like to make PowerShell the default shell for Windows. That's my personal bias." He added he doesn't expect his preference alone to set the direction of the product for the next couple of years, although he would like to see it replace the basic CMD.EXE command shell.

For now, Server Core has its own command set, including .EXE functions that operate from the command line. Would McDonald plan to alias those functions when PowerShell does become available for Server Core, so that admins won't find themselves making yet another lexicon shift? "I would like to do that," he responded.

Based on the roadmap Windows Server general manager Bill Laing presented on Wednesday morning, the server operating system's "cadence" - to borrow Intel's term - calls for a new release every five years, with interim "R2" releases in the in-between periods. In five years' time, McDonald believes, we'll all be able to look back and identify the "inflection point" where manageability of remote servers took a giant step forward, "managing hundreds of thousands of servers with very low operations," and credit PowerShell for bringing about that change of direction.

In an interview with BetaNews Tuesday afternoon, Windows Server senior technical product manager Ward Ralston explained that, during Server Core's development, the decision was made to cut all the possible overhead that was unnecessary for a server to perform certain basic functions, and .NET Framework happened to be on the list of items that was cut.

"With Server Core, it's important to remember that this is Version 1 of the product," Ralston told us. "What we did, when we started development on this, we looked at the top key workloads within an organization. At that time, it was File, Print, Active Directory, and DNS. And we said, 'How can we take those four workloads and put them in their absolute, most reliable configuration?' And that was the basis for Server Core. We removed the GUI, the .NET Framework, any DLLs or libraries that were not needed to perform those four particular roles."

Now that WS2K8 is on Beta 3, Server Core supports eight roles instead of four. But as a possible route to making more roles available, Ralston revealed to BetaNews that Microsoft is working on a possible "componentized" version of .NET Framework. Such a system would operate internally -- and ironically -- in a manner reminiscent of the Component Object Model, where procedure handlers contact one another indirectly via a common namespace.

"So we'll have the ability to just put in the core components of the .NET Framework into the product, to potentially support products like PowerShell," he added. No timeframe has been set, and a final decision has not been made, though since .NET may be the most efficient option for getting more roles onto Server Core, that development may help pave the way for PowerShell to come along behind.

Then again, that could also pave the way for other scripting languages including projects from Microsoft itself, such as IronPython. But Ralston surprised us by saying that PowerShell might render that possibility unnecessary.

"Because it's based on the .NET Framework, PowerShell could completely leverage any other existing type of language, or scripts that you've traditionally written in," he told us. "I think PowerShell will complement people who choose to install other scripting options. By no means are we attempting to restrict [such languages] on Server Core; and actually, it sounds kind of exciting, to get back to this world where everyone has a community-driven effort to create the tool to get the job done."

As evidence of this, Ralston pointed to the Scripting Center for PowerShell, where many script authors have submitted sample code. It's amazing what a community of sharing individuals can accomplish, Microsoft appears to have discovered.

"Even though you do install Server Core, and it just has the command line interface, we have scripts you can install that open up [TCP] port 3389 so you can administer it with Terminal Server," Ralston noted. But he also brought up an interesting new fact: Terminal Services can make it possible for Server Core to be managed remotely using a GUI on the remote system. "If you're sitting at a full install version," he said, "and let's say I bring up a DNS, I can connect to a Server Core running DNS, and I can administer it from another machine using the GUI on this one."

Yet what makes command line-driven administration so appealing in this late day and age is the fact that it eliminates most of the overhead and latency involved in the handling of everyday tasks, not just on the part of the processor but also the people whose own brains have to process these procedures visually as well as -- or rather than -- semantically.

And there's also a bit of nostalgia involved too, as Iain McDonald demonstrated on Wednesday at WinHEC with a PowerPoint demo geared to look like it was being typed up from a green-on-black terminal window. Taking us back to the era of those terminal-like pipelines between users and servers brings back some of the mystique and daring uncertainty that characterized the computing era when it was all so novel and unknown.