Book Image

PowerShell Troubleshooting Guide

By : Mike Shepard
Book Image

PowerShell Troubleshooting Guide

By: Mike Shepard

Overview of this book

Table of Contents (15 chapters)
PowerShell Troubleshooting Guide
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Cmdlets


In PowerShell, a cmdlet (pronounced "command-let") describes a unit of functionality specific to PowerShell. In version 1.0 of PowerShell, the only way to create a cmdlet was by using managed (compiled) code, but 2.0 introduced advanced functions, which have the same capabilities as cmdlets. Built-in cmdlets exist to interact with the filesystem, services, processes, event logs, WMI, and other system objects. Some examples of cmdlets, which also show the flexibility in parameter passing, are shown as follows:

  • Get-ChildItem "c:\program files" –include *.dll –recurse: This cmdlet outputs all .dll files under c:\program files

  • Get-EventLog Application –newest 5: This cmdlet outputs the five most recent entries in the Application event log

  • Set-Content –path c:\temp\files.txt –value (dir c:\): This cmdlet writes a directory listing to a text file

Cmdlets are named with a two-part construction: verb-noun. Verbs in PowerShell describe the actions to be performed and come from a common list provided by Microsoft. These include Get, Set, Start, Stop, and other easy-to-remember terms. The Get-Verb cmdlet provides the list of approved verbs with some information on how the verbs can be grouped. The following screenshot shows the beginning of the list of verbs and their corresponding groups:

PowerShell nouns specify on which kind of objects the cmdlet operates. Examples of nouns are Service, Process, File, or WMIObject Unlike the list of verbs, there is no managed list of approved nouns. The reason for this is simple. With every new version of Windows, more and more cmdlets are being delivered which cover more and more of the operating system's features. An up-to-date reference for verbs along with guidance between similar or easily confused verbs can be found at http://msdn.microsoft.com/en-us/library/ms714428.aspx.

Putting nouns and verbs together, you get full cmdlet names such as Get-Process and Start-Service. By providing a list of verbs to choose from, the PowerShell team has gone a long way toward simplifying the experience for users. Without the guidance of a list such as this, cmdlet authors would often be forced to choose between several candidates for a cmdlet name. For instance, Stop-Service is the actual cmdlet name, but names such as Kill-Service and Terminate-Service would both convey the same effect. Knowing that Stop is the approved verb not only makes the decision simple, it also makes it simple to guess how one would terminate a process (as opposed to a service). The obvious answer would be Stop-Process.

Cmdlets each have their own set of parameters that allow values to be supplied on the command line or through a pipeline. Switch parameters also allow for on/off options without needing to pass a value. There is a large set of common parameters that can be used with all cmdlets. Cmdlets that modify the state of the system also generally allow the use of the –Whatif and –Confirm risk mitigation parameters. Common parameters and risk mitigation parameters are covered in detail in Chapter 5, Proactive PowerShell.

The big three cmdlets

When learning PowerShell, it's customary to emphasize three important cmdlets that are used to get PowerShell to give information about the environment and objects that are returned by the cmdlets. The first cmdlet is Get-Command. This cmdlet is used to get a list of matching cmdlets, scripts, functions, or executables in the current path. For instance, to get a list of commands related to services, the Get-Command *service* command would be a good place to start. The list displayed might look like this:

The thought behind listing Get-Command as the first cmdlet you would use is that it is used to discover the name of cmdlets. This is true, but in my experience you won't be using Get-Command for very long. The verb-noun naming convention combined with PowerShell's very convenient tab-completion feature will mean that as you get familiar with the language you will be able to guess cmdlet names quickly and won't be relying on Get-Command. It is useful though, and might show you commands that you didn't know existed. Another use for Get-Command is to figure out what command is executed. For instance, if you encountered the Compare $a $b command line and didn't know what the Compare command was, you could try the Get-Command command to find that Compare is an alias for Compare-Object.

Note

PowerShell provides aliases for two reasons. First, to provide aliases that are commands in other shells (such as dir or ls), which lead us to PowerShell cmdlets that perform similar functions. Secondly, to give abbreviations that are shorter and quicker to type for commonly used cmdlets (for example, ? for Where-Object and gsv for Get-Service). In the PowerShell community, a best practice is to use aliases only in the command line and never in scripts. For that reason, I will generally not be using aliases in example scripts.

A similar trick can be used to find out where an executable is found: Get-Command nslookup | Select-Object Path returns the path C:\Windows\system32\nslookup.exe.

The second and probably most important cmdlet is Get-Help. Get-Help is used to display information in PowerShell's help system. The help system contains information about individual cmdlets and also contains general information about PowerShell-related topics. The cmdlet help includes syntax information about parameters used with each cmdlet, detailed information about cmdlet functionality, and it also often contains helpful examples illustrating common ways to use the cmdlet.

Tip

Pay attention to the help files. Sometimes, the problem you are having is because you are using a cmdlet or parameter differently than the designer intended. The examples in the help system might point you in the right direction.

The following screenshot shows the beginning of the help information for the Get-Help cmdlet:

Another source of information in the help files are topics about the PowerShell language. The names of these help topics start with about_, and range from a few paragraphs to several pages of detailed information. In a few cases, the about_ topics are more detailed than most books' coverage of them. The following screenshot shows the beginning of the about_Language_Keywords topic (the entire topic is approximately 13 pages long):

The Get-Help cmdlet has a number of switches that control precisely what help information is displayed. The default display is somewhat brief and can be expanded by using the –Full or –Detailed switches. The –Examples switch displays the list of examples associated with the topic. The full help output can also be viewed in a pop-up window in PowerShell 3.0 or higher using the –ShowWindow switch.

Tip

PowerShell 3.0 and above do not ship with any help content. To view help in these systems you will need to use the Update-Help cmdlet in an elevated session.

The final member of the big three is Get-Member. In PowerShell, all output from commands comes in the form of objects. The Get-Member cmdlet is used to display the members (for example, properties, methods, and events) associated with a set of objects as well as the types of those objects. In general, you will pipe objects into Get-Member to see what you can do with those objects. An example involving services is shown as follows: