In part 1 of this PowerShell tutorial for Windows admins you will learn about the cmdlet and pipeline concepts.
Latest posts by Timothy Warner (see all)

Update: Also check out our new PowerShell tutorial about managing Services by PowerShell MVP Jeff Hicks.

Microsoft Windows PowerShell was conceived as the next-generation replacement for the old and reliable cmd.exe command shell environment. What’s especially cool about PowerShell is that it has a lot to offer both Windows systems administrators as well as .NET solution developers.

Trouble is, you have doubtless discovered that the PowerShell documentation, whether published by Microsoft or a third party, rarely differentiates between these two very different audiences. Therefore, administrators get confused and frustrated while trying to wade through PowerShell developer terminology, and .NET developers get befuddled and angry while trying to comprehend PowerShell administrator nomenclature.

To that end, I thought in this piece that I would attempt to help at least those in the systems administrator camp by explaining in plain English the primary PowerShell vocabulary terms. Let’s get started, shall we?

The cmdlet

The cmdlet (pronounced COMMAND-let) is the basic building block of Windows PowerShell. When you install PowerShell 2.0 on a Windows system, you receive by default the core library of PowerShell cmdlets. As you probably know, Microsoft has invested heavily in PowerShell technology. Therefore, most Microsoft server technologies ship with their own custom PowerShell modules. Examples of first-party extension modules include Active Directory, SQL Server 2008, SharePoint Server 2010 and Exchange Server 2010.

Regardless of their source, all cmdlets are designed (1) using a consistent usage rubric; and (2) to accomplish a single, specific task. Take a look at the following exhibit, and we’ll break down the constituent parts and pieces of a typical PowerShell command:

PowerShell Tutorial - cmdlet Components

The PowerShell cmdlet and its components

Cmdlets always consist of a verb-noun compound phrase separated by a hyphen; this is done by design in order to make remembering PowerShell commands easy and intuitive. In the previous example, Get-ChildItem, the Get (verb) part of the command directs the action; in this case, to retrieve data. The ChildItem (noun) part of the command provides the focus for the verb; in the example, to obtain a directory listing.

NOTE: Cmdlets are completely case IN-sensitive. Therefore, the statements get-childitem, Get-ChildItem, and GET-CHILDITEM are all equivalent in practice.

You will discover that PowerShell uses many of the same verbs regardless of the origin or context of a particular PowerShell cmdlet:

  • Get
  • Set
  • Add
  • Remove
  • Clear
  • Enable
  • Disable
  • Start
  • Restart
  • Resume
  • Stop

Please check out the nifty A-Z Index of Windows PowerShell 2.0 Commands for an alphabetical list of the built-in Windows PowerShell v2.0 cmdlet library.

Most PowerShell cmdlets support one or more parameters and arguments. A parameter represents additional data that is passed into a cmdlet to customize its operation. In PowerShell nomenclature, a named parameter is the parameter name followed by an argument. While most named parameters are prepended with a hyphen (-), not all are.

Moreover, not all cmdlets require an argument to accompany a parameter; these are called positional parameters because all that is required is the name of the cmdlet and the name of the parameter issued the proper order.

You can instruct PowerShell to list the full syntax of any available cmdlet by typing get-help cmdletname from the PowerShell prompt.

In case you haven’t picked this up from context, an argument is nothing more than a value that is passed to a parameter. In the current example, the Get-ChildItem cmdlet, which functions identically to the old DOS dir command, requires that you pass an argument (namely, the filespec for which you need a directory listing) to the cmdlet. In this case, -path is a positional parameter and can safely be omitted; thus, the statements Get-ChildItem –path C:\Tools and Get-ChildItem C:\Tools are synonymous.

The Pipeline

One of the most powerful aspects of Windows PowerShell (besides the fact that its command set has its roots in the all-pervasive .NET Framework, that is), is what is called the pipeline. Those of you who are already masters of *NIX shell scripting are already familiar with the pipeline, but for us Windows administrators, give a listen.

In PowerShell, piping refers to the process of passing the results of one cmdlet as an argument into a second cmdlet. Therefore, the pipeline enables us to create compound cmdlet sequences that perform multiple tasks in a single operation. Take a look at the following example:

PowerShell tutorial - pipeline

The PowerShell pipeline

In the previous example, we “chain” together three PowerShell cmdlets by using the pipe (|) character. The net result in this case is that we receive a nifty, formatted list of our Windows services, organized by their run status. Pretty cool, eh?


There is so much more to Windows PowerShell for us systems administrators that I have had space or time to devote to in this brief article. In the second installment of this two-part miniseries, Windows PowerShell Terminology for Administrators: Part 2 of 2, I will cover two additional basic PowerShell terms: Alias and PowerShell Drive.

If there are other PowerShell-related topics that on which you would like to see coverage here at 4sysops, then please leave your request in the comments. Thanks!

Update: Also check out our new PowerShell tutorial about managing Services by PowerShell MVP Jeff Hicks.

  1. Jarred Fehr 12 years ago

    I think it is beneficial to point out that the the noun portion is always singular (i.e. Service not Services). Get-Service will list all Services.

    Looking forward to more on this series.

  2. Timothy Warner 12 years ago

    Hey Jarred,

    Point well taken–thanks for bringing that up. I’m working on some additional installments to this series that move from theory into practice with PowerShell. We’ll see several practical usage examples that should be helpful to you and other Windows systems administrators.

    Take care,

  3. alex kelly 12 years ago

    I would like something that expands on the pipeline input/output:

    – The different types of data that cmdlets can accept
    – How to query cmdlets to see what data they accept
    – What data cmdlets output

    I have been studying powershell and this is a area im still not comfortable with and im sure there are more like me.

  4. Timothy Warner 12 years ago

    Hi Alex,

    Noted! You’d like to query metadata about PowerShell cmdlets. Thanks for the suggestion.


Leave a reply

Please enclose code in pre tags

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account