This month I'm going to talk about a developing technology: Windows PowerShell. Formerly known as Monad, PowerShell...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
is an object-oriented command-line shell environment for Windows operating systems. In simple English, this means that:
- You can run either single Windows PowerShell commands or collect them into a script that you can call.
- PowerShell (generally) relies on existing objects rather than having you create them.
PowerShell depends on .NET 2.0. This structure was reflected in its original name. In ancient Greek philosophy, "monads" were the fundamental building blocks of the world, roughly equivalent to the way atoms are explained in elementary school science classes. (I started to say, "roughly equivalent to atoms," but got bogged down in electrons and quarks and strings (if string theory is correct). Anyway, you get the idea.
Unlike the existing command-line tools, PowerShell uses standardized interfaces. This means that you can communicate with all object types in the same way. If you've worked with the command-line tools, you know they don't all use the same syntax or conventions. Using PowerShell, you can interact with all kinds of objects in the same way, whether they're files or registry keys.
The relevance of PowerShell
Some of you may be wondering, "What relevance does PowerShell have for me?" After all, Windows has a command-line environment (and has had since the beginning) and we've been spending a lot of time focusing on an alternative to it because it's not always as flexible as it could be. And PowerShell isn't even as flexible as VBScript, unless a commandlet uses Windows Management Instrumentation (WMI), and then it can only run locally. Furthermore, PowerShell is only supported on Windows XP SP2 and later, and to top it off, you need to download it -- it won't be included even in Vista and Longhorn.
However, PowerShell has a certain advantage over VBScript: It has built-in access to objects, properties and methods that VBScript must connect to in order to use them. For example, we've done some work with the File System Object, and this work always requires creating an instance of the FSO. PowerShell doesn't need to create the FSO, because objects for manipulating files and folders are already accessible to it.
In fact, many of the things you'd like to do with VBScript are already built in to PowerShell, so you don't need to figure out how to do them. For example, some objects store their properties in arrays, instead of as single properties—even if there is only one property for that object. (One example that comes up a lot are network cards, for instance, if you're trying to find out a server's IP address.)
To return the values of properties stored as arrays, VBScript demands that you use a For. . .Each statement to cycle through all the arrays and return the results. PowerShell doesn't require this; it can just return all the properties associated with an object. The result is that you don't necessarily need to know how an object stores its properties to get back a complete set.
Here's another example. While you can return a collection of objects (such as all the files in a folder) with VBScript, you can't use VBScript to sort those files according to the properties you want. And although you can return only files with certain characteristics, it's not a simple trick.
Anticipating that people may want to do both of these things, Microsoft gave PowerShell the ability to sort and filter the results of a query. These built-in capabilities make manipulating data a lot simpler than it is with VBScript.
In other words, PowerShell is useful to us in the same way command-line tools are. If a tool already exists (or in this case, an interface), we can use it instead of reinventing the wheel with VBScript. Where it does not already exist, we can—and will—still script.
What can you do with PowerShell?
You can divide the things you can do with PowerShell into two main categories. The first category includes all the objects natively built into PowerShell, so you don't need to go messing around with, say, File System Objects. The second category includes everything you can access when you use PowerShell to talk to WMI.
With each generation of Windows, WMI support gets more complete (there's actually a Longhorn requirement within Microsoft to build WMI interfaces for everything you can do from the GUI). This benefits developers creating tools that plug into the capabilities of the operating system, and it benefits you by expanding the object and property set you can talk to via scripting.
One last thing about WMI: Generally speaking, you need to talk to WMI to perform tasks on a remote computer. (This is a surprising limitation given PowerShell's role of simplifying server administration, and it may be lifted in later versions.) Identifying the computer you're addressing using WMI works the same way as when you're using WMI with VBScript: the local computer's name is ".".
How can I learn more about PowerShell?
I'm glad you asked; this is the reason why I focused on PowerShell this month (next month I'll return to practical applications for regular expressions). Microsoft maintains a PowerShell site. Go there, and among tons of other information you'll see that the Scripting Guys are hosting a week's worth of interactive Webcasts about PowerShell from November 6-10 at 11:30PST. If you want to learn more about PowerShell, I heartily recommend you attend.
To sum up, PowerShell is the latest answer to the demands for real command-line support for all Windows commands. It's extensible through its use of WMI (meaning that, as WMI support grows, PowerShell becomes more powerful) but also contains some built-in functionality that makes manipulating data a lot simpler than the ordinary interfaces make it.
|ABOUT THE AUTHOR:|
| Christa Anderson
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 e-mail her at editor@SearchWincomputing.com. She often uses these emails as fodder for her scripting columns.