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 via msiexec are 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.exe on 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