July, 27, 2017 Today we start our application packaging blog with a post about the basics of the technology. This article will be useful for anyone interested in the application packaging topic. Whether you are new to application packaging and you want to learn more about the field, or you’re already an experienced packager, and you’re looking to summarize or refresh your knowledge, with this blog we intend to start building a solid software packaging knowledge base – and you are most welcome here!
What is Application Packaging and why it is needed First of all, an application package is a set of system resources (files and folders, registry keys etc.) related to some particular application collected together and prepared for deployment. Application package simplifies application deployment of these resources to the operating system so the application can work as developers have planned. Hence, application packaging is a process of binding the relevant files and components to build a customized application for a customer. Using tools like PACE Suite, we carry out the whole process of packaging. Depending on a packaging approach, the type of an output package differs.
Installation repackaging MSI repackaging implies that the changes made by a source installation in a system (usually, file system and registry) are captured and put into a newly created MSI package.
This approach guarantees fully controllable installation (no “black boxes” inside) and allows producing packages in a highly standardized manner.
However, MSI repackaging is not recommended (and sometimes not possible) under the following conditions:
- Source installation is already an MSI or contains an embedded MSI. If repackaged, a support from application vendor or package functionality may be affected or lost. For such a situation, the recommended approach is creating a transform.
- A source installation has complicated logic. This usually implies different results of an installation on different machines depending on conditions that cannot be fully modeled in a packaging environment. Example: machine-based licensing – an installation creates binary data that depends on specific machine’s parameters. For such a situation, the recommended approach is legacy setup wrapping.
Tuning vendor MSI with the help of MST If a source installation is already in MSI format (or contains embedded MSI packages) then the best option is to try re-using it. An MSI transform (MST file) should be used to adjust it to the requirements.
Legacy setup wrapping Legacy setup wrapping implies re-using the vendor’s installation mechanism by making it installable in a target environment by the means of scripting.
Complexity and specifics of legacy setup wrapping are dependent on deployment systems and target environment.
Virtualization Packaging limitations and issues such as application conflicts can be eliminated with Application Virtualization, and virtualized deployment is the best choice for some applications. Also, this approach can be chosen as a main packaging approach if all infrastructure is build based on virtual applications.
Advantages of application packaging There are many advantages of software packaging using Windows Installer. These advantages result in a solid, more robust installation that can reduce the total cost of ownership (TOC) for your organization. Because Windows Installer is part of the operating system, it provides features not available in traditional software distribution technologies.
- Advertisement – also called install-on-demand. Windows Installer gives you the ability to set features to be advertised. Advertised features are not actually installed, but they appear installed to the user. When the user invokes an advertised feature, installation of the feature occurs.
- Componentization – Windows Installer gives you the ability to divide your installation into smaller, more manageable parts. These parts are called components. Components give you more control over application resources during installation setup and runtime. Windows Installer uses components for repair.
- Standardization – Windows Installer has global rules it applies to every file installed with an application. These rules look at a file’s version and its shared DLLs to prevent conflicts between applications.
- Version Rules – Windows Installer uses version rules to decide whether to install a file to a directory or not. The rules look at the file’s date, language and whether the file is versioned, the modified date on a non-versioned file, and the highest version of the file.
- Reference counting – to track DLLs shared among components (from different installations), Windows Installer uses reference counters. The reference count occurs both at the component level and in the registry for the component’s key file. At the registry level, Windows Installer counts the number of times a DLL is installed or removed.
- Customization – you can customize installations to users’ needs by creating transforms. Transforms apply changes to a Windows Installer installation in order to tailor the installed application to the needs of a particular group of users.
- Assignment – you can use the user’s profile to place applications either advertised or installed on the destination machine. An administrator sets applications in a user’s profile, and when the user logs in on the destination machine, the designated applications are installed on the machine. With the assignment, the users have no control over the applications they receive. You must have Active Directory or another distribution tool for this to work. It also works in a locked down environment by using elevated privileges.
- Publishing – as an administrator, you can publish applications to the Programs and Features applet (Add/Remove Programs). The advertising attributes for the applications in Programs and Features are stored in Active Directory and are not placed on a user’s machine unless the user installs the application. Publishing lets the user decide whether to install the published applications.
- Open Architecture – Windows Installer’s open architecture gives you the ability to create custom solutions that add value to your projects. The architecture contains a standard, consistent set of guidelines that provide integrity for every installation and allow you to choose best of breed authoring software.
- Total Cost of Ownership – Windows Installer makes installations easier to install, maintain and support for your customers. This reduces the time you spend assisting the customer and reduces the time they need to spend troubleshooting the application installation.
- Rollback – Windows Installer installations are transactional. Because each process is a transaction, when one of the processes in the installation fails, Windows Installer reverts to the installation’s previously installed state. Rollback prevents you from having an incomplete or broken application.
- Dynamic Source List – a source list provides source resiliency for features that are installed-on-demand. The list contains all of the locations in which Windows Installer searches for an application’s source files. Windows Installer adds the most recently used directory to the source list, then goes to that source first the next time it needs to install files. Windows Installer updates the list automatically whenever features are added to an installation.
- Self-healing – also called automatic repair, is the ability of the application to repair missing components such as files or registry entries. When you start an application, Windows Installer checks a list of key paths. If any broken key paths – e.g. missing files or registry entries – are found, Windows Installer repairs the application.
- Group Policy and Security – Windows Installer sets privileges for the installation and the user. Elevated privileges control the user and application rights, and provide a more secure environment. Because of elevated privileges, the application can have more privileges than a user during an installation.
- User Policy – the policies that you set define the type of privileges that a user has.
- System Policy – the policies you set on a per machine basis define the types of privileges that the machine has. This gives you the ability to run an entire installation in elevated privileges and define only those rights users have while an installation runs.
Target audience If you are in software packaging business, first things you need to know – who your clients are and who needs application packaging services. Luckily, to define and identify the software packaging target market is no big trick. Two key markets can be singled out – the business (of any scope) and the private sector. These two market segments are distinct from one another as they have different purposes.
The most important thing for a regular software user, if we talk about the private sector, is the ease of use. The software should have a flexible and clear UI, so that a user can configure software before installing it. Consequently, at least several other important aspects arise, such as installation path, presence of icons, and possibility to select the features to be installed.
Commercial use aka the business sector implies different purposes, and therefore, other things are of major importance here:
- The main approach to software installation in business sector consists in using deployment systems or group policies for automated software installation within company network. This ensures resources and costs savings, while attaining flexibility in system maintenance and support.
- Considering the automated way to install software, the installation process should run without interaction from the end-user. During installation, a user should be left in a state of blissful ignorance achieved by hiding UI elements. When a user is deprived from the right to mess with UI, he/she can’t accidentally or intentionally interrupt the installation process. Again, this saves many resources.
- Installation process must result in a properly configured software. That means, not only the installation parameters have to be set and pre-configured. All necessary setting rules should be specified and checked before a package is made, including those settings, that are modified at or after the initial launch of an application.
Now that you understand your clients’ needs, let’s see, what packaging methods you might want to consider, if you want to serve your clients in application packaging services and consulting business.
Primary application packaging methods In the Microsoft Windows software industry, there are many ways to wrap a program, so that later it is deployed in customer’s environment. The way a program is wrapped, determines the packaging method. The most common way to categorize packaging methods is to define the extent to which the program is integrated into customer’s OS.
Examples of different application packaging tasks in PACE Suite
Based on the rules mentioned above, two most common packaging methods stand out: non-virtual and virtual.
Non-virtual packages are the most widespread type, used almost universally – both in business practice and in private sector. The vast majority of software development companies use non-virtual method to package their software. The resulting packages are installed directly into customer’s OS and work flawlessly with the real file system and registry.
According to the best practices, it is strongly advised to use Windows Installer (MSI) format for most application packaging needs.
- Being more flexible in comparison to other formats, MSI is a perfect choice to perform complex operations with packages.
- MSI allows using scripts to perform fine-tuning, therefore making it possible to deal with tasks of any complexity.
- Since many .exe installers are rather limited in terms of configuration options, they can be repackaged to Windows Installer packages. Unfortunately, some packages can’t be repackaged, as they might be based on complex internal logic (e.g., installation of a system service or a driver). In such cases, it’s possible to use MSI format as a wrapper for an .EXE file. Custom Action is used to deploy .exe files, while all additional configuration is performed using MSI. That results in a single .MSI file, containing all necessary installation logic and ready for deployment.
It should be noted, that Microsoft SCCM, one of the most popular deployment systems, is optimized for Windows Installer format providing a native support of .MSI packages. It ensures effective utilization of all features, offered by the Windows Installer technology.
Virtual packages create a virtual environment imitating a real system – its registry, file and security systems. It is done in order to minimize the possible influence of the installation on the OS and correspondingly the risks of damaging it. The main target audience for this type of packages is the business sector, as business customers strive to keep their infrastructure as stable as possible.
Application packaging requirements, standards, best practices The packaging requirements are a compilation of the Company standards and best practices. Let’s see what do the packaging requirements usually consist of:
Technology best practices.
Enterprise best practices. These practices have been defined with time during the implementation of the packaging technologies in a corporate environment. Here are some of them:
- During package installation, a user should not be able to interact with the installation interface or better not even see it.
- Application auto update mechanism should be disabled.
- Application autorun should be disabled (where this functionality is not critical).
- Desktop shortcuts and minor shortcuts (release notes, URLs, updates etc.) should be removed.
- EULA accept screen and other splash or unwanted screens should be disabled.
- All cloud based functionality (if this is not the essence of an application), all possible community connections, online services etc. should be disabled to prevent an application from the uncontrolled Internet access.
Company standards. This part of the requirements is depends on the Company’s approaches. Let’s review some of the possible requirements:
- Add branding information into the each package. Usually, this is a set of registry entries located in the predefined registry key and it’s used by some inventory software, which controls and manages Company’s software inventory.
- Specific location for shortcuts, which differs from the original shortcut location.
- Configure specific wrapper software, which is used to deploy software in a standardized way.
- Extract permissions and firewall rules from a package and define them separately. In this case, the Company’s IT administrators will deploy these rules separately.
This sums up the basics of application packaging. In the upcoming blog entries we’ll focus on virtual and non-virtual packages in detail and will tell you how exactly PACE Suite supports various types of packages.
Share this blog article: