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.