We interrupt this regularly scheduled column to bring you news of the latest version of Windows PowerShell, available for preview. Those who have worked with PowerShell in the past should definitely check out the next version to see what it has to offer.
Today's column will focus on the features and capabilities that I think will be of most interest to you: remote access, script internationalization and an easier way to roll your own cmdlets.
This is one of my favorites: the ability to execute PowerShell cmdlets on remote computers. Scripting isn't nearly as useful when it can only execute on the local computer. With remoting, you can run cmdlets on a remote computer or (even better) on a group of them. For example, you could use get-item on a collection of computers to check the file version and determine whether a service pack has been installed. Remoting is a fundamental requirement to make PowerShell widely adopted.
If you want to write a cmdlet today, how do you do it? First, you'd better be ready to do some programming in C# or VB.NET. You can write PowerShell scripts, of course -- we've talked about how to do this so you can save your work and use variables with your scripts. But, what if you're not a developer? How do you write a custom cmdlet if, instead, you're an administrative scripter with a good idea?
PowerShell 2.0 lets you write ScriptCmdlets based on existing cmdlets, instead of forcing you to start with C#. One of the advantages of this is that it makes it possible to conceal some of the messy bits of PowerShell. For example, WMI is slightly easier to use with WMI than with VBScript -- we've looked before at some examples of how you can call on WMI from within PowerShell, and we will do so again. Using ScriptCmdlets, you can wrap the somewhat messy WMI commands into a traditional cmdlet look and feel.
This may not be something you use every day, unless you do a lot of international consulting, but script internalization is interesting nonetheless. Besides, some people do a lot of international consulting. If you're writing scripts that need to work in more than one language (say, English and German), it's not ideal to have to write two versions of each one. Using PowerShell 2.0, you can write one script for all cases by separating the strings from the rest of the code -- sort of like using variables to pick up the local user's name and computer name instead of hard coding them into a script. Then, you can use the import-localizeddata cmdlet to check the operating system's language settings and replace the original strings with the localized ones appropriate to the language supported by the local OS.
Do this before you begin
The advantage to writing a short article is that I can be reasonably assured that people will finish reading before they do anything drastic. This is one of those times that I hope I'm right, because checking out the PowerShell CTP isn't as simple as downloading the next version of Windows Media Player.
First, you'll need to uninstall PowerShell version 1. Additionally, for remoting to work, all computers must be running PowerShell 2.0. Also, remoting doesn't work with Vista RTM, but needs the beta of Service Pack 1 (you can learn more about this from a Microsoft TechNet article on Windows Vista SP1 planning). Coupled with the requirement that you install the beta of Vista SP1 before remoting will work, this makes previewing the CTP sound like a heaven-sent use for a virtual machine -- or at the very least, a test computer.
Second, the scripts you write in PowerShell 2.0 may not work in version 1. They will when using only cmdlets supported by version 1, but naturally if a cmdlet requires functionality found only on 2.0, it won't work on version 1. Before writing anything you want to work in a mixed environment, be sure to review the list of new cmdlets found on this Windows PowerShell blog entry for the CTP -- and make sure you're not using anything new.
Although it's not for the casual user, PowerShell 2.0 definitely has some features that make it worth checking out. At least keep them on your radar for later experimentation. Although some features will be more immediately useful to developers than administrative scripters, the features we've talked about -- remoting, scriptcmdlets and internationalization -- will make PowerShell an even more useful command-line management tool than it is today.
If anything else on those sites intrigues you and you're not sure what value it offers, feel free to email me and I'll do a follow-up if there's enough interest in the more developer-focused features of version 2.
Miss a column? Check out the Scripting School archive.
ABOUT THE AUTHOR:
A Terminal Services MVP, Christa Anderson is the strategic technology manager for visionapp She formerly was program manager for the Microsoft Terminal Services team. She is an internationally known authority on scripting, the author of Windows Terminal Services, The Definitive Guide to MetaFrame XP, and co-author of the book Mastering Windows 2003 Server. If you have a scripting question for Christa, please email her at editor@SearchWincomputing.com. She often uses these emails as fodder for her scripting columns.
This was first published in November 2007