Archive for April, 2007

The art of converting legacy installation into a windows installer package is known to many and accepting the Vendor Repackaging tool’s output, a standard practice. While we create an msi package through the reverse engineering process of Repackaging, we are often content with making sure the application works and passes the User Acceptance test. But is that enough to ensure that the msi package is foul proof? The multiple auto-repair of windows installer and breaking of applications in a locked down environment are some of the issues facing system administrators today that would suggest otherwise.
Following are some key notes and best practices that one can follow to ensure that the package is foul proof:

1. Package Clean /Test Dirty – Repackage your application on a clean machine. This will ensure that Repackaging tool picks every single file, registry key, and other system changes made by the legacy setup. If the legacy setup fails to overwrite a file or key as it is already present on the machine, your Repackaging tool will fail to capture that information. When testing your repackaged application, ensure that it is done on a dirty machine (a typical end user machine). This will not only help you identify if the repackaged application needs to be isolated due to newer versioned Shared resources, but also help find potential conflicts between your msi package and other applications on the machine
2. Keep Data specific to the Application – The data inside your msi package should be specific to the repackaged application. Another advantage of repackaging on a clean machine is that it reduces the likelihood of junk data (data not pertaining to the application) being captured by the Repackaging tool, thus producing a clean package.  You can open the repackaged output in tools such as InstallShield Repackager to clean the msi package before building it.
3. Use Organization wide Standards – Ensure that the logic used within the msi package is standard across the organization. Following are some recommended standardizations:      
• Do not use hard-coded paths in the msi package, use pre-defined folders instead. E.g. Instead of using C:\ as the destination of a component or a path in a property value, use [WindowsVolume] pre-defined folder 
• When installing to a map drive, do not assume that the map drive will exist in the environment. Create a custom action that checks to see if the map drive exists and sets its value to a property. This property should be used as the destination instead of the hard  coded map drive path
• Set the ALLUSERS property in the Property Table to 1 for a per-machine package and ‘{}’ for a per-user package. Setting it to 2 ads an air of ambiguity
• Set LIMITUI to 1 in the Property Table to always run the installation in a basic UI mode
• If available, set the SOURCELIST property to a network source path where the msi package will be stored after the application is deployed in the production environment
•  When creating custom actions, use vbscript custom actions as they are open source(can be stored and edited inside the msi package), provide for means to interact with the windows installer package via Session and Installer objects and most importantly free of any dependencies. (assuming vbscript run time is installed in the environment
•  When deleting existing files, folders or registry keys from the system, use the RemoveFile and RemoveRegistry tables as supposed to custom actions. This will ensure that , in case of an error these changes are rolled back successfully
•  If you must make a change on the system via a custom action, ensure that the custom action is deferred and the msidbCustomActionTypeNoImpersonate bit is set. This will ensure that the custom action inherits elevated privileges from the installed
• Place all your custom actions in the Execute Sequence to ensure that they are invoked during silent mode and use appropriate conditions on the custom actions to only run when intended
4. Create the Package with the User in mind – When creating the windows installer package, make reservations and or provisions for a locked down user. Also follow the windows installer best practices to ensure that new or subsequent users logging in on the machine are able to successfully use a system managed application. Following are some windows installer best practices for handling the above:   
• Test your application for a locked down user. If necessary, give the user permissions to access folders and registry keys that the application tries to write to via the Locked Permissions table. Do not open higher level folders such as C:\Program Files, C:\Windows or C:\Windows\System32 for locked down users. Instead, set permissions on the exact sub-directory that the application needs access to:
•  If the application has registry keys in the HKCU hive, make sure that all of these registry keys are in a single component in your msi package and one of the keys is set as the Key path. This will cause a repair when a new user logs on the machine for the first time to make the user data available to the user
•  Components installing files to a user profile directory should contain a registry key path as supposed to a key file
5. Validate the Package – It is important that you ICE Validate your msi package and fix any ICE Errors or warnings that you get. An ICE free package is a way to ensure that the package follows windows installer best practices. Another important step is to check for conflicts between the msi package and the target Operating system or any other applications that may co-exist with this package on the system. You can check for conflicts in your msi via Application Manager (a.k.a Conflict Solver) in AdminStudio 8.0 suite.