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
Register
