Microsoft finally bids farewell to PowerShell 2.0

Users still clinging on to PowerShell 2.0 just received notice to quit as the command-line tool is officially leaving Windows. The confirmation came in a Windows Insider update. The move away from PowerShell 2.0 is a long time coming; Microsoft has for years encouraged users to move to later versions. Version 5.1 is …

[Anonymous Coward]

Powershell is the most mixed up and convoluted mess of commands I've ever seen. When it works, it works well, BUT... The useful commands are deprecated continually and their replacements need a lot of reading and faffing to get working. Then when you are successful in getting that module operational, there's another command you need from a different PS version to get something else to work. Installing the later version borks your scripts that have been running smoothly because you have to log into the cloud now instead of on-prem.

Every time I install a new module I get the warning:

Untrusted repository

You are installing the modules from an untrusted repository. If you trust this repository,

change its InstallationPolicy value by running the Set-PSRepository cmdlet.

Are you sure you want to install the modules from 'PSGallery'?

So the thing MS is forcing down my throat to run our domain and production servers is not official and actually 'untrusted' by Microsoft? FFS...

The documentation is all over the place and full of out-of-date info. Consistency and Powershell are at opposite ends of the spectrum.

I've got Linux cron scripts that have been running unmodified for ten+ years. Night and frikking day.

[Anonymous Coward]

Yes ...

1000 times agree !!!

Powershell is a 'Good Idea' that has been expanded beyond its original 'idea' and as per usual with MS NOT fully completed before it has been upgraded etc.

What happened to creating software/tools that have documentation that is complete, up to date and comprehensive.

Don't spend money constantly changing it IF the documentation is NOT equally updated & complete.

As a tool for everyday use it is too verbose to use ... yes I know this does not matter if you are writing scripts (Write once, use many times).

Reminds me too much of how 'systemd' (cough spit) has grown too big & complicated !!!

:)

[ecofeco]

This.

[BinkyTheMagicPaperclip]

Definitely agree the documentation could be improved. Microsoft seem determined to push the angle that this is 'a scripting language'.

It's not - it's a full featured language based on .NET that can be called using interpreted scripts.

They should celebrate it - admit it's a proper language, stop trying to hide that, make it easier to create GUI front ends and integrate with addons.

There's a huge amount of power there, it just feels like it's fighting you at times.

[nijam]

> There's a huge amount of power there, it just feels like it's fighting you at times.

Like Microsoft itself (apart from the "at times" proviso).

[JLV]

As a dev, not a sysadmin, I dabbled briefly with PowerShell and I came away with the impression that:

- It is more formal and less text-streamy than bash or zsh. If I were trying to really do sysadmin stuff, in theory (assuming none of the drawbacks and idiosyncracies pointed out above were present), I'd trust the object-orientation more than trying to bulletproof my poor bash scripts to do things that I entrust Ansible with, i.e. spinning up new VMs.

- As a dev, often relying on quick zsh scripts to automate some dev, non-admin, level stuff, I found PowerShell infuriating for precisely that reason. I can't just pipe something simple into something else and fudge the results till they're good enough. I find it very hard to experiment. I have to understand all the arcana of PowerShell commands, for even simple ones, like ls. And, after 2 weeks of not doing PowerShell, I found that I had promptly forgotten most of what I had learned. Consequently, as someone who can use Python, Ansible or just-enough-to-be-dangerous zsh, I don't see any sweet spot for me putting in the effort to really know PowerShell.

[Anonymous Coward]

Spot on !!!

Precisely my 'Verbose' point.

At 1st glance it does appear to be a 'Good Idea' BUT the commandline is too verbose and, to my mind, too baroque in structure.

If you use it every day, of course, you will remember it BUT it does not support casual use !!!

(I know ... The same argument is used against all the 'tools' in Linux BUT it is easier to quickly chain things together to 'hack' a usable result.)

The main problem is that with documentation that is not complete/usable it is a struggle to start using Powershell quickly.

Another example of trying to invent something 'BETTER' that is made 'here' (Microsoft) ... a good intent that is not fully comitted to by allowing the documentation to 'drift' out of sync with the actual tool itself.

Yes, it is a language in its own right, I agree.

:)

[Anonymous Coward]

For me, it's exactly the opposite - Powershell dead easy to try stuff and pipe into something else, other scripting languages not so much. Each to their own.

[Dan 55]

I needed to log onto Sharepoint online to upload a page, I found three different modules for doing it, two of which were deprecated and one of those was knocked on the head on the server side as I was trying to develop using it. I gave up.

[kmorwath]

That's what happen whan you mate Bash and .NET - both bad parents on their own, but the offspring couldn't be anything but awful.

And the worst thing is MS lame developers started to use it in applications too inetead of calling the proper libraries and APIs directly. Exchange became a mess for this reason too - and not only Exchange.

MS had the option to start from scratch and design a better CLI interface - for example, why not something like many SQL ones? Where you can have more statements in the editor, select which one(s) to run, and get output in a separate pane?) - and instead went again for the *nix 1970s teletype UI - really those who don't understand the bad, outdated designs of Unix are doomed to reinvent them, and we will sufer them in secula seculorum.

[JLV]

On top of my preceding criticism concerning PowerShell, I feel it bears pointing out that this level of incompatibility between PowerShell versions is ridiculous, considering that I had to change very little of my bash 3.x scripts to port them to zsh 5.x when macos defaulted to zsh as its primary shell. I haven't checked lately, but I believe they would still run under bash 3.x. Most of my effort had to do with figuring out if $BASH_SOURCE was set as well as being careful around array differences.

Maybe MS needs to meditate on "be conservative in what you send, be liberal in what you accept"?

[Jou (Mxyzptlk)]

There have been no "Versions". Though let me explain here what I actually mean means: Powershell 5.1 is the one which works from Windows 7 up to Server 2025 the same. Reason: Powershell 5.1 is the last "-non-core-non-*nix" version. 5.1 also has quite a number of important fixes for WMI etc packed it when you update on Windows 7 up to Server 2012, like awkward date blunders in Win32_Quickfixengineering when you ran it on non-us windows... And luckily they added handling of long paths with 5.0. Since Server 2016 / Windowns 10 1607 PS 5.1 is supplied by the OS (might have been with the release version of Windows 10 too, too lazy to check).

If you choose you can download and use later versions, but unless you use linux or need a special thing they added to PS 6+ don't. The had to change a lot to incorporate the unix "/" for directories, for example. On top of that, even if you have the later versions installed, you "5.1 only" script are still fine. All the OS supplied commandlets and modules (for Active Directory and the tons of other services) are written in 5.1 language too.

[UnknownUnknown]

Perhaps they can stop it auto installing and go straight to PS 5.x or better still 7.x.

Different apps, interfaces and inconsistencies abound make it a confusing hot mess.

[Jou (Mxyzptlk)]

OS integrated is not "auto installing". "go straight to PS 5.x" where 5.1 is integrated in the OS since 2016, and available for Win7/2008R2/Win8/Server2012. "or better still 7.x" first complain about auto install, which it doesn't, then complain about "going straight" to an 9 year old version or the current version?

You nick obviously refers to the question whether you have a brain or intelligence?

[Nick Ryan]

Add in the fact that Microsoft happily deprecate entire modules that were previously the only way to do something with a new module that simultaneously is incomplete as it does not feature all the functionality of what it replaces but where the only documentation is documented automatically generated from the command specification for a prior version of the incomplete replacement module.

That Microsoft claim to use PowerShell internally, is laughable as they regularly terminally break things that cannot have ever be tested anywhere and then sometimes the only functionality available is in an almost equally broken Microsoft Graph interface that apparently the PowerShell commands are just wrappers around. After a bit of PowerShell scripting it becomes very obvious why much of the internals of Microsoft 365 are in a perpetual state of almost working while also doing this very, very slowly.

[Jou (Mxyzptlk)]

Which module? Got an example? I am not doing any O365, that is what my co-workers do, so I am curious whether it applies to any non-O365 module. As for the O365 stuff: I hear my cow-orkers moo often enough loudly, so I won't be surprised there...

[An_Old_Dog]

Limited Shelf Life

I learned my lesson about not investing time into learning vendor-specific scripting languages after Apple revised AppleScript, failed to provide a script-migration program, and broke every one of my scripts.

Never again.

[Sandtitz]

Re: Limited Shelf Life

Why limit to vendor-specific languages?

Perl, Python and many others have broken backward compatibility as well between versions. Or have you really fixed all compatibility problems with some script-migration program?

I'm not familiar with AppleScript at all but the aforementioned languages have telegraphed the upcoming deprecations and changes well in advance and the support for old and new versions' support dates have had plenty of overlap for testing and migrating.

[An_Old_Dog]

Re: Limited Shelf Life

• AppleScript: when I first used AppleScript, then only way to create and edit AppleScripts was with Apple's GUI program, in which you dragged little keyword-boxes around, and typed values into the little parameter boxes. I don't recall whether or not the program automatically created the connecting lines between the boxes or not. It was dead-easy to learn, no docs required (at least for me), but it was slow to create scripts, vs typing in a text editor. At the same time, the system prevented you from making keyword typos and syntax errors. When the new version came out, the GUI program would not open the older-version files! There you were, fsck'd, dead in the water. You couldn't just open up an old AppleScript file in a text editor and change, say "print" to "output".

• Python: I don't go there.

• Perl: I go there a lot. During the Y2K runup, I created a DSL that I processed with Perl scripts to produce the hard copy for my Y2K test plans (which the testers filled out by handwriting). Everyone else in my tech group jabbed themselves in their eyes by using Excel (badly) as a "text editor". LOL.

Due to my programming style, and/or luck, I haven't had to revise any of my Perl programs (I started with Perl 4.19). That said, I'm sticking with Perl 5.X.

[JLV]

Re: Limited Shelf Life

Python....

First, yes, let's acknowledge it, it was a pretty traumatic experience for the community and people still shudder at it. Yes, it cleaned up some important design flaws and laid better foundations. But it was still a pain.

On the flip side, speaking for the mid/advanced level of users, it also was done fairly cleverly and about as doable as could be...

- Years in advance, most of 3x's incompatible syntax was made optional in Python 2x. For example, Python 2's historical syntax was `print "foo"` but also supported 3's `print("foo")`. That covered about 80% of things. So most of your 2x code could have run under 3x unmodified, if written with that in mind. Deeper, non-syntax, things like network data where 2's strings were split up into 3's strings and bytes were admittedly harder to plan for.

- A bridge module, 2to3 was developed that allowed you to provide some backward compatibility to 2 in 3 code by using some of its special capabilities, via shims.

- At least one CLI conversion utility/linter (maybe also called 2to3?) was developed that allowed you to lint and auto-convert files. Like linters, with options to turn off certain checks.

I know this, because I converted about 50k LOC in about 2 weeks of relaxed work, based on using 3 syntax in advance, having high unit test coverage and lots of automated regression checking and didn't even bother to use 2to3 shims very much, preferring to stick mostly to a home-brewed module of aliases and IF-3-THEN-ELSE hacks that I understood better and could take out at leisure later. bash & sed, along with the 2to3 conversion cli were my friends. For much of that 2 weeks I was unit testing the same exact files with a 2x interpreter and a 3x interpreter and checking that the behavior was the same, starting with the lowest level utility modules first.

So, no, it was not, quite, a case of failed to provide a script-migration program, and broke every one of my scripts..

[Fara82Light]

Final straw

PowerShell was the final straw.

We ended up using CygWin instead and gradually deprecated the Microsoft platforms.

[david 12]

Oh bullshit.

So when I looked at PowerShell 2, the way it supported system scripting was using COM objects. The same COM objects used for system scripting in VBS, the previous MS system scripting tool.

[Danny 14]

Re: Oh bullshit.

back then we used to use VBS instead of PS2, they ran faster too as it didnt need to load the PS overheads.

[Jou (Mxyzptlk)]

Powershell 3.0 = Vista version

Vista came with PS 2.0 delivered, could be upgraded to 3.0. I probably won't miss PS 2.0.

Windows 7 and Server 2008 R2 can but updates to Powershell 5.1. So with 5.1 you have that one version of PS which acts the same from Windows 7 up to Server 2025, relatively stable, with a few know quirks which are the same across a very wide range of MS-oses. Hence I make my stuff all with PS 5.1, whether it be RS485 communication with Growatt MIC and Marstek Venus, playing around with shellies, drawing nice graphs, hack things into active directory MS-docs say "not possible with powershell" - oh well, I must be doing it wrong if I make it work!

Around 98% to 99% of the time without needing external modules, since on many customer environments external, non OS-supplied, PS modules are frowned upon. And I cannot blame them :D.

In the end PS 5.1 is a worthy scripting enhancement, compared to CMD, and since you can access DOTNET and C(+) inline, and can access the .DLLs in the system directly.

One thing I like about PS above MANY other languages: All variables are preceded with a $ sign. In way too many languages you cannot distinguish between variable and non-vairable keyaords, making it unnecessarily difficult to start with them unless you have a special editor which knows all that stuff for you. Which is what I hate about .VBS, for example. And much better structured than VBS, or Python...

And, in comparison to unix *sh, it is object oriented. Very big advantage that you do NOT have to decipher/cut/sed/grep/awk/ed/etc string and binary streams by default, which is prone to fail in edge cases much easier.

[Rahbut]

Re: Powershell 3.0 = Vista version

I would agree that PowerShell is not that bad - it can be the right tool for the job, depending on the job. It took quite a few iterations to get to that point, if we're honest. PowerShell 7 is fairly decent.

I'm not sure that I'm overly fussed about stuff being Object Oriented anymore, and I'd agree with everyone saying it's verbose.

I suspect my biggest issue with Powershell isn't so much the scripting itself or the cmdlets, rather what people have done with it. It's nearly always PS when I'm presented with an incomprehensible script running into 000's of lines! That said, the fact people can write monstrous scripts with it would indicate it's fairly straightforward to pick and use. I've seen similar in Python and good old VBScript back in the day. I think ease of use could be considered a positive.

These days I'd probably look to use a combo of Bash and Go for things I might have used PS for in the past, but therein lies the issue for MS... there's no real compelling reason to put workloads on Windows these days, and there are plenty of options when you move away from Windows.

[Fruit and Nutcase]

Picture

The picture accompanying this article...

https://regmedia.co.uk/2018/06/18/funeral.jpg

Reminds me of the funeral scene with the open casket in the film Charade with Audrey Hepburn

Perhaps some of the commentards here may wish to do the same as these mourners to check on it's (v 2.0) demise

Tex Panthollow - James Coburn

https://www.youtube.com/watch?v=a8FA5zBHiFA&t=92s

Herman Scobie - George Kennedy

https://www.youtube.com/watch?v=a8FA5zBHiFA&t=150s

Full scene...

https://www.youtube.com/watch?v=a8FA5zBHiFA

[Anonymous Coward]

Attack surface

Powershell greatly increases the attack surface. I used Policy Editor to try to disable it to different degrees over the years but MS changes that.

Convenience for admins is behind much, maybe most, infections and breaches. Instead of blaming users for clicking something dangerous, blame the OS and IT people for providing users with Ford Pintos full of nitroglycerin then telling users to never slam on the brakes. Give them classes on how to avoid slamming in the brakes. Give them helmets and fireproof clothing and fire extinguishers. All in order to keep using Ford Pintos, which explode when rear ended.

I have a very low opinion of most corporate IT.

[Jou (Mxyzptlk)]

Re: Attack surface

Since about Windows 7 / Server 2008 R2 more and more things were ONLY possible via powershell. The reason given was that admins asked for automatisation, which is not feasible with GUI. If you want to do the same thing on 50+ servers...

[kmorwath]

Re: Attack surface

GUI calls APIs - and an API can be called by any tool that is able to use the proper ABI. API also allows for far better error handling. Having to call scripts instead of APIs is a step backwards, not a step forward...

[Anonymous Coward]

Why

Why does Microsoft always do something entirely divergent from the Unix/Linux world? Do they think they will lose sales to Linux if they adopt well proven technology. We have had scripting languages & shells coming out of our ears on Linux, why not just adapt one & create the api/interfaces for one. Maybe the gains woud cancel out the losses? I.e., why does Powershell exist.

[Zippy´s Sausage Factory]

Re: Why

It existed because some Microsoft employee wrote it out of frustration there wasn't a decent shell available for Windows, and the MBAs took it up and ran with it.

Personally I hate it with the passion of a thousand burning suns and feel it should be nuked from space.

[martinusher]

Bash was an option, believe it or not

If you install Cygwin, the code that emulates Linux on Windows, then the default prompt is bash. Unlike regular bash, though, this program knows how to run Windows programs -- they're all just Windows executables, after all -- so you can mix and match Windows with traditional shell commands/utilities as you think fit. You can can even use the '!#' construct to invoke scripting languages if that's what you want to do.

Cygwin has been the go-to for mixing Linux and Windows for years. Although MS has pushed back with their pseudo:Linux and their pseudoBash but its all really 'embrace, extend, extinguish' -- only the truly faithful or those under mandate from the C-Suite would believe this was progress.