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

as an FYI that page does not list the msix install process, its lists the store but that is seperate process to msix

additionally as I understand it, the winget install currently uses the msi (by default) so that will need to be looked at too right?

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.

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