Introducing Windows PowerShell

Windows scripting has long been the butt of jokes from UNIX system administrators. This has been the case for several reasons; chief among them is that Windows has been lacking many of the key features that make scripting truly useful. However, Microsoft is now not only catching up to but actually surpassing other OSs' scripting capabilities with its new Windows PowerShell scripting environment. Formerly code-named Monad, PowerShell delivers several scripting capabilities that Windows has never had and greatly improves some existing features. Even though PowerShell is still a release candidate, it's useful to know how PowerShell is filling in the capability gaps and how it works.

Filling In the Gaps
Microsoft designed PowerShell to provide a more powerful scripting and command environment than was previously available in Windows. The design team members had a number of goals in mind. In summary, they wanted to make the Windows scripting environment more powerful and easier to use than the scripting tools in any other OS. They also wanted to build an environment that would be usable for systems administration tasks and application development—and one that would integrate with the Microsoft .NET Framework. Meeting these goals meant that Microsoft had to address some capabilities that have been missing from Windows scripting tools. To fill these capability gaps, Microsoft incorporated into PowerShell the best aspects of a wide variety of commandline environments:

PowerShell 101
PowerShell is made up of lots of objects called cmdlets (pronounced command-lets). Cmdlets are analogous to DLLs in that they're executable objects that can't run on their own. For that reason, cmdlets are run from within the PowerShell command interpreter. PowerShell Release Candidate 1 (RC1) includes more than 120 cmdlets.

Cmdlets can have parameters, which can be named or positional (i.e., PowerShell interprets them according to their location on the command line). For example, when you use the get-mailbox cmdlet, the first parameter always specifies what mailboxes you want to get. You can include other parameters in this cmdlet by specifying their names.

There are several built-in cmdlets that you'll use often enough to warrant a mention here:

When you look at other people's Power-Shell scripts, you might see funny-looking abbreviations for some cmdlets, such as fl for format-list. PowerShell has extensive support for aliases. There are built-in aliases for many common commands. Plus, you can define your own aliases in your shell profile, which is a special file that PowerShell uses to apply per-user defaults and settings.

PowerShell's scripting language, Powerscript, has all the constructs you'd expect to see in a scripting language, such as constructs for looping, branching, and string manipulation. If you've ever used VMS or IBM's mainframe JCL, the syntax will be somewhat familiar. UNIX scripters will also find familiar elements, as will administrators who are used to writing VBScript scripts.

PowerShell in Action
The first Microsoft application to take advantage of PowerShell is Microsoft Exchange Server 2007 (formerly code-named Exchange 12), so I'll be providing Exchange-related examples of PowerShell in action. ( Windowsrelated examples will be covered in a future article.) Exchange 2007's UI is based entirely on PowerShell. Every action you can take in the Exchange 2007 version of Exchange System Manager (ESM) is a task, and every one of those tasks is written using PowerShell. This opens up a wonderful new world: Everything you can do in ESM can be done from the command line—something that definitely isn't true for Exchange Server 2003. There are also additional operations you can perform only from the command line, although Microsoft hasn't released a complete list of what those operations are yet.

Exchange 2007 comes with its own set of cmdlets for working with Exchange objects. You can use these cmdlets for manipulating all kinds of objects, including Microsoft Outlook Web Access (OWA), virtual directories, mailboxes, distribution groups, storage groups, and unified messaging dial plans. Because these cmdlets follow the same naming pattern, it's immediately obvious, for example, what the new-mailbox, enable-mailbox, and get-mailboxStatistics cmdlets do.

Because of PowerShell's pipelining and composition capabilities, you can perform tasks from the command line that you just can't perform in the Exchange 2003 ESM or even in the Microsoft Management Console (MMC) Active Directory Users and Computer snap-in. For example, suppose that you have a default mailbox quota policy in place and you want to apply a different quota (500MB) to members of the Executive group. In Exchange 2003, mailbox quota policies apply to databases, so you have four choices: Don't use the policy, move the users in that group to their own mailbox database, use the Active Directory Users and Computers snap-in to manually apply a quota to each account, or write a script that uses Active Directory Service Interfaces (ADSI) to make the change. With Exchange 2007's PowerShell support, applying a different quota is much easier. You simply run a command such as

get-group "Executives" |    set-mailbox    -SendStorageQuota 500MB 

Although this command is short, you can see both pipelining and composition in action. Note that the parameter for getgroup is positional, whereas the parameter for set-mailbox is a named parameter (i.e., SendStorageQuota). Why? All you can do with get-group is get a list of account objects that are members of the group, but set-mailbox has lots of other options you can apply. For example, you can just as easily give special quotas to people whose last names end in the letter x:

get-mailbox *x |    set-mailbox    -SendStorageQuota 1GB 

As this example shows, you can use wildcards to find collections of objects that interest you. However, you don't have to. The cmdlets' default behavior is to return all objects of the selected type. For example, if you run the cmdlet

get-mailboxstatistics 

you'll get statistics for all the mailboxes in your Exchange organization. This feature makes it simple to perform actions that apply to all objects of a given type. For example, if you want to retrieve all the mailboxes in your organization, group them according to the mailbox database in which they reside, and format the resulting set of objects as a list, you'd run the command

get-mailbox |   group Database | fl 

Let's look at another more powerful example of cmdlets. The command

get-OWAVirtualDirectory |    set-OWAVirtualDirectory    -FileAccessControlOnPublicComputers    blockAllExceptTranscoded 

enumerates every OWA virtual directory in an organization, then sets the WebReady Document Viewing controls to block all attachment access, except for files that can be rendered by the Document Viewing layer. Presto! With this one line, you've effectively prevented users on public computers from saving or accessing attachments unless those attachments can be transcoded, which greatly lowers the risk of accidental exposure of confidential data. If you had to apply this setting manually to each OWA virtual directory, it would be easy to miss one or more servers, leaving your protection incomplete.

Favorite Features
As you work with PowerShell, you'll find features that you use constantly. Here are a few of my favorite features:

Powering Up for PowerShell
Initially, your PowerShell scripts won't be pretty. They're probably going to look like the first scripts you created when you learned your first scripting language (only with slightly different syntax). So, until you get fluent in PowerShell and learn its ways, it might be best to think of PowerShell as a complement to existing scripting methods. The Learning Path box provides some resources to help you with the learning curve. I recommend Andy Oakley's book Monad and the Windows PowerShell Quick Start Web page, which is part of the Windows PowerShell Wiki on Microsoft's Channel9 (http://channel9.msdn.com/wiki/default.aspx/Channel9.WindowsPowerShellQuickStart).