CSCF: MSI Packages and Local Windows Accounts

All MSI packaged software normally contains two sets of components which are applied by the Windows Installer service on any local PC.

Computer (Machine) Components
- This is 99.9% of the package. All the files belonging to the package installation being loaded to the local hard drive. There is also all the system registry keys the package requires.
User Components
- Applied for every user the first time he runs the programme. This is usually just some personal registry keys representing initial software settings. These are applied to the user's profile.

Inspite of the minor significance of the User Components, if they can not be applied to the user's profile when the programme is first run, the Windows Installer will cancel the run attempt. The user can not run the application. Therefore, it is very important that each user must have read access to the source MSI file from where the computer installed the Computer Components of the package.

Currently, all CSCF MSI packages are maintained on a redundant domain share created by our domain controllers. All domain users can be granted access to this share as well as the SYSTEM account for all domain member computers. Unfortunately, we've been unable to grant local user accounts from domain computers access to this share.

The practical upshot of that deficiency is that some of our MSI packaged software can not be used by local workstation accounts. For example, Mozilla FireFox and Symantec Antivirus both want to install user components upon startup. Unfortunately, since CSCF has already given default support for local workstation accounts on CSCF Standard Windows Workstations, this is a problem we can not ignore by saying that only domain accounts are valid.

After much research and consulting (and head bashing), we now have some standard packaging practices for reducing these types of application startup failures. The goal in all of these steps is to ensure that the Windows Installer never attempts to contact the source MSI for a package when any common user runs the application.

Install packages per machine only.
- The Discover utility for creating initial MSI packages actually defaults to installation per user when it first creates an MSI package.
- The VERITAS pacakge editor allows you to specify installation as per machine.
Add DISABLEADVTSHORTCUTS to the MSI package Properties.
- This will force all shortcuts for the package to be classic Windows shortcuts and do not consult the Installer service before launching the application.
- This is done using the ORCA MSI file editor and adding a line called DISABLEADVTSHORTCUTS to the Property Table. The value assigned to this property is not relevent.
Do not allow the package to advertise components.
- Advertized components trigger the Windows Installer when the user runs them for the first time.
- Use the VERITAS pacakge editor to delete Advertizing.
Disable User Config Settings in any GPO which distributes software
- This is found in the Properties of the GPO when using the Active Directory Users and Computers administrative tool.
Where nessesary, add initial startup scripts to the package to handle a user's first attempt to run an application.