WebSearch Site

Is your server running slowly?  Check with SolarWinds ipMonitor

Get a free evaluation copy of ipMonitor

---

Ezine 184 - Review of PowerShell v2

Ezine 184 - Introduction to PowerShell v2

This week I would like to review PowerShell's version 2.  In April 2009 the latest release is was CTP3, later in 2009 the RTM (Release to Manufacturer) version was released.  While CTP stands for Community Technology Preview, it really means a Beta version - thus don't rely on this version of PowerShell 2 for a production server.

Topics for Introduction to PowerShell v2

• This Week's Secret
• This Week's Mission
• Pre-requisites
• Run get-Process on Another Machine

This Week's Secret

I am fed up with being a good boy and sticking with PowerShell v1.0.  I declare it's time to test PowerShell v2, but only on a spare, virtual, or test machine.  Creating production scripts using beta software is always a bad idea, beta features may not make it into the final version, and there numerous reasons why a script will fail unexpectedly when the full version is released.  Another problem is different versions of PowerShell on different machines, especially when you are trying to use the new 'Remoting' feature of version 2.

Most people get excited about all the innovative features of a new version such as PowerShell v2.  However, when I wear my trainer's hat I feel trepidation, because, despite what everyone says about v2 being more efficient, it's always inherently more difficult to teach newbies a more complex system.  For example, PowerShell v2 has a GUI, but in CTP 3 this is a very rough and ready set of windows.  To begin with you may find it less distracting if you stick with traditional command line!  The killer feature of version 2 is running native PowerShell commands on another computer, but this relies on WinRM, which in turn needs patience to setup and configure.

The situation is different for those who already know PowerShell v1, for them version 2 does indeed live up to the hype, and they won't need any help from me to get started.  Returning to newbies, despite version 2 having more features to understand, and more cmdlets to learn, on balance, I would still jump in the deep end and go with version 2.  Incidentally, the transition from PowerShell v1 to v2 reminds me of teaching people DOS; version 3.3 was a great vintage and while versions 4 and 5 were technically superior, they were never as easy for people learning their first command-line language.

This Week's Mission

This week's mission is simply to test the -computer parameter, which is the star feature of PowerShell v2, and works well enough in the CTP 3 version.  The whole concept behind this improvement is to open up the idea of automation via remote scripting.

Microsoft provides an msi file so installing the PowerShell v2 CTP3 is very easy.  However during setup, I encountered two traps, they were obvious make sure you don't make the same mistakes.  Firstly, start at the download page for CTP3 (not CTP2).  Secondly, pay attention to the correct .msi file for your operating system, I chose (x64) for my 64-bit hardware.  Then last week a reader kindly reminded me of a third trap, PowerShell is not SUPPORTED on the HOME versions of XP or Vista, it does however install.

Two Easy Pre-requisites

• A likely preliminary step is to remove (uninstall) PowerShell v 1.0, or in the case of Vista and Windows Server 2008, 'Turn off the Feature'.
• Get .Net Framework, I already had version 3.5 with SP1 = Version 3.5.1.  If you don't need GUI with its ISE (Integrated Scripting Environment), then you can get away with .Net Framework 2.0.

And One Difficult Pre-requisite WinRM

Remember that 'remoting' is a client server technology. Thus to get your scripts to run on other machines you must install WinRM in addition to PowerShell v2.  Furthermore, you must also install WinRM on each client computer where you expect a PowerShell v2 script to execute code sent by the server.  Incidentally, it does not help that remoting has so many synonyms; WinRM, Windows Remote and WS-Management are all names for this SOAP client-server technology.

While WinRM truly is wonderful for remoting, getting started with the correct version for your operating system is challenging.  The problem is multiplied if you are grappling with other variables such as a new version of PowerShell and firewall settings.  Thus my advice is don't try and run before you can walk, get PowerShell working on the local machine, only then think about remoting.

You should also consider firewalls.  On a local network it should be easy to take the rough and ready approach and disable the firewall on both the server and the client.  A more sophisticated tactic would be to research port numbers for WMI (135 and 445), also read-up on WS-Management and the http protocol.

As usual, experimenting on the latest versions of the operating system offers the greatest chance of getting a new technology to work.  And because Vista and Windows Server 2008 use the same version of WinRM (WinRM v2 CTP3), this client server pairing has the greatest chance of success.  XP and Windows Server 2003 should work, but it's more difficult to seek out the correct version of WinRM (WS-Management v1.1).

Run get-Process on Another Machine

While our mission is to employ PowerShell to list the processes (as seen in Task Manager) running on another machine, I want to explain my thought process so that you can adapt this script for tasks on your machine.  In fact, it will make my day if you use this simple approach to experiment with PowerShell on your network.

For the sake of long-suffering readers who are experienced with PowerShell, I shall start with the final script and then work backwards.  Naturally, change 'GuyClient' to the name of another computer on your network.

Note 1:  The key 'Remoting' command is -computer followed by the name of the victim - I mean the client machine.

Note 2: If this does not work try plain: get-Process (no parameter).  If that produces a list of process on the local machine, then go back and check the pre-requisites for remoting.

Question 1: How did I know about get-Process
Answer:  get-command
Next try get-command -noun process
Also try get-command -verb get

Question 2: How did I know about the -computer parameter?
Answer: get-help get-process -full

Guy gets sloppy.  Attention to detail will show that the full parameter is -computerName.  However PowerShell is a smart language and once that idle toad Guy types -computer PowerShell realizes that he could not possibly mean anything else so it processes the command string.  Where next?  Over to you, research other PowerShell commands that you could run against another machine, for example get-service.

Summary of PowerShell version 2

As ever, my goal is to explain the first tentative steps so that you have a working copy of PowerShell.  However, in the case of PowerShell v2 CTP3 remember this is a beta version only suitable for testing.  Once you have version 2 setup and working, then enjoy researching remoting with the -computerName parameter. 

If you are looking for handy network utilities, try some of the free downloads at Tools4Ever

See more Microsoft PowerShell tutorials

• Windows PowerShell Home  • Introduction  • Cmdlets  • Exchange 2007  • Profile.ps1  • $_.Pipeline

If you see an error of any kind, do let me know.  Please report any factual mistakes, grammatical errors or broken links, I will be happy to not only to correct the fault, but also to give you credit.

 *