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. “


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”


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!”


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”


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

This entry was posted in PowerShell v6. Bookmark the permalink.

7 Responses to More PowerShell v6 thoughts

  1. I appreciate the feedback on this sir. I still think the roll out was jarring. It was hard enough to get point and click admins to look at a CLI. Now they are told the product (to include the ISE) are dead. You reference the updates in Desktop and Server builds… I still see signs of V2 around. I like where Core is going but hey I am still not a fan of everything being labeled as DevOPS 🙂

    • Devops is just the latest “thing” in IT. We’ve had similar waves with virtualisation, grid computing, cloud etc etc. IT has to have fads or the “IT” journalists and analyst organisations wouldn’t have anything to write about. Until IT actually grows up its always going to be a roller coaster as the shiny new toys are pushed out. Having said that DevOps has some good ideas and principles that most IT shops should look at. The continuous roll out ideas don’t, and never will, suit many organisations due to their business and the applications they use.

  2. Derek W Price says:

    Honestly, the one that I really miss is Out-GridView. I use it constantly as a sortable data viewer and as a selection tool.

  3. Once I can run all required tools in pwsh, I’ll head on over to the core side. I force myself to use it where I can, but I fail and end up back in WPS. For me its not a CIM thing at all, I’ve been pushing CIM usage around the environment since PS 2.0 days — its the lack of coverage.

    I use dozens of modules from the PSGallery that do not support .NET Core. Dozens.

    While I appreciate the thought, the WindowsCompatibility workaround does not interest me at all.
    I am not interested in refactoring all of my processes to leverage the WindowsCompatibility workaround, just to then undo those changes when it is finally (and properly) fixed.

    Now, I have had it suggested to me, that the changes aren’t that drastic – a simple “Import-WinModule” would clear it up; however, the suggester failed to account for the biggest limitation of implicit remoting — deserialized (dead) objects — AND functions/cmdlets that have parameters of specific types.

    That may be my own personal limitation, I have an (possibly irrational) distaste for deserialized objects — it likely stems from banging my head against the wall when attempting to use the pipeline with Exchange cmdlets in an implicit remoting session (which, by the way, is what MS / Exchange Team recommends (or recommended) in lieu of installing Exchange Management Shell locally – and the only real method of working with Exchange Online. I often wondered if anybody who made this recommendation actually attempted to interactively manage an Exchange environment using this method before they actually made the recommendation.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s