PowerShell tutorial for admins – Part 1: cmdlets and pipeline

In part 1 of this PowerShell tutorial for Windows admins you will learn about the cmdlet and pipeline concepts.

Timothy Warner By Timothy Warner - Thu, June 16, 2011 - 4 comments

Timothy Warner is a Windows systems administrator, software developer, author, and technical trainer based in Nashville, TN.

Articles in this series

PowerShell Tutorial

Contents of this article
  1. The cmdlet
  2. The Pipeline
  3. Conclusion

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?

Conclusion

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.

Series Navigation - PowerShell tutorial for admins – Part 2: Aliases and drives

-1+1 - Rate this post
Loading ... Loading ...
Disclaimer
Your question wasn't answered? Please ask in the new 4sysops forum!

4 Comments- Leave a Reply

  1. Jarred Fehr says:

    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. 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,
    Tim

  3. alex kelly says:

    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. Hi Alex,

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

    -Tim

Please share your thoughts in a comment!

Login

Lost your password?