PowerShell - Introducing the “Body of Water”

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.

Output from a PowerShell cmdlet is always a .NET object. This could be a:

• 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

Windows PowerShell can execute four kinds of commands:

• 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:

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:

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