I support the point.

PowerShell 7+ makes the difference.

Luckily, I have an option to install PowerShell 7+ on my machines; alas, a lot of other people don't, so making it inbox would help those.

Exactly!

Indeed!
I develop in 7.x and it is always a bother to check for compatibility. Since 5.x is retrocompatible in 7.x, why not?

Indeed!

Everything as far as I'm aware is backward compatible

it isnt

@BlackV even in those cases where the two are not compatible, similarly if shipped with the OS then presumably there would be a period where the two are installed side-by-side.

The user could and should explicitly call out which version either powershell.exe or pwsh.exe they will be using so cases where the two might not be compatible issues can be mitigated.

PowerShell Core is built on top of .NET Core. And the latter isn't shipped with Windows as well, to avoid the need to support the Windows version as long as that version of Windows 10 is supported. In other words, to separate the lifecycle of the two products. See https://www.reddit.com/r/dotnet/comments/fc0g0k/why_is_net_core_not_distributed_automatically/

To better support enterprise life-cycles and stability, an included version could even be set to follow the LTS release cycle via Windows Update.

Also, the security benefits of being able to use SSH authentication across the board for all remote powershell authentication would be SO nice.

but SSH is something you'd have to enable/install and configure on each of those systems as well

This would allow me to develop all of my PowerShell for PowerShell 7 across my enterprise

It wouldn't.
Some cmdlets only work in windows, like DFS, IIS, AD, DNS, DHCP.
Im not even talking about 3rd party modules that are not being updated above 5.x
There are changes in behavior in PS7 that have not been added to 5.x as it rides on the back of update to .net core and aren't in 4.7x and might never get there

This would allow me to develop all of my powershell for powershell 7 across my enterprise without having to worry about installing it on every device across the enterprise. Updates could take place via windows update. Would be so nice.

It seems kind of common sense to include it in the OS despite whatever the challenges are.

Also, the security benefits of being able to use SSH authentication across the board for all remote powershell authentication would be SO nice.

So much this. I can't imagine the ldap, adsi, and other underpinnings are that complicated to port AD cmdlets.

This seems so lame claiming Microsoft can't figure out how to code their own tech.

Instead we get garbage like WAC which is broken from inception, instead of fast functional componentry without 10 layers of indirection from win32.

And, this probably goes without saying, but increased adoption amongst the DevOps community helps solidify Microsoft's place as an industry leader and will encourage adoption of their other products.

Powershell would be perfect for doing a quick test of an API, but the Module in PS5 has many quirks that make it work very different from what I would expect. The PS7 version is far closer to the expected behavior.

But ISE is there, out of the box. VSC is an additional software, that needs to be installed and patched. Enterprise customers doesn’t like that. At least many of the enterprises I talk to.

I would not advocate for shipping VS Code with Windows at all. Just letting @weyCC81 know that VS Code does have a PowerShell ISE theme for those that want it. :)

Neither do I. Including a development tool with Windows was a mistake. Such a tool is difficult to maintain and scale.

Nowadays, PowerShell development requires complex tooling well beyond ISE, including NuGet, dotnet.exe, Git, and Pester.

At least one of those things ships with Windows. :) WinGet makes the rest easy.

A big difference between the ISE and VS Code is that ISE executes the script line by line while VS Code executes it as a Script. That causes issues with the script if e.g. you do not reset your aggregating arrays in between (because you do not need to in the script). Also variables like $PSScriptRoot do not work in ISE

I'd love an overhaul of the PS ISE if not a swap to vscode...

At least one of those things ships with Windows. :) WinGet makes the rest easy.

Alas, an outdated version that doesn't self upgrade! :( We need another discussion post setup to get the built-in WinGet updated as well.

Yes, it’s unbelievable, that ms does not ship a current .Net or PowerShell with windows.
They have no problems including several bloat-ware tools nobody asked for with a fresh windows, but refuse to include really useful stuff they developed like .Net or PS.

.NET 9 isn't a replacement for .NET Framework 4, though - those two are separate products, existing side-by-side.

Since day one, different versions of .NET have been installed side by side. No version of .NET has ever replaced another version. Binaries that depend on .NET version X cannot be satisfied by installing .NET version Y.

Other than that, .NET 9 is the successor of .NET Framework 4.x and .NET Core 3.1, and a very competent one at that. .NET 9 has much higher performance.

.NET 9 isn't a replacement for .NET Framework 4, though - those two are separate products, existing side-by-side.

This is Microsoft dogma. You need to upgrade your 4 to 6,7,8,9 and beyond. The controversy here is that Microsoft did not prioritize compatibility with its own product offerings, presumably to deter people and push them to the cloud. The Windows products have suffered considerably from things like not improving on the MMC, win32 based offerings, and instead focused on higher level abstractions like react and web based things which suffer from horrible performance. Has there ever been a hot steaming pile of poo bigger than WAC?

The controversy here is that Microsoft did not prioritize compatibility with its own product offerings

The strong compatibility requirement for .NET Framework 4.x has prevented many of the evolutions. You couldn't get all the improvements these years with full in-place compatibility.
The legacy, compatible version may continue to exist forever like VB6, for enterprises who care. The modern one can be shipped additionally, but no chance to replace .NET Framework.

Server 2025 has removed the 2.0 engine https://learn.microsoft.com/en-us/windows-server/get-started/removed-deprecated-features-windows-server-2025#features-weve-removed-in-this-release. I would be surprised if ISE is removed before 5.1 is removed or at least turned into something like the 2.0 engine component.

maybe start a project that begins making the compatible with PowerShell (core)

I have no idea if there is some driver behind it but you can always see the latest compatibility matrix with the windows modules and powershell 7 at https://learn.microsoft.com/en-us/powershell/windows/module-compatibility?view=windowsserver2022-ps. I do agree that more work needs to be done here before 5.1 is booted out.

This is the default on Windows 11 24H2 which is what i was referring to, not Windows Server.

This appears to already be in the works:
https://devblogs.microsoft.com/powershell/windows-powershell-2-0-deprecation/#:~:text=In%20summary%2C%20the%20deprecation%20of,the%20above%20as%20a%20guide.

Best to write new code for PowerShell 5.x+ but if you have the ability in your org to use 7.x go with that. :-)

That was just an example and I agree that it's not a feasible setting. I guess I should have clarified my point better.

I wanted to address that PS7 is not just a newer version but a newer product. The habitual assumptions expecting PS7 would act as is with some fancy new features is completely wrong. As PowerShell was designed to be shell on top of the OS, there were some ties and contracts, which are cut off due to cross platform operability requirement. So, the user's or sysadmin's solutions built upon years will start not working one day, and they would not understand why.

That's why I want it opt in, so that it'd be a deliberate choice, not something that may cause accidents. Just like in a cockpit, the critical tools have different colors, or mechanism, so that the operator does not make a mistake: Some knobs require turning, others require pulling. The intention is preventing human errors.

PowerShell was an opt-in from CMD, but both are still installed by default. None of the arguments in this thread apply to whether or not PowerShell 7+ should be provided, just to whether PowerShell 5.x should be removed (which it obviously can't).

Well, PowerShell is not a continuation of CMD. Users are well aware of the difference of the tools. PowerShell 5 to PowerShell 7 is not the same leap comparing to CMD to PowerShell 5. The difference is subtle and misleading. That's not an issue with home users, power users and developers. But in corporate setups, the difference is huge. Second, No one mentioned removal of anything. So, the argumentation looks like a straw man.

just to whether PowerShell 5.x should be removed (which it obviously can't).

5.x should be an optional feature. I don't want obsolete packages on the OS.

I agree with you to a point. But Windows is so intertwined with PowerShell 5.1, I don't believe it would be replaced that easy. To clarify, it is not a PowerShell 7 Team issue, but Windows OS Dev Team issue. Only after that integration, it makes a lot of sense. I do want that leap. But with the current state, I find it risky.

@AnyOldName3, Microsoft cannot remove Windows PowerShell (i.e., PS5) from Windows, because that would break thousands of backward compatibility scenarios, despite many people wanting NO version of PowerShell in the OS, because 99% of customers don't use it, need it, or want it. PS7 is similar to PS5, but not the same, and not 100% compatible. So the only option would be to put BOTH versions, which would cause more unnecessary bloat. 99% of scenarios that require PowerShell work fine with Windows PowerShell, and 99% of the ones that don't work just fine with the user downloading and installing PowerShell Core. So, we're talking adding unnecessary bloat for everyone to make 1 out of 1,000,000 scenarios ever so slightly better. This isn't a tough call. This is a slam dunk.

No one's suggesting removing PowerShell 5.1. So many things still work with PowerShell 5.1 because people who write PowerShell scripts know that a lot of people refuse to install anything beyond what's there by default, so they've got no choice about what features they can use, and are unable to use any of the Core features, no matter how much less of a pain that would be. If Windows started bundling PowerShell 7 or later, then huge swathes of modules would start dropping support for 5.1, as their maintainers don't want to support 5.1, and would be able to make maintenance easier if they didn't have to, but do want to support the minimum version they can guarantee will be available.

No one's suggesting removing PowerShell 5.1.

Actually, yes, many people are. No PowerShell users/fans are, but many customers are asking for removing the bloat in the OS that less than 1% of users actually care about. And since Windows PowerShell can't be removed, adding another version would exacerbate this.

This really isn't a tough decision. It's overwhelming the right call to allow users who want PowerShell Core to download it, and users who don't not to be burdened with it.

It's naive to claim PowerShell is bloat that people don't use in a similar way to how people could be tricked into deleting their system32 directories a decade or two ago. It's part of the OS and gets used by the OS, even if you're not interacting with it directly.

It's not naive. It's customer reports and telemetry. You are entitled to your opinion, but the data speak for themselves.

they can't/won't make things compatible across versions

Two comparisons spring to mind....

1. The original Bourne shell begat bash, zsh, ksh etc. Each of those descendants can run sh scripts but the reverse is not the case.

2. Python 3 is incompatible with Python 2

Now in all these cases the program name is different. Same applies to pwsh.exe and PowerShell.exe, in other words they are not the same thing and not pretending to be. Pwsh.exe shares some environment with PowerShell and can use PowerShell modules but again the reverse is not the case.

Now if PowerShell/pwsh just provided the scripting language itself and all cmdlets were from the store then this would have been much less of an issue, it would be each cmdlet or module's responsibility to be backward compatible, or else choose a version that is. It is not bash's problem if grep or curl get additional options or change their defaults. As it is, we have monolithic installs so at least the "why doesn't PowerShell include X" should be happy.

I half expecting/half hopeful that we will get an update from @SteveL-MSFT behalf as part of the 2025 roadmap for PowerShell blog post that should be coming very soon. However, I can't claim any insider knowledge on this at all & is just a guess (though my guesses are usually pretty good on things like this)

Also until this discussion has an answer marked so that can be deemed as closed I'd think that it's safe to say that the survey is definitely ongoing

I would gladly start adding some kind of shebang-like annotation to the top of my scripts if it meant that PowerShell 7 could become universally available.

is that what #requires -version 7 is for?

@rhubarb-geek-nz you may have missed that I was arguing for it being possible, not about whether it was worthwhile. There are many reasons not to that do not amount to making it impossible. For example, the CEO can say "I don't feel like it" to even the most mundane change, but that will never make it impossible--just that it won't happen anymore. In fact, "complicated and difficult" are very good reasons not to remove it until a critical mass (as I mentioned).

and after people complained and scowled, they eventually lived with it.

Your counter-arguments are weak:

• the CrowdStrike debacle (and its loss of dollars) had to do with a routine software update -- not about the incompatibility with two known working versions
• the Post Office scandal had to do with improper testing and mislaid believes of executives -- not about the incompatibility with two known working versions

There are many ways to ensure that such levels of destruction can be mitigated and that is your very next point, and I point I have made repeatedly as well. Side-by-side versions, upgrade paths, et cetera, when put into place, do result in people eventually living with it. There are also many cases where companies have failed to put such mitigations in place (of which your examples count), which does not dispute that many have been successful. Does someone getting hit by a bus when jay-walking mean that cross-walks are a failure?

I suggest reading The Old New Thing blog and the lengths that are gone to to avoid breaking customers.

"The lengths that are gone" is exactly what I alluded to by "complexity and difficulty". You are actually reinforcing my point.

There is absolutely no reason to ditch PowerShell 5.1

If you read my full argumentation closely, I have never suggested to simply remove PowerShell 5.1. I have always suggested shipping them side-by-side to allow a transition as a mitigation strategy.

You may have also missed that I am not just talking about migrating PowerShell, but also the .NET version of the OS. Considering how much Microsoft is pushing the new capabilities of the later .NET versions (including a completely new GUI engine than Windows Forms) there is a lot being missed out on .NET Framework. As I have already mentioned, there are a lot of applications moving to later .NET and Microsoft is likely waiting for them to hit a critical mass before migrating the OS to catch up--specifically because they do go to lengths to avoid breaking customers. When this occurs, moving PowerShell to a later version as well will be quite natural. But hey, that's my speculation (and hope).

and after people complained and scowled, they eventually lived with it.

My impression was that you thought breaking end users' scripts was no big deal.

Your counter-arguments are weak:

Given PowerShell is used for automating business processes then breaking automated deployments is exactly the CrowdStrike scenario, and breaking end of day processing is exactly the same as the Post Office problems.

My apologies if I was misleading. Simply put: innovation and development naturally lead to breaking changes at some point. You can do a lot to improve a product without breaking changes, but at some point you will have to break something to continue improving it. After you break it there is a lot that you can do to mitigate the consequences. However, what you can never mitigate is people's emotional attachment to the old way.

What makes it not exactly the same is that both versions of PowerShell are known to be working. CrowdStrike resulted in an upload of a broken version that left people with no ability to fix it on their end. The Post Office scandal was a broken piece of software that was deemed to be more "accurate" than the people. It may feel like using a different working version will break your existing automated deployments, but that is only temporary and fully within your power to make a plan and prevent downtime. Something not available to the other scenarios. Similar with the Python versions in Linux; despite it being a very different ecosystem, deployments (many supporting cloud infrastructure) were able to cut over their automation at the same time they cut over their Python version. This is because both were known working versions with known differences that can be fully vetted in a test environment before cutting over and achieving zero downtime. That is hardly the same "breaking" that CrowdStrike or Postal Office scandal causes--rather than a surprise break it comes with customer effort.

Now, what will happen after PowerShell 7.4 LTS is shipped with Windows? I expect this site will become a ghost town because the only version of PowerShell Core that matters is the one that Microsoft ships.

Absolutely not the case here. If anything here will get busier with people raising more issues and feature requests.

ps7 and 5 bot support v2 and v3 repos, v2 being powershellget/packagemanagment and v3 being Microsoft.PowerShell.PSResourceGet

We're in a thread a Microsoft employee made to ask about it. Within the context of this thread, past statements Microsoft has made saying they don't think it's worthwhile are entirely irrelevant, as we're all here because Microsoft have indicated they're open to changing their opinion on the matter. People don't like the irrelevant message because it's irrelevant, and if they blame you for anything, it's cluttering the discussion with the irrelevant message.

Precisely. This whole discussion is about evaluating arguments and use cases to decide on the business value of adding PS7 to Windows. Saying it has no business value as a fact is like stating the conclusion without the discussion. It is also misleading because it is phrased in a way that looks like an argument against.

You claim to relay MS's opinion but you only brought that up after being called out. You didn't phrase it as "Microsoft decided that it has no business value, so we can't add it" from the get go. So I don't believe I'm wrongfully blaming the messenger while just being angry at the message; I just feel like you're not seriously trying to contribute to the debate, or if anything you seem to just try to shutdown arguments with irrelevant info.

If what you mean is that this discussion is already over and the conclusion was already communicated somewhere, I'd be happy if you could provide a link so I can get informed.

The disturbing thing here is that it was a business decision to not make PS5 to PS7 a workable transition from an OS perspective. The gaps never closed between PS7 and PS5 compatibility so the removal of PS5 breaks all those historic things. So either they are admitting that PS7 is not the way forward for comprehensive OS management and powershell is dead, or the platform itself (Windows) is on life support. This in between state is tenable for now, but speaks volumes if you dig into this thread and the overall platform.

In the end, it is all code, and you can either write the code so it works, or mark it as incompatible. They chose the latter and here we are with 2 PS's and neither of them are able to comprehensively manage the infrastructure it was originally intended to address. Literally they wrote 2 separate but similar languages for the sole purpose of managing stuff and can't manage stuff. It is bananas.

One would think in a ecosystem a single company largely controls, they would be able to come to terms with a single workable management solution and address all these gaps. But no, it doesn't/didn't make business sense to develop around all those shortcomings. I am guessing that is why MS PS people left that were there originally part of the Snover crew. The vision was ruined.

You see this same pattern repeat in the cloud with Azure Resource Manager and Graph APIs. Instead of building a consistent model for cloud resources, you end up with a mess and neither does the job comprehensively. Then tools based on it, like Powershell work like crap and don't respect their own paradigms. This is why you can't manage intune like entra like exchange like azure, et al.

So in summary you are at the mercy of MS, and they announced they don't care what you think about how the OS is managed, so carry on and do what you may. Just make sure you continue to buy licenses for your company to keep their cow mooing.

This isn't meant to be mean or terse, but it's just business. You aren't getting PS7 to replace PS5, or 8, or 9. Its just not.

Sadly, it's not so simple. A key reason for not including PS7 in Windows is over support life. When win 11 ships a version MS will supportbitbfir a long time. But .NET and PowerShell have a much shorter support life. So far, the lawyers have never been able to reconcile this issue.

@doctordns so your saying MS never updates Windows during it's lifecycle or does an update that could potentially break something. That's certainly news to me lol.

If they stick to the LTS release chain for .NET and PowerShell that should be just fine. Especially since these releases are normally backwards compatible.

Completely agree. MS needs to either transition to PS7 in Windows or fully support PS5 with bug fixes.

Apologies on the length of this response but it may give much needed background info as well as I hope some hope for the future too.

We were all surprised that the fix was merged nearly 7 years ago and is still not part of the default windows powershell installation

This is a commonly voiced view that I've heard in the community around outstanding bugs, especially if they've been fixed since PowerShell was open sourced in 2016.

Windows PowerShell & PowerShell contain many components that aren't actually a part of the core parts of those products but either are or were shipped with them. These includes modules like Microsoft.PowerShell.Archive, PowerShellGet and others.

For Windows PowerShell these aren't a part of the Windows codebase & are maintained and updated seperately & as such those updates are shipped via the PowerShell Gallery instead of being part of Windows Update.
This unfortunately leads to a broken expectation due to many thinking this is how it always worked for these updates to land on their devices via the Windows Update process.

This is true for security updates, however, because it was decided that feature updates, which include bug fixes to Windows PowerShell & it's bundled components weren't to be included in the servicing criteria for Windows they get left out of the Windows Update process & only security and some accessibility fixes of the components bundled with Windows PowerShell are made available part of the Windows Update process.

This was likely to make it easier in managing the ever growing in complexity in the overall support matrix of the feature set made available with Windows PowerShell as part of Windows. Especially as there were many bundled components, PowerShellGet, PackageManagement & Pester being a few that I can remember as having caused many headaches and needed a very different support & release cycle to Windows to enable proper bugfixes & enhancements to take place as well as to reduce tooling component sprawl that in .NET Framework was controlled by GAC - Global Assembly Cache which isn't a thing as part of .NET and as such can make Dependency Management of .NET assemblies in PowerShell quite the headache which has been seen with many 1st party PowerShell Modules like Exchange, Az, Graph to name a few.

Could/Should Windows be able to pull in updated packages that also include feature updates that are managed outside it's codebase, but used with things inside it's codebase, that's a whole different & extremely long matter to get into, but look at winget and Windows Terminal and a number of other tools/applications that are open-source developed but bundled into Windows now for an insight on what may come in future here.

Feature updates to these components which includes modules like Microsoft.PowerShell.Archive, PowerShellGet and others can all be obtained seperately to the Windows Update process, though many & I believe @mikeparker yourself & @SQLCanuck included, may have expected that these components were also updatable via Windows Update, which is not the case & AFAIK is unlikely to ever be the case for 5.1 nor for v7 either. I also personally don't believe they should be able to updated independantly of PowerShell via Windows Update, when PowerShell 7 versions are already able to be updated via Windows Update and each of these versions do contain updated versions of the respective bundled components.

The platform of PowerShell, that should & is already updatable with Windows Update, but the things you use inside it, that's a much more difficult and unique support matrix that requires hands on management that is unique to orgs and even down to individual devices.

That's why it's not sensible for those additional components to be managed as part of the Windows Update processes, or other tooling like winget, at least not yet. However this makes more sense controlled and managed using DSC whether that be directly or through other tooling like Intune etc and enable better isolation of use of different verions of these components between different versions of tooling using them.

Also from a security perspective where we've see more instances of vulnerabilities mass made available that could have been prevented as well as many broken user experiences cropping up when tooling hasn't been sensibly using the practice of version pinning for component dependencies, whether as part of their development or as part of their final released products. Whether that either be from a lack of tests or they have a more break happy development process or as part of migration work from .Net Framework to .NET certain API's used were no longer available or many other reasons.

By doing this it also moved the support processes especially for the many modules bundled with PowerShell to be hosted here on GitHub (which is a good thing) but ultimately all this caused & continues to cause some teething issues during the transition period (that we are still in the middle of) to what is coming next.

At least this is what I can tell from my now over 10 years involvement with the PowerShell Ecosystem & much more with the Windows ecosystem as a Windows Insider.

Now we have to add support for zip files which don't follow the zip spec.

You shouldn't actually need to, especially as you & your customer can very easily independently update the Microsoft.PowerShell.Archive module to a version that includes the required fix that you mentioned & remove that unnecessary code in your systems.

I say this because just becuase you have something inboxed & it has an update process already, doesn't mean you can't or shouldn't understand the hows or whys in having your own manual update processes that enable testing of any fixes out of band to them reaching general availability

The benefits of your own quick moving process over a slower moving one like Windows Update, as well as being able to slice and dice and customise the configuration of what's contained in your wider computing infrastructure estate, further strenghens longer term stability and security of that estate. It's why we much prefer now to use the minimal deployment model for management in our estate as opposed to the typical whole garage toolkit and kitchen sink deployment model that has been about for years and years. Again tooling like DSC will help with this going forward.

We don't mind whether PS7 is set as the default but if its not then please go back and merge/reimplement some of these bug fixes into 5.

7 being a different executable pwsh is gonna make it unlikely for some time that it will be come the default, at least not with lots more work but side by side to powershell for a while is very much likely to happen, as the transition story for this is resonably complex.

I also highly doubt that 5 is going to get bug fixes that aren't security related applied to it. I'd also highly recommend that the team/s that would need to discuss doing this to go spend the time in moving forward and getting 7 in alongside and formally deprecate 5.1 and give it a proper EOL Date and planned actual complete removal from future versions of Windows. Same with v2. Because it's now taking up too much of more useful time in keeping it around. I personally cannot wait to have a properly supported Windows install like that of Tiny11 that is much simpler to maintain, build & deploy and importantly follows more commonly established processes like those used in the deployment of Containers, Virtual Machines or Physical Machines, whilst keeping things completely supportable.

Whatever the default is for windows installs should be supported

Technically it is today, it just is not mandated that all different types of fixes will be backported which includes the functionality fixes in the components that aren't security related & nor that they are all to be made easily available as part of the pre-existing update process via Windows Update. This is partially to help reduce unneccessary bloat and protect your systems from accidental breaks during this transition period.

We in the community have since 2016 been trying to get people to understand the amount of complexities behind the changes with the move from .Net Framework to .NET and the rippling effect this was going to have on the PowerShell Ecosystem but even before then when The PowerShell Gallery came about as part of the early Windows 10 release that there was going to be differences going forward in how PowerShell ships things to enable more open, transparent and flexible in ways of working going forward.

that should include not making corrupt archives

I agree and unfortunately this is one of the unfortunate areas where the teething issues as part of the wider transition period tend to accidently bring out some of these painful & in many cases avoidable issues like this in the bundled components with software platforms like that of the PowerShell platform.

Can stuff like this be fixed going forward, absolutely.
Will it happen super quickly, very unlikely, especially whilst there are many other things that need time spent on them that have significantly higher level of impact in the grander scheme of things.
But there's definitely more potential to see things get fixed in future and made available to the mass majority in a more timely manner and not somewhat hidden away just to those that have either been following or helping in making some of these bigger much needed changes for the good of the PowerShell platform happen for all these years.

Again sorry on the length of this reply, hopefully though that helps you understand better all about tje pain points on the journey from where it was to where we are now & then to where it's likely going in future.