Ezine 184 – Introduction to PowerShell v2
This week I would like to review PowerShell’s version 2. In April 2009 the CTP3 version was released. Later in 2009 the RTM (Release to Manufacturer) version became available. 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
- Run get-Process on Another Machine
- Windows 8 PowerShell
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 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).
Guy Recommends: The Free IP Address Tracker (IPAT)
Calculating IP Address ranges is a black art, which many network managers solve by creating custom Excel spreadsheets. IPAT cracks this problem of allocating IP addresses in networks in two ways:
For Mr Organized there is a nifty subnet calculator, you enter the network address and the subnet mask, then IPAT works out the usable addresses and their ranges.
For Mr Lazy IPAT discovers and then displays the IP addresses of existing computers. Download the Free IP Address Tracker
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.
# PowerShell script to list process on a machine called GuyClient
# Author: Guy Thomas
# Version 2.0 April 2009 tested on PowerShell v2 CTP3
get-Process -computer GuyClient
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
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.
Tired of writing scripts? The User Management Resource Administrator solution by Tools4ever offers an alternative to time-consuming manual processes.
It features 100% auto provisioning, Helpdesk Delegation, Connectors to more than 130 systems/applications, Workflow Management, Self Service and many other benefits. Click on the link for more information onUMRA.
If you like this page then please share it with your friends
See more Microsoft PowerShell tutorials
If you see an error of any kind, do let me know. Please report any factual mistakes, grammatical errors or broken links.