Beta Man

Shell Game

Microsoft's PowerShell puts scripting power in your hands.

• By Beta Man
• 11/01/2006

So far, PowerShell seems to be the beneficiary of that experience. For starters, it won't even run scripts by default. You have to modify its execution policy (run help set-execution policy for details) before it will run any script. It also has built-in support for running only digitally signed scripts, as well as support for signing them. By allowing only signed scripts to run, you can prevent untrusted scripts from executing while running your own without concern.

PowerShell also prevents scripts from "hijacking" commands. For example, you might be used to typing dir to get a directory listing. However, what if someone managed to get a script named dir into the current directory?

PowerShell won't run scripts from the current directory unless you specify the path. For example, if PowerShell is in the C:\Test folder, where there is also a script named test.ps1, you can't run the script by typing test. You have to type .\test, which makes it clear you're not trying to run a cmdlet, an alias or something else.

If all of this seems a little paranoid, then the PowerShell team has done its job. We don't need another scripting tool to come along and open Windows to a whole new era of security nightmares. Keep your execution policy firmly locked down to its "Restricted" default and scripts won't run. You should also get yourself a code-signing certificate from someone like VeriSign or Thawte and use it to digitally sign any scripts you write yourself. Then you can set PowerShell's execution policy to AllSigned, and any unsigned scripts won't run at all.

Now for the Bad News
Windows administrators are in for a tough time. Those who can script are more productive and more desirable, so the pressure's on to get scripting skills onto your resume pronto.

PowerShell does offer a more consistent, more powerful environment for scripting and automating Windows administrative tasks. Unfortunately, it isn't all peaches and cream. Microsoft seems to have built PowerShell in large part to impress our Unix counterparts, and these guys have been scripting since the dawn of time. That means PowerShell delivers the flexibility (and cryptic two-letter commands) a Unix admin would expect. Becoming fully proficient in PowerShell, therefore, is a lengthy proposition.

Microsoft could have made things a bit easier. Variables in PowerShell, for example, don't need to be explicitly declared or assigned a data type (although they can be). This makes PowerShell easier and more flexible, but it also gives you plenty of room to get yourself into some complicated debugging exercises. Ultimately, that can actually make working with PowerShell more complicated.

Microsoft also chose a C#-like syntax for PowerShell's scripting language. That's not surprising given Microsoft's love of C#, but it's unfortunate because a Visual Basic-like syntax would have probably been less intimidating to newcomers.

All that aside, you're going to have to learn PowerShell anyway -- and Beta Man is not kidding when he says "have to." The days of the point-and-click interface for an enterprise administrator are fading. Sure, the GUI will always be there for the newbies, but the money (and job security) is going to be in scripting.

Both Exchange Server 2007 and System Center Operations Manager 2007 will have their administrative functionality built on PowerShell, meaning anything you can do in the GUI, you can do within PowerShell -- and probably do it faster. Windows Longhorn Server won't be as integrated with PowerShell, but that will come along in future releases, as well as other future Windows Server System products. So power up, get yourself on board and get a leg up on the competition.