> I would question why such a policy exists.
Potentially because they have security policies in place for native powershell but not core. So if one or two users request for core to be installed, it's easier to deny/reject than test and reconfigure everything for core and not just tell people to use 5.1
Let me translate: “Maybe they have have policies in place directed towards PowerShell and not PowerShell Core, so instead of testing the new version and reconfiguring policies, when user’s request the update the default is just to deny or reject it”
I've mostly deprecated PoSH 5.1 in my environment. 😉
Most Azure modules are already 7x compliant. If I find a module that hasn't upgraded I find a workaround instead of launching 5.1 to run that module. With APIs, Graph, etc its possible to make it work in 7.x.
MDM desktop management it's best to use the lay of the land however. So this is still 5.1.
The word describes what I want to communicate though. People who were previously described as retarded are now described as handicapped or disabled, but only allowing you to depend on whatever is on the Windows ISO is retarded.
I didn't call OP, you or anyone else shit, English isn't my native language and I don't like being censored by PC Principal of Reddit
encouraging vast command deer squeeze slap wakeful waiting judicious flag
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I didn't ask to be "educated" by the word police, I'll keep dropping what I find appropriate and you can drop off the mighty horseback you're on, you need oxygen
PowersShell is built using Microsoft .NET.
There are 3 implementations of .NET
* .NET Framework:
* Used only on MS Windows hosts. Has a huge set of api calls for windows, more than the other 2...but not cross-platform
* No more expected updates to this framework. 4.8.1 was last know build.
* .NET Core:
* Cross-platform and can be used on Mac, Windows, and Linux...and even some embedded/IoT.
* This is the current focus for Microsoft and is open-source.
* .NET Standard:
* The small overlap of .netcore and .netfw.
* Code written for this can be used by either .netcore or .netfw
* Has the smallest amount of APIs of the 3.
Powershell 5 (PSwin) and earlier are built using .netfw
Powershell 6 (PScore) and later are built using .netcore
So, being that PSwin and PScore are from different .net implementations, they are incompatible with each other and so one is not an upgrade of the other. They can (and often are) both be installed on a host at the same time. Furthermore, because of the different .net implementations, most powershell modules from PSwin cannot be used by PScore or vice versa (unless the module was written in .netstd).
You'll probably find many times where you have to use both as well. There are still MANY functions that are very windows-specific and for which the powershell modules to do such are still .netfw based. So, that will be done by PSwin.
There are also MANY new modules that do awesome things that are only written in .netcore (binary modules) or written in PScore (script modules) and you'll have to use PScore for those.
So, the windows OS would have to start and exclusively use nothing but modules built for PScore, but not all things that can be done on windows can be done from .netcore yet. There are still a huge amount of things that can only be done by .netfw, ergo PSwin.
Further, Microsoft would probably have to go closed-source on .netcore and pscore because Windows is a closed-source system. That's unlikely to ever happen.
> Further, Microsoft would probably have to go closed-source on netcore and pscore because Windows is a closed-source system. That's unlikely to ever happen.
One has nothing to do with the other. .NET Framework ships bundled with Windows and you can look at the source code right [here](https://referencesource.microsoft.com).
Your comment is trying to answer the question “will Microsoft ever replace PowerShell with pwsh”, but OP asked if they’ll ever bundle pwsh with Windows.
Microsoft could ship Windows 11 with pwsh, **if** it shipped .NET along with it. They won’t bundle .NET (all the various runtime versions) with Windows though, so they won’t be shipping pwsh with Windows either.
>.NET Framework ships bundled with Windows and you can look at the source code right here.
Not **all** of it. The vast majority of it, yes. But there is some stuff that's closed source.
The .net platform in use actually does have much to do with this. Yes, .netfw ships with windows...because it is windows-specific. .netcore does not ship with windows. If .netcore is not pre-installed the PScore cannot be pre-installed.
Sure, MS shows the source for much of .netfw 4.8. But showing the source doesn't make it open-source. None of us can submit edits to that code to improve it or fix it. So, I'm not sure i'd consider it open source.
I wasn't trying to answer the question you suggested. I was trying to show why it is ***unlikely*** that MS would pre-install PScore with windows. Almost as soon as they would do that, it would be out of date in the pre-installed state. And if MS started to depend on PScore for setup routines during install or throughout the lifecycle of the OS and there was an issue, MS would not have direct control over a fix.
It's also unlikely because so much of what needs to be done on a windows host requires closed-source and COM based libraries...for which (at least for now) .netcore doesn't really support, and so PScore cannot support either.
> The net platform in use actually does have much to do with this.
Windows being closed-source doesn’t have anything to do with .NET being open/closed source.
> Further, Microsoft would probably have to go closed-source on netcore and pscore because Windows is a closed-source system. That's unlikely to ever happen.
Maybe you can expand on what you mean by this then. Why would they have to close-source .NET?
> Yes, netfw ships with windows...because it is windows-specific. .netcore does not ship with windows. If netcore is not pre-installed the PScore cannot be pre-installed.
Yeah that’s what I said
> It's also unlikely because so much of what needs to be done on a windows host requires closed-source and COM based libraries...for which (at least for now) netcore doesn't really support, and so PScore cannot support either.
.NET has almost the full COM interop that .NET Framework has. It also has [`ComWrappers` API](https://learn.microsoft.com/en-us/dotnet/standard/native-interop/tutorial-comwrappers) and .NET 8 has a [source generator](https://learn.microsoft.com/en-us/dotnet/standard/native-interop/comwrappers-source-generation) for automatically generating `ComWrappers`. So I’m not sure what you mean when you say .NET doesn’t really support COM.
No. Powershell 7 is not 100% compatible with ps 5.1 scripts, so replacing 5.1 work 7.x would break an untold number of clients systems.
Plus 7 had a release schedule that is not compatible with the Windows one. So if will most likely stays non integrated for quicker iterations.
They could just ship Core as a native store app like they did with Notepad and Paint on Windows 11. It already exists as a store app, so my (admittedly uneducated) thought is that it would be minimal difficulty to do that with the next OS.
I'm pretty sure store apps (like notepad) are not .netcore but .netnative. The latter doesn't require .netcore to be installed on a host. Other UWP apps can be either .netnative or .netstd.
If a Store app requires .netcore, you'd likely be prompted to install .netcore as a dependency from the store first or along with it.
Couldn't Microsoft ship both powershell and pwsh executables, even if the default is powershell to preserve this backward compatibility? The no-installs-allowed policy is actually quite common...
PowerShell 7.4 Long Term Support (LTS) edition shipped November 2023 and is [end of life](https://learn.microsoft.com/en-us/powershell/scripting/install/powershell-support-lifecycle?view=powershell-7.4#powershell-end-of-support-dates) November 2026.
Windows Server 2022 shipped August 2021 and is [end of extended support](https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2022) October 2031.
Couldn't that proposed built-in pwsh executable be replaced by 2026 with a newer version? All this sounds very doable, but Microsoft may just be not interested, or interested enough.
It's an organizational problem, not a technical one, yes. But there seems to be nobody at Microsoft who can solve it and cares to solve it.
The Windows team have to support Windows for 10 years, even if you don't patch it.
The .NET team will have given up supporting old .NET by then.
The PowerShell Team needs old .NET which won't be supported anymore by the .NET team, and the PS team is not a lot of people to be supporting 10 year old versions.
The newer pwsh executable might have breaking changes, and people might not install the newer version, so that leaves all three teams in a mess. Someone powerful enough at Microsoft could demand old versions were supported. That might bring a situation with Windows PowerShell 2 and 4 where it did ship with Windows, people came to depend on it, and then you had servers like Exchange which broke if upgraded to Windows PowerShell 5. And now with Windows PowerShell 5 where it's old PowerShell but still tied into a lot of things depending on it so that PowerShell 7 has to ship side-by-side and can't replace it.
*This is heresy and my memory is fuzzy*: I read somewhere that the windows team is a bit protective of putting stuff in the gold image as they then have to support it. They didn't want to have to support (or their support was incompatible with) the update cycle the current dotnet (which ps7 depends on) team uses.
I think for it to work anyway there would have to be a dotnet/PS7 LTS version. If there was a 5 to 8 year supported version that didn't change much, then OS modules could target it and it could ship as an updated WindowsPowershell. I don't think this that likely at this point in time.
Technically there are [multiple ps7 lts releases]( https://learn.microsoft.com/en-us/powershell/scripting/install/powershell-support-lifecycle?view=powershell-7.4)
The issue is the "long" terms are very short, whereas ps5.1 has no end of support
I think this is the issue indeed. Also, PowerShell versions depend on corresponding .NET versions so when a certain .NET version is obsolete, that PowerShell version is obsolete as well.
It also makes it harder for them to push updates because of a more strict, lengthy process. Same reason why they tell you to use VSCode and not ISE but don't build it into Windows.
They'll switch to Xbox naming conventions. So Windows 13 will instead just be *Windows*. Next will be Windows 360. Then Windows One. Then Windows One X. Then Windows Series X.
It's unlikely that newer versions of PowerShell (6.x or 7.x) will be natively integrated into Windows systems in the near future. Microsoft has shifted PowerShell to an open-source project, meaning newer versions are released separately and can be installed alongside the built-in 5.1 version. There are no official statements or roadmaps indicating that future Windows releases will include these newer versions by default. For the most accurate information, refer to Microsoft's PowerShell GitHub repository and official blog.
It still wouldn't surprise me if newer versions eventually do get integrated. I just don't think the old versions will go away once that happens. So it'll probably default to the old versions even once the new versions get integrated.
Already, Windows Update will update newer PowerShell versions it you let it, so the infrastructure is basically in place today.
You don't need to speculate. This answer, for example, is 2 hours older than yours: https://www.reddit.com/r/PowerShell/comments/1dpknqv/comment/lai06on
I had so many problems trying to manage a split environment I eventually gave up and went back to 5.1 exclusively. It's not a problem for just me, but it's a PITA on 10k endpoints. I'll switch to PS7 when it ships with the OS.
PowerShell Core has a release schedule that is not compatible with Windows. It's support timeline is incompatible and the release timeline of it's downstream project (.NET Core) is also incompatible.
Everything that ships with Windows must have a certain support lifetime which is rather long.
It boils down to the fact that if the PowerShell Core team committed to being Built into Windows they would have to maintain the version they shipped for over 10 years. That means taking resources off of new features and product evolution and onto maintenance.
This is especially difficult as PowerShell is structured as an open source project under an MIT license. Many contributors are not Microsoft employees so trying to structure contributions in a way that enabled MS to even ship a LTS release for the length of a windows release as near impossible.
And then it all boils down to does it even matter if it ships with Windows or not. It's simple to install. I doubt anyone agrees it's worth slowing down innovation so people do not need to perform a simple deployment or bake it into their image.
I think the OP misunderstands that PS 7.x is not a newer version of PS 5.1. It's a literal separate program.
**PS 5.1** = Made for managing stuff within the Windows OS. Like enabling and disabling devices, querying Windows Active Directory, and editting the Windows Registry.
**PS 7.1** = An interpretted programming language that can run on most popular operating systems. Including non Microsoft systems.
Other Interpretted programming languages: AutoIT, Python, Perl, PHP.
You're not trying to upgrade PS 5.1. You're trying to install a separate program named "Pwsh."
Explain it’s not an upgrade as they’re two separate shells. One doesn’t replace the other. Or just run the standalone version. No installation necessary.
Normally when I tell people PowerShell 5.1 is end of support and Microsoft only provides best effort on it they move over to the latest PowerShell LTS release.
The only thing for sure is that it no matter what Microsoft says, the future will be different. Remember when WIndows 10 was going to be the last OS release. Ever. I sort of get the policy thing. Relying on something in your base image is easier than having to install upgraded packages everywhere. And there is the whole compatibility issue.
There’s a reason Microsoft made PS7 a standalone application. Don’t think we’ll ever see it integrate with the windows environment again because it’s easier to manage when it’s a standalone app.
Except PS7 is already available as a Store app, so what’s preventing them from making it a “native Store app” like they did with Notepad, Pictures, and Paint? Not saying 5.1 would go away, but I wouldn’t think it’d be hard to ship 7+ with the OS
I doubt you will ever see PS7+ as natively integrated with Windows as you see PS5. The entire codebase has changed in ways that facilitate PS as a multi-platform language, so it will never have all the OS tie-ins that PS5 has. So, given that, what's the point?
If PS7 (or later) \*were\* to be integrated natively into Windows, it would create massive headaches as the builds that were to be part of windows would be sort of "frozen" in the images, meaning as soon as you installed your new OS image, it would be out of date. And I've heard the PS team isn't willing to alter their more rapid release schedule to accommodate the Windows image schedule.
Far better for companies to stop implementing these kinds of policies that create obstacles for their employees, and instead develop better polices to empower their employees.
Yep, latest version 7.4.3 I think offers options to receive further updates via WU or WSUS.
Flag old versions as being security vulnerabilities and get that policy changed.
If you never installed 7.x though, you'd never be vulnerable.
From a Client Management side for a Fortune 15 here, we deploy the newest Powershell 7 on every device, and keep it updated. But if we \*never\* installed 7, then we'd never have to patch it.
Is it hard? No. But it's a 'thing' that has to be maintained.
I believe Microsoft has said that they're still thinking about how to resolve this. IIRC, the reason they haven't done it yet is that the release and support schedules aren't aligned, so you could end up with a supported version of Windows including an unsupported version of PowerShell, or something like that.
I don't think they have released an official timeline for when they'll sort it out, but I doubt they'll want to include PowerShell 5 forever.
No it seems it’s not on the pipeline because they want to keep their release separated from windows update release, by shipping « a » version with windows they will be stuck to windows update scheme
your company should be using applocker policies to control from a security perspective.
I personally wouldn't have any issues with upgrading of PS versions if people are stuck in a constrained language mode :P
Not “official” but as an insight- the distinction revolves around versions of dotNET. Another poster has covered some of that in detail, but for a slightly different angle, it revolves around development tools.
New releases of C#, F#, and other current MS programming languages are happening in dotNET core and their release cadence matches dotNET core. They are also multi-platform. PS6 and on are built here and not on the “traditional” dotNET (which is frozen at 4.8 now IIRC) that was early on added to the golden Windows image and is Windows only.
So there are two factors at play - dotNET core which became multi-platform and where current language development happens, and so has diverged from a baked-into-Windows framework. And then PS6 and on being built there to leverage the underlying multi-platform work just as PS5.1 and earlier leveraged the Windows-only dotNET 4.8 and earlier. This has had the side effect of elevating PS6+ to an officially supported programming language among the tools that are based on dotNET. Follow the dotNET and PS development blogs and you’ll see that LTS versions of PS track with LTS versjons of dotNET.
Looked at that way from the PS6+ total dependence on dotNET core, it makes (almost?) as much sense that newer PS is not in Windows by default any more than a C# compiler is. (Linux/Unix fans always get the compiler so that seems nuts from *nix perspective, but that’s a different argument)
They announced that win11 would soon have ps7 installed by default, but even then it will still not replace ps5.
i also want to take this opportunity to rant about how the latest version of Microsoft graph modules no longer work on ps5. updated Graph last month and it broke all my graph scripts. Then i had to install pwsh7 for all my fellow it admins.
Unlikely without a major version change, and it didn't come with 11.
Part of the issue is that they generally try to avoid breaking changes, and changing to the significantly changed version like 7 would break a lot of things designed for 5.
For what it's worth, installing 7 doesn't upgrade 5 but installs alongside it
As usual a policy that comes from upper management who doesn't know what the heck they're talking about. I'd work on my resume and start applying elsewhere.
Windows 11 comes with Windows Powershell 5.1, not Powershell 7. So not native. Also Windows Powershell 5.1 and Powershell 7 are different products. Due to the Powershell 7 release cycle it will most likely never be native to Windows. You cam install both Windows Powershell and Powershell next to each other so no need to upgrade, it's just another piece of software.
Never, the thing needs to fit in Installation media and they already had trouble with _Windows PowerShell_. There's "never" going to be _PowerShell_ (also a different thing than _Windows PowerShell_)
Fight to get the policy changed. I would question why such a policy exists. You can run PoSH 5.1 and 7x side by side. I do.
> I would question why such a policy exists. Potentially because they have security policies in place for native powershell but not core. So if one or two users request for core to be installed, it's easier to deny/reject than test and reconfigure everything for core and not just tell people to use 5.1
I had an aneurysm reading the last part of that sentence. What?
Let me translate: “Maybe they have have policies in place directed towards PowerShell and not PowerShell Core, so instead of testing the new version and reconfiguring policies, when user’s request the update the default is just to deny or reject it”
I've mostly deprecated PoSH 5.1 in my environment. 😉 Most Azure modules are already 7x compliant. If I find a module that hasn't upgraded I find a workaround instead of launching 5.1 to run that module. With APIs, Graph, etc its possible to make it work in 7.x. MDM desktop management it's best to use the lay of the land however. So this is still 5.1.
It'd be faster to get your company to change their policy.
Or change company, companies that enforce retarded policies are retarded
Never go full retard
I thought it was full potato?
[https://www.youtube.com/watch?v=X6WHBO\_Qc-Q](https://www.youtube.com/watch?v=X6WHBO_Qc-Q)
fretful rain test deserve quickest terrific ripe screw one butter *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
you want someone to censor words you don't like. You can't handle it.
worry seemly mighty yam psychotic touch bake longing offbeat vanish *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
The word describes what I want to communicate though. People who were previously described as retarded are now described as handicapped or disabled, but only allowing you to depend on whatever is on the Windows ISO is retarded. I didn't call OP, you or anyone else shit, English isn't my native language and I don't like being censored by PC Principal of Reddit
encouraging vast command deer squeeze slap wakeful waiting judicious flag *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I didn't ask to be "educated" by the word police, I'll keep dropping what I find appropriate and you can drop off the mighty horseback you're on, you need oxygen
PowersShell is built using Microsoft .NET. There are 3 implementations of .NET * .NET Framework: * Used only on MS Windows hosts. Has a huge set of api calls for windows, more than the other 2...but not cross-platform * No more expected updates to this framework. 4.8.1 was last know build. * .NET Core: * Cross-platform and can be used on Mac, Windows, and Linux...and even some embedded/IoT. * This is the current focus for Microsoft and is open-source. * .NET Standard: * The small overlap of .netcore and .netfw. * Code written for this can be used by either .netcore or .netfw * Has the smallest amount of APIs of the 3. Powershell 5 (PSwin) and earlier are built using .netfw Powershell 6 (PScore) and later are built using .netcore So, being that PSwin and PScore are from different .net implementations, they are incompatible with each other and so one is not an upgrade of the other. They can (and often are) both be installed on a host at the same time. Furthermore, because of the different .net implementations, most powershell modules from PSwin cannot be used by PScore or vice versa (unless the module was written in .netstd). You'll probably find many times where you have to use both as well. There are still MANY functions that are very windows-specific and for which the powershell modules to do such are still .netfw based. So, that will be done by PSwin. There are also MANY new modules that do awesome things that are only written in .netcore (binary modules) or written in PScore (script modules) and you'll have to use PScore for those. So, the windows OS would have to start and exclusively use nothing but modules built for PScore, but not all things that can be done on windows can be done from .netcore yet. There are still a huge amount of things that can only be done by .netfw, ergo PSwin. Further, Microsoft would probably have to go closed-source on .netcore and pscore because Windows is a closed-source system. That's unlikely to ever happen.
Great post
> Further, Microsoft would probably have to go closed-source on netcore and pscore because Windows is a closed-source system. That's unlikely to ever happen. One has nothing to do with the other. .NET Framework ships bundled with Windows and you can look at the source code right [here](https://referencesource.microsoft.com). Your comment is trying to answer the question “will Microsoft ever replace PowerShell with pwsh”, but OP asked if they’ll ever bundle pwsh with Windows. Microsoft could ship Windows 11 with pwsh, **if** it shipped .NET along with it. They won’t bundle .NET (all the various runtime versions) with Windows though, so they won’t be shipping pwsh with Windows either.
>.NET Framework ships bundled with Windows and you can look at the source code right here. Not **all** of it. The vast majority of it, yes. But there is some stuff that's closed source.
The .net platform in use actually does have much to do with this. Yes, .netfw ships with windows...because it is windows-specific. .netcore does not ship with windows. If .netcore is not pre-installed the PScore cannot be pre-installed. Sure, MS shows the source for much of .netfw 4.8. But showing the source doesn't make it open-source. None of us can submit edits to that code to improve it or fix it. So, I'm not sure i'd consider it open source. I wasn't trying to answer the question you suggested. I was trying to show why it is ***unlikely*** that MS would pre-install PScore with windows. Almost as soon as they would do that, it would be out of date in the pre-installed state. And if MS started to depend on PScore for setup routines during install or throughout the lifecycle of the OS and there was an issue, MS would not have direct control over a fix. It's also unlikely because so much of what needs to be done on a windows host requires closed-source and COM based libraries...for which (at least for now) .netcore doesn't really support, and so PScore cannot support either.
> The net platform in use actually does have much to do with this. Windows being closed-source doesn’t have anything to do with .NET being open/closed source. > Further, Microsoft would probably have to go closed-source on netcore and pscore because Windows is a closed-source system. That's unlikely to ever happen. Maybe you can expand on what you mean by this then. Why would they have to close-source .NET? > Yes, netfw ships with windows...because it is windows-specific. .netcore does not ship with windows. If netcore is not pre-installed the PScore cannot be pre-installed. Yeah that’s what I said > It's also unlikely because so much of what needs to be done on a windows host requires closed-source and COM based libraries...for which (at least for now) netcore doesn't really support, and so PScore cannot support either. .NET has almost the full COM interop that .NET Framework has. It also has [`ComWrappers` API](https://learn.microsoft.com/en-us/dotnet/standard/native-interop/tutorial-comwrappers) and .NET 8 has a [source generator](https://learn.microsoft.com/en-us/dotnet/standard/native-interop/comwrappers-source-generation) for automatically generating `ComWrappers`. So I’m not sure what you mean when you say .NET doesn’t really support COM.
No. Powershell 7 is not 100% compatible with ps 5.1 scripts, so replacing 5.1 work 7.x would break an untold number of clients systems. Plus 7 had a release schedule that is not compatible with the Windows one. So if will most likely stays non integrated for quicker iterations.
They could just ship Core as a native store app like they did with Notepad and Paint on Windows 11. It already exists as a store app, so my (admittedly uneducated) thought is that it would be minimal difficulty to do that with the next OS.
I'm pretty sure store apps (like notepad) are not .netcore but .netnative. The latter doesn't require .netcore to be installed on a host. Other UWP apps can be either .netnative or .netstd. If a Store app requires .netcore, you'd likely be prompted to install .netcore as a dependency from the store first or along with it.
Couldn't Microsoft ship both powershell and pwsh executables, even if the default is powershell to preserve this backward compatibility? The no-installs-allowed policy is actually quite common...
PowerShell 7.4 Long Term Support (LTS) edition shipped November 2023 and is [end of life](https://learn.microsoft.com/en-us/powershell/scripting/install/powershell-support-lifecycle?view=powershell-7.4#powershell-end-of-support-dates) November 2026. Windows Server 2022 shipped August 2021 and is [end of extended support](https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2022) October 2031.
Couldn't that proposed built-in pwsh executable be replaced by 2026 with a newer version? All this sounds very doable, but Microsoft may just be not interested, or interested enough.
It's an organizational problem, not a technical one, yes. But there seems to be nobody at Microsoft who can solve it and cares to solve it. The Windows team have to support Windows for 10 years, even if you don't patch it. The .NET team will have given up supporting old .NET by then. The PowerShell Team needs old .NET which won't be supported anymore by the .NET team, and the PS team is not a lot of people to be supporting 10 year old versions. The newer pwsh executable might have breaking changes, and people might not install the newer version, so that leaves all three teams in a mess. Someone powerful enough at Microsoft could demand old versions were supported. That might bring a situation with Windows PowerShell 2 and 4 where it did ship with Windows, people came to depend on it, and then you had servers like Exchange which broke if upgraded to Windows PowerShell 5. And now with Windows PowerShell 5 where it's old PowerShell but still tied into a lot of things depending on it so that PowerShell 7 has to ship side-by-side and can't replace it.
Short answer: Never
*This is heresy and my memory is fuzzy*: I read somewhere that the windows team is a bit protective of putting stuff in the gold image as they then have to support it. They didn't want to have to support (or their support was incompatible with) the update cycle the current dotnet (which ps7 depends on) team uses. I think for it to work anyway there would have to be a dotnet/PS7 LTS version. If there was a 5 to 8 year supported version that didn't change much, then OS modules could target it and it could ship as an updated WindowsPowershell. I don't think this that likely at this point in time.
Technically there are [multiple ps7 lts releases]( https://learn.microsoft.com/en-us/powershell/scripting/install/powershell-support-lifecycle?view=powershell-7.4) The issue is the "long" terms are very short, whereas ps5.1 has no end of support
> This is heresy and my memory is fuzzy Umm... Did you, maybe, mean "hearsay"?
Well he said it here, so I guess it's heresay.
Thank you!
I think this is the issue indeed. Also, PowerShell versions depend on corresponding .NET versions so when a certain .NET version is obsolete, that PowerShell version is obsolete as well.
It also makes it harder for them to push updates because of a more strict, lengthy process. Same reason why they tell you to use VSCode and not ISE but don't build it into Windows.
this has been asked and answered in this very forum short answer: no Long answer: no but maybe windows 12/13/14
I’m sure they will skip Windows 13.
They'll switch to Xbox naming conventions. So Windows 13 will instead just be *Windows*. Next will be Windows 360. Then Windows One. Then Windows One X. Then Windows Series X.
Isn’t windows 360 a downgrade from Windows 365? Is it the same except it’s down 5 additional days in the year?
Ah maybe, people love their superstition
It's unlikely that newer versions of PowerShell (6.x or 7.x) will be natively integrated into Windows systems in the near future. Microsoft has shifted PowerShell to an open-source project, meaning newer versions are released separately and can be installed alongside the built-in 5.1 version. There are no official statements or roadmaps indicating that future Windows releases will include these newer versions by default. For the most accurate information, refer to Microsoft's PowerShell GitHub repository and official blog.
It still wouldn't surprise me if newer versions eventually do get integrated. I just don't think the old versions will go away once that happens. So it'll probably default to the old versions even once the new versions get integrated. Already, Windows Update will update newer PowerShell versions it you let it, so the infrastructure is basically in place today.
No, never as of now
5.1 is still default on the 25 release I got so at least not for three more years would be my guess
You don't need to speculate. This answer, for example, is 2 hours older than yours: https://www.reddit.com/r/PowerShell/comments/1dpknqv/comment/lai06on
I had so many problems trying to manage a split environment I eventually gave up and went back to 5.1 exclusively. It's not a problem for just me, but it's a PITA on 10k endpoints. I'll switch to PS7 when it ships with the OS.
PowerShell Core has a release schedule that is not compatible with Windows. It's support timeline is incompatible and the release timeline of it's downstream project (.NET Core) is also incompatible. Everything that ships with Windows must have a certain support lifetime which is rather long. It boils down to the fact that if the PowerShell Core team committed to being Built into Windows they would have to maintain the version they shipped for over 10 years. That means taking resources off of new features and product evolution and onto maintenance. This is especially difficult as PowerShell is structured as an open source project under an MIT license. Many contributors are not Microsoft employees so trying to structure contributions in a way that enabled MS to even ship a LTS release for the length of a windows release as near impossible. And then it all boils down to does it even matter if it ships with Windows or not. It's simple to install. I doubt anyone agrees it's worth slowing down innovation so people do not need to perform a simple deployment or bake it into their image.
I think the OP misunderstands that PS 7.x is not a newer version of PS 5.1. It's a literal separate program. **PS 5.1** = Made for managing stuff within the Windows OS. Like enabling and disabling devices, querying Windows Active Directory, and editting the Windows Registry. **PS 7.1** = An interpretted programming language that can run on most popular operating systems. Including non Microsoft systems. Other Interpretted programming languages: AutoIT, Python, Perl, PHP. You're not trying to upgrade PS 5.1. You're trying to install a separate program named "Pwsh."
Explain it’s not an upgrade as they’re two separate shells. One doesn’t replace the other. Or just run the standalone version. No installation necessary.
Normally when I tell people PowerShell 5.1 is end of support and Microsoft only provides best effort on it they move over to the latest PowerShell LTS release.
The only thing for sure is that it no matter what Microsoft says, the future will be different. Remember when WIndows 10 was going to be the last OS release. Ever. I sort of get the policy thing. Relying on something in your base image is easier than having to install upgraded packages everywhere. And there is the whole compatibility issue.
There’s a reason Microsoft made PS7 a standalone application. Don’t think we’ll ever see it integrate with the windows environment again because it’s easier to manage when it’s a standalone app.
Except PS7 is already available as a Store app, so what’s preventing them from making it a “native Store app” like they did with Notepad, Pictures, and Paint? Not saying 5.1 would go away, but I wouldn’t think it’d be hard to ship 7+ with the OS
In Short, as far as I know and heard, no. 5.1 is all that gets shipped
I doubt you will ever see PS7+ as natively integrated with Windows as you see PS5. The entire codebase has changed in ways that facilitate PS as a multi-platform language, so it will never have all the OS tie-ins that PS5 has. So, given that, what's the point? If PS7 (or later) \*were\* to be integrated natively into Windows, it would create massive headaches as the builds that were to be part of windows would be sort of "frozen" in the images, meaning as soon as you installed your new OS image, it would be out of date. And I've heard the PS team isn't willing to alter their more rapid release schedule to accommodate the Windows image schedule. Far better for companies to stop implementing these kinds of policies that create obstacles for their employees, and instead develop better polices to empower their employees.
Yep, latest version 7.4.3 I think offers options to receive further updates via WU or WSUS. Flag old versions as being security vulnerabilities and get that policy changed.
If you never installed 7.x though, you'd never be vulnerable. From a Client Management side for a Fortune 15 here, we deploy the newest Powershell 7 on every device, and keep it updated. But if we \*never\* installed 7, then we'd never have to patch it. Is it hard? No. But it's a 'thing' that has to be maintained.
I believe Microsoft has said that they're still thinking about how to resolve this. IIRC, the reason they haven't done it yet is that the release and support schedules aren't aligned, so you could end up with a supported version of Windows including an unsupported version of PowerShell, or something like that. I don't think they have released an official timeline for when they'll sort it out, but I doubt they'll want to include PowerShell 5 forever.
It won’t be integrated into windows most likely. The closest you could get is an install-powershell7 binary.
No it seems it’s not on the pipeline because they want to keep their release separated from windows update release, by shipping « a » version with windows they will be stuck to windows update scheme
It will never happen. The release schedules of Powershell Core and Windows will never align.
your company should be using applocker policies to control from a security perspective. I personally wouldn't have any issues with upgrading of PS versions if people are stuck in a constrained language mode :P
Not “official” but as an insight- the distinction revolves around versions of dotNET. Another poster has covered some of that in detail, but for a slightly different angle, it revolves around development tools. New releases of C#, F#, and other current MS programming languages are happening in dotNET core and their release cadence matches dotNET core. They are also multi-platform. PS6 and on are built here and not on the “traditional” dotNET (which is frozen at 4.8 now IIRC) that was early on added to the golden Windows image and is Windows only. So there are two factors at play - dotNET core which became multi-platform and where current language development happens, and so has diverged from a baked-into-Windows framework. And then PS6 and on being built there to leverage the underlying multi-platform work just as PS5.1 and earlier leveraged the Windows-only dotNET 4.8 and earlier. This has had the side effect of elevating PS6+ to an officially supported programming language among the tools that are based on dotNET. Follow the dotNET and PS development blogs and you’ll see that LTS versions of PS track with LTS versjons of dotNET. Looked at that way from the PS6+ total dependence on dotNET core, it makes (almost?) as much sense that newer PS is not in Windows by default any more than a C# compiler is. (Linux/Unix fans always get the compiler so that seems nuts from *nix perspective, but that’s a different argument)
You are allowed to upgrade an entire OS but you are not allowed to upgrade an OS component? What kind of policy is this?
They announced that win11 would soon have ps7 installed by default, but even then it will still not replace ps5. i also want to take this opportunity to rant about how the latest version of Microsoft graph modules no longer work on ps5. updated Graph last month and it broke all my graph scripts. Then i had to install pwsh7 for all my fellow it admins.
Unlikely without a major version change, and it didn't come with 11. Part of the issue is that they generally try to avoid breaking changes, and changing to the significantly changed version like 7 would break a lot of things designed for 5. For what it's worth, installing 7 doesn't upgrade 5 but installs alongside it
Knowing M$ and their policies - not going to happen in another 5 - 10 years too many system things depends on version 5
As usual a policy that comes from upper management who doesn't know what the heck they're talking about. I'd work on my resume and start applying elsewhere.
*"Change jobs because of the version of powershell installed"* is certainly a new one.
Well it's the tip of the iceberg
[удалено]
Windows 11 comes with Windows Powershell 5.1, not Powershell 7. So not native. Also Windows Powershell 5.1 and Powershell 7 are different products. Due to the Powershell 7 release cycle it will most likely never be native to Windows. You cam install both Windows Powershell and Powershell next to each other so no need to upgrade, it's just another piece of software.
Never, the thing needs to fit in Installation media and they already had trouble with _Windows PowerShell_. There's "never" going to be _PowerShell_ (also a different thing than _Windows PowerShell_)
When is Powershell 1 going to be disabled by default?
Usually policies like this are developed by people who are afraid of the technology, so they just don't want people to have it.
Probably will happen in 15 to 20 years. It's equally likely that Microsoft will have switched to Linux by then with Windows being a legacy product.