Getting started with PowerShell: The basics

Are you a Windows administrator? Did you make a new year's resolution to learn PowerShell this year? If so, you have come to the right place.

In this piece, I will get you started by orienting you to the world of PowerShell, helping you get your bearings and showing you how to perform simple tasks with the language so that you have a solid foundation on which to add skills for your particular job. Let's get started.

Get-Basics

PowerShell uses a consistent syntax for all of its commands -- in fact, PowerShell commands are actually called cmdlets, because they’re much more than simple DOS-style actions. All cmdlets use the following syntax:

Verb-Noun

You can easily remember it as "do something to" "this thing." For example, here are three actual cmdlets:

• Set-ExecutionPolicy
• Get-Service
• Show-Command

All cmdlets will always follow this format. Using these three, you will set an execution policy, show a command or list of commands and get some information about a service and what it can do.

There are a few things to remember about using PowerShell at any time:

• PowerShell is case-insensitive. UPPERCASE, lowercase, cAmElCaSe -- it doesn’t matter. PowerShell simply reads the text in and performs the action you want.
• Since PowerShell cmdlets are always consistently formatted, you can chain those cmdlets and their output together and do things in sequence. For example, one cmdlet can retrieve a list of things, and you can send that list (the output from that first command) to a second command, which then does things too. This can go on and on and on as long as you need it to until whatever task you want is complete.
• The output of a PowerShell cmdlet is always a .NET object. This might not mean a lot to you right now, especially if you are not a programmer or don't have a software development background, but you will find as you learn more about the PowerShell language that this is where some of the real power in PowerShell lies.
• PowerShell works well with local systems but it also works tremendously well "across the wire" with remote systems. With a few changes to settings on both your local machine and the remote systems you want to manage, you can execute commands across thousands of machines at one time. This had been the purview of Bash and Perl before PowerShell, but now Windows has a true remote command shell equivalent.

Seeing the universe

On a machine where you have PowerShell installed, open it up and just type in the following:

Get-command

This tells PowerShell to get all of the cmdlets it knows about. In the absence of anything else, PowerShell will always send output to the screen. (You could direct this to a file, into another PowerShell cmdlet or use it some other way, but for now let's just get a sense of what can be done.)

You should see something like this:

That's the universe of PowerShell -- at least to your machine right now. Other products like Exchange, SharePoint, System Center and Office 365 all have their own set of cmdlets that you would need to import to do their service-specific tasks, but let's just focus on what your machine knows about now.

That's still a lot of cmdlets! How many, you ask? Well, let's figure out how to get PowerShell to tell us. Remember how I said that the output of a PowerShell cmdlet is always a .NET object? Well these objects all have properties -- exactly the same way that Windows files have properties. For example, when you right-click on a file in Explorer and click Properties, you get what amounts to a bunch of attributes and values describing the file -- author, location, keywords, permissions and so on.

Well, .NET objects have properties too, and one of the properties you get right out of the box is the count property. At its simplest, the count property can tell you the number of different things you're dealing with -- users, mailboxes and so on. You can simply grab the value of the count property of any cmdlet's output by enclosing the cmdlet in parentheses, including a dot, and then putting in the name of the property, count. Like this:

(get-command).count

Remember, you want to put the name of the object in parentheses, add a dot to access the properties and then enter the property name.

When I typed it in, I got a count property of 1,141. Your number might be different, depending on what versions of Windows and PowerShell you are running. Don't worry too much about these differences now.

Counting, as simple as it is, can come in handy in all sorts of situations. For example, in Exchange installations, you can get a count of how many mailboxes there are by just using:

(get-mailbox).count

Or maybe you have an Active Directory deployment and you want to know how many users there are in total. Or you want to know how many events there are in an event log. Maybe you want to monitor how many events there are from a certain service or application that writes to the event log -- but only when there are errors. A simple monitoring system could use the count property for a given event log, see when it's greater than zero and then do some stuff to alert you, like send an email.

The possibilities are pretty much endless, and many things you will want to do in PowerShell come from looking at the properties of something you're dealing with.

"But Jon," I hear you asking. "How do I know what sorts of properties an object might have?" After all, when you right-click and select Properties in Windows, the GUI makes it fairly apparent what all of your choices are. Well, keep reading.

Help me!

When I asked folks who were new to PowerShell what they wanted to learn about first, I received a really interesting comment:

I have used PowerShell commands fed to me in their entirety by various postings on the Internet -- solutions to particular problems. I can see how powerful it is, but am amazed at how much there must be to remember. Do people remember all of the commands, their syntax, the command options, switches, etc?

This is an excellent question. PowerShell is a big world of cmdlets, but don't despair -- each of them is thoroughly documented using the built-in help. You can access it by -- wait for it -- using a cmdlet called Get-Help. For any cmdlet, just precede the cmdlet name with Get-Help and you'll get a world of documentation.

Tip: When you first deploy your system, you'll probably want to run Update-Help, which will download the latest PowerShell help files from Microsoft and install them on your system. Be sure to run this as an administrator. It won't work otherwise.

The update process will only take a minute or two, but then you'll be using the latest documentation. You might want to run this every six months or so just to make sure you're not missing anything.

Let's see this in action. We'll go back to our get-command cmdlet and ask for some help:

Get-help get-command

This is what I see:

You can see that the get-command cmdlet takes a lot of parameters. If you know DOS at all, you'll remember DOS commands have flags, like dir /s, which list the contents of the directory and then all subdirectories, or move /y to move things without being required to confirm the move for Every. Single. File. Those DOS flags altered the way a command responded by default.

These cmdlet parameters act in the same way -- they affect what the cmdlet does. You can tell get-command to give you:

• Only certain types of commands with –CommandType
• Commands with certain syntax using –Syntax
• Everything using –all
• And so on

Most PowerShell cmdlets will accept parameters. You will rarely just use the default output of a command. So it's important to know where to look to find these parameters.

What else might be useful to find out about a given cmdlet? If you’re sniffing around an area or a topic, the Related Links section can be really helpful; this is where you can find related PowerShell cmdlets that might do something else you want related to the same topic or area.

For instance, if I'm running get-eventlog because I want information about the event log, I probably want to do something with that information, so running get-help get-eventlog shows me (in the Related Links section) other cmdlets I’m probably going to be interested in learning more about, including:

• Clear-Eventlog
• Get-Winevent
• Limit-Eventlog
• New-Eventlog
• Remove-Eventlog
• Show-Eventlog
• Write-Eventlog

And then I can use get-help with each of those suggestions to get more information.

Are you starting to see how you can work your way through a task using the built-in documentation? The get-help cmdlet itself has parameters, and one of the most helpful parameters is the –examples parameter. This lists out a bunch of example cmdlets that use parameters in various forms and combinations, so you can see the commands in action and build your own customized versions of these cmdlets based on the examples.

Try it yourself. Enter:

get-help get-command -examples

You can see that the examples are well documented and clear. And these are everywhere in the PowerShell universe. Going back to an Exchange environment, here's what I see with Get-Mailbox:

And here’s what I see for get-help show-eventlog -examples:

So in answer to the reader's original question -- no, everyone doesn't memorize everything all the time.

Now, sure, just like you start to remember familiar DOS commands or even Bash commands in Linux or Unix, you'll remember some things if you use them often enough. But PowerShell's help and the examples that you get right out of the box with no further effort (other than to update the help files as I recommended earlier) will always be there as guides to help you figure out what's going on and how to work your way out of a puzzle.

Something practical

We have covered only the very, very basics here, but let's do something practical before we close up this piece so that you get a real feel for PowerShell and can practice what you read here right away.

Two very common things you do in administering systems are finding processes and killing them. You might currently use Task Manager, or for more detailed work you might use the DOS command tasklist /svc to find the process ID for a given service and what it’s running, and then use Task Manager to kill it. With PowerShell, we can do the same thing.

Let's say that -- purely hypothetically, of course -- we have a browser whose name rhymes with Moogle Shrome. It is not well behaved and sucks up a ton of memory if you leave it open overnight. (As mentioned, this is absolutely hypothetical.) We need to find it and kill it before it does more damage.

You can probably guess how the cmdlets for working with processes would work. Get-process will get a list of processes that are currently running on your system, formatted as a table by default.

I know from get-help get-process that I can specify the name of a process that will display information only about that process:

And I'm thinking that if get-process gets me the information about a process, then using the verb-noun format, stop-process would stop one. (I could always check this out using get-help or get-help examples, but since I'm a in a hurry, I proceed without reading the directions and just assume that this cmdlet exists.)

My brazenness is rewarded! But now it's asking me for an ID because when I entered the stop-process cmdlet, I didn't tell it which process to stop. I could scroll up and look for the ID in the results table from get-process chrome. Looks like process ID 2924 is taking up a lot of CPU time, so I'll enter 2924 and hit enter.

If that's the only one I want, I hit Enter again on a blank line. (PowerShell is assuming there might be more than one ID I want to kill and is letting me enter multiple IDs at one time, but to skip out of this anytime you see this, simply enter a blank line.) I immediately note that Googl...ahem, Moogle Shrome has disappeared.

Without the handholding, I could have accomplished the same thing using this sequence:

Get-process

Get-process chrome

Stop-process 2924

And I'd be done.

Wrapping up

Congratulations! We just used PowerShell to kill a process that had gone awry. We puzzled our way through cmdlets, used parameters, remembered ways we could find out related cmdlets and successfully made educated guesses about whether certain cmdlets existed by remembering the verb-noun naming methodology.

Now you have the tools to make a good start at using PowerShell like a pro.