The first release candidate of PowerShell (previously code-named Monad), the company's next-generation shell-scripting engine, became available in Apr. 2006. PowerShell enables administrators to run a variety of system and application management tasks at the command line and compose scripts for routine operations that are difficult to write using existing tools. However, until developers create PowerShell extensions specific to their applications, the tool's usefulness for managing those applications will be limited.

PowerShell Streamlines Administration

PowerShell's goal is to allow comprehensive Windows system and application management at the command line or via scripts, thus complementing the graphical user interface (GUI) management tools of those systems and applications. Although GUI management tools have many advantages—for example, they are simple and intuitive and do not require mastery of arcane command and scripting languages, which are the mainstay of platforms such as UNIX and Linux—they often come under fire from administrators in large-scale computing environments, where it is often more efficient to automate routine management or maintenance tasks by running well-tested scripts.

Historically, creating such scripts in a Windows environment has been difficult. The familiar Windows command shell (cmd.exe) has limited functionality and its associated scripting (or "batch") language has limited basic programming features, such as conditional logic, loops, and debugging, making it difficult to write and test scripts of any complexity. Alternatives such as the Windows Script Host (WSH), a script execution engine introduced in 1998 and designed to work with VBScript and JScript, also have shortcomings—WSH does not offer command-line capabilities and VBScript and JScript can be complex and difficult to learn and use.

PowerShell is a more powerful command-line environment than the Windows command shell, offering a broader set of built-in commands (called cmdlets and pronounced "command-lets") for common Windows administrative tasks, such as examining processes and working with the Registry. It is a more sophisticated scripting language than the Windows batch language; at the same time, PowerShell is a higher-level language than VBScript and JScript and should be easier for nondeveloper administrators to work with. PowerShell includes features familiar to users of traditional Unix shells, such as ksh, bash, and csh. For example, users can assign friendly names (or aliases) to commands and can also define functions, typically short scripts that can be called from other commands or scripts to perform some common operation, such as a mathematical calculation.

However, PowerShell differs from traditional shells in one significant way. In traditional shells, commands are discrete, stand-alone executables that input and output streams of text. To compose command-line operations, administrators must often parse the text output of one command (with utilities such as grep and awk) and pass (or "pipe") the parsed output to other commands sequentially. In contrast, PowerShell cmdlets are pieces of .NET code, running under the control of the Common Language Runtime, that communicate with one another by exchanging structured data objects rather than text. This allows PowerShell administrators to pipe the output of one cmdlet to another cmdlet without intermediate text-processing, obviating the need for separate text-processing utilities and resulting in simpler command-line instructions and scripts.

Perhaps most significantly, PowerShell can be extended and customized in several ways. For example, ISVs and corporate developers can build custom cmdlets that encapsulate application-specific management tasks; these cmdlets can be compiled into snapins, which can be attached to the shell, allowing the new cmdlets to be invoked at the command line or used in scripts. Alternatively, developers can package new cmdlets into custom shells, which allows them to create shells for specific operational roles, such as administrators of a certain application.

In fact, Microsoft has indicated that the administrative features of its future applications will be based on PowerShell. Exchange and System Center products are up first—the administrative capabilities of Exchange Server 2007 (previously code-named Exchange 12) and System Center Operations Manager 2007 (previously code-named MOM v3) will be based on PowerShell, giving administrators complete management control of those products from the command line. However, until developers build cmdlets and snapins (or custom shells) for other applications, PowerShell's usefulness for managing applications will be limited—for example, administrators could compose PowerShell scripts that call functions in an application's Windows Management Instrumentation (WMI) interface (if one exists), much as they would call them today in a VBScript script running in WSH.

Availability and Resources

In Apr. 2006, Microsoft shipped a release candidate of PowerShell. The release candidate is publicly available, but users must register prior to downloading it. It is available in 32-bit and 64-bit versions, requires the .NET Framework 2.0, and runs on Windows Server 2003, Windows XP, and Windows Vista. The final release of PowerShell is expected in the second half of 2006 and will be available as a free download. Exchange 2007 is scheduled to ship early in 2007; Operations Manager 2007 will also ship in 2007.

More information about PowerShell is at www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx.

Customers and partners can download the PowerShell release candidate at www.microsoft.com/downloads/details.aspx?FamilyId=2B0BBFCD-0797-4083-A817-5E6A054A85C9&displaylang=en.

Microsoft has provided a number of sample PowerShell scripts at www.microsoft.com/technet/scriptcenter/scripts/msh/default.mspx.