MSIX Modernization · Nov 16, 2023

A Comprehensive Guide to MSIX vs MSI Packaging: Unlocking the Future of Application Deployment

As legacy MSI packaging methods become increasingly cumbersome and error-prone, the move towards modern MSIX packaging is emerging as a vital step in driving digital transformation for enterprise IT teams.

MSIX packaging is rapidly emerging as the modern alternative to traditional MSI packaging, offering enterprises a containerised, automated approach that underpins digital transformation. In today’s managed IT services landscape, where every minute of downtime can incur significant costs and expose security vulnerabilities, transitioning from MSI to MSIX is not merely an upgrade—it’s a strategic imperative. Learn more about how our Rimo3 Platform Automation drives automated, secure application deployment and modernisation.

For over two decades, application packaging has been a cornerstone of technology’s evolution. In today’s fast-paced managed IT services landscape, where every minute of downtime can cost hundreds of thousands of pounds and security risks are ever-present, transitioning to automated, cloud-native packaging solutions is more than an upgrade; it’s a strategic imperative.

Think of it like a supermarket warehouse where every item is meticulously boxed and bagged for safe shipping. Packaging protects the product, alleviates unnecessary expenses, and streamlines distribution processes.

Groceries? Really? How does this connect to MSIX?

Application packaging has been an integral part of computing since the dawn of programmable machines.

From the punch card boxes of the 1950s and 1960s
To the cassette tapes and floppy disks in the 1970s and 1980s
Then, embracing the era of files, folders, and icons in the 1980s and 1990s
And landing in the era of CD-ROMs in the 1990s

Ah, good ol’ CD-ROMS. Remember when an MS Office Pro installation meant juggling up to 40 floppy disks? The CD-ROM era was a wild and welcome change!

As we turn the page to the present, MSIX emerges as a groundbreaking evolution in this lineage.

This comprehensive guide explores what makes MSIX an application packaging game-changer and why you should make the switch.

What is MSIX?

First launched in 2018, MSIX is Microsoft’s state-of-the-art application packaging format, engineered to simplify application deployment and management on Windows. Leveraging containerisation, MSIX packaging enhances system performance, streamlines installations, and boosts security—delivering significant benefits for enterprise IT environments.

Targeted at both Independent Software Vendors (ISVs) and large enterprises, MSIX is positioned to eventually replace legacy formats such as Windows Installer (MSI) and traditional setup executables. Although market uptake has been slower than anticipated, its robust, modern architecture supports digital transformation and is ideal for managed IT services.

Often misunderstood as a mere evolution of MSI, MSIX is more accurately the next iteration of APPX—the packaging format utilised in the Windows Store. In practice, an MSIX package closely resembles an APPX file or an App-V package, offering a seamless transition from legacy systems to a cloud-native, automated deployment solution.

MSIX vs MSI: The Key Differences in Formats

MSI packaging installs applications directly on a device, dispersing files and registry entries throughout the operating system. Over time, these dispersed resources—whether still in active use or remnants left behind after uninstallation—can contribute to Winrot, the gradual degradation of system performance on Windows.

By contrast, MSIX is a containerized application packaging format. Instead of spreading its payload across the OS, MSIX encapsulates all files and registry keys within a secure container, which is then virtualized. This approach ensures that, while the application perceives the files to be in their expected locations, the underlying system remains uncluttered, resulting in improved performance, easier updates, and enhanced security.

Technical Details of MSIX

As already mentioned inside an MSIX, there is very little difference to an App-V package. The main difference is how the payload is deployed to a machine. MSIX is fundamentally a containerized application packaging format, similar in many respects to an App-V package. However, the key difference lies in the deployment and management of the payload.

With MSIX, the entire payload—including all application files and registry keys—is encapsulated within a secure container that remains isolated on the device even when the application is not in use. This contrasts with App-V, which only virtualizes its payload at runtime; when the application is not running, its files and registry entries are accessible via Windows Explorer and the Registry.

In technical terms, MSIX ensures that the application environment remains pristine by preventing residue build-up (commonly known as "Winrot") and reducing system clutter. Both MSIX and App-V employ containerisation/virtualisation techniques to deliver applications, yet MSIX offers a more consistent isolation layer across all usage scenarios.

That said, App-V currently manages certain limitations more effectively, particularly during runtime isolation, where it dynamically encapsulates processes to enhance security and compliance.

The rest of the time, however, the payload of an App-V package is exposed and accessible in Windows Explorer and the Registry. MSIX and App-V also share similar limitations because of being containerized/virtualized formats. Though App-V handles some of these limitations better than MSIX does at the moment.

A screenshot of what's inside an MSIX file.

MSIX File Formats and Understanding the MSIX File Structure

MSIX packaging is a modern, containerized format from Microsoft that revolutionises application deployment on Windows. There are two parts to the MSIX file: the package payload and the supporting files required by all MSIX packages. The package payload includes all the application’s files and other assets created as part of building an MSIX file.

An MSIX file comprises two essential components: the package payload and the supporting files required by all MSIX packages. The package payload contains all the application’s files and assets generated during the build process, ensuring a consistent and secure deployment environment.

Supporting Files in an MSIX Package

AppxManifest.xml

The AppxManifest.xml file is central to every MSIX package. It encapsulates all necessary metadata for installing, running, and managing the package, including details on the application's identity, dependencies, required capabilities, visual elements, and extensibility points. Additionally, updates to the AppxManifest.xml are required when invoking the Package Support Framework, ensuring seamless integration with modern deployment pipelines.

AppxBlockMap.xml

This file serves as the blueprint of the MSIX package payload. The AppxBlockMap.xml details every block of data within the package, securing package integrity by facilitating incremental downloads and enabling differential updates. This structured approach ensures that updates can be delivered efficiently while maintaining the integrity and consistency of the deployed application.

AppxSignature.p7x

For security and compliance, all MSIX packages must be signed before installation. The signing process generates the AppxSignature.p7x file, which, together with the AppxBlockMap.xml, verifies the package's integrity during installation. This digital signature is crucial in confirming that the package has not been tampered with and meets the stringent security standards required for enterprise deployments.

Differences and Roles of .msix, .msixbundle, .msixupload, and Other Related File Extensions

In addition to the MSIX file, there are other related file formats you may encounter. These are typically related to ISV applications or appear if you are publishing applications to the Microsoft store.

In the ecosystem of modern application packaging, understanding the distinctions between various file extensions is crucial for IT professionals and Independent Software Vendors (ISVs) alike. This technical overview explains the roles of the .msix, .msixbundle, and .msixupload file formats, along with their applications in enterprise environments and Microsoft Store publishing.

.msix File Format

The .msix file is the fundamental unit of Microsoft’s modern application packaging technology. It encapsulates all necessary components—including binaries, assets, and registry settings—required to securely install, update, and manage an application. This containerised approach enhances system integrity and reduces residual footprint, thereby mitigating issues like Winrot.

Key technical aspects include:

Complete encapsulation of application files and configurations.
Enhanced security via integrated digital signatures and automated integrity checks.
Streamlined update and deployment processes, reducing manual intervention.

.msixbundle File Format

The .msixbundle file serves as an aggregation of multiple MSIX packages, each tailored for a specific Windows architecture such as x86, x64, or ARM. The bundle provides a manifest that directs the installation process by determining the appropriate package based on the target device’s architecture. This capability is essential for ISVs deploying applications across diverse hardware platforms.

Technical highlights:

Contains multiple MSIX packages within a single bundle.
Descriptive manifest detailing target architectures.
Created using tools like MakeAppx.exe, ensuring consistent packaging and deployment.

.msixupload File Format

For applications destined for the Microsoft Store, the .msixupload file is the required submission format. This file can encapsulate multiple MSIX packages or an MSIX bundle, facilitating the upload process. Visual Studio often automates the creation of an .msixupload file during the packaging process, streamlining the path to publication.

Technical features include:

Consolidation of one or more MSIX packages for store submission.
Automated generation via Visual Studio, with fallback support using MakeAppx.exe.
Ensures compliance with Microsoft Store packaging requirements and digital certification protocols.

Comparing MSIX With Other Formats

APPX was originally designed for modern “app” development and was never intended to repackage traditional Win32 applications – the backbone of enterprise desktop software. Consequently, APPX packages, despite being containerized, exhibit several limitations compared to formats like App-V, which were more suitable for enterprise environments. The evolution of application packaging led to MSIX, which builds upon APPX's foundation while overcoming its shortcomings.

Technical Evolution from APPX to MSIX

When APPX was first introduced, it essentially functioned as an APPX package under a different file extension. The early tooling around MSIX still reflects this legacy, incorporating components such as:

AppxManifest.xml: A manifest file essential for configuring an MSIX package.
MakeAppx.exe: A command-line tool used to generate an MSIX package.
Add-AppxPackage and Remove-AppxPackage: PowerShell commands for installing and uninstalling MSIX packages.

These tools not only facilitate the deployment of modern packaged applications but also underscore MSIX’s technical lineage from APPX.

Enabling Enterprise Application Repackaging

MSIX represents a significant step forward by enabling enterprises to repackage their legacy applications using the MSIX Packaging Tool. Whereas repackaging to APPX was previously achievable via the Desktop Bridge – a utility not optimised for enterprise-scale needs – the MSIX Packaging Tool now supports conversion from Win32 applications in MSI, App-V, and Setup EXE formats into the robust, containerized MSIX format.

Much like the transformative shift witnessed with Windows Installer over two decades ago, MSIX offers enterprises an opportunity to standardise their application packaging strategies. This alignment with a format widely adopted by Independent Software Vendors (ISVs) ensures greater consistency in managing and delivering repackaged and Commercial Off-The-Shelf (COTS) applications, thereby streamlining IT operations and reducing technical debt.

3 Reasons To Repackage Applications To MSIX

Repackaging legacy applications into the MSIX format can greatly simplify management and deployment, particularly for older applications lacking unattended installation options or requiring post-install configuration beyond traditional installer capabilities. MSIX not only streamlines operations but also offers significant technical benefits over older packaging methods.

1. Prevents Winrot

MSIX is a fully containerized format that isolates all associated files and registry keys from the operating system. Unlike legacy packaging formats, which often leave behind scattered remnants that accumulate over time and degrade system performance (commonly known as Winrot), MSIX packages ensure that the application’s footprint remains consistent and isolated. This containment guarantees:

Enhanced System Performance: By preventing resource build-up, devices maintain optimal performance.
Improved Stability: A clean, isolated environment reduces conflicts and potential system slowdowns.
Streamlined Management: Administrators benefit from a predictable and maintainable deployment architecture.

2. Bandwidth Optimizations

MSIX packaging supports incremental downloads and differential updates, meaning that only the parts of the application that have changed are downloaded during an update. This capability offers several advantages:

Efficient Data Transfer: Incremental updates reduce the amount of data transmitted over the network, conserving bandwidth.
Faster Updates: Differential updates ensure quicker installation times by avoiding redundant data transfers.
Cost Savings: Reduced network load can lead to lower operational costs, especially in large-scale deployments.

3. Disk Space Optimizations

MSIX ensures that there is no unnecessary duplication of files across packages. When two MSIX packages contain the same file, the file is stored once on the device and shared between both applications through the use of hard links. This mechanism offers:

Optimised Storage Utilisation: Shared files prevent redundant copies, conserving valuable disk space.
Efficient Resource Management: When an application updates a shared file, the system intelligently manages file versions without duplicating data.
Seamless Deployment of Runtimes: Deploying runtimes either locally or bundled within the MSIX package does not consume additional space if already present on the device.

MSIX Compatibility with Older Windows Versions

Microsoft recognises that most enterprise applications remain rooted in traditional Win32 architecture—a trend that is expected to continue for years. This presents challenges when repackaging these applications in the modern MSIX format due to inherent limitations.

1. Challenges with MSIX Compatibility

1.1 Limitations Encountered

When deploying traditional Win32 applications using MSIX, certain limitations can arise:

Inability to Write to the Package Install Location: MSIX containers isolate their payload, restricting write operations to the install directory.
Registry and Parameter Constraints: Some registry operations and the passing of command-line parameters may not function as expected.
Working Directory Restrictions: Applications requiring a specific working directory might face issues due to containerisation.

2. Overcoming Compatibility Issues with the Package Support Framework (PSF)

To address these limitations, Microsoft released the open-source Package Support Framework (PSF). PSF uses detour technology to intercept and redirect system calls at application launch, effectively mitigating compatibility issues.

2.1 How PSF Works

PSF enables fixes to hook into an application at runtime, redirecting calls that would otherwise fail within the containerized environment. This allows legacy Win32 applications to run smoothly under MSIX, even when they require operations not natively supported by the format.

3. Implementing PSF in an MSIX Package

To integrate PSF and ensure smooth compatibility for your legacy applications, include the following components in the root of your MSIX package:

3.1 PSFLauncher Executable

PSFLauncher.exe:
Acts as the initial entry point; it loads the necessary fixup DLLs before launching the main application.
- Architecture: Ensure you include the correct version (32-bit or 64-bit) based on the target application.

3.2 PSF Runtimes

Architecture Dependent:
The PSF Runtimes support the required operations, and, like PSFLauncher, you must select the appropriate version to match your application’s architecture.

3.3 Fixup Dynamic Link Libraries (DLLs)

Multiple DLLs:
Provide the specific fixup DLLs needed to resolve various compatibility issues. Multiple fixups can be included within a single package if necessary.

3.4 JSON Configuration File

Configuration:
The JSON config file directs the PSFLauncher on which fixups to apply, how to apply them, and specifies the target applications. This file is crucial for customising the PSF behaviour to meet your application’s unique requirements.

A screenshot example of what's inside an MSIX file.

File Redirection Fixup: A Technical Overview

In a containerized MSIX package, the file redirection fixup is one of the simplest yet most effective mechanisms to manage file system writes. When an application —such as MyApp.exe— attempts to write to its install location, this fixup intercepts the operation to maintain the integrity of the MSIX container.

To configure the fixup, you must specify:

The target application that requires redirection.
The folder that the application is attempting to write to.
The file or files that need to be redirected.

For example, using a config.json file, you can instruct the PSF (Package Support Framework) to redirect any attempts by MyApp.exe to write a log file in the “My App” folder. This not only ensures that the application’s payload remains isolated and secure but also prevents potential system degradation (commonly known as Winrot).

By leveraging this approach, enterprises can maintain a clean, containerized environment that supports secure, automated deployment—key for digital transformation and robust managed IT services.

The simplest example of this is the file redirection fixup, which can be used when an application tries to write for its install location.

For this fix-up, define the application it needs to be applied to, the folder that the application is trying to write to, and the file(s) that should be redirected.

This would look like the config.json file below. It redirects any attempts by MyApp.exe to write to a log file in the “My App” folder.

An example of what the config.json file looks like - MSIX

Further information on the Package Support Framework can be found on Microsoft’s Package Support Framework or Github’s Package Support Framework.

The MSIX Container and Its Benefits

The MSIX container is a critical component of modern application packaging, ensuring that applications and their child processes run in isolation through advanced file and registry virtualization. The MSIX Container ensures that the application and child processes run in isolation from the operating system and other applications using file and registry virtualization.

This isolation not only secures the application payload but also maintains system performance by preventing conflicts with the host operating system.

An examples of the MSIX shared container.

When installed, the payload of an MSIX lays down in C:\Program Files\WindowsApps\package_name, including any files that will be part of the VFS as well as registry .dat files for any required registry keys.

This means when the MSIX package is removed and the “package_name” folder is deleted, the application has been cleanly removed from the device. Any changes made to the virtualize file system or registry are deleted as well.

Storing the registry keys for an MSIX package in .dat files so they’re virtualized at runtime has an additional benefit. Windows starts all the registry keys under HKLM and are enumerated. The more registry keys present the longer it will take to start.

If applications leave HKLM keys behind when uninstalled, they continue to make start times slower even after the application is gone. App-V doesn’t solve this problem because once installed, all the HKLM registry keys destined for virtualization are stored in the registry.

How the MSIX Container Operates

When an MSIX package is installed, its payload is deposited in a secure directory, typically:

C:\Program Files\WindowsApps\package_name

Within this directory, the package includes:

Virtual File System (VFS) Files: All application files and assets are encapsulated within the container, ensuring they remain isolated from the host system.
Registry .dat Files: The required registry keys are stored in .dat format, enabling runtime virtualization of the registry.

This architecture ensures that when the MSIX package is uninstalled, the entire folder (e.g., “package_name”) is completely removed from the device. Consequently, any virtualised changes—both file system modifications and registry entries—are deleted, preventing residual data that could degrade system performance.

Benefits of MSIX Containerization

Preventing Winrot and System Clutter

By maintaining all application data within an isolated container, MSIX packaging prevents the accumulation of orphaned files and registry entries. This elimination of residue (commonly referred to as “Winrot”) ensures that the device’s performance remains optimal over time.

Optimised Registry Management

Storing registry keys as .dat files means that these keys are virtualized at runtime. Since Windows enumerates all registry keys under HKLM during startup, legacy applications that leave keys behind can slow down system boot times. MSIX's approach guarantees that once a package is removed, all related registry data is also purged, thus enhancing startup performance.

Enhanced Security and Compliance

The isolation provided by the MSIX container not only simplifies uninstallation but also bolsters security. By containing all application components, the risk of conflicts and security breaches is reduced. This clean, containerised environment aligns well with enterprise security standards and compliance requirements, making it an ideal choice for managed IT services.

MSIX containerisation delivers significant benefits by isolating application payloads from the operating system, optimising registry performance, and preventing system clutter. This approach not only supports secure, streamlined application deployment but also underpins digital transformation initiatives by reducing technical debt and enhancing overall IT efficiency.

The MSIX Shared Container Explained

A shared package container allows MSIX packages to run in the same container. This enables them to see each other’s processes and a merged view of their virtual file systems and virtual registry. Shared containers are only available to enterprise editions of Windows and require admin privileges to use.

MSIX Shared Containers enable multiple MSIX packages to run within the same container, providing a merged view of their virtual file systems and virtual registry. This advanced containerisation feature is available exclusively on Enterprise editions of Windows and requires administrator privileges.

You can configure shared containers by defining an xml file. That gives the shared container a unique name and lists the packages that should run in that shared container. Unlike App-V connection groups, the apps running in the shared container don't need installation to deploy to a device.

How It Works

When MSIX packages share a container, they can interact with each other’s processes while maintaining isolation from the host operating system. This unified environment streamlines inter-application communication and simplifies management. Unlike traditional App-V connection groups, apps within a shared container do not require installation on the device to be deployed.

Configuring a Shared Container

Shared containers are configured using an XML definition file. This file assigns a unique name to the shared container and enumerates the MSIX packages that should operate within it. The process is automated via PowerShell commands, ensuring precise control and repeatability.

Step-by-Step Configuration

Create the XML Definition File:
- Define a unique container name.
- List the MSIX packages to be included in the shared container.
Deploy the Shared Container:
Use the following PowerShell command to deploy the container definition file:
Add-AppSharedPackageContainer -Path C:\MyFolder\ContosoTestContainer.xml
Reset or Remove the Shared Container:
To reset the shared container, run:
Reset-AppSharedPackageContainer -Name ContosoTestContainer
To remove it entirely, execute:
Remove-AppSharedPackageContainer -Name ContosoTestContainer

An example of the separate and shared containers in MSIX shared container.

For shared containers, an app can only be part of one shared container.

If you add a pre-requisite package to a shared container, all other packages needing that pre-requisite have to be part of the same shared container. They also need to co-exist with each other.

The shared container might offer a more streamlined alternative to deploying pre-requisites locally in a traditional packaging format. But you still might consider capturing pre-requisites as part of the package that depends on them.

The single instance of files means even if multiple packages contain the same prerequisite, you won’t be losing disk space.

Shared Containers and Pre-Requisite Management in MSIX Packaging

In a shared container, an application can only be part of one container, meaning that if a pre-requisite package is added, all other packages that rely on that pre-requisite must be grouped within the same shared container. This ensures that the packages co-exist and interact seamlessly. While a shared container offers a streamlined alternative to deploying pre-requisites locally via traditional packaging methods, it is still advisable to capture pre-requisites as part of the dependent package when necessary. The benefit of using a shared container is that a single instance of files is maintained—so even if multiple packages contain the same pre-requisite, disk space is not wasted through redundancy.

Technical Benefits

Consolidated Resource Management

Shared containers merge the virtual file systems and registries of multiple MSIX packages. This consolidation reduces redundancy and optimises resource utilisation, ensuring that shared pre-requisites are stored only once, thereby conserving disk space and enhancing overall system performance.

Enhanced Interoperability

By enabling applications within the same shared container to interact, the format facilitates complex workflows and integrated processes. This interoperability is crucial for enterprises managing multiple, interdependent applications, allowing for smoother data exchange and a more cohesive IT environment.

Streamlined Deployment

Unlike traditional installation methods, the shared container approach allows for immediate deployment without redundant installations. This not only simplifies the deployment process but also minimizes potential conflicts and delays, making it an ideal solution for managed IT services in modern enterprise environments.

Introduction to MSIX Core

Windows 10 version 1709 and later natively support MSIX, the modern containerised application packaging format from Microsoft. Given that Windows 10 1709 is no longer serviced, it is critical for enterprises to migrate to a supported version of Windows 10 to fully leverage the benefits of MSIX packaging.

If you are operating on legacy versions of Windows—such as Windows 7 SP1, Windows 8.1, or pre-1709 releases of Windows 10—and wish to avoid the overhead of maintaining both MSIX and non-MSIX packages, MSIX Core provides an optimal solution. MSIX Core extends support for deploying MSIX packages on older operating systems and on supported editions of Windows Server (with Desktop Experience). This ensures that your modern packaging strategy remains consistent across diverse environments, even when using legacy OS versions.

To integrate MSIX Core support, it must be added to your MSIX package during the packaging process. In the MSIX Packaging Tool, simply select the appropriate checkbox when creating a new package or updating the existing MSIX package manifest. This configuration enables the deployment of MSIX packages on a broader range of devices, ensuring compatibility and streamlined application management across both modern and legacy systems.

If you’re running a version of Windows that doesn’t support MSIX, and you don’t want to maintain an MSIX or non-MSIX package, consider MSIX Core. It allows you to deploy MSIX packages to:

Windows 7 SP1
Windows 8.1. Support versions of Windows Server (with Desktop Experience),
Windows 10 releases prior to 1709

Support for MSIX Core must be added to the MSIX package. In the MSIX Packaging Tool, select the checkbox when creating the package or updating the MSIX package manifest of existing packages.

A screenshot of the MSIX packaging tool in use.

MSIX Core does not provide the container benefits of native MSIX. It’s simply a mechanism for deploying the payload of an MSIX to an operating system where MSIX is not supported.

The Importance of MSIX Signing

All MSIX packages must be signed with a valid code signing certificate before they can be installed. This is a critical security measure that ensures the integrity and authenticity of the package.
For ISVs who put their apps into the Microsoft Store, that process automatically signs the MSIX for them. For enterprises creating their own MSIXs, they need to provide a valid certificate to sign their MSIX packages before deployment.

Enterprises have two options:

Buy a code signing certificate: Windows trusts certificates from certified providers.
Create a self-signed certificate: if you create a self-signed certificate, you should distribute it to all your devices

Whichever option you choose, use timestamping to ensure your signed MSIX packages will still be useable even if the certificate expires. For example, self-signed certificates created through PowerShell are only valid for a year.

Simply put, the time-stamping authority shows that your certificate was valid at the time of signing.

As a last note, whenever an MSIX file is edited, it must be resigned by the packaging tool used to edit the MSIX or with a utility like SignTool.exe which can be found in the Windows SDK.

1. Mandatory Signing for MSIX Packages

Every MSIX package requires a digital signature to be accepted by Windows. For Independent Software Vendors (ISVs) who publish their apps on the Microsoft Store, the signing process is automated during submission. However, for enterprises that create and manage their own MSIX packages, it is imperative to supply a valid code signing certificate prior to deployment.

2. Enterprise Options for Signing

Enterprises have two primary options for signing MSIX packages:

Purchase a Code Signing Certificate:
Acquiring a certificate from a trusted, certified provider ensures that Windows will automatically trust the signature.
Create a Self-Signed Certificate:
Enterprises may opt to generate a self-signed certificate using PowerShell. If you choose this route, it is essential to distribute the self-signed certificate across all devices to maintain trust. Note that self-signed certificates created via PowerShell are typically valid for only one year.

Regardless of the option selected, it is crucial to use timestamping during the signing process. Timestamping confirms that the certificate was valid at the time of signing, ensuring that the MSIX package remains usable even after the certificate expires.

3. Re-signing and Package Integrity

Whenever an MSIX file is edited, it must be re-signed to preserve its integrity. This can be done using the same packaging tool used for the modifications or via a utility such as SignTool.exe, which is included in the Windows SDK. Re-signing guarantees that any changes made are authenticated and the package continues to meet security standards.

How To Install and Uninstall MSIX Packages

Enterprise IT teams can deploy MSIX packages using a variety of methods that cater to both on-premises and cloud environments. Modern deployment solutions—such as Endpoint ConfigMgr, Microsoft Intune, Azure Virtual Desktop, and Windows 365 Cloud PC - ensure that MSIX packages are distributed reliably across diverse platforms.

If you are just getting started with MSIX, you can install packages using App Installer. It allows you to install MSIX by double clicking on it. The App Installer has a simple GUI interface but doesn’t let you configure the MSIX in any way. If you don’t have the App Installer on your device, you can install it from the Windows Store.

To remove an MSIX package, right click on the Start Menu and select “Uninstall” or find the app under Apps & Features and choose the uninstall option.

Alternatively, you can use the Add-AppxPackage and Remove-AppxPackage PowerShell commands.

Installing MSIX Packages

Using App Installer

For those new to MSIX, the simplest method is to use the App Installer. This utility provides a straightforward GUI, allowing users to install an MSIX package by simply double-clicking it. Note that while App Installer offers ease-of-use, it does not provide advanced configuration options. If your device does not have App Installer, you can download and install it directly from the Windows Store.

Alternative Installation via PowerShell

For more granular control, you can install MSIX packages using PowerShell commands. The primary command is:
Add-AppxPackage -Path "C:\Path\To\YourPackage.msix"

This command enables scripted and automated deployments, which is particularly useful in managed IT environments where integration with tools like Intune or Endpoint ConfigMgr is required.

Uninstalling MSIX Packages

Using the Graphical Interface

To remove an MSIX package via the GUI:

Method 1: Right-click the Start Menu, select “Uninstall.”
Method 2: Navigate to Apps & Features in the Settings app, locate the application, and select the uninstall option.

These methods are user-friendly and suitable for individual or small-scale uninstallation tasks.

Alternative Uninstallation via PowerShell

For bulk or automated uninstallation, PowerShell provides an efficient alternative. The main command is:
Remove-AppxPackage -Package "PackageFullName"

This command can be integrated into scripts or deployment pipelines, making it ideal for enterprises managing multiple endpoints.

The Future of MSIX: What’s Next?

It is clear there are benefits of MSIX but as with many things, adoption will be key, both from the enterprise and ISVs alike.

MSI gained great traction in the enterprise as a repackaging format and vendors followed suit which is why it is still such a prevalent format. App-V also gained significant traction in the enterprise, but it could never fully replace MSI and didn’t appeal to vendors.

MSIX is poised to redefine application packaging for both enterprises and ISVs, thanks to its modern, containerised approach and advanced automation capabilities. While the benefits of MSIX are clear, widespread adoption remains crucial. As enterprises increasingly transition to cloud-native environments and vendors continue to modernise their software delivery, MSIX is set to gain significant traction.

The Potential of MSIX in the Enterprise

Even though legacy formats like MSI will persist for years, MSIX has considerable potential to transform enterprise application deployment. The transition from App-V to MSIX is already underway for many ISVs, indicating early adoption signals and paving the way for broader enterprise uptake. As digital transformation accelerates, enterprises are increasingly recognising the value of containerised, cloud-native solutions like MSIX for enhancing system performance, reducing technical debt, and ensuring robust compliance.

Expert Insights

Andrew Mason, Solutions Engineer at Rimo3, encapsulates the evolving landscape:
“MSI gained great traction in the enterprise as a repackaging format and vendors followed suit, which is why it remains prevalent. App-V also found its niche but never fully replaced MSI. At a minimum, MSIX has the potential to gain significant traction in the enterprise. Those using App-V have already made headway on an MSIX journey thanks to ISV uptake of the format. MSI and older formats will exist for years to come, but the future is clearly leaning towards MSIX.”

At a minimum, MSIX has the potential to gain significant traction in the enterprise. Anyone using App-V inherently made headway on an MSIX journey thanks to ISV uptake of the format. MSI and older formats in the enterprise will exist for years to come.

- Andrew Mason, Solutions Engineer at Rimo3

Looking Ahead

As enterprises and ISVs continue to explore MSIX, we can expect a growing array of applications deployed via this format. Enhanced automation, improved security, and the benefits of containerisation will drive further adoption. Ultimately, MSIX is set to become a cornerstone of modern IT deployment strategies, supporting digital transformation and enabling scalable, efficient, and secure software delivery.

As enterprises and ISVs explore this format and encourage the technology to mature, you’ll see MSIX used to deliver more applications.

A Quicker Solution for Application Modernization Packaging

Modernising and repackaging enterprise applications can be an arduous process, but Rimo3 Cloud offers a robust, automated solution to streamline this journey. Our platform conducts an in-depth analysis of your application portfolio to determine MSIX suitability, harnessing advanced automation to simplify the entire process.

The unique Intelligent Smoke Test can convert application packages and run tests to ensure they work in the new format. At the core of our solution is the Intelligent Smoke Test - a proprietary technology that converts legacy application packages into the modern MSIX format and rigorously validates their functionality. This automated testing capability can process thousands of applications in mere hours or days, significantly reducing the manual overhead typically associated with application modernization.

Depending on the project, you can automate testing for thousands of applications in hours or days. By trading manual application testing for automation, Rimo3 Cloud not only enhances deployment speed and accuracy but also ensures improved security, compliance, and overall system performance.

Embrace this streamlined, cloud-native approach to accelerate your digital transformation and drive operational efficiency.

Trade manual application testing for automation.