General Disclaimer

If you are interested in linking, quoting, or reprinting articles from MSigeek in whole or in part, please do read the below copyright policy:

* If you want link from your site to MSigeek
You are welcome to use short quotes from Msigeek in your website or blog as long as proper credit is given. But please quote only short excerpts – up to one paragraph – from my site when you make the link. You must credit Msigeek when you quote. Always provide a hyperlink (full URL) to the article where the quote is from. Don’t hyperlink just to the homepage. Copy quoted material exactly, enclose it in quotations marks, and mention MSigeek immediately before or after the quote.

For Print media: you must print the full Internet address of the post.
* If you want to reprint my article on your web site, weblog or in your publication
Please contact me with your request. Articles from MSigeek can be reprinted only after permission. In most cases, I would expect to be paid for this. You may not republish an entire MSigeek post without an approval.

* Copyright Violation and Misuse
If we discover a website / blog republishing our RSS feeds or website content illegally, we will file a formal complaint with their advertising partners (like Google Adsense) and the DMCA department of their web hosting company.

Disclaimer of Endorsement
Reference within this blog to any specific commercial or non-commercial product, process, or service by trade name, trademark, manufacturer or otherwise does not constitute or imply an endorsement, recommendation, or favoring by The MSigeek.

The views and opinions of the authors of content published at The MSigeek does not necessarily state or reflect the opinion of The MSigeek or its owner, and cannot be used for advertising or product endorsement purposes.

References to books, software, blogs, or products as “Recommended by MSigeek” are specific suggestions only and do not necessarily constitute or imply an endorsement.

Privacy Policy
The privacy of my visitors to The MSigeek is important to me. At The MSigeek, I recognize that privacy of your personal information is important. Here is information on what types of personal information I may receive and/or collect when you use visit The MSigeek, and how I safeguard your information. I never sell your personal information to third parties.

Comment Policy and Guidelines
The following policy applies to all comments on The MSigeek:
• The author of a comment is solely responsible and liable for the contents of that comment.
• By posting a comment, you grant me the right to use, display, republish, sell, alter, or delete your comment in any way and for any reason.
• Once your comment is posted, it may not be edited or removed by you, the author. I do not have the duty to modify or delete the comment at your request; however, I reserve the right to edit your comment at our discretion.
• This policy is subject to change at any time without notice.

Please observe the following guidelines or your comment may be removed without notice:
• Submit your comment only once, the comment may not appear until I approve it.
• Please use your name or pseudonym, not site name or keywords
• Avoid non-English language.
• No offensive or inappropriate language.
• No unsolicited commercial comment.
• No signature of any kind. Please use the text field provided if you wish to display a URL with your comment.

Logo’s Used

Best Practices How-to Microsoft Windows Installer, Application Compatibility and Deployments

MSI Packaging Guidelines and Best Practices for Windows 7 / Vista

Here are few points which would prove handy while re-packaging an application for Vista / Windows 7.

1. 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

2. 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

3. 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:

4. AdminUser property commonly used to check for admin rights will not work in UAC. Microsoft has decided to set this to TRUE by default for Application Compatibility reasons. Use MSIUSEREALADMINDETECTION property instead.

5. Add installation logic that was not captured by SetupCapture. Example: Launch conditions that check for system requirements.

6. Turn off Virtualization feature. This will ensure that, duplicate files and registries are not created. This mainly happens to the applications which need a launch. The keys which are virtualized can be removed from the package as well.

7. Add support for Vista-specific features 🙁 This can be found in the “Windows Installer Options” dialog of Installation expert in WPS 7.0)

a. Disable the User Account Control (UAC) prompting for standard user installations.

b. Set options for Restart Manager.

8. Set Windows Installer logging options to provide verbose output. The installation log can provide valuable information about why an installation fails.

9. Remove 16-bit features from packages that will run on the 64-bit version of Windows Vista, if they are not part of the application’s primary functionality.

10. Remove all WRP components from the MSI package. If the installation installs a file that would otherwise be installed to an area that is protected by Windows Resource Protection (WRP), you can do one of the following:

a. Delete it from the installation and test the application with the version that is on the destination computer. However, if you do this, your application can fail if the protected file is updated or changed in the future.

b. Isolate the protected file so it is installed to a different location.

11. Fix installation-related errors that you find while performing installation and functionality tests.

12. Make other changes that are not related to Vista but are required as Customers standards.

13. Resolve CA’s which involved Nested Installation. This will throw an error while deployment.

14. Impersonation should not be used when running setups on Windows Vista. Edit the custom action and change its In-Script Options property to Deferred Execution – System Context. Test to verify that the custom action runs in this context.

15. Edit the custom action to add a description. The Windows Installer Editor documentation contains information you can use to document Wise custom actions

16. Any property beginning with MSI cannot be used. Hence avoid using the same.

17. Components cannot have a dummy GUID; it’s a best practice to generate one.

Best Practices How-to Microsoft Windows Installer, Application Compatibility and Deployments

Best Practices for Windows Installer MSI Custom Actions

The Windows Installer has many built-in actions for the installation of applications. However, when a packager of an installation package finds it necessary to write a custom action. There are some best practices which have to be followed for optimal execution.

  • Custom actions that use sensitive information should not write this information into the log.
  • Custom Actions must not attempt to set a System Restore entry point from within a custom action.
  • Return error messages from custom actions and write them to the log to facilitate troubleshooting custom actions.
  • Do not change the system state from an immediate custom action. Custom actions that change the system directly or call another system service must be deferred to the time when the installation script is executed.
  • Every deferred execution custom action that changes the system state must be preceded by a rollback custom action to undo the system state change on an installation rollback.
  • Custom actions that perform complex installation operations should be an executable file or dynamic-link library. Limit the use of custom actions based on scripts to simple installation operations.
  • Make the details of what your custom action does to the system easily discoverable to administrators. Put the details of registry entries and files used by your custom action into a custom table and have the custom action read from this table.
  • A custom actions should not display a dialog box. Custom actions requiring a user interface can use the MSIPocessMessage function instead
  • Custom actions must not use any of the MSI functions like,
    MSIVerifyLog etc…
  • If the installation must be capable of running on a Terminal Server, test that all your custom actions are capable of running on a Terminal Server.
  • To have a custom action run when a particular patch is uninstalled the custom action must either be present in the original application or be in a patch for the product that is always applied.
  • Custom actions should not use the UI level as a condition for sending error messages to the installer because this can interfere with logging and external messages.
  • Use conditional statements to ensure that your package correctly runs custom actions, does not run custom actions, or runs alternate custom action when the package is uninstalled.
  • Test that the package works as expected when uninstalling custom actions.
    If the installation must be capable of being run by users that do not have administrator privileges, test to ensure that all the custom actions can be run with non-administrator privileges.
  • Custom actions require elevated privileges to modify parts of the system that are not user specific. The installer may run custom actions with elevated privileges if a managed application is being installed or if the system policy has been specified for elevated privileges. Any custom actions the require elevated privileges must include the msidbCustomActionTypeInScript and msidbCustomActionTypeNoImpersonate Custom Action In-Script Execution Options in the custom action type.
How-to Windows Installer, Application Compatibility and Deployments

How to Test Application MSI Packages for UAC

The easiest way to simulate the UAC is to install an MSI from an elevated command line. In Vista choose to run the command prompt as Administrator. Then install an MSI. You can flag an MSI, by modifying the WordCount in the Summary Information Stream, so that it does not automatically require elevation during an install. This MSI would only be able to write to the user profile and not any protected system location. In corporate deployments this is a rare scenario.

The application installer will always need to be elevated but this will be handled by the deployment tool. If an application does turn out to be badly written then this scenario can be handled in the same way as under a locked down XP machine. Specific NTFS permissions would be given for the file, folder or registry key.

How-to Microsoft Windows Installer, Application Compatibility and Deployments

Most Common ICEs found while Package Validation in Re-packaged applications

If you repackage an installation with any version of Installshield AdminStudio, and when you try to validate it,  you will most certainly see..

ICE33 – This ICE is caused by the fact that repackager adds COM related information into the registry table as supposed to the Microsoft recommended Class ID, Prog ID and Type Lib tables. This Error can be safely ignored as the application should work properly as your com information will be registered via the Registry table.

ICE64 – This ICE warns about directories created under the User Profile folder not being specified in the RemoveFile table. So for example if your msi package contains [AppDataFolder]mydir or [PersonalFolder]mysubfolder, ensure that ‘mydir’ & ‘mysubfolder’ are specified in the RemoveFile table. Doing so will ensure that they get removed at uninstallation time.

ICE57 – If you have a component in your msi package that contains both per-user & per-machine data e.g if the component is installing a file to [AppDataFolder] and also contains a registry key being installed under HKLM. you can expect to see this Error/Warning. The ideal thing to do is separate User data from machine data into separate components. Anytime you have a component that is installing to a User Profile directory, make sure that the component does not contain a key file. This component should instead have a key path. This component should contain a registry key under the HKCU hive, set as the key path. If your msi package does not contain any registry keys under HKCU hive, create a dummy key to ensure that your user profile data is installed properly for subsequent user logging on the machine.

ICE50 – This ICE usually occurs when your installation tool is unable to extract icon from the Icon file specified in the shortcut. Sometimes InstallShield Editor displays this error. The best way to work around it is to specify an Exe or different ico file in the shortcut to extract the icon from.

Best Practices Windows Installer, Application Compatibility and Deployments

MSI Package Validation using ORCA

ORCA provides a graphical interface to the package validation functionality available as part of the MSI SDK and in several third-party tools. Validation can flag many common problems in MSI packages by analyzing package data for invalid cells or combinations of cells that are not consistent.

Validation is performed by one or more Internal Consistency Evaluators, that are organized into CUB files. Several standard validators and CUB files are provided as part of the Platform SDK. ORCA can also use custom validators and CUB files.

Choosing a CUB File

You can select a CUB file for use during the validation run in three ways:

Select a CUB file from the drop-down list.
The list contains all CUB files registered on the system for use in validation.
Type a full path to the CUB file in the edit control.
Click the “Browse” button and locate a CUB file.
The default value for validation can be changed by choosing Options… from the Tools menu and changing the Default ICE File value on the Validation tab.

Selecting ICEs to Run

You can limit the set of ICE validators that run from a particular CUB file by changing the value in the ICEs to Run field of the validation dialog.

The set of validators to run can be specified in two ways:

Specifying no value selects the default set of ICEs from the CUB file.
A set of individual ICEs can be selected by specifying the ICE names, separated by a colon character (‘:’). The set of ICEs available depends on the CUB file selected.
The default value for this field can be changed by choosing Options… from the Tools menu and changing the ICEs to Run value on the Validation tab.
Running Validation

To run validation, click the Go button. ORCA executes the specified validators in the selected CUB file, validating the current database, including any changes to the database that have not been saved.

Filtering Information Messages

To not place information messages from the validators in the list of results, uncheck the Show “INFO” Messages option. This option can be toggled while validation is running, in which case, it affects messages generated from that time on but not messages that have already been generated.

Warning and information messages can be filtered by default by selecting the appropriate options in the Tools\Options configuration dialog box on the Validation tab.

Placing Results on the Clipboard

To copy the results of a validation run to the clipboard for pasting in another application, click the Copy Results button.

Using the Validation Pane

When the validation dialog box is closed, all warnings and errors in the validation window are copied to the validation pane at the bottom of the ORCA window. To show or hide the validation pane, choose Validation Pane from the View menu. Hiding the validation pane does not erase the contents.

To jump to the location of an error, select the error by clicking on it or using the arrow keys in the window to move to the desired error. The table list and table view immediately jump to the exact location of the error that was reported by the validator.

If a table or row that contains an error is deleted, any validation errors associated with that row are deleted from the validation pane.

The data in the validation pane is replaced each time the database is validated.

Examining Table and Cell Errors

To examine the errors associated with a specific cell, right-click on the cell and choose Errors…. The error information associated with the cell appears in a small dialog. If more than one error is associated with the cell, you can click the Previous and Next buttons to switch between the different errors.

To examine the errors associated with a table but not a specific cell, right-click on the table name in the table list and choose Errors…. The error information associated with the table appears in a small dialog. If more than one error is associated with the table you can click the Previous and Next buttons to switch between the different errors.

The information presented in the Errors dialog box is the same information available in the validation pane.

If a table does not exist in the database but contains a validation warning or error (such warnings and errors usually indicate that the table or a value within the table is required but not present), a Shadow Table appears in the table list. This table is used to provide access to the validation errors or warnings associated with the table, but does not indicate the presence of the table in the database. When a shadow table is selected, the table view pane that normally displays the contents of the table does not contain any table information and indicates that the table does not exist in the database.

If there are no errors associated with the cell or table, the Errors… option is disabled.

Cancelling Validation

To cancel the validation, press the Cancel button. No additional validators run and a cancel request is sent to the currently running validator. Some ICE validators acknowledge the cancel request and stop immediately. Other validators run to completion before accepting the cancel request.

Best Practices Microsoft

Windows 7 – File and Registry Redirection : Impact on MSI Packaging

The basics of this feature is explained in the article Folder Virtualization Concepts in Windows Vista.

Impact in MSI Packaging
Files in a registry key can be found twice in your installation. Especially if the application has to be launched to customize options and settings.

Possible Work-around
During Setup-Capture:

Virtualized resources needs to be merged with the original files and the virtualized resources can be deleted from the installation resources. If file and registry virtualization is enabled on the default user environment, you will need to test the application with two different default user accounts. Check if resources from the application gets virtualized and that those contents will not affect the proper functionality of the application.

The best practice is to disable the file and registry virtualization. Microsoft does not guarantee this feature will be in future releases of Windows. If a file or registry key needs permission changes, use the LockPermission table or use a custom action to modify the related security descriptor of those resources. If the user has the permission to modify the resources, it won’t be virtualized.

It’s recommended to use the latest release of a product that supports Vista. Applications following the Microsoft development guidelines for Vista compliant applications, are modifying resources in the user profile where virtualization will not take place.

Best Practices Windows Installer, Application Compatibility and Deployments

Application Packaging Advantages & Installer Benefits

Application packaging bundles applications and operating systems into a single file called a distribution unit (.msi), which makes it easier to deploy and install them on user’s computers. Packaging reduces the total cost of ownership for the customers by enabling them to efficiently install and configure the applications. This results in an application package, which provides the product with new capabilities like advertise features without installing them, installs products on demand, add user customizations etc.

Advantages of Packaging(creating MSI packages)

    1. Customize Applications to suit the user needs.
    2. Simplify the Installation and Un-installation Procedures.
    3. Saves Time in both Installation and Un-installation.
    4. Once packaged, applications can be quickly installed on a range of desktops in multiple locations, saving administrative costs, simplifying the manage of licensing fees and minimizing support and repair expenditures.
    5. Saves Space of the product by doing apt modifications to applications.
    6. Has a great flexibility of obtaining the lost files through a phenomenon called Self Heal, this reduces the down time of application. If a critical file (a .DLL or .EXE file, for example) that is part of the distribution is corrupt or is deleted, the user can be prompted to repair the installation by presenting the original .MSI distribution. Additionally, if the installation media is available (for example, on a network share), the repair simply happens automatically.
    7. Can be advertised. So that on demand installation could take place.
    8. Upgrading of the application can be done with ease.
    9. Clean installation and Un-Installation is achieved by a process called Roll-Back.
    10. Simplifies management of new user set-up along with the revision and distribution of software repairs and new applications to existing users. Application recovery can also be improved.
    11. Helps eliminate uncontrolled software downloads and installation, enables applications to be safely removed and reduces non-business traffic on a corporate network.
    12. Using .MSI format, can automate software distribution process and ensure that the installation doesn’t break other applications that have already been installed.
    13. Application is installed via an OS service.
    14. State management is maintained. In the past, it’s been difficult to know whether an application is installed on a machine. You would have to query for a .DLL with a specific version number or determine whether an .EXE file with a specific name was present. Windows Installer provides an application programming interface (API) that lets programmers and administrators see whether a specific application is installed on a machine.
    15. Scriptable API. This whips together a VBScript to help us with the MSI file manipulations. The API to manipulate MSI files is so powerful that it can create, validate and update packages, trigger installs and uninstalls, examine the MSI repository data on computers, and perform some custom actions.
    16. Served installs. Because MSI files can be housed in a share point and delivered via a server, we can keep our installation files all in one place or move them around — closer to the users if necessary.

Hope this article helps the people who keep their first steps in packaging… 🙂