Home » Microsoft Roadmaps » Powershell 30 Preview Release

PowerShell 3.0 in Preview Release

May 28, 2012
Report by: 

PowerShell 3.0, Microsoft's command-line interface (CLI) shell and scripting engine for Windows, will be released with Windows Server 2012 and Windows 8, and is currently available in a second Community Technology Preview (CTP). PowerShell is an important tool for managing Windows desktop and server applications, such as Exchange Server, Office 365, and even some third-party tools, such as VMware's Infrastructure Toolkit for Windows. Customers and partners, especially those who have not yet adopted PowerShell, should begin evaluating the updated version.

A Key Management Tool

PowerShell is a CLI shell and scripting environment that makes it easier and more efficient to manage Windows desktop and server applications by automating repetitive administrator tasks.

Although wizards and graphical tools such as the Microsoft Management Console (MMC) are useful when learning how to perform a task, they can be less efficient when performing complex or highly repetitive tasks, such as provisioning a large number of new users in Active Directory or Office 365, or making a policy change to a large number of computers. Consequently, many administrators have supplemented graphical management tools with scripting technologies for Windows, including the following:

Batch files, simple text files containing a series of Windows commands, which run tools such as xcopy, which copies files and directories, or netsh, which allows configuration of network devices. Batch files are executed in the Windows command-line shell (cmd.exe) to perform simple management tasks.

Windows Scripting Host (WSH), a general-purpose COM-based environment for hosting scripts written in a scripting language, such as VBScript or JavaScript. WSH can manage security, invoke the appropriate script engine, and expose COM objects to provide access to the Active Directory Service Interface (ADSI), ActiveX Data Objects (ADO), and Windows Management Instrumentation (WMI), or any other COM object. Though it is no longer being enhanced, WSH is still widely used for automating administration tasks.

Third-party scripting tools, such as KiXtart, a 32-bit script language developed by Ruud van Velson of Microsoft Netherlands, has over 600 user-defined commands; support for COM to interface with ADSI, ADO, and WMI; and a graphical forms tool. Because many administrators started using KiXtart to create log-on scripts for Windows NT, it remains quite popular for managing Windows servers.

All of these technologies can still be used with Windows, but batch commands and the WSH have not received new features as PowerShell has continued to mature and expand in importance.

Why PowerShell?

PowerShell is replacing traditional shells because of its ties to the .NET Framework. In traditional shells, commands are discrete, stand-alone executables that input and output streams of text. To compose scripts, administrators must often combine multiple executables in a manner that allows the parsing of the text output of one command (with utilities such as grep and awk or custom parsers) and passing (or "piping") the parsed output to other commands.

In contrast, PowerShell commands (called cmdlets, pronounced "commandlets") are .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 pass the output of one command to another without intermediate text-processing, obviating the need for separate text-processing utilities and resulting in simpler command-line instructions and scripts.

Each PowerShell cmdlet is a small piece of code that completes a specific task, usually with both required and optional parameters. For example, the Get-Process cmdlet returns a list of all processes running on a system and their statuses, and the Get-Command cmdlet returns a list of all cmdlets available on a system. Aliases to cmdlets are often available to make the use of PowerShell easier for experienced administrators. For example, the alias "ps" can be used to run the Get-Process cmdlet. Using the ps alias makes it easier for administrators with experience on other OSs, such as Unix, to transition to PowerShell because the Unix command that returns running processes is named ps.

Furthermore, because PowerShell exploits the .NET Framework, administrators and developers can create their own customized cmdlets with .NET languages, such as C# or Visual Basic, or create an Advanced Function (a specially formatted PowerShell script that behaves similarly to a cmdlet but does not need to be compiled). Administrators can use any customized PowerShell command or script either in PowerShell's included command shell or in a PowerShell command shell customized for a specific application. For example, Microsoft's System Center Virtual Machine Manager (VMM), which uses PowerShell to manage virtual machines (VMs), includes custom VMM commands such as Get-VMCheckpoint, which an administrator can use to find the most recent checkpoint for a VM, and Restore-VMCheckpoint, which restores a VM to a checkpoint. By sending the output of the Get-VMCheckpoint command to the Restore-VMCheckpoint command, an administrator can automate VM checkpoint restoration. PowerShell also supports customized data providers, which a developer can create to provide an interface between PowerShell commands and specialized data stores or file systems. PowerShell comes with data providers that work with the Windows file system, the Windows Registry, the Internet Information Services (IIS) metabase, the Windows certificate store, and OS environment variables, and the Exchange and SQL Server teams have created providers for accessing Exchange mailboxes and SQL Server databases. Third parties have also created providers; for example, there is a provider available for SQLite, a lightweight data storage engine.

Because PowerShell was originally designed under the Trustworthy Computing Initiative's Secure by Design, Default, and Deployment (SD3) guidelines, it supports a spectrum of secure script execution models. The default setting prevents a script from running when it is double-clicked in Windows Explorer, and customers can implement stricter settings, such as requiring scripts to be signed with a trusted digital certificate.

Usage Increasing

The ability to exploit the .NET Framework, create custom data store interfaces, and host PowerShell in a command shell within an application are making PowerShell the de facto automation engine for managing many Microsoft server products, such as Exchange Server and System Center VMM. Microsoft's Common Engineering Criteria as of 2009 require Microsoft's OSs and server applications to support PowerShell to lower the cost of installation, configuration, and management. This replaced an earlier recommendation to support either command-line scripting or WMI remote management, and the change demonstrates the central role PowerShell has begun to play for automation.

To minimize the disruption to administrators, many PowerShell-enabled applications continue to use an MMC-style interface to provide administrators with a graphical management tool, even though the code that performs the underlying management tasks is made up of custom-built PowerShell commands. The new Server Manager built into Windows Server 2012 performs local and remote server deployment and management of server roles through a graphical user interface (GUI)—but uses PowerShell underneath—and all tasks can be performed directly through PowerShell. (For a more complete list of Microsoft products that are PowerShell enabled, see the chart "PowerShell-Enabled Server Products".)

Products from other companies also support PowerShell, including Citrix Workflow Studio, IBM Websphere MQ, and VMware Infrastructure Toolkit for Windows.

PowerShell has matured into a technology that administrators need to become familiar with, and its mastery is a critical job skill. IT staff should be familiar with intrinsic PowerShell features and how products they manage take advantage of PowerShell. Customers unfamiliar with PowerShell should download and work with the CTP to see what new features have been added and evaluate how they can leverage PowerShell to provide efficient and consistent administration of physical and virtual servers.

What's New in PowerShell 3.0?

There are many new features in PowerShell 3.0, including approximately 2,300 cmdlets (almost 10 times the number previously included in PowerShell 2.0). Major changes include improving multi-machine remote management, the ability to run PowerShell scripts on a schedule or with alternate credentials, and the inclusion of workflow functionality for complex task sequences.

Scheduling, Delegation, and Workflows

Organizations need efficient ways to remotely manage Windows-based computers, and with greater use of VMs and the command-line-only Windows Server Core, which is the default installation mode in Windows Server 2012, the ability to configure and manage systems remotely has become critical.

PowerShell 2.0 added the abilities to connect to remote servers and to run scripts in the background asynchronously (referred to as jobs). PowerShell 3.0 adds scheduled jobs, which use the Windows Task Scheduler to specify an event or schedule that determines when jobs execute. PowerShell 3.0 features Delegated Administration, which allows credentials to be specified at the command line or for scheduled jobs, which should be useful for server deployment, management, and troubleshooting for times when the user executing the command may have reduced administration privileges.

PowerShell 3.0 supports the Windows Workflow Foundation (WF) to enable workflows that can take advantage of PowerShell. For example, a human resources system could automatically add a user to Active Directory and provision an Office 365 account when hiring a new employee, using PowerShell commands in a WF-based workflow. Workflows are not constantly running; rather, the Windows Workflow process waits for input, restarts the workflow and processes the input, and, when input is no longer queued, saves the state of the workflow and shuts down.

PowerShell Web Access and Sessions

Beginning with PowerShell 2.0, administrators could manage remote machines using encrypted communication between two instances of PowerShell: one on the administrator's computer and one on the remote computer. Although commands are issued on the administrator's computer, they execute on the remote computer; the output of the commands is sent back to the administrator's computer. PowerShell 3.0 has enhanced this functionality in two ways:

Robust sessions. In the same manner that Remote Desktop is an instance of a Win32 interactive log-on session, PowerShell 3.0 enables administrators to disconnect from an existing remote PowerShell session and reconnect from any other system on the network. These robust sessions are designed to stay alive through both network failures and system reboots.

PowerShell Web Access has been added to enable remote connectivity to servers from anywhere, even OSs and devices that may not feature PowerShell support natively. Administrators can connect through the PowerShell Web Access UI to servers that have been enabled for remote management, and third-party applications can connect through this interface, since the interface is also a Representational State Transfer (REST)-based Web service. (For an illustration, see "PowerShell 3.0 Web Access".)

Ease of Use

Another significant area of focus for PowerShell 3.0 is ease of use. The PowerShell 3.0 CTP includes the second version of the PowerShell Integrated Scripting Environment (ISE), which is a host application for PowerShell that administrators can use to run commands and write, test, and debug scripts. The ISE provides typical code-editing features, such as customization of the environment, syntax coloring, selective execution, and context-sensitive help. The PowerShell 3.0 ISE adds IntelliSense and an interactive Show Command window to help specify required or optional cmdlet parameters. (For an illustration, see "PowerShell 3.0 ISE".) The Show Command window is available from any PowerShell instance by running the Show-Command cmdlet. Microsoft has also simplified PowerShell syntax to make the language less intimidating for new users.

Availability and Resources

The PowerShell 3.0 CTP can be installed on x86 and x64 editions of Windows 7 and Windows Server 2008 R2. The.NET Framework 4 is required. PowerShell 3.0 supports the execution of PowerShell 2.0 scripts using the PowerShell 2.0 engine for backward compatibility. Microsoft has not yet fully specified how Windows RT, the edition of Windows 8 for the ARM architecture, will be managed. It is unclear what, if any, PowerShell support Windows RT will feature.

PowerShell Remoting and background jobs require the WS-Management protocol and the Windows Remote Management service that implements WS-Management in Windows, which are currently supported on Windows Vista SP1 and Windows Server 2008 and newer.

The PowerShell 3.0 CTP 2 can be downloaded at www.microsoft.com/download/details.aspx?id=27548.

The MSDN PowerShell blog is at blogs.msdn.com/powershell/.

The PowerShell 2.0 SDK, which provides information on developing host applications, is at msdn.microsoft.com/library/windows/desktop/ff458115(v=vs.85).aspx.

Windows PowerShell, Getting Started, is at technet.microsoft.com/library/bb978526.aspx.

Additional information on remoting PowerShell is at technet.microsoft.com/magazine/ff700227.aspx.