May Community Call #26903

Fredrik Forséll (@FaffeF) I updated the link Black V (@BlackV) shared

wrong link

Ah apologies for that, thanks Ryan Yates (@kilasuit)

Thanks for bringing these over — these are exactly the right questions and we want to address them directly.

To set honest expectations for the community call: we won't have complete answers to all of these yet. What we can do is walk through what we know today, be clear about what's still being worked out, and make sure these specific scenarios are on the record as things we're actively tracking.

A few things I can say now: PowerShell 7.6 LTS retains MSI for its full supported lifecycle — nothing is changing for current deployments. The transition is happening in the 7.7 preview cycle specifically so we have time to work through exactly these scenarios before it matters.

Server Core, enterprise deployment, session configuration, and Windows Update behavior are all on our list. We'll cover what we can in the call and be straight about what we're still figuring out.

Jason Helmick (@theJasonHelmick)
Thank you for the transparent communication on this — early announcement is important here.

One concrete request for making this transition trustworthy: for every scenario that MSIX currently cannot replicate from MSI (e.g. Windows Server Core installs, session configuration endpoints, enterprise/system-wide deployment, multi-user machines, Windows Update integration), please open a dedicated GitHub issue per gap — and also audit existing MSIX-related issues in this repo, as some of these scenarios may already be tracked and just need to be surfaced and consolidated.

I would suggest organizing these issues under two milestones, with the PowerShell team owning the triage decision of which issues belong where:

• msix-must-have-before-msi-removal — blockers as determined by the team: MSI will not be removed while any of these are open.
• msix-nice-to-have — gaps the team considers desirable but not strictly blocking removal.

The key question for the team — and one I'd hope could be addressed in the community call if possible: can you commit that MSI support will not be removed as long as any of the blocking issues in the must-have milestone remains unresolved?

That single, public commitment would do more to build community trust than any timeline estimate. It gives enterprises and sysadmins a clear, public signal they can see which issues are being resolved and which are not, instead of having to follow meeting recordings or comment threads.

Florian Heberl (@floh96) -- Thank you, and this is exactly the kind of structure I've been thinking about. A public, tracked burndown of MSIX gaps — with clear ownership of which are blockers and which are not — is the right way to make this transition legible to enterprises and sysadmins.
I'm planning to open a tracking issue in the near future. It won't be before the community call, but "relatively" soon after. I also have some additional ideas I want to bring to the community, including a focused working group around the migration — more on that soon.

On the formal commitment: I hear you on why it matters, and the instinct behind it is right. I'm not in a position to make that promise today, but I can tell you the intent behind the tracking work is exactly what you described — gaps should be visible and directly tied to any removal decisions. The milestone structure you've outlined is worth serious consideration as we build that out.

Thomas Lee (@doctordns) — I appreciate you raising this directly, so let me be equally direct.

The early announcement was intentional — we wanted to surface real-world scenarios and concerns before 7.7 ships, not after. That's the feedback we're looking for, and threads like this one are exactly why we do it early.

To be clear on scope: PowerShell 7.6 LTS is unaffected. This is a 7.7 and beyond conversation. MSI isn't disappearing from under anyone today.

MSIX is the modern Windows packaging model — this is a platform direction, not a PowerShell team decision made in isolation. There are teams at Microsoft actively working to close the remaining MSIX scenario gaps. That work is happening because of concerns like the ones raised here. The direction is set.

What the community shapes is how this transition happens — the tooling, the timeline, the scenario coverage. That's where your input is genuinely valuable and what I want to hear about on May 21st.

Thanks for the response, Jason. Let me make a few comments
Like all of us, I appreciate the early warning and the chance to discuss this. I have to confess that I was disappointed that Microsoft took the unilateral decision to remove MSI before the announcement. As I mentioned, major changes like this should be discussed with the community first.

I think we all agree on a few points. MSI is well known, well understood, and widely deployed among many large and small Microsoft customers.s At the same time, MSI does have well-known issues, as has been widely discussed. MSIX is a newer technology that seeks to improve the installation process. BUT: today, MSIX is just not a drop-in replacement to MSI for many (most?) customers. If I understand it right, the next LTS release will be later this calendar year, leaving little time for customers to work out how to make up for the loss os MSI features. Would the release of the next LTS be delayed to wait for MSIX remediation?

I applaud the move to MSIX, but it needs work. The work to overcome the issues, though, would not be done by the PowerShell team. Does that mean that MS has agreed to resolve the MSIX shortcomings by the time the next LTS ships? Or is the plan to ship the next LTS without MSI despite the issues this may cause? Could you share the plan for this, given the issues noted here?

My personal suggestion is to very formally deprecate MSI. You could even make the MSI installer packages explicitly tell the interactive user that MSI is deprecated (and maybe write event logs for /Quiet installs). Then, once MSIX can do the job fully, remove the MSI. And in the meantime, publish both MSI and MSIX packages and update Install-PowerShell.ps1 to install via MSIX. Let's make sure we have both the horse and cart before proceeding.

To be clear on scope: PowerShell 7.6 LTS is unaffected. This is a 7.7 and beyond conversation. MSI isn't disappearing from under anyone today.

Well, that's not completely true. The default Winget install was changed to MSIX, as documented here:
"Beginning with the winget package for PowerShell 7.6.0, winget installs the MSIX package by default."
Shouldn't that be implemented for the 7.7 preview, not the 7.6 LTS!?
I had an issue upgrading from 7.5 to 7.6, likely due to the different installer technology. Uninstall/reinstall fixed that. But I'll probably remove it again and reinstall from Winget, but using the --installer-type this time. (and probably create a separate issue in the repo for documentation)

RHEL 10 and Debian 13 are now available for PowerShell 7.7.0-preview 1.

Great news Jason Helmick (@theJasonHelmick) thanks! Any chance we could get an LTS release? (7.4/7.6?)

Evan R (@erixom) :) - yes, for 7.6 - we are working on it now - I should know more at the time of the community call :)