Identifying and Resolving Common Challenges in MSI Deployment

File overwriting problems

A frequent problem in MSI deployments is the inability to reliably overwrite files, especially those with lower versions or no version at all. Additionally, upgrades often lead to data loss, affecting items such as registry-stored license keys and configuration files.

Abnormalities of self-repair

MSI packages can sometimes start self-repairing unexpectedly. To avoid this, it is essential to understand and implement best practices that prevent inadvertent self-repair.

Setting up the shared executable file

Mishandling shared runtime files, including vendor or Microsoft files, is a common mistake. Proper handling involves using techniques such as logless COM to avoid conflicts.

Component Management

Effective management of MSI components is key to avoiding problems during upgrades and debugging. A single component GUID should be used for each absolute path across different MSI files for consistency and to prevent conflicts.

The advanced installer automatically applies best practices to generate components for all resources included within the package.

Upgrade Challenges

Upgrading applications using MSI can present some challenges, especially with regard to handling user data.

A common problem during major upgrades is overwriting or restoring user data files, which can result in significant user data loss or disruption. This issue often stems from MSI’s default behavior of not distinguishing between files that have been modified after installation and those that have not.

To effectively manage this, it is important to develop strategies that protect user data during upgrades.

Custom Action Overuse

Overuse of custom actions in MSI files is a widespread issue.

While these actions provide flexibility, they often present complexity and potential points of failure.

It is essential to evaluate whether the desired functionality can be achieved using MSI’s built-in features or through reliable frameworks such as the Advanced Installer, rather than resorting to custom actions. This approach can significantly reduce the risk of deployment failures and simplify the installation process.

Handling of INI files

Proper management of INI files during installation is often overlooked.

It’s common to replace these files entirely, but a more nuanced approach involves merging the new settings with the existing ones.

This requires importing INI entries into the MSI tables, allowing an update that respects existing configurations and ensures proper rollback if the installation is interrupted.

Deployment considerations for users

Placing files and settings in user profiles or HKCUs is a delicate balance. While this method can be effective, it may not always be the best design solution. Careful planning is needed to ensure that all necessary settings and files are placed in every user profile and registry on the system, without interfering with user data.

If your MSI can only be installed per user, when we talk about deployment, it will lead to some challenges or problems.

As a best practice, it is recommended that the installer be changed on a per-machine basis. Alternatively, if only certain data needs to be present for each user, such as the registry or files, you can use MSI’s advertised shortcut function or the Active Setup method.

Shades of silent installation

For corporate deployments, ensuring the success of silent MSI installations is critical.

Custom actions, especially those that modify the system, must be managed carefully to avoid disrupting silent installations. All system changes must occur within the InstallExecuteSequence to ensure proper execution and rollback in both silent and interactive modes.

File Overwriting Rules

Understanding the MSI file versioning rules is critical.

These rules, designed to minimize conflicts like DLL Hell, dictate how and when files are overwritten. It is important to understand the nuances of these rules, as they differ for versioned and non-versioned files and can be affected by the setting of the MSI’s REINSTALLMODE property.

Installing the service with user credentials

Installing services that work with user credentials is fraught with potential problems, especially during major upgrades. A robust design would involve running services using accounts intended for service use, such as LocalSystem, to avoid these complications.

Custom NT privileges

Granting broad, custom NT privileges to an application or service is a red flag. These privileges should be used sparingly and judiciously, as they can pose significant security risks. In most cases, using the LocalSystem account, which already has a wide range of privileges, is a safer and more efficient choice.

Custom disk and registry permissions

Applying custom disk and registry permissions often signals deeper problems with the software being installed. While tools like WiX have made this process more reliable, it’s generally advised to avoid extensive custom permissions and instead focus on redesigning the app for more secure and straightforward deployment.

Hard-coded GUID

While some GUIDs, such as component GUIDs, must be hard-coded and persist, others, such as the Package Code, must always be automatically generated for each build. This ensures uniqueness and avoids conflicts that can arise from duplicate GUIDs.

The advanced installer automatically applies the above recommendations to all MSI packages it builds.

Explore the Advanced Installer for an automated and best-practice approach to MSI creation and deployment, ensuring your software installations are efficient and error-free.
Get your free 30-day trial now

CONCLUSION

Effective MSI deployment is both an art and a science, requiring a deep understanding of its complexities and challenges.

By adhering to best practices, constantly seeking improvements, and avoiding common pitfalls, developers can ensure reliable and efficient software installations.

With tools like Advanced Installer, which automatically integrates MSI best practices at build time and adds silent automation in the background, flaws commonly found in MSI are generally reduced, unlike tools like WiX.

While WiX is the leading free open source tool available, the lack of automation, best practices, and guidance means it’s meant for experienced IT professionals who know their way around. However, for the typical packager, it can lead to unexpected problems and bugs that need to be fixed after deployment.