Friday, October 14, 2011

Active Setup Concept in windows Installer

One has to repackage applications that have no advertised entry points (like shortcuts) but they need to install files in user profile locations or some specific user configuration. Here's how I do it.
When deploying such applications, everything is installed in System Context and all the user specific files and configuration info are missing. Because the application has no advertised entry points, there is nothing that might trigger the installation for any user. So, what do we do in this case? How can we make sure that those user-specific files & configuration info will be installed?
This issue can be solved using Active Setup Concept which is as follows:

Using Active Setup registry keys.
These keys are used by Windows during the "just-in-time" setup process for user profiles. Windows creates a user profile for each new user and then runs the "just-in-time" setup process to finish configuring it.
The registry key "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components" drives this "just-in-time" setup process.
In case you didn't know it already, this is what Active Setup registry keys look like:

The "(Default)" entry stores the Application (or Component) Name, the "Version" entry stores the version of the application while the "StubPath" entry stores the command that needs to be executed by the "just-in-time" setup process.
During the "just-in-time" setup process, Windows reads all the entries in the "...Active Setup\Installed Components" tree and runs the commands stored in each "StubPath" key. If the "StubPath" entry is empty or missing, nothing is executed.
Each time a user logs in, Windows compares the
"HKLM\Software\Microsoft\Active Setup\Installed Components\[PRODUCTCODE]"
"HKCU\Software\Microsoft\Active Setup\Installed Components\[PRODUCTCODE]"
registry keys.

If the registry entries from HKCU do not exist or they have an inferior version number than those from HKLM, then the command stored in the "StubPath" entry is executed and the appropriate entries are created in HKCU.
One of the most elegant and simple solutions for repackaging and deploying applications that have no advertised entry points but require the installation of user files and registry keys is to include Active Setup registry keys in your package.
The only thing you need to do is add the appropriate entries in "HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\[ProductCode]".

Like you can see in the above screenshot you need to create just a few entries. The "StubPath" entry is extremely important and, if missing, nothing will be executed.
"StubPath" should have a string value such as "msiexec /fauvs {ProductCode} /qb".
After the package is deployed, when a user logs in, Windows will check the Active Setup registry entries and will notice that the application is not installed for the current user. In this case it will run the command line that will force the installation of the application for the user and all user files and registry keys will be installed in the appropriate locations. After that, Windows will generate the appropriate Active Setup registry entries for the installed application so the installation process won't be repeated at the next log in of the same user.


Anonymous said...

You forgot to mention the Version part. Why don't it run for second time when user log in .

Also there are other keys in active setup like installed componenets and there is something like >{GUID} what does this means .. what do it look for and how do they get generated (>{GID}).

Mayur Makwana said...

Hi Anonymous,

The version part means...
let say version value is 2
When each new user logs on, the operating system compares Active Setup keys between HKLM and HKCU, and runs the executable if the
HKCU entry is missing or the version in HKCU is less than HKLM.
So if you ever need to update the ActiveSetup executable, just install a new version, and increment the Version registry key (i.e 3 value above) in HKLM. Next time the user logs on, the active setup will run again for that user.hence it wont run again for the second login.

As far as the Installed Component key is concern it contains the app name or the product GUID if an MSI.