Monthly Archive


PowerShell v6

PowerShell Core v6.2.1

PowerShell Core v6.2.1 has been released -

as has v6.1.4


The new versions are to primarily fix the Security Vulnerability CVE-2019-0733 -


v6.2.1 also enables tab completion for functions

What’s new in PowerShell v6.2

The What’s new in PowerShell v6.2 is available at - – together with the already existing documents for PowerShell v6.0 and v6.1.


Its worth reading through the three documents – one each for v6.0, v6.1 and v6.2 to see the whole range of changes in PowerShell core.

PowerShell 7

A recent post - – on the PowerShell team blog states that the next release of PowerShell Core won’t be 6.3 as expected but will be PowerShell 7


PowerShell 7 will be tied to .NET Core 3.0 and should bring more compatibility for Windows users. The graphic on the post shows Linux usage outstrips Windows usage of PowerShell Core by at least 5 to 1.


The lifecycle will change to align more closely with .NET Core with Long Term Servicing releases and non-LTS releases.


PowerShell 7 will eventually ship side-by-side with Windows PowerShell 5.1 but update process hasn’t been finalised.


Terminology changes are in the offing as PowerShell core is dropped for just PowerShell. This is a mistake as it takes away the use of PowerShell as a generic term that covers all versions.


The reasons for the change aren’t fully explained in the post but I suspect are linked to the very poor level of take up of PowerShell Core on Windows.


PowerShell v6.2 contains a number of experimental features including PSCommandNotFoundSuggestion

The idea of experimental features is to make the use of new features – especially those that may cause breaking changes optional. Feedback can be obtainied and the experimental features can be modified, moved out of the experimental state into the full release or even removed.


Enable-ExperimentalFeature –Name PSCommandNotFoundSuggestion

to enable the feature. Then restart PowerShell.


Trying the new feature gave these results

PS> Get-Srvice

Suggestion [4,General]: The most similar commands are: Get-Service, Set-Service, New-Service, Get-PSDrive.

I expected Get-Service so that worked



PS> Get-prcss

Suggestion [4,General]: The most similar commands are: Get-Process, Get-Alias, Get-Host, Get-Acl.

Looking for Get-Process – some of the other choices are very odd


Moving to native utilities

PS> pong

Suggestion [4,General]: The most similar commands are: popd, copy, move, ni, nv, oh, rni, rnp, sort, man.

I’d have expected to see ping in that list!


PS> Get-NtAdter


Suggestion [4,General]: The most similar commands are: Get-NetAdapter, Set-NetAdapter, Get-Counter, Get-Item, Get-Date, Get-Member.

Expected Get-NetAdapter so that counts as a success.


Looking at aliases

PS> seloct

Suggestion [4,General]: The most similar commands are: select, sort, set, del, clc, sal, sl, sleep, start, sls.

PS> stv

Suggestion [4,General]: The most similar commands are: sv, stz, clv, ft, gpv, gv, nv, rv.

Needed to see select and stz respectively so that’s good.


One last utility

PS> ipconfog

Suggestion [4,General]: The most similar commands are: ipmo, ipcsv, ipconfig.exe, inmo.

ipconfig fits the bill.


For the most part the suggested commands seem to be reasonable and reasonably accurate.

Tab completion probably removes some of the usefulness of this option but I’d recommend enabling it and giving it a try

PowerShell v6.2 experimental features

I’ve mentioned the PowerShell v6.2 experimental features before.


This blog post from the PowerShell team

gives a good overview of the available experimental features.


I’ve already covered the use of the temp drive. The command not found suggestions and implicit remoting batching look like they could be useful.  The abbreviation expansion could make interactive use more efficient

PowerShell v6.2 release

The Powershell v6.2 release has just been made available on github -


The full release notes aren’t available on the Microsoft documentation yet – they should appear in the What’s New section of


The release notes on github indicate only one breaking change  - around the –NoEnumerate behaviour in Write-Output


There are some relatively minor cmdlet updates and fixes – nothing leaps out as a major issue.


You have six months to upgrade to v6.2 before the v6.1 support stops

Powershell default parameters

The issue Scope issue with Install-Module that I discussed in recent posts is annoying because I know that I’ll forget about it and end up installing in the wrong place and have to uninstall and reinstall. Then I remembered PowerShell default parameters.


By adding the line

$PSDefaultParameterValues = @{'Install-Module:Scope'='AllUsers'}

into my PowerShell v6 profile I’ve removed the issue. Install-Module will always default to –Scope AllUsers and if I need to override it I can.


$PSDefaultParameterValues is a hashtable where the key is constructed from the cmdlet name and the parameter and a value is supplied.


I use the same profile for production and preview PowerShell v6 instances so all should be good – until there’s another change.

Install-Module in PowerShell v6.2 RC 1

Further to my last post it appears that Install-Module in PowerShell v6.2 RC1 DOESN’T follow the rules. In an elevated session if the scope parameter ISN’T used it will install to $home\Documents\PowerShell\Modules


The default appears to be CurrentUser regardless.


You have to use -Scope AllUsers if you want it to install in C:\Program Files\PowerShell\Modules

Install-Module Scope parameter

Be aware of the Scope parameter when using Install-Module. The following rules apply:

Allusers scope installs to $env:ProgramFiles\PowerShell\Modules

CurrentUser scope installs to $home\Documents\PowerShell\Modules

NoScope defined:

- - For an elevated PowerShell session, Scope defaults to AllUsers

- - For non-elevated PowerShell sessions in PowerShellGet versions 2.0.0 and above, the Scope is CurrentUser

- - For non-elevated PowerShell sessions in PowerShellGet versions 1.6.7 and earlier, Scope is undefined, and Install-Module fails


PowerShell v6.2 RC 1 uses PowerShellGet 2.0.4 and PowerShell v6.1.3 uses version 1.6.7. You’ll see different behavior depending on PowerShell version so the advice is to use the Scope parameter to ensure the module goes where you intend.


I usually want my modules in Program files (Allusers) rather than my documents folder (CurrentUser).


The lesson seems to be to use the Scope parameter rather than relying on defaults


The release of PowerShell v6.2 release candidate 1 brings more experimental features including PSTempDrive.


You can view the currently available experimental features using get-ExperimentalFeature. You’ll find a total of four:



Install PSTempDrive using

Enable-ExperimentalFeature –Name PSTempDrive


Restart PowerShell after enabling the feature.

Get-PSDrive will show a new drive named Temp. The root of the drive is set by the path in your TEMP environmental variable.


You can use and access the TEMP drive like any other drive set by PowerShell.


The TEMP drive follows the pattern of other drives created from a path on an existing drive using the filesystem provider in that the used and free space figures reflect the situation for the whole volume not the individual drives. The free space is OK like this as theoretically you could consume the whole of the available space on your new drive but the used space should reflect reality. The C: drive used space should be for the whole volume but the TEMP: drive should only show the space used in your TEMP folder etc.


If you want to remove the experimental feature – use Disable-ExperimentalFeature and restart PowerShell.


Not wholly convinced of the need for this particular feature but it gives marginally easier access to the TEMP folder.


Remember that experimental features are just that – experimental – and could be modified or even removed in a later version of PowerShell