Kesu - Fotolia


PowerShell Core 6.1 offers many small improvements

New PowerShell Core functionality includes the addition of Windows PowerShell 5.1 modules, making this version worth a closer look for administrators.

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.

$env:PSModulePath -split ';'

C:\Program Files\PowerShell\Modules
C:\Program Files\PowerShell\6\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.

Test-Connection cmdlet
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.

PowerShell Core 6.1 file navigation command
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.

Show-Markdown cmdlet
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\ -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.

Get-Command Set-MarkdownOption -Syntax

Set-MarkdownOption [-Header1Color <string>] [-Header2Color <string>]
[-Header3Color <string>] [-Header4Color <string>] [-Header5Color <string>]
[-Header6Color <string>] [-Code <string>] [-ImageAltTextForegroundColor <string>] [-LinkForegroundColor <string>] [-ItalicsForegroundColor <string>]
[-BoldForegroundColor <string>] [-PassThru] [<CommonParameters>]

Set-MarkdownOption -Theme <string> [-PassThru] [<CommonParameters>]

Set-MarkdownOption [-InputObject] <psobject> [-PassThru] [<CommonParameters>]

The ConvertFrom-Markdown cmdlet takes a markdown file and outputs HTML by default. VT100 encoded string is another option.

Microsoft returns several accelerators to PowerShell Core 6.1

Another interesting development with this release is the return of several type accelerators:

  • [adsi]: System.DirectoryServices.DirectoryEntry
  • [adsisearcher]: System.DirectoryServices.DirectorySearcher
  • [wmi]: System.Management.ManagementObject
  • [wmiclass]: System.Management.ManagementClass
  • [wmisearcher]: System.Management.ManagementObjectSearcher

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.

Dig Deeper on Windows Server OS and management

Cloud Computing
Enterprise Desktop
Virtual Desktop