5 changes coming to PowerShell 7.0

PowerShell is undergoing an upgrade to version 7.0 across all lines, bringing parity with the Windows version for all OSes, new features, and enhanced security.

Programmer working with program code

RossHelen, Getty Images/iStockphoto

Microsoft's PowerShell (PS) programming language has gone through several revisions in the last few years. Alongside advancements in supported features in newer Windows operating systems, PowerShell went open source to include support for Linux and macOS and moved its development site to GitHub for increased community support from developers, programmers, and IT admins worldwide.

SEE: How Microsoft Office is useful for developers (free PDF) (TechRepublic)

The next version of PowerShell to be released is 7.0. Though PowerShell 7.0s  still under development, tMicrosoft has been making release candidates available for users to download and test. 

These are some new features Microsoft is working on for PowerShell 7.0. Note: Microsoft is still actively working on the final release code, so certain features that are not available now may show up in the final release; conversely, features that are currently implemented could be removed (in whole or in part) as the development cycle moves toward final release.

.NET Core 3

Before making the open-source shift, PowerShell was Windows-only and based off the .NET framework. Once the jump occurred, Microsoft forked the PowerShell language and modified the underlying frameworks to .NET Core, which supports all OSes, allowing PowerShell to run on Linux and macOS, alongside Windows.

A caveat to PowerShell Core (PSC) is that many of the cmdlets admins rely on have not been ported over yet. However, developers have been working toward bridging that gap with future updates and new releases.

Windows compatibility

One of the big goals with this new version of PowerShell Core is to bridge the gap between the PS (non-core) and PSC versions with respect to the number of cmdlets available. The Windows-only PowerShell (non-core) has the lion's share of supported cmdlets, but that has slowly been changing. A goal of version 7.0 is to up the compatibility with modules to bring parity between these versions so admins can fully migrate to PowerShell Core seamlessly.

Long-term support (LTS)

Microsoft typically supports applications for a certain period of time, then moves on to the newest version of the application, effectively dropping support for older versions--PowerShell is no stranger to this; however, the jump to .NET Core will also bring in line with it the support cadence that Microsoft has established with that product line. Preview releases will be made available each month to obtain feedback as early as possible. More importantly, LTS releases will be supported for three years after the initial release compared with current releases, which are only supported for three months after a subsequent current or LTS release is made available. 

Secure credentials management

Scripting often helps simplify IT admins' lives by automating tasks—both in quantity (i.e., the number of scripts to maintain) and quality (i.e., standardized management)--but with growing reliance on local, cloud, and hybrid resources, this can cause any number of resources requiring multiple credentials to operate improperly. PowerShell has included methods for securing credentials to some degree so as to not include credentials in plain text, embedded within scripts.

To take it a step further, Microsoft is working on creating a credential store, which will act as a secure repository to maintain admin credentials either locally or remotely via the store, so the user never has to enter credentials in an unsecured manner.

Centralized logging

PowerShell's logging capability is limited to the local machine. Whenever scripts and cmdlets are executed—regardless of whether it's performed locally or remotely--the logs generated stay on the local device against which the cmdlets are running. This can make sorting through logs for feedback on issues time-consuming, requiring the user to go through all those devices separately. PowerShell 7.0 standardizes log collection through a policy that would direct all logs to a targeted system (or syslog-type server) for centralized OS agnostic management.

Also see

(TechRepublic on Flipboard)