Introduction
There are so many announcements to keep up with at Ignite, I’ve been trying to stay within my wheelhouse, which has largely been all things App-V. With over 20 years of experience in application packaging, I instinctively track new technologies such as MSIX like a jumping spider tracks a mayfly.
I’m only going to cover the roadmap items below, and in some cases, the details are a little sparse. For a good primer on the MSIX platform, check out my previous post from the Windows Developer Day keynote. I’m confident that if Microsoft can stick to their roadmap, MSIX will quickly mature into a technology capable of serving mainstream business needs.
Before getting into the roadmap, I wanted to briefly discuss Microsoft’s proposed MSIX servicing cadence. Notably, service updates will no longer be tied to Windows releases, which only happens twice a year. Microsoft plans to release new features for the packaging tool every three months along with a separate, shorter cadence for bug fixes.
The reason that this is huge is that twice a year is simply not fast enough when you need a technical fix or a blocking issue resolved to get a line-of-business application in front of an end user. For anyone who’s been maintaining an application portfolio of any size, they’ve learned the hard way just how erratically applications can behave and how common it is to unearth seemingly random errors.
It would be impossible for the product team to foresee all the ways applications can present challenges to MSIX packaging, and that’s what makes this announcement so welcome.
Package Support Framework
I spoke with application packaging vendors Flexera and Advanced Installer along with fellow MVPs (but mainly @TimothyMangan) and the common theme that kept coming up was the importance of the Package Support Framework (PSF). In short, the PSF is a way to modify the application behavior inside the container thereby enabling it to function without source code modification, which in turn makes it easier to convert legacy apps to the MSIX format.
There was some speculation that the community might need to step up and make contributions to the PSF because there seemed to be a lack of steam moving it forward, but Microsoft has stated that they will be more active in building out the framework.
What caught me off guard was the scope of the fixes and the real potential to replace application compatibility shims when using MSIX containers. One very practical use case was suggested that would support NTLM to Modern Authentication. That capability would seriously help organizations migrate from legacy authentication mechanisms to more secure, modern authentication.
Windows NT Services
Lots of enterprise application developers have used NT services to run portions of their code persistently in the background, so it’s a pretty big deal that APPX applications do not support NT services. Without NT services support, a significant portion of many organizations’ application portfolio won’t work with MSIX.
There isn’t much else available at this time, suffice it to say that, Microsoft is aware of the challenge and the desperate need to help developers refactor their applications to work within the MSIX framework. Specifics on details and dates should begin to percolate out over the next few months, and you can be sure I’ll stay on top of it and report back when there is more to discuss.
Scaleable Containment
When I started working with application virtualization, I adopted a very literal interpretation of the technology and always pushed for more isolation in order to reap the benefits of the technology. After several years of experience and thousands of virtual machines later, I’ve come to understand that isolation creates its own unique set of issues such as application to application integration.
App-V 5 addressed some of these issues by using Connection Groups and exposing APIs rather than isolating them through COM isolation.
Within the MSIX framework, the Windows Defender Application Guard is the strictest container type where it uses Hyper-V to isolate the application using hardware. However, in lieu of the fact that such strict isolation causes problems, there has been a growing demand for less strict container types.
There is some hopeful speculation that Microsoft will introduce a container with less strict isolation to closely mimic the behavior of a locally installed application.
I believe that this could be a huge win for compatibility with MSIX as this feature matures.
More Operating System Integrations
Given that applications in Windows 10 run through a container, there is a need to integrate with the operating system to trigger the application launch and integrate with other applications through mechanisms such as COM. Some extensions are there mostly for the user’s benefit, these are typically things that integrate with Windows such as the Windows Shell (e.g., shortcuts, protocol handlers, and file type associations).
Therefore, it should go without saying that as Microsoft expands the list of possible integrations, they will unblock applications that cannot convert into a useable implementation with MSIX.
Deeper Integration With SCCM And Intune
Both SCCM and Intune have basic support for managing MSIX packages, but as MSIX’s features begin to evolve and update every 2 or 3 months, the management tools will need to keep pace. While not much else was announced, it is clear that Microsoft is committing resources towards ensuring that their deployment tools are more closely synchronized with the MSIX roadmap.
MSIX Conversion as a Service
The MSIX Conversion as a Service (CaaS) is the ability to right-click applications in the Configuration Manager console and send them to the cloud for conversion. There is a bit more to it, but the process itself seems quite straightforward.
- Initiate the application conversions from the Configuration Manager console
- A clean packaging VM is provisioned in Azure
- The command line sequencer packages the application on a VM
- The output is sent to either CM, Intune, or the Windows Store
- The VM is destroyed
The feature is built to send applications to be modernized in batches and lower the administrative overhead. There is talk about exposing this capability in a forthcoming current branch of Configuration Manager, but we will have to stay tuned for exact dates.
Device Driver Support (sort of)
Installing device drivers is always a challenge, it doesn’t matter which installer technology you use. The good news is that the clouds appear to be parting with the release of the Driver Installation Framework (DIFx).
In the early stages, DIFx will only support a few scenarios for installing drivers and kernel mode services outside of the MSIX container. The goal is simply to remove those barriers from the applications that may need to install drivers or kernel mode services.
DIFx does not enable drivers to work in the MSIX container. That being said, in an ideal world, applications shouldn’t need drivers. Nevertheless, there are line-of-business applications using specialized hardware that will need this capability.
Conclusion
From what I’ve seen at Ignite, Microsoft is showing a sincere commitment to make MSIX the application format for modern application packaging. If you are running Office on Windows 10 S you are experiencing Office in a constrained version of the MSIX container. Microsoft is even willing to put their flagship productivity suite into a container.
While the initial stages of the MSIX roadmap are going to lack some features, both Microsoft and vendors are getting invested and there is a growing enthusiasm from IT Pros to adopt the technology. The technology is definitely worth a look, but migrating an entire enterprise application portfolio to MSIX is further out.
