PowerShell tutorial for admins – Part 1: cmdlets and pipeline

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
• Use Azure Storage for backup - Thu, Feb 23 2023
• Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023

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:

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:

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.