Windows Insider

Windows PowerShell Is Not a Scripting Language

• By Greg Shields
• 05/01/2010

I find myself amazed at how many IT professionals still avoid the command line.

Even if you're no longer a hands-on, technical IT practitioner, you've surely got some familiarity with it. The command line text-based interface has been around since long before the first GUI appeared. It is, in fact, so old that today's nth-generation Windows PowerShell-enabled command line now ships with many almost-graphical elements of its own.

Windows PowerShell is ridiculously powerful. Using today's Windows PowerShell, a skilled professional can quickly craft a useful single-line command. All at once, that single line can interrogate remote computers, interact with Active Directory, accomplish one or more actions and report back with a fully manipulatable "object." This object can ultimately take the form of a dynamically constructed table, a list of data, or even an exported .CSV or .XML document for use in some external IT applications. Using the miracle of pipelining, that same Windows PowerShell expert can string together a series of cmdlets, elegantly feeding the output of one cmdlet into the next -- all the way down the pipeline to some concluding result.

Yet, with all its elegance and power, why aren't more IT professionals embracing Windows PowerShell today? If it is possible -- and indeed it is -- to accomplish so much with so little, why aren't more IT pros lining up in droves to learn and make use of its ridiculously powerful capabilities? I believe that Windows PowerShell has a perception problem.

I discovered this perception problem only recently. In the past few months, another of Redmond's columnists, Don Jones, and I have been contracted by a major software vendor to develop training on Windows PowerShell. Given almost complete flexibility in designing the courseware, Jones and I took a step back from the Microsoft messaging as well as from much of its aficionados' online content. To best explain its capabilities to students, we needed to determine what Windows PowerShell is at its core.

Absolute Precision
When we looked at the scripts, the scripting suggestions and the scripting constructs that you can find virtually everywhere on the Internet these days, Jones and I realized that Windows PowerShell's problem is that to the uninitiated it's a scripting language. But, in fact, it's not.

This misperception is not a good thing. Think for a minute about how IT neophytes perceive scripting languages. Solutions like batch, KiXtart and VBScript are all widely considered to be some of the most historically significant Windows scripting languages. While powerful in their own right, for today's freshly minted IT professionals these languages are too complicated, too difficult to learn and a potential source of catastrophe if not wielded with absolute precision.

Their feelings aren't far from the truth. With languages like VBScript, we've all heard the stories of how a few misplaced characters caused a massive deletion -- or of the all-server reboot script that somehow got launched in the middle of the day. VBScript and others weren't without their own security problems, with unprotected runtime environments being automatically installed and listening on every Windows desktop and server.

As a result, entire industries have emerged to create management software that automates the job of the IT professional, all without the nasty scripting interface. For many, the entire process of scripting has become demonized to the point at which it has even been disabled from running in the domain.

Administrative Automation
So, if Windows PowerShell isn't a scripting language, then what is it?

I submit that Windows PowerShell 2.0 is a text-based administrative automation solution. Through the simple connection of a few key cmdlets, even the greenest of IT pros can speed up the completion of the most difficult IT tasks.

Consider, for example, the common problem of adding new AD users and granting them access into one or more global groups. Accomplishing that task using the Windows GUI today requires a set of mouse clicks for each and every user created. Information must be entered multiple times, increasing the chance for error.

Additionally, the time involved to accomplish the task grows linearly with the number of users there are to create. This process is so time-consuming that many of the aforementioned graphically oriented administration solutions have built their own wizards for batch user creation.

On the other hand, consider the elegance of this single Windows PowerShell command:

Import-CSV newusers.csv | New-
ADUser -passthru | Enable-ADAc 
count -passthru | Add-ADGroup 
Member "New Users"

In a single line, this command reads through the list of new users contained within an Excel spreadsheet's .CSV file. It pipes the users it sees to the New-ADUser cmdlet to create those users, then pipes them again to Enable-ADAccount to enable their accounts, and then completes the thread by piping the entire result to Add-ADGroupMember to add their accounts to the New Users global group. Using what's likely the same spreadsheet of users that you've received from your HR department, four commands in a single line have accomplished the task.

That being said, I'll admit that this column's title isn't an entirely true statement. Windows PowerShell indeed comes equipped with some powerful scripting constructs that enable it to accomplish all the tasks you're used to seeing in a scripting language.

But at its very core, Windows PowerShell is something far superior to a scripting language. It's a not-that-difficult mechanism to swiftly accomplish IT's daily tasks, all without the repeated steps and potential for error that accompanies using the mouse.

So, if you haven't yet taken a look at Windows PowerShell for fear of having to learn a new language, give it another chance. You may find that its capabilities are easier and more fulfilling than you think.