Why you should consider an upgrade from PowerShell 5.1 to 7

Why move to PowerShell 7?

PowerShell 7 does not abandon on-premises deployments but adds improved support for modern alternatives. One key update, pipeline parallelization, is part of the stable release. The ForEach-Object -Parallel cmdlet can run several scripts at the same time for every piped input object. The feature also supports job object returns, as opposed to console writes.

In previous versions, these processes would happen sequentially, which makes for slower performance. It's a similar concept to how a webpage loads: CSS and JavaScript execute line by line until the entire page is generated, which can take up valuable time. Pipeline parallelization allows multiple threads to run concurrently to solve this type of performance issue.

A sequential cmdlet with five tasks, each taking one second, will take five seconds to complete. Meanwhile, executing these simultaneously could achieve equal results in a second. While execution order isn't guaranteed, the script can throttle how many scripts are run together at a given time.

What else is included in PowerShell 7?

• new operators for pipeline chains, null conditionals and ternaries;
• easier investigation of errors via dynamic views;
• module import support thanks to a new compatibility layer; and
• direct invocation of DSC resources.

PowerShell 7 brings other performance improvements. Baked-in SSH remoting creates a PowerShell host process on a specified computer as a subsystem, which is touted as a stepping stone toward a general hosting model that Windows PowerShell 5.1 has with the Windows Remote Management 2.0 feature. Environments with a mix of Windows, Linux and MacOS operating systems will benefit from this added control.

Finally, PowerShell 7 supports Docker containers. Admins can download images and run commands within associated containers without local admin privileges or the sudo command.

Notes on operating system compatibility

On the Windows platform, PowerShell 7 supports Windows 8.1, Windows 10 and the following Windows Server versions: 2012 (R2 included), 2016 and 2019. On Apple systems, macOS 10.13 High Sierra or later is supported. PowerShell 7 also supports the following systems and platforms:

• Red Hat Enterprise Linux;
• CentOS 7;
• Fedora 30 or later;
• Debian 9 (including ARM32/64);
• Ubuntu 16.04 LTS or later (including ARM32/64); and
• Alpine Linux 3.8 or later (including ARM64).

Microsoft is committed to supporting x64 architectures. PowerShell community members have built Arch and Kali Linux packages to extend support to those systems -- even if the support isn't official. These distributions support x86-64 architectures.

How to migrate to PowerShell 7

The PowerShell team built the new open source version of PowerShell to run in tandem with Windows PowerShell 5.1 by setting up separate installation directories. However, the latest PowerShell 7 version will install as an in-place upgrade to replace earlier instances of the open source PowerShell found in the system.

The PowerShell 7 installation locations are:

• %programfiles%\PowerShell\7
• The %programfiles%\PowerShell\7 folder is added to $env:PATH

The path location separates PowerShell 7 from other versions on your system; users without administrative rights or those that want to keep earlier versions should install with the ZIP package.

The new executable name is pwsh.exe whereas the Windows PowerShell 5.1 runs powershell.exe.

Locations for PowerShell modules

Modules extend the capabilities of PowerShell by adding new commands. These modules are stored in various locations within the system. The $Env:PSModulePath variable holds the module folder storage locations. PowerShell checks these locations automatically when the user attempts to import a module. The newest version of PowerShell prioritizes autoloading of modules. There are new locations for PowerShell modules, AllUsers scope and CurrentUser scope. PowerShell 7 loads both core and desktop modules without issue.

PowerShell 5.1 modules are forward compatible with PowerShell 7. This includes Azure PowerShell and Active Directory. Microsoft has taken steps to make the migration from PowerShell 5.1 easier for those who depend on incompatible modules. A UseWindowsPowerShell switch in the Import-Module cmdlet lets users assess compatibility across modules. PowerShell 7.1 added protections to prevent clobbering in the following core modules:

• PowerShell.ConsoleHost
• PowerShell.Diagnostics
• PowerShell.Host
• PowerShell.Management
• PowerShell.Security
• PowerShell.Utility
• WSMan.Management

Profile management changed with PowerShell 7

Profiles are scripts that run at the beginning of a PowerShell session to add customization to one's ecosystem via aliases, commands, drives, functions, modules and variables

Older versions of PowerShell required users to recreate these adjustments for every session, which is time-consuming and tedious. By automating the application of these scripts, admins can get to work more quickly. Profiles also ensure that important configurations aren't missed.

These filenames -- and locations -- have changed since Windows PowerShell 5.1. Profiles are now located at $HOME\Documents\PowerShell. References to \WindowsPowerShell have been removed; most locations now live within the \PowerShell branch of the file system within \Program Files and \Users. These profiles are named accordingly:

• AllUsersAllHosts;
• AllUsersCurrentHost;
• CurrentUserAllHosts; and
• CurrentUserCurrentHost.

Remoting, group policy and logs

PowerShell 5.1 used the Web Services-Management (WS-MAN) protocol for connecting and data transport. PowerShell 7 uses that same endpoint when Windows Remote Management is enabled. However, PowerShell 7 can use its own endpoint by using the Enable-PSRemoting cmdlet to add a new configuration.

On the SSH side of things, users who run operating systems that are noncompliant with Windows components have some options, such as the new parameters to the New-PSSession, Enter-PSSession and Invoke-Command cmdlets to make remoting possible. Users can specify strings, computers and usernames. The KeyFilePath parameter handles key authentication.

For a company that runs multiple servers in an enterprise environment, Group Policy settings operate similarly to profiles. They define values that are consistently respected throughout the deployment. Admins can customize:

• console session configurations;
• module logging activations;
• script block logging activations;
• script execution policies;
• PowerShell transcription actions; and
• delegation of default source paths for Update-Help.

PowerShell 7 includes Group Policy templates, which remove much of the work required in prior versions. These files use the .admx and .adml extensions. To install core administrative templates, teams can execute the InstallPSCorePolicyDefinitions.ps1 script.

A separation of powers is the theme throughout PowerShell 7. This holds true for event logging. Windows PowerShell 5.1 and PowerShell 7 log events in distinct logs to avoid confusion and for easier reference. The Get-WinEvent -ListLog *PowerShell* command retrieves a list of logs.

Scripting with Visual Studio Code

Teams that run Windows PowerShell 5.1 on non-Windows systems had a way to use Visual Studio Code as the source code editor. PowerShell 7 extends support for Visual Studio Code to both macOS and Linux. PowerShell in Visual Studio Code requires installing an extension, which is explained at this link.

The traditional scripting tool for admins is the PowerShell Integrated Scripting Environment, which is available within Visual Studio Code but only for Windows PowerShell. This option within the Command Palette changes the editor layout and expands the capability of the editor while it unlocks PowerShell functionality.