PowerShell always had an MSI package that you could download and distribute yourself to install and update, starting with Preview 1 of v7.7, which has changed to MSIX. In this short blog post, I will explain what this means.
MSI vs MSIX
MSI packages have been around for quite some time, but so have MSIX packages. But what’s benefits of using one or the other?
“Benefits of using MSI
With the introduction of MSI, Microsoft streamlined the process of deploying and managing centralized applications. There are lots of benefits of the MSI format, including the following:
- Standardization. MSI provides a standardized method for application installation, making it easier for IT administrators to manage software across a wide range of devices.
- Customizability. IT administrators can customize MSI files through transforms — .mst files — allowing for tailored installations that meet specific enterprise requirements.
- Rollback and repair. One of the standout features of MSI is its ability to roll back installations if something goes wrong. Additionally, MSI supports self-repair, which could fix corrupted installations automatically.
- Administrative installation. MSI supports administrative installations, enabling network-based installations that save time and bandwidth.
- Integration with Group Policy. MSI integrates seamlessly with Group Policy in Active Directory environments, allowing IT to centrally manage application deployments.
IT departments have used MSI deploying standard desktop applications in Windows environments. Its feature has made it an ideal format for large-scale deployments where version consistency, scalability and manageability are paramount.
However, MSI-based applications can leave residual “rot” on the OS. When admins uninstall an MSI package, application files in AppData and registry entries from the app’s usage often remain on the machine, cluttering the system. This phenomenon, commonly known as Windows rot, can slow down a PC with each new installation.
Microsoft aimed to address this issue with the MSIX format, ensuring that when an application or package is uninstalled, all references to the application are completely removed from the system.
Benefits of using MSIX
MSIX also came with some new capabilities and benefits that differentiate it from MSI, including the following:
Backward compatibility. MSIX also supports existing Win32, WPF and WinForms applications, making it easier for developers to transition to this new format without extensive rewrites.”
Universal packaging format. Admins can use MSIX packages across different types of Windows devices, from desktops to mobile devices, offering a unified approach to application deployment.
Enhanced security. MSIX provides a secure installation process by ensuring that packages are signed and validated. This reduces the risk of malicious software, unlike MSI.
Efficient updates and bandwidth savings. With MSIX, updates are more efficient. The technology supports differential updates, meaning only the changed aspects of an application need to be downloaded. This reduces bandwidth and installation time to the client or server.
State management. MSIX includes built-in support for application state management, ensuring that user settings and data are preserved across updates.
Containerization. Applications installed using MSIX can run in a lightweight container, isolating them from the system and other applications similar to App-V.”
Source: https://www.techtarget.com/searchenterprisedesktop/tip/Comparing-MSI-vs-MSIX
Announcement from Microsoft
Today, Jason Helmick from Microsoft posted an article here:
“
PowerShell MSI package deprecation and preview updates
Beginning with PowerShell 7.7-preview.1 (April 2026), the MSIX package will be the primary installation method for PowerShell on Windows. We will no longer ship the MSI installer package for new PowerShell releases.
For existing releases, including PowerShell 7.6, we will continue to provide MSI packages. However, MSI isn’t planned for future releases, including PowerShell 7.7 GA and beyond.
Why we’re making this change
MSIX provides a modern installation and servicing model and is supported by Windows deployment tools. It uses a declarative model that’s more predictable and reliable than MSI, which relies on custom actions and scripts that can lead to inconsistent behavior. MSIX supports built-in update mechanisms with differential updates. Microsoft is investing in improving MSIX.
MSI is a legacy technology. Servicing MSI installations requires external tooling and often results in full reinstalls. MSI doesn’t meet modern accessibility requirements, particularly for screen reader scenarios. To be accessible, MSI must present predictable tab stops and accurate announcements for screen readers, which it doesn’t. Accessibility is a core requirement for PowerShell.
This decision isn’t just about modernizing packaging for its own sake. It’s about ensuring that PowerShell installations are modern and accessible for all users, now and in the future.
Looking forward
Our goal is to provide a fully accessible, reliable, and enterprise-ready installation experience. At this time, MSIX doesn’t support all use case scenarios that MSI enabled, such as remoting and execution by system-level services (like Task Scheduler). We recognize this gap and are actively working to address it.
As part of this work, we’re investing in:
- Improving MSIX support for system-level and enterprise deployment scenarios
- Ensuring accessibility requirements are fully met across all installation paths
- Providing clearer guidance and tooling for deployment at scale
We will continue to share updates as this work progresses.
Closing
We understand this change may require adjustments, especially in environments that rely heavily on MSI-based deployment. We appreciate your patience as we make this transition.
Our focus is to ensure PowerShell remains accessible, predictable, and practical for all users.
— The PowerShell Team”
What does this mean for you?
The biggest thing is that, because it’s MSIX starting with the latest Preview 1 of v7.7 (as mentioned above), remoting and execution from system-level services like Task Scheduler no longer work. Things should work with a service user account, but not with NT AUTHORITY\SYSTEM or with Group Managed Services Accounts. But they are working on that and hopefully have a good solution for these use-cases.
MSIX is designed differently and has limitations due to the AppXManifest.xml inside; there’s no option to load libraries and executables. (Source https://x.com/awakecoding/status/2042656310387147110, I read that just now and remember we already talked about that at the MVP Summit when I met Marc-André Moreau)
Wrapping up
Things are changing for PowerShell on Windows; hopefully, it will turn out for the better and become comparable to the previous installers… Have a lovely weekend!