Getty Images


How admins can benefit from switching to PowerShell 7.4

This PowerShell release includes PSReadLine enhancements, better integration with Windows Defender Application Control and new features to ease native command use for all platforms.

The release of PowerShell 7.4 is a significant milestone in the development of PowerShell.

PowerShell's updates continue to improve upon an already strong scripting platform. PowerShell 7.4, released in November 2023, adds a strong foundation in .NET 8 to make it a relevant release for several years. The other enhancements and new features help streamline scripting tasks, especially when it comes to working with native commands or executables. As PowerShell continues to evolve, these updates should solidify its position as an indispensable tool for IT administrators, offering powerful capabilities to automate complex workflows and to manage systems efficiently.

Why PowerShell 7.4 benefits from .NET 8 and LTS

PowerShell 7.4 is the first version built on .NET 8, which is a Long Term Support (LTS) version that provides support for three years. The previous PowerShell release ran on .NET 7, which was a Standard Term Support release, offering 18 months of support.

In the world of software, if you intend to use a specific version of a product for a long time, you are best served by an LTS version. Since PowerShell 7.4 runs on .NET 8, this means that the PowerShell team intends to support it by releasing bug fixes and security updates for the length of the support term.

This gives you the confidence that writing a script for PowerShell 7.4 has support for several years to come.

What are the PSReadLine improvements in PowerShell 7.4?

Besides a beneficial support schedule, PowerShell 7.4 also comes with command-line editing improvements by including PSReadLine 2.3.4.

Admins who work in the console benefit from the fixes and improvements that enhance UX and functionality in PowerShell. Some of the changes include dynamic color selection for inline predictions and options to improve handling both on Windows and Linux, as well as upgraded prediction display.

PowerShell 7.4 adds ProgressAction as new common parameter

PowerShell 7.4 introduced a new feature to enhance your scripting experience. The developers added ProgressAction as a common parameter, which is a parameter that can be used on any cmdlet because it is part of PowerShell. Because a cmdlet accepts all common parameters, that doesn't mean that the parameter affects a cmdlet. For example, using the Verbose parameter on a cmdlet that doesn't generate that type of output has no effect.

The ProgressAction parameter tells PowerShell how to respond to progress updates generated by some script, cmdlet or provider, such as a progress bar generated by the Write-Progress cmdlet. ProgressAction takes any of the ActionPreference values, which you might be familiar with from similar common parameters, such as ErrorAction. The following are the valid values:

  • Stop. No progress bar. Outputs an error message and stops.
  • Inquire. Prompts for permission and only displays the progress bar if the user responds with a Y or A.
  • Continue. The default. It shows the progress bar and runs the code.
  • SilentlyContinue. No progress bar is displayed.

How PowerShell 7.4 works with Windows Defender Application Control

Windows Defender Application Control (WDAC) restricts driver and application use on managed clients. WDAC enforces Constrained Language Mode for all PowerShell scripts. Earlier versions of PowerShell lacked the debugging functionality in Constrained Language Mode, which made scripting difficult.

With the upgrade in PowerShell 7.4, scripts that execute in audit mode of WDAC now log additional details to the event log to describe what restrictions apply if the policy was in Enforce mode. This should make writing and debugging scripts for WDAC much easier.

Experimental features become mainstream in PowerShell 7.4

The PowerShell experimental feature system lets users try unofficial functionality for testing and feedback purposes. The developers integrated several of these trial features into PowerShell 7.4 to make them an official part of the automation tool.


PowerShell 7.4 enables PSCustomTableHeaderLabelDecoration by default. The $PSStyle automatic variable, introduced in PowerShell 7.2, applies a different format to table header labels for calculated values rather than the properties of objects. The Get-Process cmdlet is a good example of this. It includes the following calculated columns: NPM(K) for Non-Paged Memory (kilobytes), PM(M) for Paged Memory (megabytes), WS(M) for Working Set (megabytes) and CPU(s) for CPU (seconds). PowerShell 7.4 italicizes these columns. This is a small but significant change to help new PowerShell users understand they are seeing a calculated property rather than the actual object property.

PowerShell table headers
The italicized headers distinguish the calculated property from the object property to help new PowerShell users understand the difference.


If you run a native command in PowerShell and it errors, the $LastExitCode variable holds information about the result. PSNativeCommandErrorActionPreference gives you more control over native command failures by producing error objects that are then handled normally through the PowerShell error stream. With PSNativeCommandErrorActionPreference, native command errors respect your $ErrorActionPreference without any fancy scripting on your part.


While working in the PowerShell console, previous versions of PowerShell detected data being piped between two native OS commands or a native command and PowerShell -- and vice versa -- and attempted to convert that data into a string, potentially preventing the pipe from functioning as expected. With PSNativeCommandPreserveBytePipe, PowerShell 7.4 preserves the byte-stream data, providing support for additional native OS tools. Now, inside of PowerShell running on Linux, you can successfully execute the following commands:

# Native command piped to native command
curl -s -L $uri | tar -xzvf - -C .

# PowerShell command piped to native command
(Invoke-WebRequest $uri).Content | tar -xzvf - -C .


The $PSNativeCommandArgumentPassing variable now controls how PowerShell calls native commands so you can now pass empty strings, as well as arguments that include quotes. Previously, PowerShell constructed a string and invoked the native executable using the string, but now, PowerShell uses the ArgumentList property of the StartProcessInfo object. The $PSNativeCommandArgumentPassing variable automatically enables the new method with a setting of Standard. If you prefer the traditional method of building a string, use the Legacy setting. On Windows, the default is Windows, and this accepts invocations for several native Windows executables.

Anthony Howell is an IT expert who is well versed in multiple infrastructure and automation technologies, including PowerShell, DevOps, cloud computing, and the Windows and Linux operating systems.

Dig Deeper on IT operations and infrastructure management

Cloud Computing
Enterprise Desktop
Virtual Desktop