As mentioned, PowerShell is a task automation platform for IT professionals and comes to you in two forms: Windows PowerShell and open source PowerShell (aka PowerShell 7).

In this chapter, any material specific to either version of PowerShell is noted as Windows PowerShell or PowerShell 7. But for the most part, almost everything you know about Windows PowerShell is useful in PowerShell 7. However, there are some differences and improvements.

Windows PowerShell versus PowerShell 7

PowerShell comes to you in two broad forms: Windows PowerShell and open source PowerShell (aka PowerShell 7). Microsoft first shipped Windows PowerShell as an add-on to Windows XP and developed the product significantly in later releases. The concept of Windows PowerShell began with the Monad Manifesto (https://packt.link/ZZHnW). This document provides a fascinating insight into the development of Windows PowerShell.

After the release of Windows 8.1 and Windows PowerShell 5.1, Microsoft transitioned the product into the open source PowerShell 7. Microsoft also transitioned .NET Framework to open source (aka .NET), which underpins PowerShell 7. Windows PowerShell is feature-complete, and it is highly unlikely that new features will be developed. PowerShell 7, on the other hand, is under active development.

Windows 11 comes with Windows PowerShell 5.1 fully installed. You have to install PowerShell 7 if you wish to use it.

Microsoft developed Windows PowerShell on top of the Microsoft .NET Framework. In many cases, Windows PowerShell is just a thin wrapper around .NET. PowerShell cmdlets leverage .NET.

Microsoft moved .NET Framework and Windows PowerShell into open source (with Microsoft funding while running the development teams). .NET Framework became simply .NET and Windows PowerShell became PowerShell 7. If you read old documentation, you may find that the first versions of open source PowerShell were known as PowerShell Core and version 6.x. For the most part, these were proof-of-concept implementations and are no longer supported.

Why does this matter, you may ask? There are a few reasons. First, by moving to .NET, the development team did not port every component of .NET Framework. If you manage your system today using Windows PowerShell, some of your scripts may not work. One example is the WSUS module, which you would normally use to manage Windows system update services. The cmdlets in this module use some APIs that Microsoft did not make available in .NET, so the cmdlets do not work and there is no direct workaround. The WSUS product team need to re-engineer their module to make the cmdlets function with PowerShell 7. Fortunately, the number of modules that do not work is very low. The Windows compatibility feature, described in the next section, resolves most of these compatibility issues.

If you are familiar with Windows PowerShell, you should be able to use it immediately. All the language constructs in Windows PowerShell carry over into PowerShell 7. All the core PowerShell cmdlets (that is, those that come with Windows PowerShell) are available in PowerShell 7. This means that almost all your scripts should work fine. From the console, all the commands you use in Windows PowerShell work fine too. In most cases, if you can use Windows PowerShell, you know how to use PowerShell 7.

There are also some key differences between Windows PowerShell and PowerShell 7, most of which are improvements.

The main differences lie in the new and updated features contained in PowerShell. Each version of PowerShell 7 has incorporated large numbers of changes and improvements. To find the specific changes that each new version incorporates, see https://packt.link/yPEPK.

Windows PowerShell compatibility solution

A challenge for PowerShell 7 is that most of the Windows PowerShell modules, which Microsoft has published, do not work natively In PowerShell 7. To enable you to use these commands within PowerShell 7, the PowerShell team has developed the WindowsPowerShell compatibility solution.

This solution involves creating a PowerShell remoting session for the local machine (using a Windows PowerShell 5.1 endpoint), loading the module into the remoting session, and then using implicit remoting to create local functions that call the remote cmdlets.

This solution works very well – all but three Microsoft Windows Server modules work fine using the compatibility solution. One small issue is that the display XML that Windows PowerShell uses to format the cmdlet output is not imported with this solution by default. You can, however, manually load this XML.

Although the compatibility solution does not provide 100% fidelity, it gets close. And even for those modules that you cannot use directly in PowerShell 7, you can use PowerShell remoting as a workaround. The scripts at https://packt.link/6w3FC show how you can install, configure, and manage WSUS using PowerShell 7.

Installing PowerShell 7

Windows PowerShell comes built into every edition of Windows 11 (and the related versions of Windows Server). Microsoft also uses Microsoft Update to keep Windows PowerShell fully up to date.

Microsoft does not currently ship PowerShell 7 inside any version of Windows, although it is easy for you to install the product.

There are several ways you can install PowerShell 7 in Windows 11.

The first method is via the Microsoft Store. From Windows 11, you can use Microsoft Store and search for PowerShell 7 like this:

Figure 2.1 – Installing PowerShell 7 via the Microsoft Store

You click the Get button and follow the prompts to install PowerShell 7 via the Store.

The second method, and possibly the more IT-pro-friendly method, involves using the Install-PowerShell.ps1 script, which you download directly from the PowerShell team’s GitHub repository at https://packt.link/C54Up. This PowerShell script, created and maintained by the PowerShell team at Microsoft, allows you to install the latest released version using an MSI installer package that was created by the PowerShell team. You run this script, and it downloads and runs the MSI package (which also updates the Windows Path variable to enable Windows to find PowerShell post-installation).

Here is a simple script that downloads the latest released version of PowerShell 7 and installs it using an MSI file:

# 1. Download PowerShell 7 installation scriptSet-Location C:\Foo
$URI = 'https://aka.ms/install-powershell.ps1'
Invoke-RestMethod -Uri $URI |
  Out-File -FilePath C:\Foo\Install-PowerShell.ps1
# 2. Install PowerShell 7
$EXTHT = @{
  UseMSI                 = $true
  Quiet                  = $true
  AddExplorerContextMenu = $true
  EnablePSRemoting       = $true
}
C:\Foo\Install-PowerShell.ps1 @EXTHT | Out-Null
# 3. For the Adventurous - install the preview and daily builds as well
C:\Foo\Install-PowerShell.ps1 -Preview -Destination C:\PSPreview |
   Out-Null
C:\Foo\Install-PowerShell.ps1 -Daily   -Destination C:\PSDailyBuild |
   Out-Null

The output from running this snippet is as follows:

Figure 2.2 – Installing PowerShell

As seen in Figure 2.2, you can also use the Install-PowerShell.ps1 script to download different versions of PowerShell to specific folders, enabling you to have multiple versions of PowerShell 7 installed, possibly for testing. For the brave, this script also allows you to install a preview build for the next version of PowerShell. For the ultra-brave, you can also use the latest build of PowerShell 7 (the build of the day), enabling you to evaluate some of the new features coming in the next release of PowerShell or added to the latest build.

Since PowerShell 7 is an open source project with a GitHub repository, you can download versions of PowerShell 7 directly from GitHub:

Figure 2.3 – PowerShell release page on GitHub

You can also use third-party package management tools, such as Chocolatey.

Keeping PowerShell up to date

Like almost every application, updates to PowerShell are a fact of life. With Windows PowerShell, Microsoft delivers updates via Microsoft Update.

Updating PowerShell 7 is a bit more complex, owing to the product’s nature and the different installation methods available to you. Like so many things with PowerShell, you have options.

Whenever the PowerShell team releases a new version of PowerShell 7, they update metadata held on GitHub to indicate the latest version(s) available. You can see the metadata using the following snippet:

Function Get-PWSH7ReleaseInformation {# Get details of overall PowerShell 7 information
  $FR = 'https://raw.githubusercontent.com/' +
  'PowerShell/PowerShell/master/tools/metadata.json'
  $MetaFullRelease = Invoke-RestMethod $FR
# Get Details of latest preview
  $MetaPreview = Invoke-RestMethod 'https://aka.ms/pwsh-buildinfo-Preview'
# Get Details of the latest daily build
  $MetadataDaily = Invoke-RestMethod 'https://aka.ms/pwsh-buildinfo-daily'
# Display this information
  'PowerShell 7 Status:'
  $MetaFullRelease
  'Preview information:'
  $MetaPreview
  'Daily Build information'
  $MetadataDaily
}
Get-PWSH7ReleaseInformation

When you run this code, you see something like this:

Figure 2.4 – Viewing release metadata

When PowerShell 7 starts, it checks the metadata, and if a new version is available (from GitHub), you will see a message something like this:

Figure 2.5 – Checking metadata at startup

Microsoft Update (MU) can also update PowerShell 7 when a new version is available. At the time of writing, MU can service your version of PowerShell within two weeks of it being available on GitHub. Likewise, if your installation is via the Microsoft Store, the Store should automatically download and apply updates.

These automatic methods of updating PowerShell 7 do take time, so if up-to-dateness is a key issue, consider just using the Install-PowerShell.ps1 script when and where you need to update the version of PowerShell on your system immediately.

If you use other tools, such as Chocolatey, you have to use these tools when PowerShell notifies you that an updated version is available.

PowerShell has three key pillars:

• Cmdlets: Small programs that do useful things, such as retrieve a set of files in a folder. Some cmdlets come with PowerShell, some come with applications and services, and you can leverage a huge library of third-party tools.
• Objects: Data structures representing entities within your computer and containing properties and methods. Cmdlets can consume and produce objects.
• The pipeline: The pipeline enables you to chain two cmdlets – the output of one cmdlet is sent, or piped, to a second cmdlet.

Cmdlets

Cmdlets are small programs that do useful things, such as getting the details of all the running processes. Cmdlets developers write these cmdlets as .NET classes, typically using C#.

Cmdlets come either with PowerShell itself or as part of an application such as VMware or the various Windows Server features. In Chapter 5, you can read more about the tools you can use to manage Windows, including the Remote Server Administration Tools (RSAT).

Cmdlets are named using a strict noun-verb syntax, based on a restricted and well-known set of verbs. For example, you use the Get-Process command to get details of the processes. Likewise, you would use the Get-Service command to get details of all the services on a system. The strict naming of cmdlets is a great feature that helps you to discover other cmdlets.

Cmdlets take parameters that affect how the cmdlet operates. You specify a parameter with a parameter name (which always begins with a - character) and usually some value. For example, if you wanted to get details on the DHCP client service running in Windows 11, you would type as follows:

Figure 2.6 – Using Get-Service to view a Windows service

For more details on Powershell cmdlets, see https://packt.link/f9ZTD.

Objects

In PowerShell, an object is a data structure that contains properties and methods about some entity, such as a file or a Windows process. The properties of an object are specific attributes of that object, such as the file’s full name or the process’s current CPU usage. You can create objects using cmdlets (for example, the Get-Process command returns objects of the system.process.diagnostics type).

You use objects in PowerShell when you manage Windows and write scripts to automate some activity, such as deleting all the files in temporary folders. Objects are fundamental to PowerShell and are great at simplifying scripting.

A benefit of objects is that the details of the object are easy to view. Just pipe the output of a cmdlet to Get-Member, and you can discover precisely what is inside each object. There is no prayer-based text parsing, as is more usual in Linux environments. See https://packt.link/KULU6 for an explanation of prayer-based parsing.

For example, you can get details of the optional features available In Windows 11 using the Get-WindowsOptionalFeature cmdlet. When you use this cmdlet, PowerShell returns an array of objects, each representing one of the optional features. You can then pipe the output of that command to Get-Member to show what is inside each object occurrence like this:

Figure 2.7 – Using Get-Member

When you automate Windows optional feature management, you easily discover that the property’s name, holding the feature’s current status is state. As you use PowerShell, this behavior becomes more and more useful.

For more details about objects inside PowerShell, see https://packt.link/QKxyh.

The pipeline

The pipeline is a feature of PowerShell that takes the objects a command creates and uses them as input for another PowerShell command. You use the | character to indicate the pipe operation, which you saw previously when you piped the output of the Get-WindowsOptionalFeature to the Get-Member command. The first cmdlet produced several objects (one for each Windows optional feature). By sending those objects to the next cmdlet, Get-Member can tell you what those objects look like.

The incredibly powerful pipeline enables you to create simple scripts to accomplish complex tasks. For example, suppose you wish to know which company made the software that uses the most virtual memory on your system. On Windows 11, each running application uses one or more (or a lot more) Windows processes. So, we can do this:

Figure 2.8 – Using the pipeline

In this example, you use Get-Process to get all the processes on your system. Powershell returns a process object for each Windows process. You then pipe it to Sort-Object to sort the objects based on VM usage (with the greatest VM usage sorted to the top). Then you take the top 150 of those processes (that is, the 150 processes using the most VM) and group them by the company attribute of the process object, which should be the application manufacturer. However, some apps do not populate that property!

PowerShell rests on top of .NET, so each PowerShell object, each service, each process, and so on is a .NET object. .NET provides a rich set of objects that enable you to interact with all the key Windows services and applications. In many cases, PowerShell is merely a wrapper around the functionality provided within .NET.

For more information on the pipeline, see https://packt.link/QVl4S.

Understanding these three pillars is fundamental to learning and mastering PowerShell.