PowerShell Troubleshooting Guide

Michael Shepard

Chapter No 1
"PowerShell Primer"

In this package, you will find:

The authors biography
A preview chapter from the book, Chapter no.1 "PowerShell Primer"
A synopsis of the books content
Information on where to buy this book

About the Author

Michael Shepard has been working with computers since the early '80s, starting with
an Apple II in school and a Commodore 64 at home. He started working in the IT
industry in 1989 and has been working full-time since 1997. He has been working at
Jack Henry & Associates, Inc. since 2000. His focus has changed over the years from
being a database application developer to a DBA, an application admin, and is now a
solutions architect. In his years as a DBA, he found PowerShell to be a critical
component in creating the automation required to keep up with a growing set of
servers and applications. He is active in the PowerShell community at Stack Overflow
and projects at CodePlex. He has been blogging about PowerShell since 2009 at
.
I'd like to thank my employer, Jack Henry & Associates, Inc., for
allowing me the freedom over the last few years to both learn and
teach PowerShell. My wonderful wife, Stephanie, and my children,
Simeon and Gwen, also deserve thanks for humoring me when I can't
stop talking about PowerShell, and for giving me some breathing
room to write.

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Troubleshooting Guide

PowerShell Troubleshooting Guide uses easy-to-understand examples to explain the
PowerShell language, enabling you to spend more of your time writing code to solve
the problems you face and less time agonizing over syntax and cryptic error messages.
Beginning with the foundations of PowerShell, including functions, modules, and the
pipeline, you will learn how to leverage the power built into the language to solve
problems and avoid reinventing the wheel. Writing code in PowerShell can be fun,
and once you've learned the techniques in this book, you will enjoy PowerShell more
and more.

What This Book Covers

Chapter 1, PowerShell Primer, provides a brief introduction to some of the most
important entities in the PowerShell language including cmdlets, functions, scripts, and
modules. A special emphasis is placed on the importance of the pipeline in
PowerShell operations.
Chapter 2, PowerShell Peculiarities, includes a number of features of the
PowerShell language, which are unusual when compared with other mainstream
programming languages. Examples of these topics are output from functions and
non-terminating errors.
Chapter 3, PowerShell Practices, shows a few ways that the scripting experience in
PowerShell can be improved, either in performance or in maintainability. A lengthy
discussion of the various output cmdlets is included.
Chapter 4, PowerShell Professionalism, gives examples of practices that might not be
as familiar to traditional system administrators but are common among professional
developers. These practices will help scripters create more reliable products and be
more confident when making changes to existing codebases.
Chapter 5, Proactive PowerShell, presents a number of practices that, when applied to
code, will result in more flexible code with fewer bugs. In a sense, this is pre-emptive
troubleshooting, where we create our code thoughtfully in order to reduce the need for
troubleshooting later.

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Chapter 6, Preparing the Scripting Environment, covers the idea of knowing the
characteristics of the environment in which your scripts are running. We also spend
some effort trying to weed out network connectivity issues.
Chapter 7, Reactive Practices Traditional Debugging, shows how to perform
traditional troubleshooting in PowerShell using the debugging features of the console
and the ISE, along with other techniques. It wraps up with an example of how using
the wrong PowerShell feature to perform an operation can lead to poor performance.
Chapter 8, PowerShell Code Smells, explains the concept of code smells (signs of poorly
implemented code) and compares it with antipatterns, best practices, and technical debt.
It then shows some ways that PowerShell code might begin to smell.

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Primer
This chapter will give you a very brief overview of the main features of the
PowerShell language. By the end of the chapter, you will be familiar with the
following topics:

Cmdlets
Functions
Scripts
Pipelines
Variables
Modules

Introduction
Windows PowerShell (or just PowerShell, for short) was introduced by Microsoft
in late 2006 accompanied by little fanfare. In the last seven years, PowerShell has
gone from being what might have seemed like a research project to what is now
the mainstay of Windows automation and is included in every Windows operating
system and most of the major Microsoft products including Exchange, System
Center, SQL Server, SharePoint, and Azure.
PowerShell is often thought of as a command-line language, and that is an
accurate (but incomplete) view. Working on the command line in PowerShell is a
joy compared to MS-DOS batch files and most of the command-line tools that IT
professionals are used to having at their fingertips work with no changes in the
PowerShell environment. PowerShell is also a first-class scripting language where
the knowledge you gain from the command line pays off big time. Unlike MS-DOS,
PowerShell was designed from the beginning to be a powerful tool for scripting.
Unlike VBScript, there is an interactive PowerShell console that allows you to
iteratively develop solutions a bit at a time as you work your way through
a sequence of objects, methods, and properties.
For More Information:
www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Primer

PowerShell includes several different elements that work together to create a very
powerful and flexible ecosystem. While this chapter will give you an overview of
several of these pieces, be aware that the PowerShell language is the subject of many
books. For in-depth coverage of these topics, refer to PowerShell In Practice by Don
Jones, Jeffery Hicks, and Richard Siddaway, Manning Publications.

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:

[8]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Chapter 1

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.

[9]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Primer

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.
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 GetService). 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.

[ 10 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Chapter 1

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 PowerShellrelated 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.
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 GetHelp cmdlet:

[ 11 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Primer

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.
PowerShell 3.0 and above do not ship with any help content. To
view help in these systems you will need to use the UpdateHelp cmdlet in an elevated session.

[ 12 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Chapter 1

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:

Functions
Functions are similar to cmdlets and should follow the same naming conventions.
Whereas cmdlets are compiled units of PowerShell functionality written in managed
code like C#, functions are written using the PowerShell language. Starting with
PowerShell 2.0, it has been possible to write advanced functions, which are very
similar to cmdlets. It is possible to use common parameters and risk mitigation
parameters with advanced functions. An example of a function is shown as follows:
function get-PowerShellVersionMessage{
param($name)
$PowerShellVersion=$PSVersionTable.PSVersion
return "We're using $PowerShellVersion, $name!"
}
[ 13 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Primer

Calling the function at the command line is straightforward, as shown in the

following screenshot:

Scripts
Scripts are simply files with a .ps1 file extension, which contain PowerShell code.
It is possible to parameterize a script file in the same way that you would a function
using a Param() statement at the beginning of the file. If we were to store the
following code in a file called Get-PowerShellVersionMessage.ps1, it would be
roughly equivalent to the Get-PowerShellVersionMessage function in the
previous section:
param($name)
$PowerShellVersion=$PSVersionTable.PSVersion
return "We're using $PowerShellVersion, $name!"

A security feature of PowerShell is that it won't run a script in the current directory
without specifically referring to the directory, so calling this script would look
like this:
.\get-powershellversionmessage name Mike

The following screenshot shows the aforementioned code being stored in a file:

[ 14 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Chapter 1

And the output would be (on the computer I'm using): We're using
PowerShell 4.0, Mike.
Depending on your environment, you might not be able to run scripts
until you change the execution policy. The execution policy dictates
whether scripts are allowed to be executed, where those scripts can
be located, and whether they need to be digitally signed. Typically, I
use set-executionpolicy RemoteSigned to allow local scripts
without requiring signatures. For more information about execution
policies, refer to about_execution_policies.

It is also possible to define multiple functions in a script. However, when doing

so, it is important to understand the concept of scope. When a script or function
is executed, PowerShell creates a new memory area for definitions (for example,
variables and functions) that are created during the execution. When the script or
function exits, that memory is destroyed, thereby removing the new definitions.
Executing a script with multiple functions will not export those functions into the
current scope. Instead, the script executes in its own scope and defines the functions
in that scope. When the script execution is finished, the newly created scope is
exited, removing the function definitions. To overcome this situation, the dot-source
operator was created. To dot-source a file means to run the file, without creating a
new scope in which to run. If there was a script file with function definitions called
myFuncs.ps1, dot-sourcing the file would use the following syntax:
. .\myFuncs.ps1

Note that there is a space after the first dot, and that since the script is in the current
directory explicit use of the directory is required.

Pipelines
PowerShell expressions involving cmdlets and functions can be connected together
using pipelines. Pipelines are not a new concept, and have been in DOS for a long
time (and in Unix/Linux forever). The idea of a pipeline is similar to a conveyor
belt in a factory. Materials on a conveyor belt move from one station to the next as
workers or machinery work on the materials to connect, construct, or somehow
modify the work in progress. In the same way, pipelines allow data to move from
one command to the next, as the output of one command is treated as the input
for the next. There is no practical limit to the number of commands that can be
connected this way, but readability does keep command lines from continuing
forever. It can be tempting to string more and more expressions together to create
a single-line solution, but troubleshooting a pipeline evaluation can be tricky.

[ 15 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Primer

When working with long pipeline constructions, consider

breaking the line into several expressions to make the
execution clearer.

Prior to PowerShell, pipelines dealt with output and input in terms of text, passing
strings from one program to the next regardless of what kind of information was
being processed. PowerShell makes a major change to this paradigm by treating all
input and output as objects. By doing this, PowerShell cmdlets are able to work with
the properties, methods, and events that are exposed by the data rather than simply
dealing with the string representation. The PowerShell community often refers to the
methods used by string-based pipelines as parse-and-pray, which is named after the
twin operations of string parsing based on an understanding of the text format and
hoping that the format of the output doesn't ever change. An example, shown in the
following screenshot, illustrates this quite well:

It's easy to think of the output of the MS-DOS dir command as a sequence of files
and folders, but if the output is carefully studied, something different becomes clear.
There is a tremendous amount of other information provided:

Volume information

Volume serial number

A directory-level caption

A list of files and folders

A count of files
[ 16 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Chapter 1

The total size of those files

The number of directories

The space free on the drive

To work with this output and deal with, for instance, the file names, there's a
tremendous amount of work that would need to be done to analyze the formatting of
all of these elements. Also, there are several different formatting parameters that can
be used with the MS-DOS dir command that would affect the output. By passing
data between cmdlets as objects, all of this work is eliminated. The PowerShell
Get-ChildItem cmdlet, which is similar to the MS-DOS dir command, outputs a
sequence of file and directory objects if the current location is a filesystem location.

How pipelines change the game

To see how the choice of an object-oriented pipeline changes the way work is done,
it is sufficient to look at the MS-DOS dir command. I am picking on the dir
command because it has a simple function and everyone in IT has some level of
experience with it. If you wanted to sort the output of a dir command, you would
need to know what the parameters built into the command are. To do that, you'd
do something like this:

[ 17 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Primer

It's clear that the designer of the command had sorting in mind, because there is a
/O option with five different ways to sort (ten if you include reverse). That is helpful,
but files have a lot more than five properties. What if you wanted to sort by more
than one property? Ignoring those questions for a moment, does the collection of
sorting options for this command help you at all if you were trying to sort the
output of a different command (say an ATTRIB or SET command)? You might hope
that the same developer wrote the code for the second command, or that they
used the same specifications, but you would be disappointed. Even the simple
operation of sorting output is either not implemented or implemented differently
by MS-DOS commands.
PowerShell takes an entirely different approach. If you were to look at the help for
Get-ChildItem, you would find no provision for sorting at all. In fact, PowerShell
cmdlets do not use parameters to supply sorting information. Instead, they use the
object-oriented pipeline. MS-DOS developers needed to encode the sort parameters
for the dir command inside the dir command itself is because that is the only
place that the properties exist (including sorting criteria). Once the command
has been executed, all that is left is text, and sorting text based on properties
is a complex parse-and-pray operation (which we have already discussed). In
PowerShell, however, the output of Get-ChildItem is a sequence of objects, so
cmdlets downstream can still access the properties of the objects directly. Sorting in
PowerShell is accomplished with the Sort-Object cmdlet, which is able to take a
list of properties (among other things) on which to sort the sequence of objects that
it receives as input. The following are some examples of sorting a directory listing in
MS-DOS and also in PowerShell:
Sorting method
Sort by filename

DOS
command
DIR /O:N

Sort by extension

DIR /O:E

Sort by size

DIR /O:S

Sort by write date

DIR /O:D

Sort by creation date

Out of
luck
Out of
luck

Sort by name and size

PowerShell equivalent
Get-childitem | sort-object Name
Get-ChildItem | Sort-object
Extension
Get-ChildItem | Sort-object Size
Get-ChildItem | Sort-object
LastWriteTime
Get-ChildItem | Sort-object
CreationTime
Get-ChildItem | Sort-object
Name,Size

[ 18 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Chapter 1

It can be clearly seen by these examples that:

PowerShell examples are longer

PowerShell examples are easier to read (at least the sorting options)

PowerShell techniques are more flexible

The most important thing about learning how to sort directory entries using SortObject is that sorting any kind of objects is done the exact same way. For instance,
if you retrieved a list of applied hotfixes on the current computer using Get-hotfix,
in order to sort it by HotFixID, you would issue the Get-Hotfix | Sort-Object
Property HotFixID command:

Another point to note about sorting objects by referring to properties is that the
sorting is done according to the type of the property. For instance, sorting objects by
a numeric property would order the objects by the magnitude of the property values,
not by the string representation of those values. That is, a value of 10 would sort
after 9, not between 1 and 2. This is just one more thing that you don't have to
worry about.

What's the fuss about sorting?

You might be asking, why is sorting such a big deal? You'd be correct; sorting is
not necessarily a tremendously important concept. The point is, the method that
the designers of PowerShell took with the pipeline (that is, using objects rather than
strings) that allows this sorting method also allows other powerful operations such
as filtering, aggregating, summarizing, and narrowing.

[ 19 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Primer

Filtering is the operation of selecting which (entire) objects in the pipeline will
continue in the pipeline. Think of filtering like a worker who is inspecting objects on
the conveyor belt, picking up objects that are bad and throwing them away (in the
bit bucket). In the same way, objects that do not match the filter criteria are discarded
and do not continue as output. Filtering in PowerShell is done via the Where-Object
cmdlet and takes two forms. The first form is somewhat complicated to look at, and
requires some explaining. We will start with an example such as the following:
Get-ChildItem | Where-object {$_.Size lt 100}

Hopefully, even without an explanation, it is clear that the output would be a list
of files that have a size less than 100. This form of the Where-Object cmdlet takes
a piece of code as a parameter (called a scriptblock), which is evaluated for each
object in the pipeline. If the script evaluates to true when the object in the pipeline
is assigned to the special variable $_, the object will continue on the pipeline. If it
evaluates to false, the object is discarded.
PowerShell 3.0 made a couple of changes to the Where-Object cmdlet. First, it added
an easier-to-read option for the $_ variable, called $PSItem. Using that, the previous
command can be rewritten as follows:
Get-ChildItem | Where-object {$PSItem.Size lt 100}

This is slightly more readable, but Version 3.0 also added a second form that
simplifies it even more. If the script block is referring to a single property, a single
operator, and a constant value, the simplified syntax can be used, shown as follows:
Where-Object Property Operator Value

Note that there are no braces indicating a scriptblock, and no $_ or $PSItem.

The simplified syntax for our sample filter command is this:
Get-ChildItem | Where-Object Size lt 100

Variables
PowerShell variables, similar to variables in other programming languages, are
names for data stored in memory. PowerShell variable references begin with a dollar
sign and are created by assigning a value with the assignment operator (the equals
sign). Unlike many programming languages, you do not need to define variables
before using them or even specify what type of information the variable is going to
point to. For instance, the following statements are all valid:
$var = 5
$anothervar = "Hello"
$files = dir c:\
[ 20 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Chapter 1

Note that while the first two assignments were simple (integer and string constants),
the third involved executing a pipeline (with a single statement) and storing the
results of that pipeline in a variable. The command in the third line returns a
collection of more than one kind of object (it has files and folders). Note that there is
no special notation required to store a collection of objects.
Several common parameters in PowerShell take the name of a variable in order to
store results of some kind in that variable. The ErrorVariable, WarningVariable,
OutVariable parameters, and (new in Version 4.0) PipelineVariable parameter
all follow this pattern. Also, all of the *Variable cmdlets have a Name parameter.
These parameters are expecting the name of the variable rather than the contents of the
variable. The name of the variable does not include the dollar sign. In the following
screenshot, you can see that the outvariable parameter was passed the file value,
which caused a copy of the output to be stored in the variable called file:

In short, referencing the content of the variable involves the dollar sign, but
referencing the variable name does not.

Modules
In Version 1.0 of PowerShell, the only ways to group lists of functions were to either
put script files for each function in a directory or to include several functions in a script
file and use dot-sourcing to load the functions. Neither solution provided much in
the way of functionality, though. Version 2.0 introduced the concept of modules. A
PowerShell module usually consists of a folder residing in one of the directories listed
in the PSModulePath environment variable and contains one of the following:

A module file (.psm1) with the same name as the folder

A module manifest (.psd1) with the same name as the folder

A compiled assembly (.dll) with the same name as the folder

[ 21 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

PowerShell Primer

One tremendous advantage that modules have over scripts is that while every
function in a script is visible when the script is run, visibility of functions (as well
as variables and aliases) defined within a module can be controlled by using the
Export-ModuleMember cmdlet.
The following module file, named TroubleShooting.psm1, re-implements the
Get-PowerShellMessage function from earlier in the chapter using a helper
function (Get-Message). Since only Get-PowerShellVersionMessage was exported,
the helper function is not available after the module is imported but it is available to
be called by the exported function.
function Get-Message{
param($ver,$name)
return "We're using $ver, $name!"
}
function Get-PowerShellVersionMessage{
param($name)
$version=$PSVersionTable.PSVersion
$message=Get-Message $version $name
return $message
}
Export-ModuleMember Get-PowerShellVersionMessage

Importing a module is accomplished by using the Import-Module cmdlet. Version

3.0 of PowerShell introduced the concept of automatic importing. With this feature
enabled, if you refer to a cmdlet or function that does not exist, the shell looks in
all of the modules that exist on the system for a matching name. If it finds one, it
imports the module automatically. This even works with tab-completion. If you hit
the Tab key, PowerShell will look for a cmdlet or function in memory that matches,
but If it doesn't find one it will attempt to load the first module that has a function
whose name matches the string you're trying to complete. Listing the cmdlets that
have been loaded by a particular module is as simple as the Get-Command Module
module name.

Further reading
For more information, check out the following references:

The Monad Manifesto at http://blogs.msdn.com/b/powershell/

archive/2007/03/19/monad-manifesto-the-origin-of-windowspowershell.aspx

[ 22 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Chapter 1

Microsoft's approved cmdlet verb list at http://msdn.microsoft.com/enus/library/ms714428.aspx

get-help get-command

get-help get-verb

get-help about_aliases

get-help get-member

get-help about_functions

get-help about_functions_advanced

get-help about_scripts

get-help about_execution_policies

get-help about_scopes

get-help about_pipelines

get-help where-object

get-help about_variables

get-help about_commonparameters

get-help about_modules

Summary
In this chapter, we have seen the main building blocks of PowerShell as a language.
We have demonstrated how similar functionality can be implemented using a
function, a script, and a module. An emphasis was placed on how PowerShell's
use of an object-oriented pipeline gives tremendous advantages in terms of
flexibility without re-implementing common features such as sorting and filtering
in each function.
PowerShell provides an innovative programming and scripting experience. The
next chapter will highlight various ways that the PowerShell language functions
differently from other programming languages.

[ 23 ]

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide

Where to buy this book

You can buy PowerShell Troubleshooting Guide from the Packt Publishing website:
.
Free shipping to the US, UK, Europe and selected Asian countries. For more information, please
read our shipping policy.

Alternatively, you can buy the book from Amazon, BN.com, Computer Manuals and
most internet book retailers.

www.PacktPub.com

For More Information:

www.packtpub.com/networking-and-servers/powershell-troubleshootingguide