PowerShell is powered by commands.
Commands get things done. There are four basic types of commands:
cmdlets, functions, scripts, and native commands. It is not necessarily
important to know the differences between these command types to work
with PowerShell and SharePoint, but it doesn’t hurt.
Cmdlets
Cmdlets (pronounced command-lets) are
compiled commands that are installed and registered with PowerShell;
they are all named using a verb-noun combination. To make them easy to
remember, the noun part of a PowerShell cmdlet is always singular. The
verb portion of the name should be one of the PowerShell acceptable
verbs. Because the verbs are “standardized,” you can usually guess the verb portion of the cmdlet. An example of a cmdlet is New-SPWebApplication, which has a corresponding Remove-SPWebApplication.
Although you might have expected the verb “delete” to delete a
SPWebApplication, “delete” is not one of the standardized verbs, so it
cannot be used.
As you might have already guessed, the SharePoint
commands that we will be using are cmdlets. You saw that SharePoint
installed the cmdlets on the server, and the Management Shell
registered them with the host using the PSC1 file; and you now know how
to manually register them in the ISE.
SPEED TYPING
As you’ll soon discover, some PowerShell
cmdlet’s names can get rather long; and even after you’ve typed all
that, you still need to add parameter names. As admins, we are
accustomed to clicking “Next” buttons; we’re not ready for all this
typing. PowerShell has our back, though, supporting “tab completion.”
Once you start typing a cmdlet’s name, or one of its parameters, you
can press the Tab key and PowerShell will start cycling through all the
cmdlets, parameters, or methods that are available based on what you
have entered. This helps you save time and avoid typing out those long
PowerShell lines more quickly. It also helps if you’ve forgotten a
cmdlet or parameter name. For a cmdlet, just type part of the name and
then start pressing the Tab key. Parameters are even easier; just type
a hyphen (-) and then start pressing Tab. PowerShell will cycle through
all the parameters for that cmdlet. Pretty spiffy.
Functions
Functions are made up of a command or a
series of commands that are intended to be reusable for performing a
task multiple times within the same script. Functions can accept
parameters (variables that are passed to the function at the time the
function is called), which enables the same code to be executed with
different parameters each time. This provides the benefit of reducing
the amount of duplicate code in a script. Functions are defined in
PowerShell by typing the function into the host. PowerShell then parses
the function and verifies the syntax. Functions can be reused for the
lifetime of the host session. If you close the host then you lose the
function, and you will need to enter it again when you start another
session with the host. You can enter functions into your profile so
they will be available whenever you start a session.
NOTE There’s
nothing worse than working on an award-winning function only to lose it
when you shut down the host. Consider yourself warned and save your
function in your profile or at least to a text file so you can copy it
later. A great way to protect yourself against this calamity is to run
the Start-Transcript cmdlet each time you open PowerShell. Start-Transcript creates
a text file that’s a transcript of everything that happens in that
PowerShell session. If you run this every time you use PowerShell,
you’ll never lose that important function that will finally gain you
the richly deserved admiration of your co-workers.
Functions have their place and are great for
containing code that you want to call from various other scripts or
commands, but space limitations prevent an in-depth treatment of them
here.
Scripts
PowerShell scripts are made up of a mix
of commands, functions, loops, decision trees, user input/output —
basically all the methods available to PowerShell for creating reusable
code with program-like functionality. General SharePoint administration
will commonly result in the use of “one-liners,” whereas scripts are
generally reserved for larger-scale repetitive tasks, such as an
automated installer for SharePoint if you find yourself doing that a
lot. Aside from the amount of code involved, a primary difference
between a script and a one-liner is that scripts are saved to a text
file with a .PS1 file extension. Later you can run the script by typing in the filename.
Scripts, in contrast to functions or PowerShell
snap-ins, survive the host shutdown and can easily be recalled. Another
great benefit of the script is that once a script is created and
tested, it can be saved to a script library and reused. By default,
hosts do not run unsigned scripts. This is to protect you from
accidentally running scripts that have the same name as common
commands. In addition, hosts will warn you if you attempt to run a
script that has not been signed. This prevents you from executing a
script that has been modified to do something malicious, such as
replacing all your SharePoint backups with pictures of the world’s
ugliest dog. You can modify the security setting using the cmdlet Set-ExecutionPolicy.
Because you can accomplish so much using the SharePoint cmdlets. Scripts are only
necessary if you want to chain together a complicated series of cmdlets
or walk through complicated loops.
NOTE For security reasons, the PowerShell application is not associated with .PS1 files. The default application associated with .PS1 files is Notepad, so double-clicking a .PS1 file
will open the file in Notepad. This effectively prevents users from
double-clicking a malicious script and running it accidentally. If you
change the file association, which is not recommended, you run the risk
of inadvertently running a malicious script. While this might seem very
inconvenient, there were some very dark days when hackers were using
VBScript to compromise machines. Microsoft wants to ensure that
PowerShell is only used for good, not evil.
Native Commands
Native commands are commands that run
outside of the host process, such as notepad.exe or stsadm.exe. These
commands can still be called from within the commands or scripts that
you execute in the PowerShell host. This provides useful functionality
that may not be provided by PowerShell directly. For example, suppose
your script were logging information to a .txt file, and at the end of the execution you wanted to display that .txt
file automatically. You could add a line such as the following to the
end of your script to automatically launch Notepad.exe in its own
process and display your log file:
Notepad.exe "MyLog.txt"
