PowerShell 7 features set to address some, not all, functionality gaps
While PowerShell 7 is set to unify the cross-platform and traditional Windows versions of the tool, it might not check all the boxes in terms of features IT admins want to see.
PowerShell has been a staple of automation and scripting within the Windows world, but with the advent of PowerShell Core and its cross-platform capabilities, the language continues to become an alternative to traditional shell languages on Linux systems.
But what's in store for the future of PowerShell? Let's take a look at the near- and long-term possibilities that PowerShell 7 -- set to launch over the coming months -- will bring to the IT community, as well as the items that are likely to remain on IT admins' wish lists.
PowerShell 7 features bridge a gap
Released in 2018, PowerShell Core extended the scripting language's reach beyond Windows, and into Linux and macOS. At the time of the release, Microsoft also stopped development of the traditional Windows PowerShell tool.
But there were some functionality gaps and module incompatibilities between PowerShell Core and Windows PowerShell, as the former runs on the cross-platform .NET Core framework and the latter runs on the .NET framework.
PowerShell 7, the next major release, is intended to reconcile these differences, and unify PowerShell Core and the traditional Windows PowerShell. It also will drop the name "Core."
Along with a bevy of other updates, PowerShell 7 features will include the ability to run Windows PowerShell modules that were not available in previous Core releases. This will help address one of the key reasons that Windows admins have avoided migrations to the newer version.
Architectural enhancements
Besides improvements to the language itself, the future of PowerShell should involve architectural changes that facilitate its use in development and scripts. There are a number of technologies in the background that will support these efforts in PowerShell 7, including:
PSScriptAnalyzer
PSScriptAnalyzer is a static code checker that runs a set of rules to analyze and ensure the quality of written PowerShell code. Currently, admins deal with a lot of overhead to call PSScriptAnalyzer, but version 2.0 of the module provides a proper API that the PowerShell Core Editor Services can call upon. This will eliminate many of the existing freezes and pauses that make writing compliant code more difficult.
Discussions around how to add [secrets management] to PowerShell are ongoing.
PowerShell Core Editor Services
In the past, PowerShell Core Editor Services have used a custom-rolled language server protocol (LSP) server. In certain use cases, extending and updating this LSP server was a challenge. With version 2.0, the editor services use the cross-platform .NET LSP implementation OmniSharp LSP, which should boost both speed and stability.
PSReadLine
PowerShell, for a long time, has had an implementation of the venerable Linux ReadLine library, which includes a vastly superior command-line editing experience, with features such as syntax highlighting, undo-redo support, multi-line editing and bash style command completion. PSReadLine did not support PowerShell Core, but will do so in version 2.0 -- making for an improved editing experience.
.NET Core and cloud services
PowerShell 7 will be based on the .NET Core 3.0 framework, which will enable PowerShell to run in container instances and cloud services. This could enable PowerShell 7 features, such as the use of Azure Functions to trigger a script to run. It could also let teams use PowerShell container images within Azure DevOps and other CI/CD tools to interact with a multitude of different systems and APIs.
Desired State Configuration (DSC)
As the PowerShell language matured, Microsoft introduced Desired State Configuration, a feature that enables admins to apply a configuration more easily to a given resource using a domain-specific language (DSL) written in PowerShell. As PowerShell evolved into a cross-platform tool, the future of DSC became unclear. Most development has been around reimplementing DSC as the Azure Policy Guest Configuration -- and this has raised questions regarding the fate of local versions of DSC.
Future direction for PowerShell 7 features
PowerShell developers have suggested other potential areas for enhancement -- namely, secrets management and off-box logging -- that they will explore for the future. Both of these capabilities would make it easier for system administrators to use the language in a broader range of use cases.
Secrets management
Many other languages include the capability to store secrets, such as API keys or passwords, within an encrypted container for later use in code. Though there have been community efforts and ways to use Windows capabilities, such as the Data Protection API, as a workaround, PowerShell has lacked a comprehensive and native capability to do this. But a strongly encrypted architecture, coupled with cross-platform capabilities, would enable IT teams to use PowerShell in more production environments.
Discussions around how to add this capability to PowerShell are ongoing. Currently, those discussions center around the use of an independent module named Microsoft.PowerShell.SecretsManagement. This would enable the creation of a local vault, with the ability to access a remote vault. The logic flow would look something like:
User Context > Local Vault > Secrets Vault > Remote Vault
Much work is needed, however, to hash out exactly what this implementation will look like.
Off-box logging
PowerShell has a strong logging capability; admins can store code within ScriptBlocks and store the execution of commands in log files and the Windows event log. What is lacking is the native ability to send these logs directly to a third-party logging service, such as Splunk. Microsoft is exploring how best to support this capability, which is a very important one to organizations who need to closely track what executes in their environments.
