Monthly Archive

Categories

PowerShell v6

More PowerShell v6 thoughts

My last post - about PowerShell v6 – brought some interesting comments. Here’s some more PowerShell v6 thoughts generated by those comments.

Comment Quote 1

“What’s the incentive to upgrade on Windows from 5.1 to 6.x? My understanding is that not all functionality is present in the open source version (specifically, WIM and COM). It’s not functionality that I use, personally, but I don’t see much reason to “upgrade” while the new version is still working to reach feature parity. “

Reply:

PowerShell v6 supports COM. I don’t use WIM so don’t know how much WIM support is available in Windows PowerShell. If it was meant to be WMI then v6 has always included the CIM cmdlets which are a better choice than the WMI cmdlets. The WMI accelerators are also available in v6 if you need them.

All of the CDXML (CIM/WMI) based modules that I’ve tested work in v6.

 

Comment Quote 2

“Also, and this is not as trivial as it seems, the command name changes from “powershell” to the incredibly ugly “pwsh” – which will wreak havoc with many scripts and people’s muscle memory”

Reply:

The official reason for the introduction of pwsh was that it was confusing having 2 powershell.exe on the PATH when you have v6 and v5.1 installed on the same machine. Having said that the thread that introduced the change was originally about reducing the length of the executable name because Linux users didn’t want to type powershell – it was deemed to be too long! Pwsh was a compromise and like all compromises usually pleases no one.

 

Comment Quote 3

“So I think that all this data shows is that Powershell 6.x is growing in popularity on Linux, but it’s not yet an attractive alternative to 5.x for Windows users. I certainly hope that the message Microsoft take from the figures is that they’ve got some way to go yet to persuade Windows users that the new Powershell is an actual improvement, and not to further abandon Windows Powershell users!”

Reply:

The problem with PowerShell on Linux is that much of the PowerShell functionality we take for granted on Windows – networking, storage, WMI – just isn’t available on Linux. There isn’t much on the gallery either for Linux as far as I can see. So why the great usage on Linux? To my mind PowerShell on Linux is currently around the Windows PowerShell v1-v2 level for functionality.

The WindowsCompatibility module makes most, if not all, Windows PowerShell modules work in v6 but its a workaround not a long term solution.

I have a lot of difficulty understanding where PowerShell v6 is going – hopefully more will be revealed in 2019.

 

Comment Quote 4

“If I can’t do ActiveDirectory administration with V6 then it is a show stopper in most “Windows” shops”

Reply:

On Windows 10 1809 / Server 1809 / Server 2019 the AD module works in PowerShell v6.1.1 EXCEPT when trying to access or modify the protected from accidental deletion attribute.

The AD module works in PowerShell v6.1.1 via the WindowsCompatibility module on earlier versions of windows

PowerShell dashboard

The PowerShell dashboard shows some interesting data:

https://msit.powerbi.com/view?r=eyJrIjoiYTYyN2U3ODgtMjBlMi00MGM1LWI0ZjctMmQ3MzE2ZDNkMzIyIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9&pageName=ReportSection5

 

Linux is by far the dominant platform for PowerShell v6 usage – about 4 times as much usage on Linux as Windows for December 2018!  Does this mean that PowerShell is destined to become a Linux orientated tool?  It has been stated by the PowerShell team that usage patterns will drive development so Windows users need to step up if they want input into future PowerShell

 

PowerShell 6.1 is taking over from 6.0 but a significant number of users are still using 6.0 and 6.1 previews – Why?

 

Very little V6.2 preview usage is recorded

 

Windows 10 is the dominant Windows version for PowerShell v6

 

North America accounts for just over half the v6 usage. UK is next at 4.91%.  Time for the rest of the world to contribute?

 

PowerShell is now open source and as such will be driven by “the community” in other words those how get involved and push their needs and/or pet views of where PowerShell will go. Is that a good thing?

 

The idea behind Windows PowerShell was for it to become the de facto scripting language and automation engine on Windows. It succeeded. What is the long term PowerShell v6 goal? Is to become the de facto cross-platform scripting language and automation engine? if so there needs to be a ton of functionality appear so that Linux can be managed at the same level as Windows.

Group-Object change in PowerShell v6.1

There’s a subtle Group-Object change in PowerShell v6.1.

In PowerShell v5.1 if you do this:

$ts = 'ffrluoluntlvxutxbdvbktgyyvsvcrkxoyfotzkzogcwuwycmnhuedk'
$ts.ToCharArray() | group

 

You get this:

Count Name Group
----- ---- -----
    3    f {f, f, f}
    2    r {r, r}
    3    l {l, l, l}
    5    u {u, u, u, u...}
    4    o {o, o, o, o}
    2    n {n, n}
    4    t {t, t, t, t}
    4    v {v, v, v, v}
    3    x {x, x, x}
    2    b {b, b}
    2    d {d, d}
    4    k {k, k, k, k}
    2    g {g, g}
    4    y {y, y, y, y}
    1    s {s}
    3    c {c, c, c}
    2    z {z, z}
    2    w {w, w}
    1    m {m}
    1    h {h}
    1    e {e}

 

If you repeat the exercise in PowerShell v6.1 you get this:

Count Name Group
----- ---- -----
    2    b {b, b}
    3    c {c, c, c}
    2    d {d, d}
    1    e {e}
    3    f {f, f, f}
    2    g {g, g}
    1    h {h}
    4    k {k, k, k, k}
    3    l {l, l, l}
    1    m {m}
    2    n {n, n}
    4    o {o, o, o, o}
    2    r {r, r}
    1    s {s}
    4    t {t, t, t, t}
    5    u {u, u, u, u...}
    4    v {v, v, v, v}
    2    w {w, w}
    3    x {x, x, x}
    4    y {y, y, y, y}
    2    z {z, z}

 

In PowerShell v6.1 the results are automatically sorted by the Name (the same behaviour is exhibited in PowerShell v6.2 preview 3). That may, or may not, be what you want. Not sure exactly when, or even why, this behaviour changed.

 

When I’m using Group-Object I’m usually looking for the most or least common item so I tend to sort on value.

 

I don’t understand the value of this change and suspect its yet another change to PowerShell that was introduced to meet someone’s pet view of the world – one of the major problems of open source projects no one seems to really apply the “just because we can doesn’t mean we should filter”.

Return of the missing PSDiagnostics

Return of the missing PSDiagnostics members in PowerShell v6.2 preview 3.

 

In Windows PowerShell v5.1 the PSDiagnostics module contains these members:

Disable-PSTrace
Disable-PSWSManCombinedTrace
Disable-WSManTrace
Enable-PSTrace
Enable-PSWSManCombinedTrace
Enable-WSManTrace
Get-LogProperties
Set-LogProperties
Start-Trace
Stop-Trace

 

In PowerShell v6.1.1 you just get these:

Disable-PSTrace
Enable-PSTrace
Get-LogProperties
Set-LogProperties

 

Quite a few missing.

In PowerShell v6.2 preview 3 we’re back to the original set:

Disable-PSTrace
Disable-PSWSManCombinedTrace
Disable-WSManTrace
Enable-PSTrace
Enable-PSWSManCombinedTrace
Enable-WSManTrace
Get-LogProperties
Set-LogProperties
Start-Trace
Stop-Trace

 

NOTE: this is just on Windows – I don’t have a non-Windows machine to determine what’s available on non-Windows platforms

Join-String

Join-String is a new cmdlet in PowerShell v6.2 preview 3. Join-String enables you to use the pipeline to join strings.

 

We’ve had the –join operator for a long time:

PS> 1..3 -join ','
1,2,3

 

As an alternative you could do

PS> 1..3 | Join-String -Separator ','
1,2,3

 

You can add a prefix and suffix to the final string:

PS> 1..3 | Join-String -OutputPrefix 'A' -OutputSuffix 'b' -Separator ','
A1,2,3b

 

You can use the property of objects on the pipeline as a source for the data:

PS> Get-ChildItem -Path C:\Scripts\Techniques\ | select -ExpandProperty Basename | Join-String -Separator ','
arrays,numbertechniques,stringtechniques

 

Quotes – single or double – can be added

PS> Get-ChildItem -Path C:\Scripts\Techniques\ | select -ExpandProperty Basename | Join-String -Separator ',' -SingleQuote
'arrays','numbertechniques','stringtechniques'

PS> Get-ChildItem -Path C:\Scripts\Techniques\ | select -ExpandProperty Basename | Join-String -Separator ',' -DoubleQuote
"arrays","numbertechniques","stringtechniques"

 

The current culture can also be use to influence the string. For instance dates:

PS> Get-Date

11 December 2018 16:25:43

PS> Get-Date | Join-String
12/11/2018 16:25:52

 

To me the string version of the date reads 12 November 2018 not 11 December 2018 so I need to use my culture

PS> Get-Date | Join-String -UseCulture
11/12/2018 16:26:54

 

And now it looks correct.

 

I suspect that Join-String will become one of those cmdlet that has many, many uses. For instance an easy way to create sequential file names:

PS> 1..5 | foreach {$_ | Join-String -OutputPrefix 'File' -OutputSuffix '.txt'}
File1.txt
File2.txt
File3.txt
File4.txt
File5.txt

PowerShell v6.2 preview 3 install issue

PowerShell v6.2 preview 3 install issue - PowerShell v6.2 preview 3 is now available from https://github.com/PowerShell/PowerShell/releases but you may notice a probloem if you install over the top of PowerShell v6.2 preview 2.

 

When you click on the icon to start preview 3 the console will flash open and then immediately close.

 

The fix is to either uninstall preview 2 before installing preview 3 OR install preview 3 over the top of preview 2 and immediately rerun the preview 3 installation selecting the repair option. The install will work through and then PowerShell v6.2 preview 3 will work.

 

The underlying cause is understood and hopefully will be fixed in a later release

Moving FSMO roles in PowerShell v6.1.1

With the Windows Server 2019 media now being available again it’s time to move my test lab over to the new version. I’d built a Windows Server 2019 VM and installed PowerShell v6.1.1. I discovered that in Server 2019 and the Windows 10 October 2018 update that the AD module worked in PowerShell v6.1.1. I decided to try moving FSMO roles in PowerShell v6.1.1 as I updated the domain and removed the old Server 2016 domain controller.

 

The usual schema update went smoothly – updated the schema version to 88 from 87. Installing AD domain services and DNS on the new DC worked. Promoting the Windows 2019 system to be a DC worked with no problems.

 

Time to move the FSMO roles. They would move automatically when the old DC was removed but its always better to control the action.

Import-Module ActiveDirectory

will load the AD module into PowerShell v6.1.1.

 

There are 5 FSMO roles – 2 at the forest level

PS> Get-ADForest | Format-List Name, *master

Name : Manticore.org
DomainNamingMaster : W16DC01.Manticore.org
SchemaMaster : W16DC01.Manticore.org

 

And 3 at the domain level – I only have a single domain to worry about.

PS> Get-ADDomain | Format-List *master, PDC*

InfrastructureMaster : W16DC01.Manticore.org
RIDMaster : W16DC01.Manticore.org
PDCEmulator : W16DC01.Manticore.org

 

The forest level FSMO roles moved:

PS> Move-ADDirectoryServerOperationMasterRole -Identity W19DC01 -OperationMasterRole DomainNamingMaster -Confirm:$false

PS> Move-ADDirectoryServerOperationMasterRole -Identity W19DC01 -OperationMasterRole SchemaMaster -Confirm:$false

PS> Get-ADForest | Format-List Name, *master

Name : Manticore.org
DomainNamingMaster : W19DC01.Manticore.org
SchemaMaster : W19DC01.Manticore.org

 

For the domain level FSMO roles I decided to get ambitious

PS> Move-ADDirectoryServerOperationMasterRole -Identity W19DC01 -OperationMasterRole RIDMaster, InfrastructureMaster, PDCEmulator -Confirm:$false

PS> Get-ADDomain | Format-List *master, PDC*

InfrastructureMaster : W19DC01.Manticore.org
RIDMaster : W19DC01.Manticore.org
PDCEmulator : W19DC01.Manticore.org

 

Moving FSMO roles in PowerShell v6.1.1 was successful

Active Directory cmdlets in PowerShell v6.1.1

Just discovered that you can run the Active Directory cmdlets in PowerShell v6.1.1 BUT there is a huge caveat.

 

The Windows 10 October 2018 (Windows 10 1809) update includes the RSAT tools (including the AD tools) as optional features. This means that you can easily install the AD tools:

Add-WindowsCapability -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 –Online

 

The AD PowerShell module now has a 1.0.1.0 version with the PSEdition set as Core,Desk

 

I’m running the Windows 10 Insider Preview build 18282 which has moved on a bit from Windows 10 1809 and PowerShell Core v6.1.1.

 

The AD module can be imported and the commands that I’ve tried have worked.

 

For the AD cmdlets to work in PowerShell Core looks like you need Windows 10 October 2018 update or later and PowerShell v6.1.1 or later. I’m going to say you should upgrade to v6.1.1 if you have v6.1 as the later version fixes a .NET security bug.

 

This is a big step forward for PowerShell Core being an acceptable replacement for Windows PowerShell though there are still a few gaps to be filled.

Finding the minimum and maximum values

Finding the minimum and maximum values in a set of numbers is ridiculously easy with PowerShell.

I’ve created a function in line with the other techniques I’ve shown but in reality could be be done equally well as a single line of code:

function get-minmax {
[CmdletBinding()]
param (
[int[]]$iarray
)

$mm = $iarray | Measure-Object -Minimum -Maximum

New-Object -TypeName PSobject -Property @{
Minimum = $mm.Minimum
Maximum = $mm.Maximum
}
}

 

Just pipe the array into Measure-Object and use the –Minimum and –Maximum parameters as shown. I created an output object for easier handling if you want to do anything else to the array.

 

You can also get the sum and average of the array with Measure-Object. PowerShell v6.1 adds the Standard Deviation and an –Allstats parameter so you don’t need to specify each individual option:

PS> $iarray = 1,2,3,4,23,5,6,7,8,9,10,23,11,12,13,7,14,15,16,17,18,20,21,22,11,23,24,25
PS> $iarray | Measure-Object -AllStats

Count : 28
Average : 13.2142857142857
Sum : 370
Maximum : 25
Minimum : 1
StandardDeviation : 7.46030057411125
Property :

Test-Connection cmdlet

The Test-Connection cmdlet wasn’t included in PowerShell v6.0 but did make a come back in v6.1.

 

The v6.1 version of Test-Connection has some serious issues as I’ve described before.

 

Work is being done at the moment to remedy those issues – hopefully for v6.2

 

This is your chance to comment on a cmdlet and help determine how it will work.

 

The issues to comment on are:

https://github.com/PowerShell/PowerShell/issues/7685

https://github.com/PowerShell/PowerShell/issues/6557

 

PowerShell v6 is community driven.  This is an opportunity to help drive the PowerShell you want to see.