PowerShell Core 6.1 does not have the headline-grabbing features of PowerShell Core 6.0, but many of its new features, while smaller, make it a worthwhile upgrade.
PowerShell Core 6.0's January release delivered noteworthy features such as PowerShell on Linux and Secure Socket Shell remoting. While not as flashy, the PowerShell Core 6.1 September release came with improved performance and expanded cmdlet compatibility.
Administrators can upgrade from 6.0 to 6.1 at their own pace, but they must be aware that the PowerShell Core support lifecycle is six months. Admins might want to find a reason to upgrade sooner to take advantage of PowerShell Core's latest features.
PowerShell Core 6.1 includes Windows PowerShell 5.1 modules
The change that's going to cause the most excitement -- and the most confusion -- is that the PowerShell Core 6.1 module path automatically includes the Windows PowerShell 5.1 modules.
The first folder listed above holds the personal modules, the second holds the modules downloaded from the PowerShell Gallery with PowerShell Core, and the third holds the modules installed with a particular version of PowerShell. The last entry covers the Windows PowerShell 5.1 modules, which is where the confusion arises.
For example, execute the following command:
Get-Module -ListAvailable
A PowerShell project team member details the tool's roadmap.
The output only lists PowerShell Core 6 modules. To include the Windows PowerShell 5.1 modules, you need to add the -SkipEditionCheck switch -- which is not currently documented in the help file -- to the end of the command.
When you list the available modules in version 6.1 of PowerShell Core, notice that there is a new column in the output called PSEdition. It has a value of either Core or Desk. If the module manifest has a line similar to the one below, the module will register as Core.
CompatiblePSEditions = @("Core")
Otherwise it's treated as a Desk version, and you must use the -SkipEditionCheck switch to see it.
The same is true when importing a Windows PowerShell 5.1 module. You need to use -SkipEditionCheck; otherwise, you'll get an error:
Import-Module netadapter -SkipEditionCheck
In version 6.1 of PowerShell Core, you can use a lot of the Windows PowerShell modules, but not all of them. The module will work if it's a script module (assuming it doesn't use commands that aren't available in PowerShell Core), a CDXML module or a binary module that only uses assemblies compatible with .NET Core, including the Windows Compatibility Pack for .NET Core.
The Active Directory module is one popular module that still does not work with PowerShell Core.
PowerShell Core 6.1 brings more speed and experimental features
PowerShell Core 6.1 increases performance significantly for the following cmdlets: Group-Object, Sort-Object, Import-Csv and ConvertFrom-Json.
Also, with this version, administrators can use experimental features. The following command shows the current list:
Get-ExperimentalFeature -ListAvailable
In version 6.1 of PowerShell Core, you can use a lot of the Windows PowerShell modules, but not all of them.
In PowerShell Core 6.1, there aren't any experimental features listed. I expect this feature will be used in later updates.
Version 6.1 of PowerShell Core also introduces the Run as Administrator option on the PowerShell jump list and task bar icon to make it easier to start from an elevated prompt.
The cmdlet Test-Connection, missing from PowerShell Core 6.0, returns in PowerShell Core 6.1, but the display needs improvement. The project team should remove the progress information and the running progress bar. The reply information also needs to be properly formatted.
At the time of publication, both the online help file and PowerShell's help documentation refer to the 5.1 version of Test-Connection, not the 6.1 version.
The top screenshot shows how PowerShell Core 6.1 formats output from the Test-Connection cmdlet compared to the Windows PowerShell v5.1 version on the bottom.
PowerShell Core 6.1 brings a new file system navigation command, cd -, to return to the previous location. Push-Location and Pop-Location, available in 5.1 and 6.0, produce the same result.
In PowerShell Core 6.1, the command cd - command brings you back to the previous location.
PowerShell help files move toward markdown
At some point, PowerShell help files will be available in the markup language Markdown rather than XAML. As a first step, PowerShell Core 6.1 adds cmdlets with Markdown functionality: ConvertFrom-Markdown, Get-MarkdownOption, Set-MarkdownOption and Show-Markdown.
At the time of publication, there are no help files to explain this functionality. This is a recurring theme with the PowerShell Core project. Much of the documentation either needs to be updated or is missing outright. The PowerShell project's request for comments on this functionality explains the ideas behind the cmdlets.
In the PowerShell console, Show-Markdown displays the contents of a markdown file.
The Show-Markdown cmdlet displays the contents of a markdown file in the PowerShell console.
Alternatively, the following command will display the markdown file in your browser:
Show-Markdown -Path C:\test\README.md -UseBrowser
The first time I ran this command on my Windows 10 machine, PowerShell prompted me to choose a browser, which will be the default for future calls.
The Get-MarkdownOption and Set-MarkdownOption cmdlets control markdown rendering.
The first two allow you to run scripts against Active Directory. This is similar to how it was done in Windows PowerShell 1.0 before Active Directory cmdlets arrived. If you need to work with Active Directory with PowerShell Core 6.1, this is your only option until the project team ports the cmdlets.
The Windows Management Instrumentation (WMI) accelerators were useful in Windows PowerShell 1.0, but their use diminished with the WMI cmdlets in Windows PowerShell 2.0 and the Common Information Model cmdlets in PowerShell 3.0. I've only seen a use for the WMI accelerators when performing actions against the System Center Configuration Manager database.
People who are new to PowerShell Core should look at the project and contribute ideas they would like to see in a future release. With PowerShell now an open source project, this type of feedback is necessary.
