Q&A
Modern App Packaging: Why MSIX Is Replacing MSI and App-V
Microsoft's MSIX format is steadily becoming the standard for modern application deployment, offering a more reliable, container-based approach than legacy installers.
As organizations look to modernize application deployment strategies, MSIX has emerged as Microsoft's long-term solution for packaging and distributing Windows apps. While MSI and App-V have long histories in the enterprise, MSIX introduces a containerized model that simplifies management, improves security, and enhances compatibility with modern Windows environments.
In an upcoming Live! 360 Orlando session (taking place Nov. 16-21), Kevin Kaminski will provide practical guidance on moving from traditional packaging methods to MSIX. The session, titled "MSIX Application Packaging," will examine how MSIX differs from its predecessors, outline steps to convert legacy applications and highlight best practices for enterprise-scale deployments.
Attendees can expect to learn not only the technical details of repackaging applications but also how to integrate MSIX into CI/CD workflows and address potential compatibility issues. With adoption rates for Win32 conversions climbing, Microsoft continues to refine the format, expanding support and tooling to help IT professionals streamline app delivery.
This Q&A with Kaminski offers a preview of the session's focus areas and explains why organizations still relying on MSI or App-V should start considering MSIX as the go-forward standard.
For more insight, make your plans to join us at this year's Live! 360. Save $400 if you register by Sept. 26!
Redmondmag: How does MSIX streamline app deployment compared to MSI or App-V?
Kaminski: At a high level, you could argue they are very similar, and that has probably contributed to the difficulty in retiring App-V deployments. App-V was acquired from Softricity, and that made it technically an agent that facilitated the virtualization of applications. Later versions had App-V as a Windows feature, but it was still essentially an add-on.
It was an unusual solution, as the application is installed on the client, file and registry redirection took place to trick the application into thinking it is installed in the Program Files folder, for example. To add that special magic, there was this sort of bubble effect where changes to application settings and registry were stored in a non-persistent state. If your application was broken, it is a simple matter of exiting the application and resetting its state.
To take things a step further, the bubble also has some COM isolation in place to hide applications from each other. This was both helpful and painful, but essentially it led to the consolidation of applications on a multi-user Windows virtualization host and also uncovered the secret world of application dependencies where COM isolation became an issue. Sometimes, we would have to bundle software into a single App-V package to ensure the proper operation of a critical line-of-business application.
MSIX differs in that it focuses on placing the application in a persistent container; from download to launch, the application behaves as a container. App-V provided a method to convert applications into an isolated state, but MSIX is the future state of applications. Its previous iteration, known as Universal Windows Applications, struggled for adoption primarily because it was too strict an execution environment for most Win32 applications.
What happened is that MSIX had a larger feature set, which was expanded upon by the community to increase the number of applications that could be successfully converted to MSIX. Suppose you are developing your application for or looking to transform legacy applications. In that case, it is time to consider MSIX now that it has matured and conversion rates for Win32 software are over 70 percent.
Software vendors can more reliably build and deploy client applications using Microsoft's Store infrastructure or the MSIX app-attach method to their enterprise or retail customers. Applications that migrate to MSIX are treated as native application formats, with no agent to install or enable. Windows 10 and Windows 11 have many applications that are part of the operating system, which get updated through the Windows Store.
MSIX is the long-term vision for delivering virtual/modern applications on the Windows platform. App-V is still around, but organizations are better off investing time in learning and using MSIX technologies.
What steps are involved in converting legacy applications into MSIX?
Before you delve into the complexities of packaging, there are some basic items to address.
A packaging request may seem unnecessary if you are just creating a quick package, but if you are making something for MSIX, it is probably essential. A packaging request doesn't have to be a wall to get service, but from packaging far too many things, you need to understand what is being asked of you. Some basic stuff would be:
- Application Name
- Application Version
- Installer files
- Install Instructions
- License files or licenses
- A login or access is required to launch the app
There is other nice-to-have information, but you see where this is going without clearly defining the request and what success looks like. A significant amount of time could be wasted chasing media, license codes, testing and updating the package.
You will also need virtual machines for packaging and testing; these virtual machines must be configured for their specific roles. Generally, I prefer to use a local installation of Hyper-V and increase the hardware in my host machine, but everyone has their favorite tool. I just like Hyper-V for being simple and free. Also, avoid using packaging machines in the data center; your administrator won't like the idea that you might have several VMs with all sorts of snapshots taken. Data center storage is significantly more expensive than local SSD, which essentially drives my decision to keep packaging to a desktop or laptop with extra SSD disk and RAM.
When you think you are ready, there is also a massive consideration for MSIX, because we are in an era where polymorphic code is being used to bypass antivirus software. One way to help counteract the use of suspicious code is to ensure that the code is signed and that even includes legacy software installers though some legacy software does not have signed components. You can use a self-signed certificate for the process, but I don't recommend it for anything other than testing.
Use your certificate authority or a third-party signing certificate for your MSIX packages. Once you have obtained this certificate you can use it for a variety of technologies to mark application code or installers as trusted. Signing code is the best way to help various security technologies determine if this application is trusted to run or not and this is why MSIX makes it a requirement.
To finish off the packaging environment you have to consider the use of third-party tools. Microsoft offers a free repackaging tool but there are a number of vendors that have packaging tools available for MSIX repackaging. You will likely have a temporary snapshot with the tools installed as you will likely go back to that snapshot while repackaging.
Are there any compatibility issues with MSIX in mixed OS environments?
I wouldn't say there are compatibility issues, but there have been some notable changes between Windows 10 and Windows 11 in terms of functionality. Before I delve into that further, I would say that, in general, from Windows 10 onward, the API level of compatibility with applications has been extremely high, and Microsoft offers AppAssure to customers who encounter blocking compatibility issues with their applications and Windows Updates.
As for differences in the operating system with Windows 11, the advent of Shared Package Containers enabled MSIX packages to share a common runtime environment, thereby optimizing disk usage. A more essential fix was the addition of a context menu that allowed applications to have right-click menu support in Windows. Applications that require modification of their installation folder's files were given the ability to enable this feature as part of the packaging process.
One more obscure issue was how different versions of Windows would handle MSIX packages with the same name but a different signer. Some will let you install both packages, while others will limit you to one.
What are best practices for enterprise-scale MSIX deployments?
A lot of it comes down to planning and process, when you are migrating a portfolio of applications it is going to be crucial to find the experts in the company that know enough about each application so that it can be packaged and tested before production use. With some applications they have dedicated support teams that can be used but many applications are not frequently modified and become forgotten in many ways. In these cases, sometimes a power user and the software vendor are your only resources.
Build a standardized packaging environment so that you get predictable results when repackaging applications for MSIX. Also, you may have more than one person doing the packaging so having naming standards, file share folder naming and documentation locations defined to keep everything in order as applications get packaged.
Testing of course is very important, make sure that you have a separate device that is considered production but is a test device as in no user is using it as their primary device. The user can then log into the test device either remotely or locally for application testing. What I like to do is ensure at the very minimum there is separation from packager testing, pre-production, and production environments.
Staggering the rollout of an application is a possibility, this will vary on how you publish and manage applications but if it is a sensitive line of business application then the rollout of a new version might only go to a small initial group until confidence is gained that the application is suitable for a larger audience.
How can MSIX be integrated into modern CI/CD workflows?
For developers wanting integration this exists via the Azure DevOps Marketplace where MSIX specific steps can be added to your pipeline. You would then configure tasks to build, create and of course sign the package. You will need to use VCBuild or MSBuild to compile the application's source code.
The package MSIX file is then created and signed before building the output needed for installing and running the application. The artifacts are published and the process is complete.
Of course, there is much more work when you get into building your pipeline but as you can see Microsoft has built specific tooling that could be compared to WIX but being a MSIX version. Regardless, this helps close the gap for developers building applications and having them successfully install.
What tools can validate and troubleshoot packaging issues?
Unfortunately, MSIX is more about how well the application runs as an MSIX application as the containerization of the application imposes technical hurdles for applications not designed for MSIX. When an application is repackaged from Win32 to MSIX the application sometimes gets confused or it needs help integrating with the operating system. The Package Support Framework is key to getting high levels of application compatibility as this is where most of the application compatibility work has been done.
When repackaging from Win32 to App-V or MSIX the domain of knowledge about applications and how they interact with the operating system and each other becomes much more important. Most packagers today focus on making installers run silently which is largely a different skill set and tool set than MSIX. There are third party MSIX packaging tools to help simplify the MSIX packaging experience for the packager but troubleshooting largely goes back to some basics.
Process monitor and process explorer are two key tools from the sysinternals toolkit that monitor application behavior at a deep level. These tools look at what processes are loaded the launch command line of an application or trace the activity through the registry and file system.
Some people will mention network tools like Fiddler or Network monitor as options but those tend to be rarely used unless there is a fair bit of internal network isolation that might interfere with application packaging and testing. Not that I like blaming network for everything but if you are going to blame the network you will need proof.
But at a more basic level you will likely use a PSF fixup called PsfTraceFixup to provide an API logging interface. Many issues will be API calls that don't work and the packager's job is to see if there is a way of resolving the issue, if not there has to be a judgement call if the functionality is required or not. For example, before right click menu support you had to determine if this was in fact an issue you needed to resolve or was it considered more of a cosmetic integration with the Windows shell and still proceed with the application in a MSIX format.
Be prepared to understand that MSIX uses different tools and skills you might not be familiar with. Understanding your applications will go a long way but being able to read application traces and troubleshoot compatibility issues with MSIX is going to be the key to getting high success rates with application conversion. The PSF is there to be mastered and is your toolbox for remediating many of the application issues you may see.