What is PowerShell?
PowerShell is (and will remain to be) used
in most of Microsoft’s current line of server products. Although basic administrative tasks can
usually be performed through a GUI, administrators must often delve into
PowerShell to make infrastructure level configuration changes. While this certainly does not hold true in
every case, it is becoming more and more common to have to perform tasks using PowerShell.
But What is PowerShell?
PowerShell is the Microsoft Command Line Interface (CLI) for Windows based
systems, products and the automation framework.
It consists of a command-line shell/editor (Input) and a scripting
language that is built on top of the .NET Framework.
PowerShell provides full command-line access to the component object model (COM), data stores
(such as the registry and the file system) and Windows Management
Instrumentation (WMI). It enables the performing of administrative tasks on both
local and remote Windows systems undertaken by suitably qualified technicians
or systems administrators.
PowerShell includes (but is not limited to):
- Cmdlets for system administration tasks such as:
- Managing the registry
- Managing services, processes and event logs
- Cmdlets that use common syntax and naming conventions (data can be shared; with the output from one cmdlet being used as the input to another cmdlet.)
- Powerful object manipulation capabilities.
- Extensible interface. Enterprise developers and/or administrators can build custom cmdlets or tools and utilities to administer software.
- System.Diagnostics.Process object.
- System.IO.FileInfo object.
- System.String object, or
- any .NET object whose assembly is loaded into PowerShell including custom .NET objects
- cmdlets
- PowerShell scripts
- PowerShell functions
- Standalone executable programs
If a command is a standalone executable program “PowerShell.exe” launches
in a separate process.
If it is a cmdlet, it is executed within the PowerShell process.
Why use PowerShell?
The extent to which software/product
administration (of any kind) requires PowerShell (and by extension PowerShell
knowledge) is intended to protect less experienced (or less knowledgeable) “administrators”
from making “novice or simple” (often destructive) mistakes.
A basic administrative task can normally
be performed through a products management console, but for many Microsoft server
products, low level installation and/or configuration changes, and potentially
destructive operations have to be performed through PowerShell.
It is presumed that “if an administrator knows enough to use a relevant PowerShell cmdlet”,
then that person should know enough to safely perform the intended action and
understand the expected outcome whilst mitigating any business risk.
In summary: performing an administrative
task using PowerShell requires knowledge and intent and a deep founded interest
and understanding of the expected outcome and potential business risk.
PowerShell: A History Lesson
Let us take a trip down PowerShell lane and revisit the versions and the main features introduced in each version.
A Long Time Ago, in a Developers
Conference Far, Far Away
PowerShell (as we now know it) was publicly revealed at the
Professional Developers Conference (Los Angeles) in October 2003. Code named
"Monad", all major releases since are still supported with full
backwards compatibility. Following the
public reveal, the first public beta release occurred on June 17, 2005, Beta 2
on September 11, 2005, and Beta 3 on January 10, 2006.
On April 25, 2006 Microsoft formally announced that
"Monad" had been renamed "Windows PowerShell" followed
quickly by Release Candidate 1.
PowerShell Version 1.0
Release Candidate 2 of PowerShell version 1.0 was released on
September 26, 2006 with final RTW on November 14, 2006 for Windows XP SP2,
Windows Server 2003 and Windows Vista.
PowerShell Version 2.0
PowerShell Version 2.0 was (still is) integrated with Windows 7 and
Windows Server 2008 R2 and was released for Windows XP with Service Pack 3,
Windows Server 2003 with Service Pack 2, and Windows Vista with Service Pack 1.
PowerShell 2.0 included changes to the scripting language and
hosting API, in addition to including more than 240 new cmdlets.
New features of PowerShell 2.0 included:
- PowerShell Remoting
- Background Jobs
- Transactions
- ScriptCmdlets
- Modules
- Script Debugging
- Windows PowerShell Integrated Scripting Environment (ISE)
- Exception Handling with Try-Catch-Finally
- Block Comments
- Modules - allows script developers and administrators to partition PowerShell scripts in self-contained, reusable units. Code from a module executes in its own self-contained context and does not affect the state outside the module. Modules have a persistent state as well as public and private members.
- ISE - a GUI-based PowerShell host that provides integrated debugger, syntax highlighting, tab completion in a tabbed UI, as well as the ability to run only the selected parts in a script.
PowerShell Version 3.0
PowerShell Version 3.0 is integrated with Windows 8 and with Windows
Server 2012. It is also available for Windows 7 with Service Pack 1, Windows
Server 2008 with Service Pack 1, and for Windows Server 2008 R2 with Service
Pack 1.
PowerShell 3.0 is part of the Windows Management Framework (WMF) 3.0,
which also contains the Windows Remote Management (WinRM) service to support
PowerShell remoting.
New features in PowerShell 3.0 included:
- Job Scheduling
- Session connectivity
- IntelliSense and Snippets
- Help update
- Automatic module detection
PowerShell Version 4.0
PowerShell Version 4.0 is integrated with Windows 8.1 and with
Windows Server 2012 R2. It has also been made available for Windows 7 SP1,
Windows Server 2008 R2 SP1 and Windows Server 2012.
New features in PowerShell 4.0 included:
- Desired State Configuration
- Default Execution Policy set to RemoteSigned
- Save-Help
- Enhanced debugging
PowerShell Version 5.0
An initial public preview of PowerShell 5.0 was made available with
Windows Management Framework 5.0 (WMF5) on April 3, 2014.
On November 18th, 2014, Microsoft released the November 2014 Preview
of the Windows Management Framework Core 5.0 package. Improvements were made to
Desired State Configuration (DSC), OneGet, PowerShellGet, PowerShell class
definitions, and debugging for PowerShell background jobs.
New features in PowerShell 5.0 include:
- PowerShell class definitions (properties, methods)
- PowerShell .NET Enumerations
- Debugging for PowerShell Runspaces in remote processes
- Debugging for PowerShell Background Jobs
- Desired State Configuration (DSC) Local Configuration Manager (LCM) version 2.0
- DSC partial configurations
- DSC Local Configuration Manager meta-configurations
- Authoring of DSC resources using PowerShell classes
Basic Command Syntax
PowerShell is based around the use of
cmdlets.
Each cmdlet is constructed in a “verb –
noun” combination. The verb component
refers to a word that describes an action to be undertaken, whilst the noun
component refers to the object. With
that understanding, a PowerShell cmdlet is made up of two words, the first word
(the verb) tells Windows what action you want to perform, while the second word
(the noun) tells Windows what type of object you want to perform the action on.
Consider the following command:
Clear-Host
The verb (or action) in this case is “Clear”.
What needs to be cleared (the Object)? The
“host”.
This command will clear the screen
back to the command prompt (in the PowerShell window).
To find a list of default PowerShell Verbs enter the following in a PowerShell console window:
To find a list of default PowerShell Verbs enter the following in a PowerShell console window:
Get-Verb
The verb (or action) in this case is “Get”.
What needs to be returned? a list of accepted verbs thus the noun is “Verb”.
PowerShell
vs DOS (Showing your Age)
If (like me) you grew up with MS-DOS, most of
the old DOS commands work in a PowerShell environment. For example, the DOS command
for clearing the screen was CLS. The CLS command can be used in PowerShell as
an alternative(Alias) to the Clear-Host command.
There are many other PowerShell cmdlets that have a recogniseable Alias.
To find a list of default PowerShell cmdlets with an Alias enter the following in a PowerShell console window:
There are many other PowerShell cmdlets that have a recogniseable Alias.
To find a list of default PowerShell cmdlets with an Alias enter the following in a PowerShell console window:
Get-Alias
The verb (or action) in this case is “Get”.
What needs to be returned? a list of Aliases “Alias”.
Summary – The Ripple Effect
The Ripple Effect is based on the understanding that we are all
connected. These connections stretch like an incredibly interwoven and
complicated tapestry. Each of us exists within this tapestry. Thoughts and
actions are like stones dropped in a pond and they create ripples that travel
outward.
Now extend that into the world of PowerShell. Every action (be it,
cmdlets or scripts) we undertake and the affects those actions have can cause a
reaction – an orchestrated change (it is better planned than unplanned) within a
controlled environment. The nature of
PowerShell means that many differing products and technologies can be
administered via a PowerShell session.
These sessions can cross boundaries, can provide remote administration
in place of actually needing to be present in front of a hardware or software
platform. These actions are informed choices
made by a suitably experienced administrator that can have huge impacts and
risks to a business, but are still under the control of the administrator to “press
the execute” button.
How Many Cmdlets?
Windows Server
2012 R2 has many PowerShell cmdlets built into the operating system. PowerShell
is fully extensible - You can even develop your own custom cmdlets. Microsoft also provides modules that add
additional PowerShell cmdlets that allow you to perform more specialised tasks.
Microsoft server products based around PowerShell also have their own sets of
cmdlets. The sheer number of PowerShell
cmdlets is vast.
Next Time...
Next time we will create our first splash in this ever increasing "body of Water"Thanks for Reading
Mark
