Packaging applications for enterprise deployment at the volume necessary to keep up with demand require organizations to be more flexible about packaging preferences. These days, the volume of change is too high not to seriously consider a more dynamic approach.
Those continuing with an old, rigid process following outdated standards will fail to keep up with packaging needs, resulting in increased security risk and an ever-growing backlog of prioritized updates that is impossible to clear.
Taking a more flexible approach based on what makes sense for any given application can have a dramatic, positive impact on a team's ability to keep up.
4 Types of enterprise application packaging
There are four basic methods of Windows application packaging that enterprises can consider:
-
Repackaging applications into MSI formats, or creating MST files for applications already provided as MSI, to handle customizations.
-
Example: Repackaging legacy applications originally distributed as executable installers without robust vendor support for enterprise deployment, such as older versions of specialized finance software or legacy industry-specific applications.
-
-
Setup authoring, where custom actions and dynamic logic are developed to address specific application challenges during installation.
-
Example: Applications requiring highly specialized or custom configurations not supported by standard installation mechanisms, such as in-house developed applications or niche software with complex dependencies or licensing configurations.
-
-
Command Line Deployment. Using vendor-provided command-line options, often combined with the PowerShell Application Deployment Toolkit (PSADT), to simplify deployments and add customization.
-
Example: Deploying browsers like Google Chrome or Firefox, or common productivity tools like Slack and Zoom, where vendor-provided installers are robust, and simple customization via command-line is sufficient.
-
-
Leveraging the Microsoft Store for automatic updates or deploying applications configured for automatic updates directly from vendors.
-
Example: Applications such as Microsoft Teams or OneDrive, which frequently update for security reasons, and whose automatic updates minimally disrupt user workflows.
-
The first two methods—repackaging and setup authoring—are often used together or interchangeably in traditional environments, so I’ll address them as a group. The others are covered individually below.
1. Repackaging / 2. Setup authoring
Traditionally, IT teams have relied heavily on the first two methods—repackaging and setup authoring. While these approaches remain widespread, it's a good time to reconsider if these should really be the only two tools in your toolbox. Compared to the other methods above, setup authoring is expensive (requiring expertise) and slow (involving lots of trial and error). Even when considered only when repackaging is insufficient, these methods result in an average cost of $646 and a turnaround time of 4.2 days.
First introduced with Office 2000 in 1999, Windows Installer provided us with a valuable standard with some helpful benefits (silent installation support, verbose logging, roll-back, repair, etc.). It made it a perfect target for repackaging, as vendors rarely offered silent installation support and customization options. Microsoft pushed the format, too, encouraging software vendors to offer MSI setup files as a "Works with Windows" requirement.
Love it or hate it, Windows Installer's custom action feature means that anything not technically supported by an MSI setup could still be run from within an MSI setup. Sometimes, this meant an entire command line installation of the application, negating most of its value as an MSI in the first place. It also meant that if you spent enough time and effort, you could make your MSI setup do whatever was necessary and get a nice sense of satisfaction that you have a single installer format you've standardized upon for every package.
However, over time, we've seen Windows Installer lose favor with software vendors. What we frequently refer to as "legacy" executable installers have made their way back as they are widely considered to be less complex and don't need specialized knowledge. With frequent updates required, built-in automation features and simplicity align more naturally with modern software delivery practices.
At the same time, command-line installation and customization options have improved, making repackaging them to achieve an MSI setup less necessary. Finally, MSI’s advanced capabilities, like self-healing and rollback, are less critical now, as application stability, dependency handling, and built-in auto-update mechanisms have improved significantly.
The reason so many repackage to MSI today tends to be "because that's the way we've done it for the last 20 years" more than for any tangible benefits worthy of the effort required.
3. Command line deployment
Increasingly, enterprises are shifting toward vendor-provided command-line options, further enhanced using wrapper scripts like PSADT. This method offers greater flexibility and speed, reducing complexity compared to extensive setup authoring.
For some, use of a patch catalog has been an introduction to this approach, as patch catalog solutions rely entirely on delivering command-line installation of a limited set of publicly available installers.
You'd be hard-pressed to find any application released in the last several years that does not provide some basic ability to install silently. Apart from speed and reliability, some significant benefits of taking a command line approach include retaining any and all of the logic the vendor intended and actually being supported by the vendor.
Some installers dynamically handle dependencies and configurations based on what is on the endpoint. Others may make low-level system changes not natively supported by Windows Installer. Ensuring your repackaged installation contains everything it should for the target environment or crafting a custom action to perform restricted actions simply isn't necessary when taking advantage of the installer provided.
The primary benefit of repackaging that remained was capturing desired changes to adjust shortcuts, default settings, etc., but the popularity of script wrappers like the PowerShell App Deploy Toolkit (PSADT) has made package customization much easier and repeatable. Not only can PSADT help standardize and brand the end-user experience, but it also makes many common customization needs quite easy to implement. Just a few key examples:
-
Set-ADTItemPermission handles the inclusion of file, folder, and registry permission changes.
- Killing a process before install or uninstall can be handled using the CloseProcesses parameter available via Show-ADTInstallationWelcome.
-
Remove-ADTFile and Remove-ADTFolder are provided to delete any unwanted files or folders.
- DLLs can be registered or unregistered using Register-ADTDll and Unregister-ADTDll.
- You can add or edit INI file values with Set-ADTIniValue
- You can stop and start services with Stop-ADTServiceAndDependencies and Start-ADTServiceAndDependencies.
Of course, there is everything PowerShell can do natively as well, so the possibilities are endless. Without PSADT, it could be as time-consuming as the setup authoring approach, but with the added benefit of reusability. By wrapping all setups with a common PSADT template, you have a single place to insert any customizations with a simple condition (for example, if the application name is "Adobe Reader", then add these Adobe Reader customizations).
4. Taking advantage of automatic updates
The fourth option, utilizing automatic updates via the Microsoft Store or directly from vendors, is the quickest approach but carries perceived risks not all are comfortable accepting. If an unexpected change occurs, automatic updates could disrupt business processes. However, for an increasing number of organizations, the potential security risks associated with delayed updates outweigh the operational risk of automatic updates.
This approach is also the most uncomfortable for long-time packagers who have routinely spent time and effort identifying and disabling automatic updates as part of their deployment process. The reason for this was that the application user would often not have permission to perform the update, so errors would occur if an automatic update were attempted in the user's context. But today, many applications support installation into the user profile, where permissions are less restrictive.
Enabling automatic updates isn't really a method I advocate at this stage, but I do see increased interest. To such an extent, I'm considering introducing a feature in App Readiness that will help identify when Microsoft Store is an option for the application you are packaging-- and even make it easier to pull such into the existing package automation workflow that today focuses on the dynamic command line and repackaging support. Interested? Please let me know!
Consider what's best for each specific application
Organizations should evaluate each application individually rather than strictly adhering to one or two packaging methods. Attempting to force applications into unsuitable methods leads to slower deployment cycles, increased complexity, and higher risks. Given the growing volume and rapid pace of required updates, maintaining flexibility and openness to all four packaging strategies can help enterprises move at the velocity they seek.
The need to adapt for each application is something I'm excited to be automating with App Readiness, where intelligent automation means working the same way you traditionally would manually. You will prioritize your preferred methods, and then the automated packaging process will fall back on your second or third choice when automated testing does not confirm a successful initial outcome.
By carefully choosing the optimal approach for any given application—whether it's repackaging, setup authoring, vendor command-line options, or automatic updates—organizations can significantly enhance their agility and security posture. Ultimately, flexibility and adaptability in packaging decisions ensure IT teams spend their valuable time efficiently, keeping pace with the continuous flow of critical application updates.
