One of the things that we teach students in the InstallShield and AdminStudio training classes is to use advertised shortcuts if at all possible. A Windows Installer advertised shortcut causes Windows to verify that all of the application’s component key paths are in place before launching the application. If a key path is missing, Windows Installer will try to repair the application before launching the program. This is an appropriate way to repair user-specific data, including files in the user’s profile directories (e.g. “My Documents”) and registry data in HKEY_CURRENT_USER. We often see the need to repair user-specific data if one user installs a program and then a different user logs onto the computer and tries to run it.
Advertised shortcuts work well for repairing user-specific data if the application has shortcuts. What about programs that don’t have shortcuts, such as add-ins for Microsoft Office? For these cases, Windows offers the Active Setup registry keys. These are two registry keys that Windows uses to decide whether an application is installed for a user as they are logging into Windows.
The basic idea is to create a per-machine registry key in HKEY_LOCAL_MACHINE and then compare that key with a similar key in HKEY_CURRENT_USER. If the version information in the keys is different, then Windows runs a command specified in the HKEY_LOCAL_MACHINE key and updates the version data so that the command does not run again. A flowchart of the process is shown in Figure 1.
Figure 1: The process of executing Active Setup commands
Creating Active Setup keys in InstallShield
To make Active Setup work with your setup, you must have the setup write values to the following registry key:
HKEY_LOCAL_MACHINESoftwareMicrosoftActive SetupInstalled Components[ProductCode]
The values are:
“StubPath”=”msiexec.exe /fou [ProductCode] /qb”
This registry information is shown graphically in Figure 2, which shows an example InstallShield project with Active Setup data. Note that the Version value is delimited with commas, not periods.
Figure 2: An InstallShield project showing the Active Setup data in HKEY_LOCAL_MACHINE
When the end user logs into the computer, Active Setup will compare the registry key in HKLM with the corresponding key in HKCU. If the version in HKCU is less than the one in HKLM or the HKCU key does not exist, Windows will copy some of the values from the HKLM key to the HKCU key and then execute the command in the “StubPath” value.
At some point, the user who originally ran the setup will log off and then log into the computer again. If the setup did not write any Active Setup information to HKCU, Active Setup will run the repair unnecessarily for this user. The solution in this case is to use the setup to write some additional registry data to the HKCU key. The key and values are shown graphically in Figure 3 and the text of the values is shown below. Note that this data does not include a StubPath value.
HKEY_CURRENT_USERSoftwareMicrosoftActive SetupInstalled Components[ProductCode]
Figure 3: An InstallShield project showing the Active Setup data in HKEY_CURRENT_USER
After installing the program, the user who installed it will be able to log off of and back onto Windows without seeing a progress dialog from Windows Installer. Any other users will see the Windows Installer progress window, show in Figure 4, the next time they log into Windows as the setup writes missing data to their profile.
Figure 4: The Windows Installer
Considerations for Deploying Setups that use Active Setup
One issue that system administrators frequently encounter with Active Setup is ensuring that Windows Installer can locate the source media to complete the repair invoked by Active Setup. Windows Installer needs the source media to copy files into the user’s profile folders. In an environment where workstations are connected to the network, you can put the source media on a server and make sure that the SOURCELIST property points to the appropriate directory on the server.
In an environment where users don’t have access to network servers, you may want to copy the source media to a location like:
C:ProgramDataSample CoSample App 3000 Setup
By putting the installation media in a commonly accessible location, you are ensuring that Windows Installer will succeed in repairing the application’s per-user data regardless of which user initiates the repair.
Links for More Information
For those readers who would like to find more information about Active Setup, I’ve included a few links below.
3 Tips for Your Repackaging-Related Questions (See Tip 1 – How to Repair User-Specific Data for Applications without Shortcuts or Executables)