Creating MSIX Packages with RayPack 6.1

Last week I was in London, and had a chance to speak to a few MS guys standing behind #MSIX. Also last week, a new version of RayPack Studio has been released, bringing some improvements over MSIX conversion in the latest revision 6.1. With this post I wanted to make a quick walkthrough of going from so-called legacy installations (traditionally all setup.exe and alike, but recently the Windows Installer format has been counted to that group) to the new, modern and native Windows-10 way of installing and servicing apps.

Installing Firefox in MSIX format (auto-conversion from MSI)

There is a way to make all of this happen on a virtual machine via the PackBot module, but for the sake of simplicity I am going to go the easy way, with local repackaging. I am going to to the following:

Set up my environment

Make the first snapshot

Install and configure Firefox

Make the second snapshot

Compare the snapshots, create RCP (RayPack Capture Project)

Clean-up the project, remove obsolete resources and OS noise

Set-up the signing facility

Build and run MSIX file

After starting RayPack, go to FILE > New > Repackaging to open the Repackaging wizard:

Pick the Firefox Installer, and adjust the required fields as needed. I always use the Advanced mode (see the picture below) which enables all screens and settings:

The snapshotting and installation is pretty straightforward – simple select the installer and go next until reaching the following page:

The defaults should be just fine, in most cases enabling only C drive, HKLM and HKCU registry keys would be sufficient. The aggressive list is by default disabled, but in my opinion you should go with it, as it makes the subsequent clean-up easier.

You should avoid enabling permissions scanning. This may be useful for some IT Pros, but in case of repackaging to MSIX only takes system resources and does not bring any value-added.

After all, proceed to the next screen until the setup is started.

The installation does not require any special attention. After it you can start Firefox, and configure a few things like:

Disable auto-updates

Disable Maintenance Service

Skip first-run UI

Set up the default home page

…and so on

When ready, make a second snapshot. After a while and accepting summary pages, the repackaged project will be open. The project itself is not in any particular format (MSI nor MSIX) but has a loose file structure, with an XML definition that links the resources and meta-data. From this project, it is possible to go to MSI, MSIX, App-V and a few other formats RayPack offers. I personally find it useful to store the project for some further reference, as sometimes cleaning-up to many resources requires rebuilding – which is easy if you have your source project!

This is the place where a final clean-up and review should take place. Make sure the values (like Product name, Version and Manufacturer) are correct, and take a look at the numbers in the Project overview to have some initial feeling about the content of the package.

There are at least three views which should be of interest now:

Files and folders

Registry

Shortcuts

Depending on how many exclusion lists have been selected before, you may get a clean state right away or a state that requires some manual intervention. If you see a resource which does not belong to the repackaged app (for example noise from OS, Windows Updates, antivirus etc.) just exclude it by right clicking the item and selecting the right option.

As a side note – this clean-up step used to be much more important for the MSI packaging or any other packaging to a so-called “fat-client”. Leaving up unnecessary resources could lead to some serious conflicts later on. Fortunately, since the MSIX format operates on a virtualized file system, leaving up too many resources would not have that big impact, except of polluting the package with unnecessary resources (which means increase in size) and any DLL or other resource conflicts will be only scoped to the current package, leaving the system intact. Still, making sure that the MSIX package is clean and as light as possible is still important, and I would not underestimate the importance of this step.

Now, back to Firefox, for this repackaging, I haven’t changed anything in the Maintenance Service from Mozilla. This is why you should simply exclude it from RCP, before the final conversion takes place.

Repeat the clean-up for registry and services, it should be pretty trivial now.

Before we go any further, there is some configuration to be done. MSIX packages must be digitally signed, otherwise the user will not be able to install (and consequently run them). For this to work, we need to configure our digital signature and make RayPack know about it.

If you already have .cer and .pfx files (+ optional password for it) you may go directly to the SETTINGS > Tagging + signing screen, where the values can be provided.

Otherwise, you can create your own personal certificate for testing (aka self-signing). There are many ways of doing this, I prefer to start the following PowerShell script:

Replace the placeholders with values you need, and run it. In the working folder, you should get three files, containing the certificate, the private key for it and password for signing. Make sure to import the certificate to a trusted store on the development/test machine (simple double click and selecting a certificate store would be just fine). Obviously, self-signed certificate are not an option for production, for enterprises their trusted certificates could be distributed over GPO or other means, and the signing itself can be delayed and done by other services.

Now, once the certificate is available and trusted, head to FILE > Settings > Signing + tagging and configure them accordingly.

You will need to execute this one-time step once (or to be more precise: once for each profile). After the signing is set up, you can build as many MSIX packages as you want, without changing a bit in projects. RayPack takes over the heavy lifting from you, by adjusting the manifest values accordingly.

Once this one-time step is done, it is time to generate our package. Press FILE, select Build and then MSIX package from the list of available formats:

Select the place where the package is going to be saved and press OK. After a while, the MSIX file should be available.

Try to test it out. Go to a clean Desktop (having no previous Firefox installed). Make sure the certificate that we created is trusted by this device. Double click the package, and select Install. It will take just a few seconds to pull the sources and register the application. Note, that you do not need to be an administrator to do it, as all MSIX-installations are registered in per-user context.

You can now press the Launch button to run your Firefox from the MSIX package.

Voilà, the program runs just fine! There are still couple of areas which may require revisiting (and has been omitted from this tutorial for the sake of clarity), mostly about disabling certain options, tweaking the profiles up, adjusting some further meta-data etc. Additionally, there is a pretty decent support for VM integration (Hyper-V, ESXi and Workstation) which makes some steps easier to do with a simpler setup on a clean VM image.

This concludes this small tutorial. For many apps, the conversion is trivial and requires no specialized knowledge. The tooling ecosystem is constantly being improved, and next and upcoming features of MSIX should make it easier to get more apps running without any additional tweaks.

Integrated shimming engine (using Detours) which can be used to fix a few common issues in apps themselves (Package Support Framework).

Open source!

Even old legacy apps (see exceptions above) can be converted to MSIX, without a change in the binary code or recompilation.

On cons side:

Not all apps can be converted. You should be aware of services which are not supported right now, and all limitations that App-V imposes (drivers, IPC via registry etc.).

Full support is only available on Windows 10 1809 and newer. Earlier versions of Windows 10 are likely to be supported soon (1709 and 1803). Windows 7 and Windows 10 will be only available via MSIX Core, which provides no contenerization and thus removes many advantages over legacy technologies.

The format itself is a bit verbose, and documentation in many places poor or contradictory. You should rather stick to tooling from Microsoft or ISVs, like RayPack.

When comparing to App-V, there seems to be a subset of features which MSIX does not support, for example scripting before launching (this may change in the future, but be aware that some dynamics are right now not easily supported out-of-the-box).

I am really looking forward to further development of MSIX and its ecosystem. The technology is promising, and it has been so far one of the most important changes in the software deployment since 20 years, the last one being Windows Installer from MS Team.