Click here to monitor SSC
  • Av rating:
  • Total votes: 24
  • Total comments: 6
Jonathan Medd

PowerShell Version 2: What is new and why is it important?

21 September 2010

It was a year ago that Microsoft shipped PowerShell 2. Jonathan Medd  lists the top ten reasons why PowerShell 2 should be an important tool  for your work.

On 22nd October 2009 Microsoft released Windows Server 2008 R2 and Windows 7; PowerShell, version 2.0 was included as a part of that release. PowerShell version 1.0 had shipped a few years earlier during November 2006 at ITForum in Barcelona. So what has changed during those three years, how has the product matured and why would the regular systems administrator or database administrator care?

In this article I will highlight the ten most important reasons why this should be important to you, whether you had a previous interest in Windows PowerShell or not.

1) It’s in the Operating System!

The previous version of Windows PowerShell, 1.0, was a separate download which could be installed on Windows operating systems from Windows XP for clients and Windows Server 2003 for servers and later. This meant potentially a lot of work to make it available throughout an organisation, not just technically to deploy it, but also the likelihood that a systems administrator may need to justify to various parts of the organisation why they need to deploy; in other words a potential barrier to adoption. Sometime after the release of the individual downloads for the various versions of the Windows operating systems, Windows PowerShell 1.0 was made available via Windows Update. This gave the possibility for customers using either Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM) an easier method for deployment; however they still potentially had non-technical hurdles to clear.

In addition, PowerShell 1.0 required the .NET Framework version 2.0 to be installed first. This was not included as part of Windows Server 2003 or Windows XP, so again potentially an extra install and more questions to answer along the lines of "Why do we need this again?".

With the initial release of Windows Server 2008, PowerShell 1.0 was made available to install as a Feature, so that was a step in the right direction of being easier to install, however it was not installed by default.

Fig 1. – Install PowerShell 1.0 as a Feature in Windows Server 2008

With the release of Windows Server 2008 R2 and Windows 7, PowerShell 2.0 is included as part of the operating system by default. There are no downloads required, no installation wizards to complete and no managers to convince as to why it should be installed – it’s already there!

Note: For versions of Windows prior to Server 2008 R2 and Windows 7, a separate download of PowerShell 2.0 was offered within weeks of it being shipped as part of  Windows Server 2008 R2. It is now available as part of Windows Update.

In fact, PowerShell is becoming such a fundamental part of Windows administration that in Windows Server 2008 R2 PowerShell has even made it onto the Start Bar.

Fig 2. – PowerShell 2.0 icon on the Windows Server 2008 R2 Start Bar

Another important step forward with the release of Windows Server 2008 R2 is that it is now possible to install PowerShell 2.0 on top of the Server Core installation option of Windows Server. In case you are unaware, since Windows Server 2008 it has been possible during installation of the operating system to choose Server Core as an option; this is a cut down version of Windows Server with no GUI. The primary aim with Server Core is to provide a version of Windows Server with a minimum installation for particular server roles, consequently reducing the attack surface and levels of patching which are required.

Only specific roles such as Active Directory or DHCP were available in Server Core for the initial release of Windows Server 2008. One item missing was the .NET Framework which, since it is a requirement for PowerShell, meant that it was not supported to run PowerShell on Server Core systems. Now in Windows Server 2008 R2 selected portions of the .NET Framework have been made available for the Server Core option; consequently it is possible to install PowerShell 2.0. It is important to mention that it is not installed by default in Server Core, however this is a natural consequence of a modular based operating system – only the required components are installed.

2) 100+ New Cmdlets

PowerShell 1.0 shipped with over 100 cmdlets which were available to any user out of the box. With the release of PowerShell version 2.0 another 100+ cmdlets were introduced as standard. These range from new groupings of cmdlets to provide specific new features and functionality to single cmdlets to make the systems administrator’s life slightly easier in many different places.

One of the goals of the PowerShell product team when improving PowerShell between versions 1.0 and 2.0 was to make lots of small improvements in addition to the more publicised new features. In this blog post Jeffrey Snover, Distinguished Engineer and leader of the PowerShell team, describes how they aimed to make 1000 things 1% better.

For example, PowerShell version 2.0 contains a new cmdlet Get-Random, which amongst other things can generate random numbers. Let’s use Get-Random to generate a random number between 1 and 10:

Get-Random -Minimum 1 -Maximum 10

Fig 3. – Generating a random number with Get-Random

Pretty simple you will agree. How could you have done this in PowerShell version 1.0 without the Get-Random cmdlet? Well you could have used some .NET code, for instance:

$randomnumber = New-Object System.Random


Fig 4. – Generating a random number with New-Object System.Random

Will it save you hours of time? No. Will it make your life for that one particular task just that little bit easier? It might well do. Will hundreds of these smaller improvements make you feel happier about your experience with PowerShell? Quite likely so.

If you want to find out more about what new cmdlets are available and examples of how they might be used, you can check out my blog series, PowerShell 2.0: One Cmdlet at a Time, where I have gone through each new cmdlet.

3) Remoting

One of the most frequently requested improvements to PowerShell 1.0 was the ability to run all of the fantastic newly-available cmdlets against remote systems. Whilst there was one major cmdlet, Get-WMIObject, which had built-in remoting capabilities and there were some workaround possibilities, such as third-party products, generally the remoting story was not a great one. In PowerShell 2.0 there are thirty-five standard cmdlets which feature built-in remoting capabilities and, most importantly, you can run any PowerShell cmdlet on a remote Windows system after first establishing a remote connection to that machine utilising Windows Remote Management (WinRM).

In a previous article for Simple-Talk I covered in detail the various parts of remoting work and what needs to be done to make it available. Consequently I won’t go into detail here, however it is important to know that it is a major step forward from the previous release and opens up so many more possibilities for remote management of Windows systems.

4) Integrated Scripting Environment (ISE)

With PowerShell version 1.0, the systems administrator worked either from the familiar blue console or they were writing scripts in a third-party editor such as PowerGUI, PowerShell Plus or PrimalScript. With the release of PowerShell version 2.0 a new tool, the Integrated Scripting Environment (ISE), is included by default. With the ISE, it is possible to work both in a console style, with much nicer features than the standard console, and edit scripts in one tool.

The tool is split into three sections, as seen in the below figure. An Editor Pane for writing scripts, a Command Pane area for entering interactive commands and the Output Pane for displaying output either from executed scripts or interactive commands.

Fig 5. – PowerShell ISE components

Some of the main benefits of the PowerShell ISE are:

  • Syntax highlighting within scripts and the console
  • Multiple tabs for script editing
  • Easier copy and paste than the standard console
  • Multiple console tabs
  • F1 style help for cmdlets

Fig 6. – Syntax highlighting within scripts and the console

Fig 7. – Multiple tabs for script editing

Fig 8. – Easier Copy and Paste than the standard console

Fig 9. – Multiple console tabs

Fig 10. – F1 style help for cmdlets

These features are available out of the box, so whilst a systems administrator might have a third-party editor for writing scripts on their own workstation, that tool would not likely be available throughout the organisation. If there was a need say to make some quick minor changes to a script residing on a server then it could be opened within the PowerShell ISE and features such as syntax highlighting would be available. Previously, Notepad might have been used, which despite its many uses over the years, can’t compete with a tool like this for features.

It is also possible to customise the PowerShell ISE and the way to do it is using PowerShell code! Doing so is beyond the scope of this brief introduction, but checking out the variable $psISE and the options property would be a good starting point.

Fig 11. – $psISE

Fig 12. – $psISE.Options

5) Jobs

PowerShell version 2.0 introduces the concept of 'jobs'. In the previous version when a command was submitted at the console, the prompt was not returned to the user until that command had completed. Whilst this may not be a problem for commands which complete quickly, it could be an issue for those that are say retrieving large amounts of data or making changes to multiple remote machines. By utilising 'jobs', it is possible to submit a command, or sets of commands, as a job. Once submitted control of the console is returned to the user and the results of the submitted job can be retrieved later. Let’s look at an example:

Imagine that we wanted to return all of the directories in the C:\Program Files folder, this could take some time and we might want to get on with something else in the meantime. The below code would get the required results:

Get-ChildItem "C:\Program Files" -Recurse | Where-Object {$_.PsIsContainer -eq $true}

Instead, let’s submit that as a job and collect the results later:

Start-Job -ScriptBlock {Get-ChildItem "C:\Program Files" -Recurse | Where-Object {$_.PsIsContainer -eq $true}}

We can check on the status of jobs we have submitted with the Get-Job cmdlet. Notice the State is Running.

Fig 13. – Details of a running job

Once finished, the State will change to Completed.

Fig 14. – A completed job

Now that the job has finished, it is possible to go and collect the results with the Receive-Job cmdlet. The default behaviour of Receive-Job is to remove results when retrieving them, so we will use the –Keep parameter to leave them available for subsequent retrieval if necessary.

$directories = Receive-Job -Id 1 -Keep

Now if we look at the Count property of the results we have returned we can see that there are 201 directories in C:\Program Files on this machine:


Fig 15. – Count property of the results from the submitted job.

This was a very simple example; however it is not difficult to imagine how it would be possible to extend this to more complex tasks. It is also worth noting that some cmdlets in PowerShell version 2 have a –Job parameter, so it is possible to submit a job directly from the cmdlet itself. For example, to submit a ping test to both Server1 and Server2 as a job, execute the below.

Test-Connection -ComputerName Server1,Server2 -AsJob

To help find which cmdlets which can submit a job directly, use the below command to retrieve a list of cmdlets with the –Job parameter:

Get-Command | Where-Object {$_.definition -match 'asjob'}

Fig 16. – Cmdlets with a –Job parameter

6) New Operators

The marketing people may not think it is a big feature, but it makes everyday life working at the command line, or writing scripts, that little bit easier. PowerShell 2.0 introduces three new operators: Split, Join and Splat (what a great name!)

For Split and Join think the Split and Join methods of System Strings, but now as operators. For example to split the below strings using a comma to distinguish them, use the below:

'rod,jane,freddy' -split ","

Fig 17. – Splitting strings

Conversely, to join the three strings together:

'rod','jane','freddy' -join ","

Fig 18. – Joining strings

Splatting allows the administrator to specify parameters and values in a hash-table and then supply the hash-table to be used in a cmdlet. We use the @ sign to do this. For example, firstly create a hash-table with a parameter of Name and values of a* and s*.

$services = @{Name = "a*","s*"}

Fig 19. – Splat hash table

Now use the Get-Service cmdlet to retrieve all services beginning with an ‘a’ or an ‘s’.

Get-Service @services

Fig 20. – Using splatting to retrieve services beginning with an ‘a’ or an ‘s’.

Obviously, that was a very simple example, but you can imagine the possibilities for invoking cmdlets with multiple values supplied from a hash table.

7) Modules

In PowerShell version 1.0, it was quite a task  to supply additional cmdlets to the user. They had to be packaged up into what is known as a 'snapin' and installed on the user’s system, typically from an MSI install. In version 2.0 Modules are essentially the evolution of snapins and it is now possible for the System Administrator or DBA to provide this kind of functionality for other users. No longer is there a need to create dlls: Instead,  a module can be created and shared simply as a script with functions in it.

The environment variable $PSModulePath lists the location where PowerShell will look for modules, by default it is the two locations below:

Fig 21. – Default paths for modules

For example let’s turn the following function into a module.

Function Squared


param ($a)


$SquareResult = $a * $a

Write-Host “The Square of $a is $SquareResult”


To create a Maths module, you can simply create a folder Maths in a default module path and copy the function above into a file Maths.psm1 . That’s right, all that needs to be done to create a module is to save functons, which typically would have been in a standard PowerShell script *.ps1 file, into a *.psm1 file! (It is possible to make things more complicated, but that’s for another article).

Fig 22. – The Maths module

The cmdlet Get-Module with the –ListAvailable parameter confirms that the Maths module is potentially available to use.

Fig 23. – Available modules

To use the module we execute the Import-Module cmdlet with the name of the module Maths and the –PassThru parameter just to expose the output of this command to the screen.

Fig 24. – Import the Maths module

Now the Squared function is available for use:

We could now add many other mathematical functions to the Maths module and easily distribute all those functions to other users.

8) Bundled Modules in Windows Server 2008 R2

As mentioned in section 6, the introduction of modules makes it easier for the Systems Administrator or DBA to create and distribute re-usable code for themself or others. The use of bundled modules makes it even easier. This is  the mechanism whereby Microsoft is distributing additional cmdlets for the manageability of their product base. For instance, in Windows Server 2008 R2 there are many components which newly feature built in PowerShell support and the method to access them is typically by using Import-Module. A sample of these Windows Server Roles with PowerShell support is listed below, for the full list follow the subsequent link. I think if you are a Windows focused systems administrator it’s pretty likely that you are going to touch one or more of these areas.

  • Active Directory
  • Group Policy
  • IIS
  • Remote Desktop Services
  • Failover Clustering
  • Network Load Balancing

Previous versions of Windows Server typically only had PowerShell support for these roles via third-party products. Now it’s available from the OS and the sooner you start getting to grips with it the better – you want to be better at your job don’t you?

9) Third-Party Vendors

When PowerShell 1.0 first shipped a number of third-party software vendors quickly jumped on the bandwagon and released various sets of PowerShell cmdlets and toolkits. Some, like Quest with the Active Directory cmdlets, to plug gaps in Microsoft’s coverage of their own products; others like PowerGadgets from SoftwareFX, to extend the built-in functionality of PowerShell.

However, after the initial buzz things went a little quieter for a while. That is until PowerShell 2.0 was released and now they seem to be coming from everywhere! Very few systems administrators work in an entirely Microsoft software based organisations and typically most need to be multi-skilled across many vendors’ software. Wouldn’t it be great if the systems administrator only needed to learn one scripting language to manage the different environments they were responsible for? How about combining elements from different technologies in the same script? Well if they manage any of the below technologies, then it is possible.

  • VMware vSphere Virtualisation. One of the early supporters of PowerShell via what was known as the VI toolkit, and is now known as PowerCLI. PowerCLI has become incredibly popular with VMware administrators and new versions now typically ship in line with vSphere releases. In a previous article for Simple-Talk I explained how to get started with PowerCLI.
  • Citrix XenApp 6. Another product which typically has a large cross-over with Windows administrators and has recently deprecated the long time MFCOM interface used by scripters and developers in favour of a PowerShell SDK. There are also PowerShell cmdlets for Citrix XenServer
  • Not just Windows systems. Work with Red Hat Enterprise Virtualization Manager? Then there are PowerShell cmdlets.
  • Maybe the admins work with storage hardware, not just software? Well NetApp have released a PowerShell toolkit for managing their storage. The interesting thing about this toolkit from a development point of view is that it took one engineer only three months to write 350 cmdlets!
  • Or what about managing Intel vPro Processors with their recently released PowerShell module?

If your software / hardware vendor of choice is not shipping a PowerShell toolkit, and you need one, then tell them you want it!

10)Exchange and SharePoint 2010

OK, not a point specifically about PowerShell 2.0 itself, but did I tell you Exchange 2010 ships with 638 cmdlets and SharePoint 2010 with 492?! If you’ve read this far then you probably don’t need any more convincing.


PowerShell 2.0 brings a lot to the table; with new cmdlets, enhancements to existing cmdlets and new features such as remoting, jobs and the ISE. However, it’s possibly the impact of becoming part of the OS, the numerous modules included as part of Windows 2008 R2, the hundreds of cmdlets shipping with products like Exchange and SharePoint and the rapidly growing PowerShell toolkits from third-party vendors which is making it a must for every systems administrator’s toolkit.

Jonathan Medd

Author profile:

Jonathan Medd has been working with Windows Infrastructure products since 1997 and, more recently, virtualisation technologies from VMware. In 2007, he discovered Windows PowerShell and now spends a lot of time encouraging the IT pros he meets to use PowerShell by talking with them, giving presentations to User Groups, and via posts on his blog. He also co-hosts the Get-Scripting PowerShell podcast, which contains info on how to learn PowerShell and what's going on in the PowerShell world. In April 2010, he was awarded status as a Microsoft Most Valuable Professional (MVP) for PowerShell, and you can follow him on Twitter at @jonathanmedd

Search for other articles by Jonathan Medd

Rate this article:   Avg rating: from a total of 24 votes.





Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.

Subject: Shipped some tit, eh?
Posted by: Anonymous (not signed in)
Posted on: Friday, October 1, 2010 at 7:08 AM
Message: "Note: For versions of Windows prior to Server 2008 R2 and Windows 7, a separate download of PowerShell 2.0 was offered within weeks of *** tit *** being shipped as part of Windows Server 2008 R2. It is now available as part of Windows Update"

Subject: Re Shipped some tit, eh?
Posted by: Andrew Clarke (view profile)
Posted on: Friday, October 1, 2010 at 8:16 AM
Message: Oops. Fixed.

Subject: thanks
Posted by: Anonymous (not signed in)
Posted on: Friday, October 1, 2010 at 9:17 AM
Message: Great article outlining a must for every IT Professional.

Subject: And this is good?
Posted by: Anonymous (not signed in)
Posted on: Friday, October 1, 2010 at 6:27 PM
Message: I'm sorry that I still do not understand what PowerShell is all about. I had hoped that based on the opening comments "whether you had a previous interest in Windows PowerShell or not" that perhaps I could understand why PowerShell should be important to me. I would expect the #1 point to be an exclamation! of what PowerShell can do for me, instead I find "It’s in the Operating System!" which is yet another problem I now have to deal with. I.E. "sort-of" got unbundled, and yet we still get more and more bundled :(

Subject: Re: And this is good?
Posted by: Phil Factor (view profile)
Posted on: Saturday, October 2, 2010 at 3:22 AM
Message: Maybe you'd have enjoyed the rather more reserved viewpoint about Powershell, of Chris Massey in

Subject: Agreed - what's the point?
Posted by: Anonymous (not signed in)
Posted on: Sunday, October 3, 2010 at 12:07 PM
Message: PowerShell seems like yet another hammer trolling around the technology arena searching in vain for some kind of nail -- any kind of nail -- on which to pound. But alas, the ground is covered with screws and honestly, we don't need to build a new house.

The PowerShell converts keep bantering on about how great it is, but I've yet to see anything new that it brings to the game. Every example I've yet to see is something that was easy to do with batch files, VB Script, JScript, or some combination of the three, perhaps along with Windows Scheduler or SQL Agent. Perhaps one or two fewer lines of code are needed with PowerShell, but who cares about that if I have to spend three months learning the thing?

New technology for the sake of being cool? Not cool. If this is really such a great tool, prove it with some solid examples. Show me what it can do to make my life easy and help me spend less time in the office and more on the beach sipping an icy umbrella drink.


Top Rated

PowerShell Desired State Configuration: Pull Mode
 Automated configuration management is simpler with Desired State Configuration (DSC) and Push mode, but... Read more...

The Poster of the Plethora of PowerShell Pitfalls
 One of the downsides of learning a new computer language is that transfer of training doesn't always... Read more...

Getting Data Into and Out of PowerShell Objects
 You can execute PowerShell code that creates the data of an object, but there is no cmdlet to generate... Read more...

SMTP Routing Changed in an Exchange Database Availability Group
 In Exchange Server 2010 it is possible to make the system more resilient by creating a Database... Read more...

Emulating the Exchange 2003 RUS for Out-of-Band Mailbox Provisioning in Exchange 2007
 Exchange's Recipient Update Service was important in Exchange 2000 or 2003 in order to complete the... Read more...

Most Viewed

Upgrade Exchange 2003 to Exchange 2010
  In this article, the first of two in which Jaap describes how to move from Exchange Server 2003... Read more...

Upgrade Exchange 2003 to Exchange 2010 - Part II
 In Jaap's second article on upgrading straight from Exchange Server 2003 to 2010, he explains how to... Read more...

Goodbye Exchange ExMerge, Hello Export-Mailbox
 ExMerge was a great way of exporting a mailbox to an Exchange PST file, or for removing all occurences... Read more...

Exchange E-mail Addresses and the Outlook Address Cache
 Because Exchange auto-complete cache uses X.500 addresses for e-mail sent to addresses within the... Read more...

PowerShell One-Liners: Collections, Hashtables, Arrays and Strings
 The way to learn PowerShell is to browse and nibble, rather than to sit down to a formal five-course... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.