Why IT needs a standard application install package

One of IT’s biggest responsibilities is to acquire, prepare and deliver Windows applications to employees. But oftentimes, different groups within the same organization process the same applications in unique ways. IT pros need a common application install package they can use to deliver software after they’ve customized it toward their companies’ needs.

Different IT groups tend to use different techniques for application packaging and delivery that are dictated by the deployment method they will use at the end of the process. The group that deploys applications using Microsoft System Center Configuration Manager has a different process than the group that deploys apps directly in the desktop image. Packaging an application in Microsoft App-V or VMware ThinApp is again different. If a group uses app layering, it might not even have a formal process yet. And the Citrix team always does its own thing.

By using completely different processes for different apps delivered to different departments, IT tends to duplicate efforts and lack efficiency. To change this, IT must shed a fundamental notion that pervades its thinking: that MSI is the ideal app delivery format.

The ubiquitous MSI, Microsoft’s proprietary application installer package file format, was designed in the 1990s and has only minimally evolved since. There are plenty of tools available to show IT what is contained in the MSI application install package, and this transparency is helpful, but it is not a great format for the ultimate delivery to users.

IT must customize application delivery to meet the needs of the business, often by integrating an app into end-user workflows that involve multiple other applications from multiple vendors. The ability to create these multi-app workflows is the key to Windows’ productivity power.

Because MSI is so old and its functionality so limited, vendors that create applications with this application install package unfortunately resort to the use of what are called custom actions inside the file, seriously limiting the transparency that MSI was originally intended to have. These custom actions are black holes preventing IT from understanding what the installer intends to do. Without this visibility, administrators usually end up repackaging an application into something that is OS-specific, forcing them to have to create different packages for x86 and x64 OSes, and again for Windows 7 and 10.

The App-V format might be the closest thing to what IT needs.

In an ideal situation, organizations would have one team responsible for customizing and packaging applications into a common format. The application install package would be independent of delivery technology, and the vendors of the delivery technology would all need to accept this format. Unfortunately, such a format does not exist today. If the repackaged MSI were up to snuff, organizations would already be doing this. Although some IT departments try to share repackaged MSIs as a common format between groups, they often don’t end up using them.

The App-V format might be the closest thing to what IT needs. I don’t mean that IT would need to use App-V to actually virtualize the app; I am only talking about the App-V format. With automation using the new auto sequencer that Microsoft released earlier this year, admins can easily customize and package any app (including all of those that IT can’t virtualize because of issues with driver compatibility and the like) into a format that potentially every deployment technology could reuse.

The great thing about the format is that it is OS-independent, so admins only have to package it once. Microsoft even has an existing PowerShell utility that will natively restore the App-V formatted file back into an installed program in lieu of an installer. Unfortunately, that utility comes with a lot of unwanted software, so I wouldn’t recommend it as is for building images or layers or deploying apps through Configuration Manager. But the technique it relies on is sound.

While we wait for the industry to resolve this issue, there are some things IT departments should be doing today. Investigate how much rework is going on in the packaging of applications for different deployment types. Encourage more communication, sharing ideas and information about the apps, as well as the actual output of different groups’ efforts. Review and update app delivery processes, and choose someone to own that process and maintain it yearly. Lastly, talk with vendors about interest in a common application install package model and what they can do to help IT get there.

Article Source

Leave a Reply

Your email address will not be published. Required fields are marked *