For a long time, the benefits of packaging have shown a lot of value. As an example, just walk through the supermarket: All goods are packaged, except the fresh items you hand pick, some of them may be in bags, but they have been delivered packaged. So, the purpose of packaging is to protect the product, keeps it from going bad, decreases costs, informs, simplifies distribution, and many other benefits.
What does this have to do with MSIX? As long as there have been programmable computers, there has been a form of application packaging and many types: punch card boxes (1950’s and 1960’s), cassette and floppy (1970’s and 1980’s), Files, Folders, Icons (1980’s and 1990’s), CD-ROMS (1990’s). Good old CD-ROM, at least no more up to 40 floppy disks for a MS Office Pro installation! 😊
Back to MSIX, first announced in 2018 it is the latest application packaging format from Microsoft. Sometimes referred to as the next version or evolution of MSI, understandably from the name, it is more accurately described as the next version of APPX, the format used in the Windows Store. As we will see later inside an MSIX package there is almost no difference to the content of an APPX file or, for that matter, an App-V file.
So, what makes MSIX different to these existing formats?
The most obvious difference is to MSI packages which install locally on a device, placing file and registry resources where needed on the machine. Over time these resources, whether still in use or left behind after the original application has been removed, lead to Winrot – the gradual loss of performance on a Windows system. MSIX by contrast is a containerized format meaning that its payload doesn’t get spread across the OS. Instead, all its files and registry keys are stored in a container and where necessary virtualized so that to the application it looks like they are in the expected file system or registry locations.
As already mentioned inside an MSIX, which is effectively a signed zip file, there is very little difference to an App-V package. The main difference is how the payload is deployed to a machine. While MSIX is a containerized format even when not in use App-V only gets virtualized at runtime, that is when running the application processes are isolated in the App-V virtual environment. 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 being more mature handles some of these limitations better than MSIX does at the moment.
This brings us to APPX, the Windows Store format. APPX as a format was never targeted at the Enterprise for repackaging applications as it wasn’t meant for Win32 applications which make up pretty much all the desktop application we know and love in the enterprise. APPX packages, which are also containerized, had a number of limitations, even more than App-V, and the idea was for ISV’s to develop their apps to be “modern apps” for a “modern OS” thus mitigating these limitations. When it was first released MSIX was essentially an APPX package with a different file extension and indeed still today a good part of the tooling around MSIX is from APPX, the AppxManifest.xml file in the MSIX, MakeAppx.exe to generate an MSIX package as well as the Add-AppxPackage and Remove-AppxPackage PowerShell commands to install and uninstall MSIX packages.
MSIX also makes it possible for enterprises to repackage their applications using the MSIX Packaging Tool (repackaging to AppX was possible via a utility called the Desktop Bridge but again this was never targeted at the enterprise). With the MSIX Packaging Tool existing Win32 applications in MSI, App-V and Setup EXE formats can be captured in or converted to the MSIX format. Much like Windows Installer did nearly 20 years ago, MSIX now presents the opportunity for enterprises to move to a package format that is that same as ISV’s will, hopefully, embrace and start using more.
So why would you want to repackage your applications as MSIX’s?
Here are some reasons to consider:
- First and foremost, must be the opportunity for clean installs and uninstalls because of the MSIX Container meaning a faster cleaner Operating System that is less susceptible to Winrot.
- MSIX also offers network bandwidth optimizations allowing MSIX packages to be downloaded and validated incrementally. This also allows for differential updates, that is only the differences between one version of an MSIX and the next need to be downloaded to upgrade an application.
- Disk space optimizations ensure that there is no duplication of files in MSIX packages, in other words if two MSIX packages contain the same file then that file is only laid down once on the device but is shared between both apps by creating hard links. If at any point one of the apps updated that file then it would no longer be the same file and each would use the appropriate version of the file. This could be very useful when it comes to deciding whether to deploy runtimes locally in more traditional formats or to bundle them in the MSIX package as these runtimes would not take up additional space when the packages are deployed to the same device.
Package Support Framework
As previously mentioned MSIX is a package format for modern applications however Microsoft has recognized that most enterprise applications are still traditional Win32 applications and are likely to be so for many years to come. It is therefore likely that applications will come against some of the limitations of MSIX such as the inability to write to the package install location, certain registry actions and launching applications with parameters or a specific working directory. To overcome these issues, they released an open-source project called the Package Support Frame based on Detours technology that allows fixes to hook into an application when it is launched and the redirect calls where necessary to mitigate an issue.
To implement the PSF in the package you will need to include the following in the root of your MSIX package:
- The PSFLauncher exe – this will be the executable that initially gets launched and loads the required fixup before launching your application and injecting the fixup. There is a 32-bit and 64-bit launcher depending on the architecture of the app being fixed so make sure you include the correct file.
- The PSF runtimes – these too are architecture dependent
- The fixup DLL – this is the file that will provide the fixup. There are different DLLs for different fixups and you can include more than one fixup at a time in your package.
- A JSON config – this is the file that tells the PSF Launcher which fixups to apply and how as well as which applications to apply the fix ups to.
The simplest example of this is the file redirection fix up which can be used when an application tries to write to its install location. For this fix up you would define the application that 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 following in the config.json file which would redirect any attempts by MyApp.exe to write to a log file in the “My App” folder:
The MSIX Container
As previously discussed, the MSIX Container ensures that the application process and child process run in isolation from the operating system and other applications using file and registry virtualization. When installed the payload of an MSIX is laid 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 that when the MSIX package is removed and the “package_name” folder is deleted then the application has been cleanly removed from the device including any changes made to the virtualize file system or registry.
Storing the registry keys for an MSIX package in .dat files so that they are only virtualized at runtime has an additional benefit; when Windows starts all the registry keys under HKLM are enumerated, thus the more registry keys present the longer it will take to start. If applications leave HKLM keys behind when they are uninstalled these keys will continue to cause start times to be slower long after the application is gone. Even App-V doesn’t solve this problem because once installed all the HKLM registry keys that will be virtualized are stored in the registry.
The MSIX Shared Container
As the name suggests a shared package container allows MSIX packages to run in the same container enabling them to see each other’s processes and a merged view of their virtual file systems and virtual registry. Shared containers are a feature only available to enterprise editions of Windows and will require admin privileges to use.
Shared containers are configured by defining an xml file that gives the shared container a unique name and lists the packages that should run in the shared container. Unlike App-V connection groups the apps that will run in the shared contain do not need to be installed to deploy the shared container to a device. The shared container definition file is deployed to a device using the PowerShell command Add-AppSharedPackageContainer <path>. Similarly, the shared container can be reset and removed with the appropriate PowerShell commands.
One thing worth noting about shared containers however is that an app can only be part of one shared container, thus if you add a pre-requisite package to a shared container all other packages that need that pre-requisite will have to be part of the same shared container, and furthermore will need to be able to co-exist with each other. So, whilst the shared container might offer a more streamlined alternative to deploying pre-requisites locally in a traditional packaging format you may still want to consider capturing pre-requisites as part of the package that depends on them bearing in mind that the single instancing of files means that even if multiple packages contain the same pre-requisite, you won’t be losing disk space.
MSIX Core
MSIX is support on Windows 10 1709 and later; considering that 1709 is no longer being serviced that means everyone should be using a version of Windows 10 that supports MSIX. However, if you find yourself in a situation where you are running a version of Windows that MSIX is not supported on and you don’t want to be maintaining an MSIX package as well as a non-MSIX package you could consider MSIX Core which allows you to deploy MSIX packages to Windows 7 SP1, Windows 8.1. Support versions of Windows Server (with Desktop Experience) and Windows 10 releases prior to 1709.
Support for MSIX Core will have to be added to the MSIX package, in the MSIX Packaging Tool this is done by selecting a checkbox when creating the package or updating the MSIX package manifest of existing packages.
MSIX Core does not provide the container benefits of native MSIX, it is simply a mechanism for deploying the payload of an MSIX to an operating system where MSIX is not supported.
MSIX Signing
All MSIX packages must be signed with a valid code signing certificate before they can be installed. For ISV’s who put their apps into the Microsoft Store that process automatically signs the MSIX for them. For enterprises creating their own MSIX’s they will need to provide a valid certificate to sign their MSIX packages with before they can be deployed. Enterprises have two options:
- Buy a code signing certificate from a certificate provider – because Windows trusts certificates from most CA’s the certificate you buy will already be trusted by your devices.
- Create a self-signed certificate – if you create a self-signed certificate you will need to distribute it to all your devices.
Whichever option you choose is a good idea to also use time-stamping to ensure that even if your certificate expires your signed MSIX packages will still be useable, self-signed certificates created through PowerShell for example are only valid for a year. Put simply the time-stamping authority validates that your certificate was valid at the time of signing.
Whenever an MSIX file is edited, it needs to be resigned either by the packaging tool used to edit the MSIX or with a utility like SignTool.exe which can be found in the Windows SDK.
Installing and removing MSIX packages
For enterprises MSIX packages can be distributed via traditional methods such as Endpoint ConfigMgr and Intune, as well as being deployed to cloud solutions such as Azure Virtual Desktop or Windows 365 Cloud PC. If you are just getting started with MSIX you can install packages very simply using the App Installer which allows you to install an MSIX by simply double clicking on it. The App Installer has a simple GUI interface, but it is worth noting that it doesn’t allow you to configure the MSIX in anyway. If you don’t have the App Installer on your device, it can be installed from the Windows Store.
To remove an MSIX package you can either 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.
Conclusion
It is clear that there are benefits to be had from MSIX but as with many things, adoption will be key, both from the enterprise and ISV’s 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.
As a minimum MSIX has the potential to gain significant traction in the enterprise not only because anyone using App-V has inherently already made headway on an MSIX journey but also because of ISV uptake of the format. It is likely that we will still see MSI’s and even older formats in the enterprise for years to come but as enterprises and ISV’s alike explore this format and encourage the technology to mature I expect we’ll be seeing a lot more applications delivered as MSIX.
We know how cumbersome the application modernization and packaging process can be. With Rimo3 Cloud we are not only able analyze your application portfolio for suitability for MSIX but through automation and our unique Intelligent Smoke Test we also able to convert the suitable candidates and then test the converted MSIX packages to ensure that applications continue to work in the new format. For applications that do not convert or do not test successfully after conversion details are captured to support further investigation and remediation. Through automation we eliminate unsuitable candidates, create MSIX packages for suitable candidates and identify which can be deployed and which need further investigation or remediation, all in a matter of hours or days compared to the time it would take to attempt to package each application, including the unsuitable ones, manually.
So, can we get your application supermarket ready for your users?
#WeKnowApps
Further Reading
- More about MSIX: What is MSIX? - MSIX | Microsoft Docs
- Package Support Framework Overview: Package Support Framework - MSIX | Microsoft Docs
- PSF GitHub Page: GitHub - microsoft/MSIX-PackageSupportFramework
