21 September 2010

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

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.

1143-JM1.jpg

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.

1143-JM2.jpg

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:

1143-JM3.jpg

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:

1143-JM4.jpg

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.

1143-JM5.jpg

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

1143-JM6.jpg

Fig 6. – Syntax highlighting within scripts and the console

1143-JM7.jpg

Fig 7. – Multiple tabs for script editing

1143-JM8.jpg

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

1143-JM9.jpg

Fig 9. – Multiple console tabs

1143-JM10.jpg

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.

1143-JM11.jpg

Fig 11. – $psISE

1143-JM12.jpg

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:

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

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

1143-JM13.jpg

Fig 13. – Details of a running job

Once finished, the State will change to Completed.

1143-JM14.jpg

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.

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:

1143-JM15.jpg

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.

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:

1143-JM16.jpg

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:

1143-JM17.jpg

Fig 17. – Splitting strings

Conversely, to join the three strings together:

1143-JM18.jpg

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*.

1143-JM19.jpg

Fig 19. – Splat hash table

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

1143-JM20.jpg

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:

1143-JM21.jpg

Fig 21. – Default paths for modules

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

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).

1143-JM22.jpg

Fig 22. – The Maths module

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

1143-JM23.jpg

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.

1143-JM24.jpg

Fig 24. – Import the Maths module

Now the Squared function is available for use:

1143-JM25.jpg

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

http://technet.microsoft.com/en-us/library/ee308287%28WS.10%29.aspx#BKMK_Appendix

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.

Summary

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.

Keep up to date with Simple-Talk

For more articles like this delivered fortnightly, sign up to the Simple-Talk newsletter

This post has been viewed 25089 times – thanks for reading.

Tags: , , , ,

  • Rate
    [Total: 24    Average: 4.3/5]
  • Share

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

View all articles by Jonathan Medd

  • Anonymous

    Shipped some tit, eh?
    “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”

  • Andrew Clarke

    Re Shipped some tit, eh?
    Oops. Fixed.

  • Anonymous

    thanks
    Great article outlining a must for every IT Professional.

  • Anonymous

    And this is good?
    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 🙁

  • Phil Factor

    Re: And this is good?
    Maybe you’d have enjoyed the rather more reserved viewpoint about Powershell, of Chris Massey in http://www.simple-talk.com/community/blogs/camassey/archive/2010/09/23/94652.aspx

  • Anonymous

    Agreed – what’s the point?
    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.