Monthly Archive


PowerShell v6

PowerShell v6.0.2

PowerShell v6.0.2 is available from


The only real change is that .NET core 2.0.6 is used in this release to counter the Hash Collision vulnerability -


A number of changes that affect the way the project builds and releases code have also been implemented – these SHOULD be transparent to the user 🙂


Win32-OpenSSH also has a relatively new release – v7.6.0.0p1-Beta - The jump in version number is to bring it inline with the base OpenSSH code.


Still no simple way to install and configure OpenSSH but it is getting a bit better. Most won’t  need to run a instance of powershell in bypassexecutionpolicy mode as part of the install.  If you’re not allowing scripts to run then why bother with OpenSSH remoting?  If you’re using Allsigned then it probably makes sense. In any case it’s still too complicated.


The ability to release new versions like this is one of the big plus points for having PowerShell as an open source project.


If you want to find the name of the local computer you use $env:COMPUTERNAME.


Except that doesn’t exist in Linux PowerShell v6 – you have to use $env:HOSTNAME


PowerShell 1 Consistency 0


I can live with having $env:HOSTNAME because I bet that’s what Linux users would look for. It would be nice to also have $env:COMPUTERNAME for Windows users starting out with Linux.


It gets better.


If you create a SSH remoting session using PowerShell v6 to a Linux system - $env:HOSTNAME ISN’T exposed. You have to use the hostname legacy utility.


If you create a SSH remoting session using PowerShell v6 to a Windows system - $env:COMPUTERNAM IS exposed.


PowerShell 2 Consistency 0


Could be worse I suppose.

PowerShell v6 and PowerShell Direct

Not seen this reported anywhere so thought I post.


PowerShell v6 went to GA in January 2018. PowerShell Direct is a feature of Windows 10/Windows Server 2016. By accident I found that PowerShell v6 and PowerShell Direct work together.


PowerShell v6 is based on .NET core which is basically a subset of the full .NET CLR (that powers Windows PowerShell )


PowerShell Direct is a technology by which a PowerShell v5.1 session on a Windows 10/Windows Server 2016 Hyper-V host can establish a remoting session to a Windows 10/Windows Server 2016 virtual machine over the VM bus rather than using WSMAN.


By default PowerShell v6 can’t access the Hyper-V module but if you add the PowerShell v5.1 module path to the PowerShell v6 module path:

$env:PSModulePath = 'C:\Windows\System32\WindowsPowerShell\v1.0\Modules\;' + $env:PSModulePath


You can then create a credential

$cred = Get-Credential manticore\richard


This is required because you’re not relying on Kerberos to authenticate as you do in standard remoting within the domain.

You can then create your session:

$s = New-PSSession -VMName W10PRV01 -Credential $cred


And use it

Invoke-Command -Session $s -ScriptBlock {Get-Service}


The session has a ComputerType of VirtualMachine

PS> $s | fl

ComputerType : VirtualMachine
ComputerName : W10PRV01
ContainerId :
VMName : W10PRV01
VMId : 374d0569-3b22-441d-84dc-802aed67dea9
ConfigurationName :
InstanceId : c6e6b1c1-8ed5-409f-be4c-0a1262342cb7
Id : 1
Name : WinRM1
Availability : Available
ApplicationPrivateData : {DebugMode, DebugStop, UnhandledBreakpointMode, PSVersionTable...}
Runspace : System.Management.Automation.RemoteRunspace
State : Opened
IdleTimeout : -1
OutputBufferingMode :
DisconnectedOn :
ExpiresOn :


You can also enter the session

PS> Enter-PSSession $s
[W10PRV01]: PS C:\Users\Richard.MANTICORE\Documents>


I’ve not tried all the Hyper-V cmdlets but the Get* cmdlets that I have tried all work.

PowerShell v6.0.1

PowerShell v6.0.1 is available from


This release upgrades PowerShell to use .NET core v2.0.5 which addresses a couple of security vulnerabilities. The release also addresses upgrade issues on some Linux distributions due to version numbers being misunderstood.


Also available is the v1.0.0 beta for OpenSSH This version supplies one of my wishes for 2018 in that the installation and configuration is much simpler

PowerShell v6 GA and beyond

PowerShell v6 achieved General Availability on 10 January 2018.


Why do these things always happen when I’m in a plane over the Atlantic?


GA is a tremendous milestone but its not the end by any means. Work has already begun on v6.1


Note a service release at the end of January to use .NET core 2.05

V6.1 looks to be planned for about 6 months from now with some interesting features.

Windows Compatibility Pack

As reported last month the Windows Compatibility Pack for .NET core is available. This adds back some of the functionality missing from .NET core. This functionality is ONLY of relevance on Windows machines.


A PowerShell module based on the Compatibility Pack is in the works – this will add a number of cmdlets including the WMI cmdlets back into PowerShell v6 on Windows. There’s no ETA on the module at this time.


There is a module on the PowerShell gallery that will add the .NET components of the Compatibility Pack into your PowerShell v6 session.

PS>  Find-Module -Name PSCoreWindowsCompat | ft -a

Version Name                Repository Description 
 ------- ----                ---------- ----------- PSCoreWindowsCompat PSGallery  Provides the Microsoft.Windows.Compatibility Pack to PowerShell Core.


If you want to inspect the module

PS>  Save-Module -Name PSCoreWindowsCompat -Repository PSGallery -Path C:\Source\ -Force


To install the module:

PS>  Install-Module -Name PSCoreWindowsCompat -Repository PSGallery -Verbose -Force 
 VERBOSE: Repository details, Name = 'PSGallery', Location = ''; IsTrusted = 'False'; IsRegistered = 'True'. 
 VERBOSE: Using the provider 'PowerShellGet' for searching packages. 
 VERBOSE: Using the specified source names : 'PSGallery'. 
 VERBOSE: Getting the provider object for the PackageManagement Provider 'NuGet'. 
 VERBOSE: The specified Location is '' and PackageManagementProvider is 'NuGet'. 
 VERBOSE: Searching repository ''PSCoreWindowsCompat'' for ''. 
 VERBOSE: Total package yield:'1' for the specified package 'PSCoreWindowsCompat'. 
 VERBOSE: Performing the operation "Install-Module" on target "Version '' of module 'PSCoreWindowsCompat'". 
 VERBOSE: The installation scope is specified to be 'AllUsers'. 
 VERBOSE: The specified module will be installed in 'C:\Program Files\PowerShell\Modules'. 
 VERBOSE: The specified Location is 'NuGet' and PackageManagementProvider is 'NuGet'. 
 VERBOSE: Downloading module 'PSCoreWindowsCompat' with version '' from the repository ''. 
 VERBOSE: Searching repository ''PSCoreWindowsCompat'' for ''. 
 VERBOSE: InstallPackage' - name='PSCoreWindowsCompat', version='',destination='C:\Users\Richard.MANTICORE\AppData\Local\Temp\51711061' 
 VERBOSE: DownloadPackage' - name='PSCoreWindowsCompat', version='',destination='C:\Users\Richard.MANTICORE\AppData\Local\Temp\51711061\PSCoreWindowsCompat\PSCoreWindowsCompat.nupkg', uri='' 
 VERBOSE: Downloading ''. 
 VERBOSE: Completed downloading ''. 
 VERBOSE: Completed downloading 'PSCoreWindowsCompat'. 
 VERBOSE: InstallPackageLocal' - name='PSCoreWindowsCompat', version='',destination='C:\Users\Richard.MANTICORE\AppData\Local\Temp\51711061' 
 VERBOSE: Catalog file '' is not found in the contents of the module 'PSCoreWindowsCompat' being installed. 
VERBOSE: Module 'PSCoreWindowsCompat' was installed successfully to path 'C:\Program Files\PowerShell\Modules\PSCoreWindowsCompat\'.


Notice the installation path is OUTSIDE of the current version of PowerShell v6 so should remain available through any upgrades.

PS>  Import-Module -Name PSCoreWindowsCompat


Now you’ve got it how do you use it? The module DOESN’T have any functions – it just loads the .NET namespaces.


Its back to PowerShell v1 days – everything is a script instead of a cmdlet. For instance the Compatibility pack contains the System.DirectoryServices so you can script against AD.


Let’s say you want to see all the users in the domain:

$dom = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain() 
 $root = $dom.GetDirectoryEntry()

$search = [System.DirectoryServices.DirectorySearcher]$root 
 $search.Filter = "(&(objectclass=user)(objectcategory=user))" 
 $search.SizeLimit = 3000 
 $result = $search.FindAll()

foreach ($user in $result){ 


Use System.DirectoryServices.ActiveDirectory.Domain to get the current domain. Create a System.DirectoryServices.DirectorySearcher object and set the filter to users. Find all of the users and display their distinguishedname


Its a lot more complicated than using the cmdlet:

PS>  Get-ADUser -Filter * | select DistinguishedName


but it gets the job done.


If you need to administer AD and you need the cross platform capabilities of PowerShell maybe you should use the  PSCoreWindowsCompat module (with aplogies to A-Team fans everywhere)

PowerShell v6: #9 Release candidate 2 features

A couple of features of PowerShell v6 release candidate 2 need commenting on.


Firstly, I was surprised when installing RC 2 on a Windows 10 machine (Insider build) that RC1 was removed. In the past you’ve been able to run numerous versions of PowerShell v6 side-by-side. This has consequences if the behaviour continues into the GA version and the 6.1 alpha/beta releases as you’ll have to choose between the stable, production version and the changeable new version.


Secondly, and this one was publicised by the PowerShell team, Pester is no longer installed by default with PowerShell v6. You can download the latest version of Pester from the PowerShell gallery. Not sure on thinking behind this decision but the download is easy so it’s not a deal breaker –you just have to remember to do it. May be best to use Save-Module for the download so you don’t have to perform the download if a new version of PowerShell v6 becomes available and overwrites the current version.


Next job is to install the OpenSSH optional feature and see how that goes. Be very interested to see if and how its updated as new versions of the  Windows Insider builds are released.

PowerShell v6: #8 Release candidate 2

Release candidate 2 for PowerShell v6 is available for download from -


One worrying point is the the OpenSSH implementation which is required for remoting to and from Linux systems doesn’t appear to be any where near a release candidate - The latest release as of this writing is The steps to install OpenSSH are still too complicated and time consuming. There is an installation script but it doesn’t complete all of the manual steps!


at the moment I’d really recommend that you only install OpenSSH where you need it and don’t consider it as a replacement for WinRM based remoting apart from a few narrow scenarios:

- Windows <-> Linux remoting

- Cross domain remoting

- Remoting to or from a non-domain system


Ducks need to be lined up if PowerShell v6 is going to GA in January 2018

PowerShell v6: #7 Module paths

There is a very significant gap between the functionality available in PowerShell v6 as opposed to PowerShell v5.1. In part this is due to the underlying version of .NET but mainly to the defined module paths in the two versions.

In PowerShell v5.1 I have:

PS>  $env:PSModulePath -split ';'
C:\Program Files\WindowsPowerShell\Modules


In PowerShell v6 I have

PS C:\scripts> $env:PSModulePath -split ';'
C:\Program Files\PowerShell\Modules
c:\program files\powershell\6.0.0-rc\Modules


The vast majority of the module supplied with PowerShell v5.1 reside in C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules which PowerShell v6 can’t see.


Unless you add it in yourself

$env:PSModulePath = $env:PSModulePath + ';C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules'


I’ve appended the PowerShell v5.1 modules to the PowerShell v6 module path.


There’s still no guarantee that the modules will work – it depends on the module code and if it accesses .NET classes that aren’t available in .NET core.


You’ll have to use trial and error to determine what works. For instance:


all work. BUT they’re from CDXML modules based on CIM classes not binary modules. As a rule thumb I’d expect the CIM based modules to just work. Binary module will definitely be trial and error.

PowerShell v6: #6 Windows compatibility

PowerShell v1 through v5.1 have been based on the full .NET framework. PowerShell v6 is based on .NET core which is a cross platform subset of .NET that’s available for Windows, Linux and mac. This has meant that Powershell v6 on Windows is a poor relation of PowerShell v5.1 in terms of the functionality available – for instance the Active Directory module won’t run on PowerShell v6. This makes v6 a backward step for administering Windows. Steps are being taken that will improve Windows compatibility of PowerShell v6.


The .NET core team are releasing a Windows compatibility pack – see for what’s likely to be in it.

A number of cmdlets including:

WMI cmdlets

Eventlog cmdlets

PerCounter cmdlets


are ear marked for being ported to PowerShell v6 using the compatibility pack. When this happens and what else is will be included is unsure. You can follow the issue at