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