Richard Siddaway‘s recent TechNet presentation (around the datacentre in 80 scripts) was a first opportunity for me to have a look at what’s coming in the next version of Windows PowerShell.

I’ve written previously about PowerShell (as an introduction to the concept and from an IT administrator standpoint) but, just to summarise, in a logical diagram of the Windows Server System, PowerShell would sit between Windows Server and the rest of the Windows Server System as the integration and automation engine (and PowerShell support is part of Microsoft’s common engineering criteria for 2009 – it’s already widely used by Exchange Server, SQL Server and by recent System Center products – and there is growing third party support too).

Whilst PowerShell is really an automation engine, it’s commonly expressed as a command shell and scripting language which underlies the graphical user interface. PowerShell is based on the Microsoft.NET Framework but does not require a knowledge of .NET programming. As for whether it will eventually replace cmd.exe as the CLI in Windows – maybe one day but not for a while yet (maybe not at all – Unix has several shells to chose from for administration).

Key PowerShell features include:

• cmdlets – small piece of functionality which perform a single function (and use a verb-noun naming structure).
• Providers -functaionality to open a data store as if it were a file system (e.g. certificate store, registry, etc.).
• Extensiblity – there are around 130 cmdlets in the PowerShell base and functionality can be added as required (Exchange, SQL, etc.) in the same way that Microsoft Management Consoles are built up from various snap-ins. A Windows Installer file registers a DLL and PowerShell accesses it as a snap-in (using the add-pssnapin command in the profile) and from that point on the additional functionality is available in PowerShell.
• Pipeline – the pipeline is used to pass .NET objects between cmdlets (non-programmers – think of objects as “blobs of stuff” with methods and properties to do things with them!)

Windows PowerShell was originally released in November 2006 and was finally included within Windows Server 2008 this year (it wasn’t ready in time for Vista). At the time of writing, PowerShell 2.0 is still a community technical preview (there have been two releases – CTP and CTP2) so there may be changes before release, but some of the improvements we can expect to see (and this list is not exhaustive), based on CTP2, are:

• Remoting. New remoting capabilities require PowerShell to be installed on both the client and the server and use Windows Remote Management (WinRM), which is based on WS-Management (check that winrm is running with get-service winrm). At present, remoting requires administrator rights for both configuration and use.
• Jobs. PowerShell jobs run asynchronously and can be started using the psjob cmdlets (get-command *.psjob to list available cmdlets), some cmdlets support the -asjob parameter (get-help * -parameter asjob) where that option is provided.
• Runspaces. Jobs can also be used with PowerShell’s remoting capabilities in RunSpaces, which create a persistent connection between the local and remote machines in order to speed up the response. Remote commands are invoked using invoke-command. For example, to create a runspace and execute a script as a job, I might use the following code:
  $r = new-runspace -computername mycomputer
invoke-command -runspace $r -scriptblock {remotescript} -asjob
  after which I could use get-psjob and other cmdlets to manipulate the job (e.g. check on progress, receive data, etc.).
• Script cmdlets. Cmdlets can now be written in PowerShell, rather than being compiled from a .NET language.
• Transactions. In the same manner as SQL Server, Exchange Server and Active Directory apply a database transaction-logging mechanism, PowerShell now has the potential for transaction-based processing (i.e. carry out an action, if it completes then OK, if not then roll back). This functionality is implemented at the provider level so is not universally available (at the time of writing, only the registry supports this).
• Graphical PowerShell. A new tool, with script editor, interactive prompt and results pane.
• WMI. Improved support for Windows management instrumentation (WMI) through type accelerators ([WMI], [WMIClass] and [WMISearcher]), the ability to pass credentials with get-wmiobject and new wmi-focused cmdlets (invoke-wmimethod, set-wmiinstance, remove-wmiobject). In a simple example to launch a process using WMI I might use the following code:
  $c = [WMIClass]”Win32_Process”
  $c.create(“win32program.exe”)
  and to clear up afterwards I might use:
  get-wmiobject -class win32_process -Filter "Name='win32program.exe'" | remove-wmiobject

It should be stressed that PowerShell 2.0 is still under development (it’s a community technology preview – not even a beta) and that things may change. It may also break things – there are also some naming clashes (e.g. with the PowerShell Community Extensions), new keywords (e.g. data) and it’s more complicated than the original version. Even so, PowerShell 1.0 already has tremendous potential and I’d be using it more often if I was doing more administration work. As more products use PowerShell for automation then knowing how to use it will become an ever-more important skill for Windows administrators – version 2 is definitely worth a look and if you want to know more about PowerShell then I recommend checking out the PowerShell UK user group and the PowerShell team blog.