MSIX – The Need for a New Application Package Format.

In this article, Rory Monaghan shares his thoughts on the new MSIX application packaging format announced by Microsoft at Build 2018. He looks at what it means for organizations who have invested in App-V and MSI, and those looking to make application deployment easier.

—
I have spent my entire career employed to deal with the complexity of customizing and deploying applications in Windows. Compared to other popular Operating Systems in use today, Windows sticks out like a sore thumb when it comes to providing a poor experience installing and uninstalling applications.

On a Mac, an install is typically a case of one or two clicks, and you’re done. On modern Linux distros, application installs are also just a matter of a couple of clicks. ChromeOS for example – simple! Mobile device Operating Systems are so simple, young children can install and remove applications. On Windows, some applications make you go through a bizarre thing called an ‘installation wizard,’ which has been terrifying technophobes for decades.

Back in 2014, I had the pleasure of attending a session by Ruben Spruijt at BriForum, where he gave his predictions on the future of the workspace. He stated that like cockroaches, Win32 apps will be around long after the apocalypse. He also predicted a container like technology for installs on Windows operating systems. An install as simple and predictable as those on a Mac.

Meet Microsoft’s App Package Format: MSIX.

At this years Microsoft’s Build event, they announced the new application package type for Windows. MSIX! It’s just what Ruben was talking about, and best of all, you can convert many of your existing Win32 apps to this format with ‘relative ease.’

Is the new format an application package type that will streamline installs or automate packaging to the point that Application Packagers will be out of a job? No, in fact, the way Microsoft envisions it, you’ll still be able to add your own customization layer to MSIX packages. Kind of like a modern transform but they’re also thinking ahead by creating a Package Support Framework that encourages contribution from all of us. They also suggest we’ll be able to create application templates, to allow us to create updated packages wholly automated from the command line\PowerShell.

While it appears MSIX won’t eliminate re-packaging entirely for organizations, it addresses many of the current shortcomings of existing application package types for Windows while also helping to modernize your existing applications so they can take advantage of the new UWP features in Windows 10.

Also, if successful packagers spend less time reverse engineering dodgy vendor packages and more time adding modifications to suit their customer’s wants and needs, that is a HUGE win!

Getting Developers Onboard.

John Vintzel spoke at length during Build on this new package format. You can watch the presentation for yourself below.

My initial impression was that it was difficult to perceive what the result of MSIX would mean for those of us in enterprise IT. Not all that surprising, given Build is a developer-focused event.

An interesting point raised during his session that was developer focused but will ultimately have an effect on IT Pros is the fact he showed that there will be a native option in Visual Studio to distribute with an MSIX package format.

In the past, Microsoft leaned on Flexera to provide free additional tooling for producing MSIs from Visual Studio. At Build, it was announced that Advanced Installer partnered with Microsoft and released their own product called Advanced Installer Express which today integrates with VisualStudio and allows developers to output to the new format.

At the time of Build, Microsoft did not have an MSIX Packaging Tool publicly available. They demoed one during the event, and today they do have a tool, but it’s only in Preview.

Though Microsoft’s own tooling is not quite ready yet the fact they are already targeting developers with this new format and ensuring integration with Visual Studio is a good sign.

They never did that with App-V.

In fact, as John suggested during his session, many developers are entirely unaware that App-V even exists, let alone the fact some IT Pros are taking the apps they developed and repackaging them into this mystical virtual application package.

It Seems The Reports of App-V’s Death are Only Slightly Exaggerated.

If you have been in the trenches with me sequencing and deploying apps using App-V 4.x and App-V 5.x you probably came to the same conclusion that I did. Microsoft doesn’t seem to have big plans for it.

We were offered a glimmer of hope with the announcement that App-V was going inbox with Windows 10 Enterprise and Server 2016. Surely that meant Microsoft was committed to App-V and finally, it would get some love. For years, calling Microsoft support for App-V was a lengthy process of trying to explain to the person on the other end of the line what App-V is and that it is indeed a Microsoft product. That was all going to change right!? WRONG!

If you haven’t moved forward to Windows 10 yet and you have deployed App-V to Server 2012 R2, Windows 7 or one of the older Windows operating systems, you’re probably well aware that there are currently 11 hotfixes available for App-V 5.1, but there’s no rollup or service pack. App-V 5.1 mainstream support ends on September 1st, 2018 with an App-V 5.2 or 6.0 nowhere in sight.

All updates for the Windows 10 version of App-V thus far have been fixes. In fact, in one case they deployed an update which was meant as a fix, but it ended up breaking a lot of apps by changing the way the registry was handled. This was left broken for some time, and the fix seemed to be an undo of that original fix.

During the Build session, John stated that you do not have to stop your App-V efforts to wait for MSIX tooling. One of the most active Microsoft App-V engineers (Sebastian Gern) also echoed this in a blog post back in May. The good news is that you will actually be ahead of the curve with App-V and they have stated they will provide the ability to easily migrate your App-V apps to MSIX.

If you have a history with App-V, you may take that with a pinch of salt. We were promised we could easily migrate our App-V 4.x apps to 5.x and that conversion didn’t work very well for a long time. They did eventually improve the PowerShell conversion tool, but it was likely too late for many.

The good news here is if you look in the MSIX Packaging Tool at an MSIX package, you’ll see familiarity. You have a VFS (Virtual File System) just like in App-V. The directory variables are mostly the same, and you can see prefixes with AppV. (The app in the screenshot above was not an app converted from App-V to MSIX, it was an MSI I captured with the Preview tool). The registry also has similar prefixes.

Just like with your .appv file today, you can rename your .msix to .zip, open it up and take a look for yourself. You’ll see the content are very similar to App-V. You may remember with App-V 5.x, the goal was to use a universal package standard. App-V and AppX were constructed pretty similarly with this in mind. This appears to also now apply to MSIX.

Should I Really Care About MSIX?

Here’s the deal. I’m really skeptical when it comes to Microsoft, and the app install and packaging side of things. I got my feet wet with Softgrid. I thought Microsoft would build and improve on the fine work Softricity did but that never really happened. App-V also proved too complex for many. People seemed to struggle with the concept of isolation. The isolation also added application compatibility limitations due to drivers, COM+ components and more requiring extra effort and workarounds to deploy.

Download the App-V Decision Matrix.

ClickOnce was fine in theory, but the execution was very poor. It just wasn’t suitable for the majority of applications. Particularly in the enterprise!
If we go back as far as scripted installs, I’m sure we all know why that was terrible. Installs which failed part of the way through on a subset of the thousands of machines you tried to do the install on. You were then left trying to then create a new script to either remove or repair the broken install if that was even possible.

A lot was left up to humans in that case, and when that happens, it’s usually a disaster waiting to happen. I’m sure we’ve all experienced a machine getting so messed up from a bad scripted install that re-imaging and starting again was the quickest solution.

MSI on paper seemed like a valiant effort. The installs could fail gracefully and undo what had been done up to that point of failure. No harm, no foul. If a user inadvertently removed files or folders an app required, the app could self-repair and put them back. The install switches ensure a standardized method for silently installing applications, and enterprise-class deployment tools all supported it.

What went wrong was that the format left too much wiggle room for vendors and developers. If you look at the Google Enterprise MSI or Okta’s MSI, you won’t see files in the file table or shortcuts in the shortcut table. Instead, you may see files added to the Binary table and items in the CustomAction table. Meaning the MSI is really just a wrapper. The vendor used their own installer called via a CustomAction which when it fails may not rollback gracefully, which cannot leverage the auto-repair features and which does not adhere to any industry best practices. You want to customize your Chrome install? Maybe remove the taskbar shortcut using the MSI? You better get to scriptin’.

MSIX could serve as a solution to standardize and possibly get developers and vendors to follow an industry best practice and make all of our lives easier, but the jury is still out on that. John stated his boss who’s a lead on the MSIX product team actually created the Custom Actions feature in MSI. He will be well aware of the need to standardize as much as possible with MSIX.

If you watch the Build sessions some of the questions from developers in the audience suggest Microsoft have a pretty steep hill to climb, BUT there’s still a lot to like about MSIX and reasons to consider it a viable option in the future. These include:

• Clean uninstall. The package format is standardized, and apps are containerized, meaning the format provides a truly clean uninstall.
• The container features of the technology ensure predictable and reliable deployments.
• MSIX uses differential updates at the block level. Unlike some existing installer technologies, it’s not going to re-run the entire install over again for an update. It only updates what you intend to update.
• Applications can have a single instance of stored files. If two applications use the same DLL, it only needs to install once, and the other app can use it. If the app which installed the dll gets updated to a new version of the dll, the other app should get its own instance of the dll required. It was stated at Build, developers won’t need to do anything extra for this to work, the platform will do it for us.
• Code Signing at the package level. You can sign all of your packages. During the package creation, you must ensure the Publisher information matches that of your cert. This ensures the integrity of the installer.
• In future, MSIX will work on your traditional workstations, laptops, HoloLens, Xbox, ARM devices running Windows and presumably devices running Windows 10 S.
• Resource packages will allow things like different languages to automagically be installed with the app based on the context of the machine they are running on. You won’t need to install multiple language packs or have separate packages for each language.
• An obvious huge benefit is that you can take your existing Win32 apps and get them into the Windows 10 Store today. If you are a developer, this may help improve how you monetize your software. If you’re in an enterprise, it may make the Store for Business more attractive.
• Can be used to modernize apps for Windows 10 but can also still be used for Windows 7 packages with little effort. (See DEMO)
• Open Source. Community contributions are welcome, and developers can create packages on Windows, MacOS, Linux, etc.

Third Party Vendors Getting Involved.

I mentioned that AdvancedInstaller launched a product during Build to support MSIX. Flexera has now also released their own MSIX product. Most interesting to me, however, is CloudHouse who also launched an MSIX product. As stated in this article, MSIX leverages some container capabilities. CloudHouse extend the container ethos for your MSIX apps using their own container. While Microsoft doesn’t have tooling generally available and doesn’t even have a tool for migrating your App-V apps to MSIX, CloudHouse do. You can bring your apps forward using their container. What’s more, CloudHouse is excellent when it comes to containerize legacy applications which only work on XP, Server 2003, etc. So you have the added benefit of being able to containerize more apps than you could if just relying on MSIX.

That’s fine on the tooling side but what about third-party support for the MSIX format itself? I can remember when Adobe started to provide their own App-V Sequencing guides. A handful for vendors did this, and some even offered App-V packages of their apps. A real key to the long-term success of MSIX will be vendors providing their products as MSIX. I don’t have any inside information, but my guess is that we’ll see vendors hop onboard the MSIX train in the future.

Concerns.

I had a definite leg up when it came to testing MSIX. Not only do I have a lot of experience with application packaging but I also kicked the tires on AppX and the Desktop Bridge several times, so all of the concepts were already familiar to me.

If you have not used the Desktop Bridge or AppX yet and you are drawing on your MSI and App-V experience something which may throw you is the need to sign your packages. I have an example of this in my article. I can see the advantages of signing the packages, BUT I wonder if there’s a better way to achieve this in an enterprise. If we deploy our apps internally within our corporate network using our existing deployment tools, I’m not sure how much more we gain with the certification – we’re deploying from a trusted source. Instead of signing each package, perhaps the signing should be handled by SCCM (which has not been mentioned as a deployment tool for MSIX yet, only InTune and the Store).

Where the certification does make much more sense is for apps deployed publicly through the Windows 10 Store or possibly in a BYOD scenario to user’s personal devices but internally from a corporate-owned deployment tool and kept within the corporate network. Personally, I think the package signing becomes over the top in that case and acts more an impediment to IT Pros.

During Build, much was made about the autoupdate capabilities, which is great for developers who put their apps on the Store. Less great for those of us in an enterprise. We like to control our updates. There’s already uproar about how Windows Updates have been handled by Microsoft. I’m not sure organizations will also want to sign away control of their app updates too.

Reasons to be Less Concerned.

The tool is very much in its infancy, and there’s a lot to like about it already. It’s much easier to get into than say something like MSI packaging BUT not everything is going to work. Right now, drivers don’t work. It’s unclear if they’ll ever work. Support for services is currently in Microsoft’s backlog. SOME shell extensions will work. I’m not mad at this though. This is Microsoft’s chance to reign things in.

As stated earlier in this article, it’s time to try and push standardization to limit the amount of reverse engineering required by packagers. If it improves the Microsoft ecosystem and ultimately the end user experience, I’m all for it.

Rory.