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)
Since development has been completed on the next version, PowerShell 7.0, Microsoft has made it available on their GitHub page for all users, sorted by operating system.
New features Microsoft has introduced in PowerShell 7.0. Note: Though Microsoft has completed the final release code, certain features and functions currently available are known to have been affected. A list of these changes may be seen here and can be expected to be fixed in a future release.
.NET Core 3.1
Before making the open-source shift, PowerShell was Windows-only and based on 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 relied on have not been ported over yet. However, with PS 7.0, much of that gap has been bridged and will continue with one, unified PowerShell moving forward.
Backwards compatibility with Windows PowerShell
One of the big goals with PowerShell 7 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. Now with PS 7.0 switching to .NET Core 3.1, the move brings with it “significantly more backwards compatibility with existing Windows PowerShell modules,” according to Microsoft. This includes those that require GUI functionality and role management modules native to Windows.
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, and PowerShell is no stranger to this; however, the jump to .NET will also bring 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.
Updates to existing cmdlets
While there are a number of new additions to PS 7.0, a few of the more notable updates to existing cmdlets include parameter updates that allow users to work with objects, perform functions, and utilize operators in different, more useful ways.
The ForEach-Object cmdlet, used to iterate items in a collection, now includes the -Parallel and -ThrottleLimit parameters, which serve to process data sets through parallelism and can limit the number of blocks running in parallel respectively.
The Get-Error cmdlet, by default, provides insight into the last error that occurred. It includes a fully detailed view of the qualified error, including exceptions. Additionally, when run with the -Newest parameter followed by a number, the last errors detected will be displayed, correlating to the number input.
For example, running the cmdlet below will generate the last 5 errors reported in the session:
Get-Error -Newest 5
Note: PS 7 has a new default view when displaying errors called ConciseView, by Microsoft. ConciseView will display errors in a single line as opposed to the multi-line, multi-colored view PS users are used to seeing when an error occurs. ConciseView only applies to errors occurring in the terminal; errors occurring in scripts or through parsing will still be displayed using multi-line.
A new operator included–and quite useful–is the ternary operator that functions much like an if-else statement, only simpler, by comparing two expressions against its condition to see if it is true or false. In the example below, using the Test-Path cmdlet, if the referenced path exists, the result will return as “exists”; however, if it does not exist, it will return as “does not exist.”
Test-Path “C:Users” ? “exists” : “does not exist”
Another extremely useful addition is the pipeline chain operator. These come in the form of “&&” and “| |”, and serve to chain pipelined data based on conditional statements. The && operator executes the pipeline to the right of it, but only if the pipeline to the left of the operator executed successfully. Subsequently, the | | operator executes the pipeline to the right of it, but only if the pipeline to the left of it failed. They also may be used with native commands in addition to cmdlets and functions.
The null-coalescing, assignment, and conditional operators are a new set of operators used to obtain values from evaluated operands. While most commonly aimed at advanced-level users, these new operators will allow them to simplify obtaining data from complex functions and even allow them to base them conditionally, depending on the information sets they are working with. Microsoft has included detailed descriptions, including examples of how to maximize data management via its online scripting guide.
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.
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.
New version notification settings
PowerShell 7 includes the ability to notify users when a new version of PS is available. The default behavior is to check once a day for new updates. Which updates will be delivered will depend on the notification channel PowerShell subscribes to: Generally Available (GA) or Preview and Release Candidate (RC) channels.
Not only is this useful for users, but the channel subscription may be changed in the event that you wish to try out an experimental feature, or perhaps requires long-term support (LTS) only cmdlets for their production scripts. By creating the environment variable $Env:POWERSHELL_UPDATECHECK, the system’s channel may be set.
Editor’s note: This article has been updated from its original version, published on Nov. 20, 2019, to reflect changes to PowerShell 7.0 since its release.
(TechRepublic on Flipboard)