Identifying and Resolving Common Challenges in MSI Deployment
MSI deployments, while effective, are often marred by common errors.
This article explores the intricacies of MSI deployment, identifying common issues and providing guidance for more efficient MSI deployments.
By acknowledging the strengths of MSI and leveraging continuous improvement practices, including user feedback, IT professionals can mitigate these challenges and achieve more reliable deployments.
Common Challenges in MSI Deployments
File Overwriting Issues
A frequent problem in MSI deployments is the inability to reliably overwrite files, especially those with lower versions or without any versioning. Additionally, upgrades often lead to data loss, affecting items like registry-stored license keys and configuration files.
Self-Repair Anomalies
MSI packages can sometimes initiate self-repair unexpectedly. To avoid this, it's essential to understand and implement best practices that prevent unintentional self-repair.
Component Management
Managing MSI components effectively is key to avoiding issues during upgrades and patching. A single component GUID should be used for each absolute path across different MSI files for consistency and to prevent conflicts.
Advanced Installer automatically applies best practices to generate components for all the resources included inside the package.
Upgrade Challenges
Upgrading applications using MSI can present several challenges, particularly concerning the handling of user data.
A common problem during major upgrades is the overwriting or resetting of user data files, which can result in significant data loss or disruption for the user. This issue often stems from the MSI's default behavior of not distinguishing between files that have been modified post-installation and those that haven't.
To effectively manage this, it's important to develop strategies that safeguard user data during upgrades.
Marking Vital Components as Permanent
One approach is to mark components containing crucial user data as "permanent," ensuring they are not removed during the uninstallation process.
This technique, however, requires careful planning as it can lead to remnants of older versions remaining on the system if not managed correctly.
Using Consistent Component GUIDs
Another strategy involves using a consistent component GUID for shared files across multiple MSI packages.
This ensures proper reference counting, preventing the accidental deletion of shared files when one of the applications is uninstalled.
However, this approach necessitates a high level of coordination and consistency in GUID management across different installers.
Managing File Conflicts and Registry Changes
In addition to managing file conflicts, it's also vital to address potential registry changes during upgrades.
Upgrades can unintentionally reset registry keys, particularly those containing configuration settings or license information.
Careful planning and testing are required to ensure that registry modifications during an upgrade do not inadvertently overwrite or reset these critical settings.
Understanding MSI File Overwrite Rules
Developers must also be aware of the nuances involved in the file overwrite rules of MSI. These rules differ for versioned and non-versioned files, and understanding how they apply in upgrade scenarios is crucial to avoid unintended overwrites.
For instance, versioned files typically follow a strict hierarchy where higher version numbers overwrite lower ones, while non-versioned files have different criteria based on their modified and creation dates.
Custom Action Overuse
The overuse of custom actions in MSI files is a widespread issue.
While these actions offer flexibility, they often introduce complexity and potential failure points.
It's crucial to assess whether the desired functionality can be achieved using MSI's built-in features or through reliable frameworks like Advanced Installer, rather than resorting to custom actions. This approach can significantly reduce the risk of deployment failures and streamline the installation process.
Handling INI Files
Proper management of INI files during installation is often overlooked.
It's common to replace these files outright, but a more nuanced approach involves merging new settings with existing ones.
This requires importing INI entries into MSI tables, allowing for an update that respects existing configurations and ensures proper rollback if installation is aborted.
COM File Registration Challenges
Another common pitfall involves the self-registration of COM files.
Rather than relying on this method, which can lead to various issues, using MSI's COM advertisement tables is recommended. This approach is more reliable and avoids the pitfalls associated with self-registration.
Per-User Deployment Considerations
Deploying files and settings to user profiles or HKCU is a delicate balance. While this method can be effective, it might not always be the best design choice. Careful planning is needed to ensure that all necessary settings and files are deployed to every user profile and registry on the system, without interfering with user data.
If your MSI is installable only on a per-user basis, when we talk about deployments this will lead to some challenges or issues.
As a best practice, it is recommended that the installer is changed on a per-machine basis. Alternatively, if only certain data must be present on each user, such as registry or files, you can either use the MSI Advertised Shortcuts functionality or the Active Setup method.
Silent Installation Nuances
For corporate deployments, ensuring the success of MSI silent installations is essential.
Custom actions, particularly those that modify the system, should be carefully managed 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 Overwrite Rules
Understanding MSI's file versioning rules is critical.
These rules, designed to minimize conflicts such as DLL Hell, dictate how and when files are overwritten. It's important to grasp the nuances of these rules, as they differ for versioned and non-versioned files and can be affected by MSI's REINSTALLMODE property settings.
Service Installation with User Credentials
Installing services that run with user credentials is fraught with potential issues, particularly during major upgrades. A robust design would involve running services using accounts intended for service use, like LocalSystem, to avoid these complications.
Custom NT Privileges
Granting extensive, custom NT privileges for 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 possesses a wide range of privileges, is a safer and more efficient choice.
Custom Disk and Registry Permissions
Applying custom permissions on disk and registry often signals deeper issues with the software being installed. While tools like WiX have made this process more reliable, it's generally advisable to avoid extensive custom permissions and instead focus on redesigning the application for more secure and straightforward deployment.
Hard Coded GUIDs
While some GUIDs, like component GUIDs, should be hardcoded and remain stable, others, like the Package Code, should always be auto-generated for each build. This ensures uniqueness and avoids conflicts that can arise from duplicate GUIDs.
Advanced Installer automatically applies the above recommendations in all the MSI packages it builds.
Explore Advanced Installer for an automated, best-practice approach to MSI creation and deployment, ensuring your software installations are efficient and error-free.
Get Your 30-Day Free 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, continuously seeking improvements, and avoiding common pitfalls, developers can ensure reliable and efficient software installations.
With tools like Advanced Installer, which automatically integrate best practices into MSIs at creation time and adds silent automation in the background, the flaws typically found in MSIs are generally reduced, unlike with tools like WiX.
Though WiX is the leading free open-source tool available, its lack of automation, best practices, and guidelines means it's intended for experienced IT professionals who know their way around. However, for the typical packager, it might lead to unexpected issues and flaws that need fixing after deployment.
Written by
Alex Marin
Application Packaging and SCCM Deployments specialist, solutions finder, Technical Writer at Advanced Installer.