I want to take you back just over 20 years to when I was working at the Woolwich Building Society in their IT department (my first job after University). Seated next to me were the application profiling team members — people who were writing scripts to wrap applications into "packages" that could be distributed using login scripts in Novell.
Fast forward to today. If I want a new desktop application brought into my enterprise, I still have a team of people performing what is a pretty similar function to get my application "packaged" for distribution via Microsoft System Center Configuration Manager (SCCM) — or Microsoft Endpoint Configuration Manager (MECM) as it's now known — or equivalent desktop management tooling.
However, after two decades, the way we package and test applications is about to massively change. Below, I want to take a closer look at what application packaging is, why it has been relatively stagnant, and why that is about to completely change.
What Is Application Packaging And Why Is It Necessary?
Application packaging and deployment is a way for enterprises and large organizations to standardize and streamline the way they put software on users' devices. The process involves creating an application package for each piece of software that a business unit (HR, Finance, etc.) requires with predefined system and user settings (admin rights, network access, etc.) suitable for the specific standards and controls set within that organization.
This allows IT administrators to deliver the latest versions of software with new features and security updates in a consistent and, arguably, more timely manner in order to stay current or gain a competitive advantage. It also reduces the total cost of ownership (TCO) and application management costs as IT does not have to troubleshoot individual devices but can instead package, test, and troubleshoot on a global level.
Microsoft (Now Windows) Installer And MSI (1999)
When Microsoft Installer was launched in 1999, it provided a framework for the installation process where installers could synchronize with each other, have a database of installed products, and introduce a level of consistency that hadn't existed before.
Using an MSI file, you could install both the .exe and registry keys, specify file locations, create Custom Actions that are not part of the standard install, etc. Using MSIs brought greater control, efficiency, and speed to the process of packaging and deploying apps, especially LOB critical apps, across the entire organization.
Through all the versions of Windows since Windows 2000, enterprises have been creating MSIs for their app packaging needs and deploying them in the same way for the past 20 years. Why? Because this process has been proven to work and be effective, even if it can be time and labor intensive.
Before creating an application package, a new application needs to be tested with each version of Windows you are running, and potentially with other apps as well, to check for conflicts. After the package is created, it needs to be tested again, then deployed in a pilot, and often tested again. Any issues that are found need to be fixed, and then tested, and then repackaged and redeployed again. Even though this cycle of testing, packaging/deploying, and testing often took a long time, it was better than any other alternative. Today, for some organizations, getting a new application ready for distribution could take 6-8 weeks.
For a long time, MSI was the go-to standard for application packaging. However, Microsoft chose not to build their own packaging tools or an ecosystem around packaging tooling as they were looking to ISVs to fill that void. But as the industry evolved, there was no proper way of dealing with remnants of golden DLL Hell and WinROT.
Virtualization Changes Application Packaging (2006)
SoftGrid changed this legacy set of issues and created the rise of application virtualization. They realized that the use of COM isolation and virtual file systems could prevent problems such as DLL Conflict Hell. This allowed applications to run in parallel on the same desktops without any issues, reducing much risk and uncertainty. By bundling the application and all related dependencies into a virtual bubble, the days of application conflict were behind us. The focus shifted towards stability and performance improvements.
In 2006, Microsoft acquired SoftGrid, which gave them instant access to the best application virtualization technology on the market, as well as a large user base and know-how. Microsoft updated many of the existing features and introduced their security standards before re-branding it Microsoft Application Virtualization or App-V. According to Microsoft, this is what App-V does:
Microsoft Application Virtualization (App-V) 5 lets administrators make applications available to end users without having to install the applications directly on end user computers. App-V transforms applications into centrally managed services that are never installed and don't conflict with other applications.
App-V has never quite reached the popularity or adoption of MSI despite it bringing many improvements. Early releases had a relatively high failure rate, causing lots of re-work and often an inability to package into the App-V format. The velocity of technology change increased again after the introduction of Windows 10 in 2015. Many organizations again decided to attempt the shift to the new format, initiating another time and resource intensive packaging and testing process for hundreds or even thousands of applications. It is also worth noting, that App-V packages are nearing their end-of-life in 2026. Something had to change.
The New App Packaging Standard MSIX (2018)
Since the introduction of Windows 10, Microsoft has insisted that application compatibility has greatly improved compared to previous versions — going as far as claiming that it is a non-issue for upgrades. At the same time, Microsoft recognized the need for a new way to package applications that would lead to better deployment reliability and improved security. On Developer Day 2018, Microsoft released a new version of app packing technology called MSIX:
"MSIX is our vision for a complete containerization solution and it inherits all the great features in UWP and most importantly, it applies to all Win32, WPF, Windows Forms, and UWP applications. The MSIX packaging format was open sourced today."
This modern form of app packaging and deployment was created to reduce or eliminate the tedious tasks and issues listed above. One of the biggest features of MSIX is that it isolates the application, or containerizes it, creating a digital version of the app, so that it is independent of OS updates, app updates, and other customization options. This means that you can distribute it on many platforms, whether MECM, Microsoft Intune, or other solutions. Of course, this new format will need to mature, and we have already seen some remediation activities to allow apps to move to Intune using the new .IntuneWin format because they cannot be converted to MSIX at this point.
With the introduction of MSIX, Microsoft has opened a floodgate of change coming to application packaging and testing, preparing us for a very different future ahead: one characterized by automation, self-service, and containerization.
What Has Changed & What To Expect In The Near Future
Despite the name, MSIX is not an evolution of MSI. It is a completely new unified packaging format that allows organizations to create secure, reliable, and high-performing applications regardless of their input.
MSIX supports Microsoft's Modern Management vision as its technology uses innovative streaming technology that only downloads the delta between an existing app and the upgrade, therefore optimizing bandwidth. Because an MSIX app lives inside a virtual application container, it creates a strict isolation between the app and the OS. They are also more automatable as EXE installers and MSI packages can be packaged and tested unattended as long as the EXE installers support silent installation.
Read More: Will Modern Desktop Drive Application Package and MSIX Adoption?
This goes hand-in-hand with the changes going on within enterprises at the moment: Executives, IT teams, and business units alike are pushing Digital Transformation, more incremental but more frequent software upgrades, and more automation and self-service while centralizing IT services. MSIX supports all this better than any other packaging technology ever has, e.g., by eliminating DLLHell and WinROT, decoupling of the OS updates, app updates, and customizations, as well as containerization.
In Summary
For the past twenty years, enterprises and large organizations have been packaging and deploying the same way. They tested the apps, created MSIs, packaged them, deployed them, tested them again, looked for conflicts, errors, etc. It is a tedious process that took up a lot of IT resource time and money.
Only recently, with MSIX and through app containerization, application packaging and testing began undergoing (and is still undergoing) a major change. Yet the process for requesting a new application and getting it packaged and finally ready for deployment has not moved with the times. It is an area that we are very keen to explore at Juriba, especially since so many of our projects get stuck in the application packaging work stream. Innovation and change is coming to the market, and we will explore this topic further next week. Stay tuned.
