At the Windows Developer Conference this March, Microsoft announced MSIX as their latest idea of the future for application delivery. This followed with more details released at the Microsoft Build Conference in May. I applaud these efforts by Microsoft; they follow the call I made last year for the development of a new standard application format that meets both the needs of the developers and of IT Professionals that deal with them. In this post, I’ll explain what I know about MSIX, both the good and the less then perfect, and what I am looking for to determine if MSIX will be the true successor to App-V.
What it is
For those catching up on the news, MSIX is intended to be a replacement for the ubiquitous MSI format.
It builds on a foundation of several other packaging formats that Microsoft uses. These formats all use a PKZip-based file compression that contains files that are needed, registry information, and additional XML based descriptive data, and digital signatures . The existing formats I am referring to include Universal Windows Platform Apps (UWP), Desktop Bridge (aka Centennial), and App-V. To be clear, the PKZip is the base but to support efficiency some of the metadata describes file offsets and block-level hashes, so while you can peek inside using pretty much any PKZip utility program to view the contents, you can’t make changes and reseal it with those tools; you will need specialty tools. In each case the XML uses a base schema of the AppX schema. Those other than UWP are augmented by an additional schema that extends the application definition beyond the limited definitions allows by UWP.
Microsoft’s intent is to woo developers to use the new format, setup build and repackaging vendors to embrace the new format with new tooling, and to entice IT Professionals to use it for easier deployments. That new tooling will be both from Microsoft and 3rd parties, and should include the ability to convert existing MSI, EXE, and App-V, packages into the new format without source code. This is critical for IT as they may be able to move apps without depending on slow moving or disinterested vendors, as well as in-house applications.
The carrot for IT folks that Microsoft offers is that these are enterprise store apps. 
IT isn’t likely to see that as a good thing yet, but within a couple of years so called ”Modern Management” and the Windows Store for Business should be good enough to be acceptable. When IT wants control and/or customize a MSIX package will use an external Modification Package for that. MSI folks will relate this external file to the MST, while to App-V fans it will be like the DeploymentConfig file, although likely wrapped in a PkZiped wrapper with a different XML schema. You end up running these things in the equivalent of an AppX “Bundle”, which App-V folks will think of as a Connection Group. I suspect that these groups would have to be prebuilt and not dynamic, but we’ll have to wait to see…
These packages will be able to run in a revamped windows container,
which will enhance security and allow for clean removal. The details on what exactly a revamped container means are not yet disclosed (and may not be entirely determined at this point). But Microsoft depicted it using the drawing shown here.
To help applications where you don’t have source code and violate their rules for what you can do and not do
in the new runtime container environment, Microsoft will also introduce something called the “Package Support Framework”. The PSF is, essentially, a built in shimming framework. I think of it as a replacement to the Application Compatibility Toolkit and it works similarly, although the chrome around it is modernized. Fixups are not automatic and IT will need to figure out what fixups they need, but a few standard simple fixups may be selected during GUI packaging, and someone with development experience can extend it to write more comprehensive fixups (without access to the original source code).
It will take some time for Microsoft to build up these capabilities, and we will see it come piecemeal over a period of time.
For further information on MSIX
There are some videos to watch from Microsoft Build. This one, with Microsoft Principal Program Lead Stephan Wick , and this one, with Microsoft Principal Program Manager Lead John Vintzel both provide good detail. Additionally, some friends, colleagues, and others have written great articles on what’s good about MSIX on blogs.
Looking at MSIX without the “Rose Colored Glasses”
So, what’s not to love? Well, I do have a few concerns that deserve airing…
First, I have to address the benefits for MSIX that Microsoft pushes. Almost all benefits Microsoft lists are being achieved with App-V today in Windows 10. The exceptions are:
- Deduplication of identical files in different packages. but partition-wide level dedupe built into the OS would solve that for App-V too.
- Auto-updating of the app. Uh, I’ve yet to meet a large enterprise interested in that. This feature will actually be a problem if the enterprise can’t control the updates.
- Store Distribution. Microsoft could fix that today for the store for Enterprise if they wanted to add in deliver of App-V format.
Microsoft makes a big deal over how MSIX will allow enterprises to not have to repackage apps when the OS updates (Package Paralysis). But that problem has already been solved! In my work with Enterprises that are migrating to Windows 10, we have found that the effort to migrate from Windows 7 to 10, or for one Windows 10 based version to another, is an effort that is 95% in understanding how to deploy and control the different underlying OS. The efforts to touch and repackage the applications have not been needed, and we are not repackaging them, especially if they used App-V to package them originally. As customers approach me now with their migration plans, I routinely talk them out of plans to repackage and test the apps. With extremely rare exception, they’ll be fine. Additionally, over the past few years we have made the creation of new App-V packages easier. So, if you used App-V, Microsoft already solved the big migration issue they promise to now solve with MSIX. Granted, it would be nicer if the vendors released in App-V format over MSI today, but we are OK now without it.
Second, we have seen minimal indication of an intent to make the packages work on Windows 7. There is a prototype shown in one video, but there were some serious restrictions associated with it. Given the third item that follows, I am guessing that won’t change, and I am OK with this, but you might have expected full support on 7. After all, the lack of Windows 7 support was a barrier (but not the only one) to Centennial which led to negligible adoption.
Third. Microsoft stated that we will see the technology roll out in parts over the next few releases. I am assuming that this means Redstone 5, 6, and 7, which means that we will see a solution dribbled out with partial capabilities. While Microsoft doesn’t provide dates, it is easy to see that this means 2021 before we know what it really can and cannot do. Hence why should they work on an implementation on Windows 7 when it will already be out of support by then?
Fourth. What will work and what won’t. The existing base of Win32 and .NET applications that Microsoft loves to refer to as legacy (when it fits their message) utilize a vast Windows API, some of which goes back 30 years. These apps run today and Microsoft deserves good marks for making sure they keep running. Given the history of App-V, which could handle most of them, and Centennial, which could only handle a small subset (Microsoft has said 50% but I put it at more like 20%), what coverage will we get? A goal of less than 100% is a problem for you if your line of business app doesn’t come along. But how far will they go? We don’t know. If less than 50%, it does not solve the problems they intend to solve. If up to 70%, then they have a good chance of slowly having it take over. It will need to be above that 70% to get rapid adoption, which still probably means 2025 or later in terms of the Enterprise calendar.
One thing that we very clearly learned from App-V is that code written years ago sometimes do things that we think are crazy today. Like writing a log file into the program folder that we see in the Stephan video. In App-V we automatically remediate those calls, redirecting the write into safe locations. Given the demos that we saw at build, it looks like they expect either the developer to modify their code, or an IT Pro to write their own code using the upcoming “Package Support Framework” instead.
That’s just nuts! On one hand, the enterprise is running a lot of software that the developer isn’t going to update or, in the case of inhouse LOB apps, the source or developers are no longer available. On the other hand, I can write the code in PSF but I just don’t think the average IT Pro is going to. For a lot of important apps currently deployed in the enterprise it is NEVER going to happen. [EDIT: My friends at Microsoft have indicated to me that the video on which I based this “nuts” paragraph may have been misleading. Supposedly the PSF tooling will somehow automatically detect and check the appropriate boxes. We’ll have to see it to believe it, but that sounds like my kind of thinking.]
To get the full fidelity of the applications in use out in the wild Microsoft must learn from their past and remediate undesirable app behavior rather than restrict it. Remediations for the most common problems should be automatic as part of the framework, and tooling provided should provide information about restricted APIs to help with development of PSF fixes.
Fifth. I have serious concerns about running those apps in the container. We learned those lessons already with App-V, and over isolation does not work for the way the enterprise builds workflows of independent apps that interconnect using the Windows API. App-V’s balance of isolation and integration has proven to work quite well. We learned those lessons the hard way last year when Microsoft tried to make the App-V virtual registry run in a container and had to back-track. The container feels like a bit of a step back into over-isolation. To say that the job is done just because the app can be run in isolation is just wrong. Application Interoperability is a requirement in my mind, but is it in Microsoft’s? Time will tell.
Sixth. We need a clear separation between efforts to develop the format schemas and the efforts to implement the format in the container. In my call for action last year I was very clear about that. The format should be independent of the implementation. Ultimately the XML describes the intent of how the application wants to expose portions of itself and integrate with the OS, with the end-user, with other applications, and with data. It should cover 100% of the kinds of interactions expressed via the MSI (including the “intent” of custom actions) today, and 100% of the Windows API. Properly constructed, the output of an MSIX formatted package could then be implemented in a variety of ways. Those that work in the new MSIX container can run there, but we need to be able to implement those that won’t in more traditional ways. I believe that we will have a converter that can take the App-V format into MSIX, but what about the other way around? Or implement an MSIX formatted app as the traditional MSI would have been. At anything less than 100% coverage on the MSIX container implementation means we need 100% coverage in the format and reverse-oriented tooling in order to achieve a single format.
Conclusions
So where does this leave App-V toady? What does Microsoft say? I love how John says it in his video:
| MSIX is the deployment technology moving forward.
If I am deploying App-V should I stop? No, no. If you are deploying App-V, you are just ahead of the game. |
And just in case, Stephon says it this way in the other video:
| Someone just asked me this yesterday…
“I’m about to start a new project with a customer on App-V. Should I do this, or should I wait for MSIX?” No, today that’s still a good decision; go with App-V for that project…. and we will make sure, from App-V, that you will have a smooth path over to MSIX. |
Microsoft has a history of talking themselves into believing that the next new thing they are building will solve all of the problems of the past and not create new ones. While I believe that Microsoft will provide the tooling to perform a conversion, we still have to ask if everything that works in MSI deployments today will work running in the container. I believe that if Microsoft is to fully succeed with MSIX, issues 4-6 in the list above must be addressed.
When Microsoft released App-V version 5 I said that they were rebuilding the product for the next 10 years requirements. So the timing of MSIX (assuming it does not have the early life issues that we saw in the App-V 5 rewrite that delays it a couple of years) is probably about right with that. If it arrives in 2021 and is good enough, it will still take about 3 years to be routinely adopted. But I’ve been here before. Properly implemented, MSIX will be “App-V version 6”. But if the “promises of intent” fall short when reality arrives, we’ll end up using MSIX where it makes sense and traditional App-V where it doesn’t.
I look forward to working with MSIX, but I do take a more realistic view; Microsoft will not cure all app evils with MSIX. Openness in the platform provides the potential opportunity for third parties to solve some of the gaps, but possibly only the gaps that Microsoft sees up-front and builds into the SDKs. Stay tuned over the next few years as we learn more.
For now, I continue to recommend App-V to my customers, both those currently using it and those that are not yet. It continues to be the easiest way to deploy your applications and produces more stable desktops for your users.
