Getting Started with PowerShell

You're doubtless aware that Windows PowerShell exists, and that it's somehow a big deal in the Microsoft world. But perhaps you've been too busy to really dig into PowerShell, or maybe you aren't sure why you should care about it. Let's clear up some misconceptions and answer that question in the process.

Why PowerShell?

First, we need to bust two major PowerShell myths.

PowerShell is a scripting language. Not true. PowerShell contains a scripting language: a very tiny one, with only about two dozen keywords. But PowerShell is actually a command-line shell, much like cmd.exe or UNIX Bash shell. You run commands -- such as Ipconfig, Ping, and other commands that you've undoubtedly run in the past -- in this shell. True, at some point you might want to combine multiple commands into a batch file, and you're welcome to call that scripting if you want to. But it isn't really programming such as you'd perform in Microsoft Visual Studio.

Part of this myth comes from the fact that PowerShell allows itself to be used as a kind of lightweight programming language by folks that have those skills. But it doesn't require you to have those skills to be effective.

Microsoft wants to push people away from the GUI. Also not true. Microsoft is trying to de-emphasize running GUI consoles on the server; servers aren't well-equipped to deliver a good GUI experience without compromising server-lever performance. But running GUIs on the client, even one that connects to a server to do its work, is very much alive.

PowerShell merely represents an alternative for administrators. GUIs can be built to run PowerShell commands in the background, so PowerShell can both provide the functional guts to a GUI and be available for direct use by administrators.

That said, Microsoft is definitely engaging in triage over what its GUI consoles can do, typically focusing on day-to-day tasks. Unusual or less frequent tasks might eventually be available only via the command line. Be upset about that if you want, but also understand that failing to add PowerShell to your skills repertoire could damage your career in the long term.

Running Commands

Using PowerShell doesn't need to be complicated. For example, suppose you want to add a new user to Active Directory (AD). That task is fairly easy:

New-ADUser -Name DonJ -samAccountName DonJ -Title CTO -City "Las Vegas" -Department IT

As you can see, the New-ADUser command accepts several command-line parameters. Those parameters (e.g., -Name, -Title, -City) correspond to the same fields that you'd see when using Active Directory Users and Computers to add a user. So why use the command line instead of the GUI? Because the command line makes it easier to do many things in bulk.

For example, suppose you've been given a Microsoft Excel spreadsheet of new users that need accounts. The first row of the spreadsheet contains column headers: City, Title, Department, Name, and samAccountName -- the attributes of those users. Simply save the Excel file as a comma-separated value (CSV) file, perhaps naming it NewUsers.csv. From there, you can easily use PowerShell to create the new users:

Import-CSV NewUsers.csv | New-ADUser

As you can imagine, this approach is much faster than manually creating the users in the GUI. PowerShell takes just a few seconds to create 100 user accounts, whereas creating that many accounts in the GUI can take a few hours. By the way, New-ADUser is a command from the Microsoft ActiveDirectory module, which you'll find in the Remote Server Administration Tools for Windows 7 and on Windows Server 2008 R2 (and later) domain controllers (DCs). You need to run

Import-Module ActiveDirectory

to load the module into memory after installing it on your system.

Learning the Syntax

The most difficult thing about any command-line interface (CLI) is learning the command syntax. Which parameters are available? What does each one do, and which values will it accept? Administrators often spend hours on a search engine looking for syntax examples. But with PowerShell, you can get started much more easily. Need to do something with services?

Help *service*

Run that command in the shell and you'll get a listing of commands that deal with services. Suppose you find a promising-looking one in Set-Service. You can quickly learn how to use that command by running another command:

Help Set-Service -full

The -full parameter is important. This parameter provides a lot of extra information, including details on each and every parameter's usage as well as practical examples. No need to hop on Bing to find examples; they're already in the product.

Note that some folks use the formal Get-Help command rather than just Help. I prefer the latter, which automatically pauses the display after each screen of text. There's no need to pipe the file to More when you use Help.