Will first say that I don't agree with the changes being made here but using a zip can achieve the same status quo of using an MSI, it's just a bit more manual work.

2. based on the above, what does a zip based install look like

For a ZIP install you would extract the zip into a directory and add it to the PATH. This can replicate how the MSI works today by extracting it into C:\Program Files\PowerShell\7\ but it can be any path you choose.

3. enable session configuration endpoints (i.e. Get/Set-PSSessionConfiguration)

AFAIK you just need to run Enable-PSRemoting on the pwsh instance that's been extracted. This will copy the pwrshplugin.dll and other config files to the correct locations and register the session configuration data as expected. The tickbox in the MSI is essentially just calling Enable-PSRemoting after it has been installed.

7. What does this do for updating ? what does this do to windows update?

This is where I'm less certain but it should be a matter of setting the same reg keys as what the MSI does to register the product with Microsoft Update.

Agree these are all solvable

We now have an entire manual process (talking zip file method) to go through that the installed did previously, so this effects Org and end-users a like, but for Orgs automation/packaging/deployments needs to change, or have a per user install with its limitations (current limitations, that may change)

windows update will be looking for a install guid that the zip file is not creating

I think these are things the they should be thinking about and providing clear direction on before making the change

additionally some clarity on why now?

Same sentiment here. When I get a chance I plan to pop open the 7.6.0 MSI in Orca to see if any regkeys are getting set beyond the obvious for things like the Right Click context menu "Run with Powershell 7" if that option is chosen, the shell .ps1 file associations, etc. I don't think automating what the MSI does with the ZIP contents is a large ask it's just why move off a working solution to a solution that is non-working in multiple areas so suddenly and with no discussion to understand the challenges this will pose.

I don't think automating what the MSI does with the ZIP contents is a large ask it's just why move off a working solution to a solution that is non-working in multiple areas so suddenly and with no discussion to understand the challenges this will pose.

Welcome to corporate policies :) I think it sucks and I'm sure there's probably people in the pwsh team who also think it sucks but cannot say so.

I had similar suspicions honestly. Normally you see a dialogue here first for feedback and even then modifications are treated with some pretty impressive care with concerns to breaking existing processes for the user base. The sudden announcement and lack of dialogue so far has been a bit jarring and not indicative of how the working group\committee broached these kinds of changes up to this point.

Yeah, sounds like there might be edicts from elsewhere, November is a short time frame, hopefully this thread sticks to the , "these are things I see that will be broken" vs "Microsoft you are clowns" and in fairness short time frames are a reasonable way to force change (better or worse) in a very large org

clarification and goals would be nice for powershell team

Were you able to find any outline for the next community call showing this will be a topic discussed? As is I haven't been able to find anything showing the team will go into further details on the decision or open it for feedback. Would certainly assuage some concerns if discussions were on the table.

@JAK1047 - Yes — MSI deprecation is on the agenda for the May 21st Community Call. You can follow along and add any additional questions here: #26903

Wouldn't it have been better to gave had the conversion BEFORE nuking a well known, reliable, and simple way to install powershell. The MSIX option is not a perfect replacement.

As an open source project, consulting users first tends to be a good idea. This removal does nothing to improve my trust with PowerShell management and Microsoft. This is a very sad move. Count me very dissapointed.

Ms should reinstall MSI as an option till MSIX works for every installation.

N sumnary, The community needs better stewardship for PowerShell.

Also, if accessibility is an issue, then just offer the .msix as an accesible alternative to the .MSI

From the information that has been provided the through-line appears to be a focus on accessibility, but I'm having trouble understanding how MSIX can assist with this. From the concerns collected so far it's, in fact, measurably less accessible to most enterprise environments where Powershell is used in restricted setups using non-standard user accounts. And it may be may own bias as an engineer speaking, but I'd assume this would be the primary user base for Powershell Core.

Could any examples be provided showing what accessibility gaps MSIX for Powershell will help bridge? The only thing I've found myself so far (that was also mentioned in the original blog post) was interaction with screen readers which I'm not sure has been a concern to begin with. If there's a use case being solved that would certainly help assuage the unease in the community a bit . Or at least lessen the sting slightly.

How do you want to close the gap? MSIx doesn't magically will get fixed.
The timeline with 7.7 isn't make any sense. Did you mean 17.7?
We need installation and patching via SCCM and machine wide installations.

Before removing MSI, we need to ensure that MSIX is compatible with Server Core, SCCM and other systems first.
Microsoft’s decisions sometimes lead to odd situations like this.

"we're reading all of it and taking it seriously"....

I'm not convinced.

I currently maintain the Chocolatey package for Windows for pwsh 7.
Years ago I did the OpenSSH installer where I made the same installer work inside and outside of chocolatey and made it work all the way from early, jank versions of Nano through PowerShell 2 on Windows. It was literally like reproducing all that I knew about MSI internals into a Script + ZIP installer - I could feel myself going through them one-by-one, but I wanted to service Nano!

A couple years ago an MS PM nicely asked if I could update that package and so you can see a 2024 release. (Follow barebonesinstaller.ps1 here: https://gitlab.com/DarwinJS/ChocoPackages/-/tree/master/openssh/tools?ref_type=heads)

The hardest scenarios are upgrading over a previous version.

But the reasoning here seems to be:

1. Move to MSIX because MSI is too hard...
2. But not all the MSI scenarios were ever fully covered...
3. And, msix does not work on all the platforms where installs are done...
4. So .zip's are great - but they do even fewer of the scenarios needed than MSIX...
5. And since all the installation 'bits and pieces' for both human and headless machines are not documented here: https://github.com/PowerShell/PowerShell/tree/master/docs, the MSI is the only documentation of "all the things"

And so you now have to reverse engineer and implement in script code, something that:

• handles all the implicit things MSI does (like automatically scheduling a reboot if files were locked and we tried an overwrite)
• and all the special scenarios engineered into that package.

So while MSI may feel over-engineered at times - aren't we now saying - have each person go and do all the legitimate things MSI does for a powershell install by reverse engineering the requirements by trial and error what MSI does automatically?

If MSIX has never been able to achieve the MSI level of install functionality required for installing powershell, why keep going lower on the pole to .ZIP ? Isn't it a case-in-point for making the install framework that 'handles all the things' the single source of truth, rather than abandon it?

I already travelled that path when I built the OpenSSH installer and it is a trail of tears of "painstakingly recapturing all the things engineered into mature installation frameworks through Agile re-discovery of a working framework called MSI"

The winget manifest includes both MSIX and MSI installs. You can install the MSI using winget install --id Microsoft.PowerShell --source winget --installer-type wix. This was a change in the 7.6 release that I am only just finding out about. We will either update the docs or update the winget manifest.

The winget manifest includes both MSIX and MSI installs. You can install the MSI using winget install --id Microsoft.PowerShell --source winget --installer-type wix. This was a change in the 7.6 release that I am only just finding out about. We will either update the docs or update the winget manifest.

Appreciate the update

I've been leading the charge to get support for packaged applications in the "system context". We do have work lined up for engineering to provide this ability. It will be coming in two parts. The first addresses having a packaged application registered and the second enables its execution. I feel this pain myself every time I'm attempting to set up a new machine whether it's a VM or a physical device.

Changing the operating system itself takes a lot longer than any of us wishes, and building the business justification to change something that was a fundamental assumption/assertion when the technology was built also took time.

This is another step along the journey of addressing all the "chicken and egg" problems. Something "seemingly" as simple as getting the environment refresh for winget install foo in CMD and subsequently in PowerShell 7 took many years and needed long cycles for each dependent step to be completed and rolled out.

I've been leading the charge to get support for packaged applications in the "system context". We do have work lined up for engineering to provide this ability. It will be coming in two parts. The first addresses having a packaged application registered and the second enables its execution. I feel this pain myself every time I'm attempting to set up a new machine whether it's a VM or a physical device.

Changing the operating system itself takes a lot longer than any of us wishes, and building the business justification to change something that was a fundamental assumption/assertion when the technology was built also took time.

This is another step along the journey of addressing all the "chicken and egg" problems. Something "seemingly" as simple as getting the environment refresh for winget install foo in CMD and subsequently in PowerShell 7 took many years and needed long cycles for each dependent step to be completed and rolled out.

And MS wonders why people move to Linux. Here you have the definitive and final answer.

Changing the operating system itself takes a lot longer than any of us wishes, and building the business justification to change something that was a fundamental assumption/assertion when the technology was built also took time.

Who could have known that customers would expect to install software that could be shared by multiple users?

And MS wonders why people move to Linux. Here you have the definitive and final answer.

Who could have known that customers would expect to install software that could be shared by multiple users?

We know there are issues but these comments don't contribute anything to the discussion. There's no need to throw sarcasm at the people trying to improve the situation, especially when we're asking for more transparency.

Changing the operating system itself takes a lot longer than any of us wishes, and building the business justification to change something that was a fundamental assumption/assertion when the technology was built also took time.

I appreciate the insight and I don't doubt any of it, but I'd love to know what more business justification was required than "the product doesn't work for our enterprise customers". 😄

I'd have thought these deficiencies would have been fairly self-evident to the teams involved, well before MSIX was actually released, let alone 8 years later? I mean, to my knowledge, it was an evolution of the AppX format that first debuted in Windows 8 like 14 years ago, so how come nobody wanted to address these issues and have it properly ready for enterprise use at release? Then WinGet and PowerShell presumably wouldn't be having all these problems with it now, and everyone would be much happier.

The cynic in me is imagining another "chicken and egg" scenario, where the business argument is that nothing needs to be enterprise-ready out of the box because enterprise takes forever to adopt anything new, but maybe that's because enterprise has learned that nothing new ever works properly out of the box? 😵‍💫

Who could have known that customers would expect to install software that could be shared by multiple users?

There's no need to throw sarcasm

It wasn't sarcasm, it was disbelief and a question that should be asked of the decision makers in the crisis management meeting or post mortem. In the Agile world you can't commit to something that you have no control over, and it appears that the PowerShell project has no control over the implementation of the installers. So rather than make it a dependency it should be merely a wish list item that could be transitioned to when it becomes fit for purpose. In the mean time revert to the existing tried and tested mechanisms. That completely bypasses the "chicken and egg" problem. I consider myself a PowerShell evangelist and even I can't recommend putting PowerShell 7 in production environments. If you have lost us then who are you doing it for?

Would be a good idea if msix could install machine-wide.
System tools shouldn't be installed per user only.