PowerShell Empowerment

Alex Angelopoulos has a passion for scripting. In his work as a consultant and a network administrator over the past 10 years, Alex has written hundreds of scripts to automate all kinds of administration tasks. And as a regular contributor to Scripting Pro VIP (www.scriptingprovip.com) and the former Windows Scripting Solutions newsletter, Alex has helped raise Windows IT pros’ awareness of scripting’s benefits and improve their scripting skills for nearly that long. In a recent conversation, Alex shared his thoughts with me about the usefulness of Windows PowerShell as a quick task-automating tool and how the shell makes it much easier for Windows administrators to fashion their own time- and work-saving solutions than using older batch-file, cmd.exe scripting methods.

Q: How did you get started in IT, and what are you doing currently?

A: I started out doing small/medium business IT support in the Windows 95 era. Over the last few years I've also moved into writing about administrative automation and developing specialty administrative solutions.

Q: What got you started writing scripts?

A: I started scripting in 1992, on UNIX. On Windows, what really got me started was a long-neglected LAN that I helped administer 1997 through 1999. Although there was no “magic bullet” solution to our problems, we were able to dramatically reduce the workload using automation. That experience also shaped my view of the scripting environment.

One thing that I didn't fully realize until later was the importance of teamwork. The administrator I worked for, Ahmad Sa'adeh, was a huge part of the solution. When he saw what we could do with automation, he was willing to make the short-term sacrifices in time and effort that it took to get us going. Another important lesson was that standardizing systems and lifecycle management dramatically reduces the need for custom solutions. Finally, I learned that there's never a magic solution-in-a-box. The right tools can help immensely, but when dealing with specific real-life problems, the best guarantee of a solution is having a lot of possible partial solutions that can be assembled.

Q: What sparked your interest in using Windows PowerShell?

A: I started using PowerShell the first day the beta was available for download; I had already been sold on the idea. PowerShell is fundamentally a shell and was explicitly designed from the ground up by people with centuries of combined experience using bash, csh, Perl, VMS DCL, and other shells and scripting languages.

We've never had a comparable shell on Windows. The cmd.exe shell more or less “happened,” and developers cleaning it up subsequently were always limited by compatibility requirements and the available Windows infrastructure. The Windows Script Host (WSH) developers did design WSH explicitly for Windows administration, but they were designing a scripting host, not a shell. They were also constrained by other roles the languages needed to fit, the past history of those languages, and the Windows infrastructure once again.

Q: What aspects of PowerShell make it especially useful for a Windows admin? How easy is scripting using PowerShell compared with doing so in other scripting languages?

A: In the short run, the fact that it's a shell, letting you work interactively and in 15-second snippets of time, is crucial. So is the fact that it's designed to glue things together readily; most real-world administrative problems are solved by solution accretion rather than solution design.

Over the long run, the critical factor in PowerShell's utility is its use of administrative-shell principles that people spent years figuring out on UNIX/Linux, VMS, and Windows; those are enduring values. PowerShell works with your instincts rather than against them.

As for ease of scripting, answering that highlights the point behind PowerShell. Once you know the basics, batch processing and gluing tasks is extremely easy. Some things PowerShell can't do very well yet, and may never be able to do as easily; for example, advanced COM automation tasks that are fairly straightforward in WSH are sometimes incredibly difficult in PowerShell due to .NET's constraints. The way to script those in PowerShell is to use a WSH script or even directly host VBScript/JScript within it. This isn't a "my tool is better than your tool" contest; it's all about making it easy to use what you have to get the job done.

Q: Talk about a useful PowerShell scripts you’ve written—from the point of view of how well it solves a business or technical problem.

A: Actually, I’ve found that the main advantage of PowerShell has been not having to write scripts. You can do improvisational work rapidly. Unlike my WHS scripts, most of the lengthy Powershell scripts I write are specific to complex problems particular organizations have. The daily tasks are a different story; most of those just happen and never become scripts.

Jeffrey Snover illustrated the point fairly well in a TechNet interview (see (channel9.msdn.com/Showpost.aspx?postid=25506) where he explained the standard administrative model. You might be looking for information; you try a command, it doesn't work, you try something else, that almost works, and then you know what you need to do and go on to the next thing.

Let me use an example where I pick on VBScript, which is my preferred scripting language. I'm sitting at a computer on a network and need to find out the OS version on a computer named Weeble that I see on the LAN. I could go to the other computer, but that requires finding it, and it might be in a locked office, off site, or in use. I know I can use the Windows Management Instrumentation (WMI) Win32_OperatingSystem class to find out details, and theoretically I could write VBScript to return the information, but I also need to know the property in that class. I can enumerate the property names in VBScript as well, but doing so takes even more time. In any case, once I write the script, I'd be unlikely to ever use it again. Tasks like this don't play to VBScript's strengths.

In PowerShell, I would just run this command:

gwmi Win32_OperatingSystem -Computer Weeble

which displays basic information about the remote OS. (Note that you’d need to replace with the actual computer name.) It turns out that the default data display doesn't show me what I'm after; let's say I want to know whether it's a 32-bit or 64-bit architecture and what the actual OS variant is. So I tell PowerShell to tell me all properties of the computer in a list format:

gwmi Win32_OperatingSystem -Computer  | fl *

From the output I can see that the information I want is OSArchitecture and Caption. However, it's no longer relevant; I found out what I want to know. I could reissue the line as

gwmi Win32_OperatingSystem -Computer  | fl OSArchitecture,Caption

to show just what I'm after. Using this as an example, I could write literally hundreds of PowerShell scripts that retrieve specific information, but there's no point. Why carry around hundreds of static scripts, most of which you’d only rarely use, when you can get the information you're after in five seconds from what you know?

Q: What would you tell Windows administrators to encourage them to dive in to PowerShell?

A: I’d try to throw them into the shallow end: Get PowerShell onto the system they normally work from, then start using it as both their command-line shell and Run dialog. Using PowerShell is the only way to get to understand it. I also encourage people to keep using their old tools in PowerShell, since they already know how they work.

Administrators don't sit down and say “I'm going to learn how to use a new scriptable shell today.” Admins keep networks and software running. When they run into problems that don't have affordable off-the-shelf solutions, they start looking at gluing together their own solutions. Those solutions are always constrained by the problem's characteristics, their knowledge, and the available resources. Over the next couple of years we'll see people becoming more familiar with PowerShell. It will also become more ubiquitous: Newer versions of Windows will ship with it, and more of the Windows 2000 systems that can't run it will go away through attrition. Another thing to remember is that PowerShell won’t displace current tools; it's quite happy to run cmd.exe and WSH tools that are already out there. The way PowerShell wins is by being a better glue, not by making you rebuild everything you've developed over the last decade.

Q: What resources would you suggest for PowerShell newbies?

A: In the case of PowerShell, the starting point is using it as a shell. Things that would take a thousand words to explain poorly become instinctive when you spend time just doing them. Other great sources are the TechNet scripting center, the PowerShell newsgroup on news.microsoft.com, the PowerShell developer blog, and the books and presentations done by the PowerShell development team. (See the Learning Path box for links to PowerShell resources.)