/build/static/layout/Breadcrumb_cap_w.png

Active Setup Concept

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.

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]"
and
"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.


Comments

  • Good article. The only thing I would add is that its recommended to limit the active setup to modify only items that a user would be able to modify. Things like HKCU and the user's profile, but not HKLM or the Windows directory. This is espcially so when working with UAC. Also, you don't necessarily need to use PRODUCTCODE, you can use a visually friendly name as well. - jmaclaurin 10 years ago
  • Great post mayur_mak. jmaclaurin I always use a PRODUCTCODE always get nervous with the visually friendly name because I have come across to many people that love to try and play with the name on the applications I have worked on. If I use visually friendly name I always seem to get burned. The question I have is can you use anything else aside from the PRODUCTCODE or Visually friendly name I might be able to use? - Zinder10 10 years ago
  • I suppose you could use anything you want. Maybe like a ticket, job, or workorder number or whatever makes sense in your environment. Something like a time stamp might not be a good idea. My suggestion was only that you are not limited in your choice. A GUID doesn't necessarily give much of a clue if your desktop support guys are trying to figure out a problem. - jmaclaurin 10 years ago
  • My active setup has a couple of dwords and strings, but I have found that only the key gets created within hkcu and not it's items.


    Server 2016 domain controller is the target system.

    1:- Does anyone know why this is?

    2-: The active setup is created during MSI install (part of mst) and triggers an exe when a user logs in. How can I have the MSI uninstall action remove the active setup key from book and hkcu? - SKninja 3 years ago
    • You need to specify what the EXE is doing and it would suggest from your limited description that the EXE is at fault. To answer the second question, you can certainly remove the HKLM part of the active setup but to remove the entry in HKCU realistically requires you to have no roaming profiles in your organisation, and also for you to derive the SID of the currently logged in user and delete the registry keys from HKU\SID\rest of path. Or more simply, itemise all the SIDS under HKU and delete the entry in any profile containing it. - EdT 3 years ago
This post is locked
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ