Repository navigation
Please re-add MSI installer packages for >= v7.7 #27383
Description
Summary of the new feature / enhancement
Summary
Could you please continue to provide an MSI installer alongside the MSIX package for all future PowerShell releases?
Starting with recent releases, the standalone MSI for x64 has been dropped in favor of MSIX-only distribution, and that change creates real friction for a number of common scenarios.
Why MSI still matters
- Enterprise deployment — MSI is the lingua franca for GPO Software Installation, SCCM/Intune Win32 app deployment, and third-party tools like PDQ or Chocolatey. MSIX coverage in these tools is still uneven and adds operational complexity.
- Server / Core scenarios — MSIX relies on the AppX stack, which is awkward (or unavailable) on Windows Server Core, build agents, and minimal images. MSI just works.
- Automation & CI — Silent install with custom
ADDLOCAL/properties, predictable install paths, and clean uninstall viamsiexecare well understood. MSIX equivalents (Add-AppxPackage, sideloading policies, signing requirements) are noticeably more painful in unattended pipelines. - Per-machine installs and PATH — MSI gives a clean per-machine install with
pwsh.exeon PATH and predictable file locations. MSIX's redirected paths and per-user model regularly trip up tooling that expects a stable, machine-wide install. - Signing & distribution flexibility — MSI can be signed and distributed through internal channels without the additional MSIX packaging/signing constraints (and without needing the Store route).
Request
Please keep producing the PowerShell-<version>-win-x64.msi (and ideally x86/arm64) artifact as a first-class release asset going forward, in addition to MSIX. Many of us would really appreciate not having to maintain workarounds or pin to older releases just to keep MSI-based deployment working.
Thanks a lot for all the work on PowerShell — and for considering this!
Proposed technical implementation details (optional)
No response
Activity
rhubarb-geek-nz commentedon May 3, 2026
If the PowerShell team don't provide an official MSI signed by a Microsoft certificate and published in a well known place then I predict the following will happen:
To stop this sequence, provide a Microsoft signed MSI at the place everyone would expect to find it.
kilasuit commentedon May 13, 2026
Jason Helmick (@theJasonHelmick) Steve Lee (@SteveL-MSFT)
I have to agree with the above
MSI is known, tested and trusted & tbh, as nicely as I can be, MSIX is an absolute mess in its current state which isn't as widely tested and therefore nowhere near as trusted. It will take a lot to get close to MSI level of trust. Also people & orgs need to be able to side by side test, and removing msi, stops them from being able to do this.
Therefore, I'd kindly urge you and the team to reconsider and have both msi and msix packages for further 7.7.x releases.
doctordns commentedon May 13, 2026
I agree that the MSI installer should not be eliminated, at least not yet. As an open source project, this change really should have been discussed with the community first. We should not learn of this decision via the emails documenting the PRs rdmoving MSi. Sure,MSI is not perfect, but it's known, heavily used, and a reliable deployment method.
I suggest MSI is retained , but formally deprecated, for the next release. Then, once MS has improved MSIX, remove it for 7.8. That will give MS time to resolve MSIX's shortcomings. And, if the remediation is NOT ready for 7.8, then bump thd removal to 7.10. A nice controlled path.
Joachim-Otahal commentedon May 15, 2026
Possibly stupid beginner question: Isn't MSIX per default user only? I searched on how to install an MSIX so powershell 7.7 "system wide", available for all users, including the SYSTEM user, without any additional interaction. I can find things on reddit or on "install pyhton MSIX for all users", which tell
Add-AppxPackage -Path "PathToYourMSIX.msix" -AllUsers
Add-AppxProvisionedPackage -Online -PackagePath "PathToYourMSIX.msix"
I would have to check in a victim VM whether that works as expected, probaly does.
EDIT: And does this mean that powershell 7.7 and higher will not available for Server Core any more?
marshallwp commentedon May 15, 2026
MSIX from the Store is configured to be user-scoped, but if you download the MSIX directly you get a system-scoped variant that installs to Program Files. So that alleviates at least one concern for me.
DrusTheAxe commentedon May 16, 2026
No. MSIX supports Per-User and All-Users. The latter is accomplished via "provisioning".
The classic "per-machine" model is "install v1 in a singular location, point everyone to it, then update-in-place with v2 content and everyone has v2".
MSIX strongly avoids update-in-place, to avoid the servicing complications. Instead, v2 content is laid down in a different directory from v1, and a user's updated to point to v2 instead of v1.
"Provisioning" adds a package family to a list tracked in Windows. Packages in this list are offered to every user (if they don't have), so it's more of an "All User" model than "Per-Machine" -- packages are still registered per-user, but updates are more of a controlled and non-impactful migration from vOld to vNew, vs the classic "kick everyone out of the pool so I can update the bits".
"All-User" provides the same net result as "Per-Machine", but in a less impactful way.
This has nothing to do with the Store, or any other source for a package. It's core MSIX behavior.
Here's some light reading you may find helpful:
P.S. I think your script is bugged.
Add-AppxPackagehas no-AllUsersoption. If you remove itthen you're (a) installing (add, aka stage+register) the package for the current user and (b) provisioning the package, to make it available to all users (current and future).
rhubarb-geek-nz commentedon Jun 11, 2026
As part of step 2 I have updated my ZIP to MSI script to repackage the win-x86, win-x64 and win-arm64 zip releases as MSI.
Like a self-fulfilling prophecy, we have reached step 3
Karl-WE commentedon Jul 17, 2026
if not already included, adding these aspects for revision and including into #27565
God-damnit-all commentedon Aug 16, 2026
This is such a terrible idea and I'm appalled that this was pushed through before addressing the numerous MSIX shortcomings.
I'd hoped that Windows K2 meant the trend of trying to force people onto unfinished products would stop, but apparently that's not the case. This is the sort of move that gives the Appx framework such a bad reputation.
Maybe I would've considered it if the flaws had been fixed beforehand, but as a result of this I don't plan on ever letting it handle my PowerShell installs.