Active Setup

An active setup is a very simple registry function that causes much confusion, but it’s something that every packager should understand and be able to use. You don't always need to use an active setup but if you are in an environment where for whatever reasons advertised shortcuts are not used then an active setup can quickly solve the issues with per user registry keys or per user files.

Active setup contains 2 parts a local machine part and a current user part.

Open the Registry "Regedit.exe" and naviagte to:

HKLM\Software\Microsoft\Active Setup\Installed Components

The HKLM keys are the important keys and the only ones you need to understand and put into your package, the HKCU keys will automatically get created when a user logs onto the machine.

The HKCU keys will get generated here:

HKCU\Software\Microsoft\Active Setup\Installed Components

A common packaging mistake is to add both the HKLM and the HKCU registry keys into a package, only the HKLM keys are required and the HKCU keys will automatically get created. This can be argued that the HKCU active setup keys should be in the package so that the active setup does not need to run for the installing user but as packages are normally distributed via SCCM or a similar distribution tool they are always installed as a user which will never actually log onto the machine such as the `System` account or an `Installer` account.

The following keys are required to successfully run an active setup command.

(Default) (REG_SZ)- This is used as the name of the product and is only required so its easy to identify the package.

Version (REG_SZ) - This is required to identify the current version of the package and the current version of the active setup keys, changing the version number after the package is installed will initiate the active setup next time a user logs onto the machine, even if they have already run that particular active setup.

StubPath (REG_SZ)- This contains the actual command that will be executed. For most packaging situations this will be an MSI repair command although it is possible to run any command.

This is not an exhaustive list of the keys but these are the most vital from a packaging perspective.

To enable an MSI to repair and re-install the per user files and registry keys contained in the package for every user that logs onto the machine it is just a simple case of importing these keys into your package:

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode]]
@="[ProductName]"
"StubPath"="Msiexec /foums [ProductCode] /qn"
"Version"="[ProductVersion]"

Run MSIEXEC /? if you are unsure about the /foums command line options, you can change these to suit your requirements.



By using the MSI properties [ProductCode], [Productname] and [ProductVersion] within our MSI package we can just import the registry file whenever we come across a package that needs current user files or registry keys to be present before the application will run.

Active Setup test

Testing active setup is very easy.

Log into a test machine with and Administrative account and copy the following into a text file and import it to the registry.

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\Active Setup Test]
@="Active Stup - test"
"StubPath"="Notepad.exe"
"Version"="1,0"

Now log off and log in as a test User and see what happens, you should see the screen below, in this example you have to close notepad before the logon process will continue. I selected notepad just as a test so that we can see what actually happens. You will also notice that the Personalized Settings dialogue box contains the name that we included in the (Default) key, this lets us know which setup is running.



Close the open notepad and the logon process will continue as usuall.

Whilst you are logged onto the test user account open "Regedit" and navigate to HKLM\Software\Microsoft\Active Setup\Installed Components and you will find the following.



Notice how the only key that is shown is the “Version” REG_SZ key showing the current version “1,0”, this shows that the active setup has ran for this logged on user and will not run again.

Log off this test user account and log back in as your administrator account.

Now change the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\Active Setup Test\Version” key to “Version = 2,0”

Log off and log back in as the test user account and you will find that the active setup runs again, by changing just the version number we can trigger the active setup StubPath command to run again for all users, in practice you would not change the version number very often.

See Active Setup is easy :)