Most Common Challenges of MSI Deployment 

Introduction

Microsoft Installer (MSI) – is one of the most widely used delivery options for software, overwhelmingly popular in corporate networks, primarily because of the numerous benefits and the powerful MSI tools available for installation.

Managing Change Control in Large-Scale MSD Deployments

Recommended: Major Difference Between MSI vs EXE Installers

File Overwriting Issues

There are always issues with overwriting files during MSI deployments, and if their versioning is low or nonexistent, it significantly complicates the process.

Furthermore, upgrades are a problem because they can cause data deletion, such as license keys stored in the registry or configuration files.

Self-Repair Anomalies

In some cases, the MSI packages can start self-repairs from time to time. To avoid this way of listening, Doing so will help to ensure that people are not unwittingly encouraged to employ unintentional self-repair.

Shared Runtime File Deployment

One of the most frequent errors is improper handling of shared runtime files, which could be vendor or Microsoft files. Other behaviors of proper handling include preventing most of the conflicts, for instance, by using registration less COM.

Component Management

It is, therefore, essential to understand how to properly manage MSI components to eliminate problems during upgrade or patching undertakings. Using a single component GUID for each absolute path is beneficial because it does not cause conflicts and will need to be used across multiple MSI files.

Advanced Installer also applies best practices to develop the components of all the apparatus in the package.

Upgrade Challenges

It is essential to be aware that upgrading applications traditionally delivered using MSI can pose several issues, most commonly regarding data management.

One of the most encountered issues in major changes is the overwriting or resetting of the user data files; this could lead to a huge data loss for the user or disrupt the service.

This issue results from the MSI’s default setting of not being able to differentiate between the post-installation changed or accessed files and the rest of the files.

To precipitate this, proper measures should be created to ensure users’ data is secure during upgrading.

Marking Vital Component as Permanent

Some of these vital components of a computer can only be considered permanent when marked as such in a particular way.

There are two general solutions to this issue. The first solution is to label some components as “permanent,” which won’t be deleted if the user uninstalls the program; such a component usually contains critical user information.

This technique, however, needs a lot of planning since it may lead to a situation where there are bits and parts of old versions in the system.

Using Consistent Component GUIDs

Another consideration is where shared files are employed, and the component GUID of these files should be identical in all MSI packages.

This also provides a mechanism for proper reference counting to prevent the sharing applications’ files from being deleted when one of the applications is uninstalled.

However, this approach requires high communication and standardization of GUID handling among the various installers.

Resolving File Conflicts & Changes Made to Registry File

There are also other concerns, such as registry changes that can affect the files needed during the upgrade or migration processes.

Application and system updates can sometimes damage registry keys, especially those holding configuration details and licenses.

These values are essential settings for the registry and require considerable planning and testing to avoid the loss of settings in the registry when performing upgrades.

Recognizing MSI Files Overwrite Policies

Further, developers need to pay attention to the working of MSI about overwriting the rules of files. As explained below, this behavior varies with the versioning status of the files and is important to understand in the context of upgrades to prevent overwriting of files.

For instance, files with version numbers usually differ from non-versioned files. In the first case, files with higher versions outnumber files with lower versions.

On the other hand, the non-versioned files are arranged according to specific rules dealing with the modified date and the creation date.

Custom Action Overuse

The problem of custom actions in MSI files is widespread: developers use them too often. Though these actions may be convenient, they result in creating different options and, therefore, new layers of management and new chances for failure.

To seek the above goals, one should ask if the required functionality can be accomplished through MSI’s built-in capabilities or by employing a reliable frame. This can help decrease the chances of having a failed deployed application and make the process faster.

Handling INI Files

Another important aspect not implemented correctly in this case was the management of INI files during the installation.

Indeed, to deal with them, the technologies can replace these files as a whole, although, in most cases, it is possible to make changes to apply new settings as modifications to existing ones.

This means that INI entries have to be imported into MSI tables. The update needs to check for existing configurations, and when performing the update, it must be able to roll back if installation is stopped.

COM File Registration Challenges

In place, another common mistake that is frequently made is that of self-registration of COM files.

Instead of relying on this, numerous complications arise; hence, using MSI’s COM advertisement tables is better. This third period is more reliable and less susceptible to self-registration pitfalls that are associated with the process.

Per-User Deployment Considerations

Deploying files/settings to the user profiles or HKCU is good, but it is always gray. While dividing tasks and assigning each to a specific person can be an efficient approach, it may not be the most appropriate design solution.

There is a careful approach towards migrating different settings and files, which should replace the system files following the users’ profiles and registry keys without disturbing users’ files.

Another challenge or issue addressed when we are discussing deployments is that, per reference, your MSI is installable only on a per-user basis.

Typically, it would be best if the installer was changed when the machine is changed since it is designed to be configured for each specific machine. In the other case, where at least some of the data must be displayed for each user, you have two options: the MSI Advertised Shortcuts or the Active Setup.

Silent Installation Nuances

Effective MSI silent installation in corporate environments is crucial.

Initially, custom actions must be applied sensibly to enhance the system’s stability during installation and post-installation processes, thereby avoiding any disruption to silent installations that alter the system’s current state.

It is necessary that all the existing systems must be made within the “InstallExecuteSequence” for the correct sequence of execution and rollback in both the modes, that is the silent mode and the interactive mode.

File Overwrite Rules

MSI contains a file versioning that must be understood to ensure the correct file version is used.

These rules, which Single Source Branding was established to reduce issues including DLL Hell, determine when and how files are overwritten.

One must understand that these conventions vary depending on whether the files are versioned and the settings of the MSI property REINSTALLMODE.

Service Installation with the User Account Details

Installing services that utilize user credentials necessary for work is risky since it increases potential problems during substantial updates.

A way to have a better design would be to start services using other accounts mainly for service utilization, For instance, LocalSystem.

Custom NT Privileges

Allotting vast, special NT privileges for an application or service is always an alarm indicator. These privileges should be allowed on a limited basis only since they can be a veritable minefield for security.

In most instances, using the LocalSystem account is recommended because it already has many permissions and rights.

Disk and Registry Security Permissions

Assigning a new permission scheme to a disk and Registry is usually a sign of a more significant problem with installed software.

Custom permissions, while marginally more reliable with tools such as WiX, are generally best limited and avoided due to the complexities involved in ensuring that the changes provide a solid and reliable foundation for the application moving forward, which can generally be better addressed through redesigning the application for more straightforward and more secure deployment.

Hard Coded GUIDs

For the same reasons, only some of them, such as the component GUIDs, should ideally be hard coded and remain unchanged. In contrast, others, such as the package code, should always be set dynamically for each build.

This makes it unique and valuable as it does not allow the appearance of two similar GUIDs that may be sourced from a database. Advanced Installer adapts the above recommendations in all the MSI packages it generates.

Conclusion

Do you find it challenging to prepare your MSI deployments? Don’t let weak links such as security loopholes and disruptions hinder your performance.

SignMyCode can greatly help you when it comes to improving the MSI packages’ deployments and adding an extra layer of protection to them.

Our platform guarantees that your installers are well-known and reliable to minimize cases of fantasy and fraud by digitally signing them with Trusted Code Signing Certificates.

Search