Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

Active Setup

Created: 22 Oct 2007 • Updated: 23 Oct 2007 • 11 comments
R-Vijay's picture
+2 2 Votes
Login to vote

If your application requires installation of components such as files or registry keys on a per-user basis, but your application has no advertised entry points or other triggers to initiate the installation process, then Active Setup is the solution.

What is Active Setup?

Active setup is a process that runs automatically when a user logs in.

How Does Active Setup Work?

Registry keys at HKLM\Software\Microsoft\Active Setup\InstalledComponents\%APPNAME% and HKCU\Software\Microsoft\Active Setup\InstalledComponents\%APPNAME% are compared, and if the HKCU registry entries don't exist, or the version number of HKCU is less than HKLM, then the specified application is executed for the current user.

How do you create an Active Setup?

To implement Active Setup, you need to package all your user installation requirements into an EXE preferably, using SMS Installer, or Wise Installation System, and place the EXE on the client workstation during the main application installation process.

In addition, populate the following registry key with two ( REG_SZ ) values: KEY: HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\% APPNAME% - where %APPNAME% is an arbitrary string which can be the application name, or its product code GUID if using an MSI. (As long as it is unique on that workstation!) VALUE1: StubPath=<full local path>\YourActiveSetup.exe VALUE2: Version=1 When each new user logs on, the operating system compares Active Setup keys between HKLM and HKCU, and runs the nominated 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 (VALUE2 above) in HKLM. Next time the user logs on, the active setup will run again for that user.

To force a repair using the existing MSI where a separate Active Setup EXE is not required, you can do it this way:

Create the following key structure under HKEY_LOCAL_MACHINE hive:
HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\[ProductCode]

Under this registry key, create a <new string value> such as: "StubPath"="msiexec /fauvs {ProductCode} /qb"


Comments 11 CommentsJump to latest comment

SH79's picture

That's a very handy post Vijay.

I've just started Vista packaging but have used ActiveSetup in the past - a very useful mechanism.

However, do you ever feel restricted?
As it only runs once per user you need to be very sure that it achieves what it has set out to do. Otherwise the only way to get it to re-run is just like you describe by incrementing the 'version' (or purge\decrementing a particular users version).

You need of course to make sure that your roaming profiles are effective.
I'm not really sure on this - does HKCU always roam with the user?
If it does and some userprofile files do not, then how do you recreate these on another machine seeing as ActiveStup has used up its one life?
The files I'm talking about are files not created in C:\Users\test-user\AppData\Roaming (i'm presuming this is the only part of the users profile that roams and that the users HKCU hive is in here somewhere - please correct me if I'm wrong).

I've recently toyed with the idea of using the Run key to repeatedly run an exe on user login. The exe would include logic to check for the presence of certain important user data - if not there then it would create them etc.
But it seems that on Vista, UAC will intervene and deny anything from the logon path like this that requires admin privileges. So is a manifest needed?

What about an ActiveSetup msi repair? Will this not be denied by UAC or will it succeed if you have it installed on a per-machine basis using a deployment tool?

Sorry for long comment..if you have any thoughts on any of this rant I'd appreciate you voicing them.

Login to vote
WiseUser's picture

Hi Vijay ,

Its a good article , For your reference I have already posted an article for the types of active setup , hope this will also be helpful to others..

Wise User

Altiris Certified Professional

Login to vote
R-Vijay's picture

Hi Shane...

As you must be aware in windows Vista the entire application architecture is made to be as user perspective rather than a machine one. The HKCU entries and files always roam in the network. Eg: would be the Users Folder.

Yeah. I did look through the microsoft article on creating an application to execute in run mode. It looks fine for a bootstrap program rather than a MSI. The UAC always interferes in every process of an application. Hence, for this solution we will need a msifest which mentions the runas mode to asadministrator. However, the best practice for developing application says to run any application as an invoker.

As the entries are gonna be userspecific there wont be any problem in repairing.

It is adviced not to have any HKCU keys when the application is gonna undergo a machine level deployment. Its a better practice to use shadowkeys instead. Because, when the application is launched for every user, it will go for a selfheal.

Hope I have tried to answer your questions.
Please revert back if you have any more questions or clarifications..


Microsoft MVP [Setup-Deploy]

Login to vote
SH79's picture

Thanks for the reply Vijay..

You've written above that "As you must be aware in windows Vista the entire application architecture is made to be as user perspective rather than a machine one. The HKCU entries and files always roam in the network. Eg: would be the Users Folder."
When you say 'Users Folder' what parts do you refer? Is it ALL the users folder excluding Appdata\Local and LocalLow? Am new to Vista so only getting to grips with the new structure.

You mention also 'shadow keys' - a new term for me.. any links to some background reading?

Regarding use of ActiveSetup\Run - when vendor msi's are being deployed per-machine it's necessary to allow it to self-heal for the user.
One would hope that the vendor msi is tailored properly to only install current user data or only run CAs that don't need admin privileges. This is as it would have been on XP etc. Otherwise you would need to run the CA's as deferred execution\sytem context, and hope they work, or condition them not to run on repair in the first place - right?

So presuming you're at a stage when the msi has self-healed and installed necessary user data. But a user can always delete their user data. So on next log in, no ActiveSetup, therefore app is broken.

Also - depending on exactly what 'roams'.. if the HKCU keys do & indicate that ActiveSetup has already run for this user, but some of the user data does not roam, then you've a broken application on subsequent desktops. Hence my question on what exactly roams with the user.

This is why I would've investigated using the Run key - the msi could be modified feature wise to repair as efficiently as possible so running it every time for a user might not be too much of an overhead. Obviously no need if you've got advertised shortcuts.

Otherwise you'd have to use your deployment tool to manage this somehow.. i.e. either placing the current user data on the machine itself (if it detected it was missing) or forcing the msi to repair.

I suppose my main question is: If your msi repairs fine for a user using ActiveSetup, will it also run successfully from the Run key (using the same msiexec /f command)?
Or is it going to be intercepted by UAC and a prompt for credentials thrown?
Has the Run key been singled out for extra attention and ActiveSetup not?

Login to vote
Matias Magnus Andersen's picture

Hi there,

Ive been browsing the web for quite some time now and not found any others with the issue im facing, which is a bit wierd since all packages using "Active Setup" should be facing this issue.

Anyways here goes:

I Install my MSI package on target machine, users logs on and "Active Setup" will do its thing, Repairing and so on. Creating entry points in the users HKCU hive preventing a repair next time the user logs on. Well all is fine so far.

One day the Application will be uninstall for some reason (may it be stupid user interaction or Admin removong the app from the target Machine) Application is gone, well all still fine.. for now.

Next day the package needs to be reinstalled on the machine, every thing goes smooth until the user logs on. "Active Setup" should run to repair the users settings/preofile, but its not because the package populated the HKCU key last time the application were installed (and they havent been removed).

Are there any "nice" way to counter this behaviour?

Have a few work arounds but they are all somewhat "ugly". (Either by using a script to go trough all users hive to remove the Active setup string or make a counter which stays on the machine which appseach uses to increment the "Version" in the "Active Setup" entry).

Login to vote
WiseUser's picture

A possible Work around I can suggest is to create a Flag key in HKCU which is something like this

and set this entry as Key path .

Whenever the package is reinstalled revise a minor version so that registry key will be unique resulting in a non clash with old application for active setup.

Altiris Certified Professional

Login to vote
R-Vijay's picture

Answering your question
“If your msi repairs fine for a user using ActiveSetup, will it also run successfully from the Run key (using the same msiexec /f command)?
Or is it going to be intercepted by UAC and a prompt for credentials thrown?
Has the Run key been singled out for extra attention and ActiveSetup not?”

UAC will surely interfere in this phenomenon, however it wont stop the process as the entries are being made in the current user. You have very well turn this UAC off by setting a property in your custom developed MSI for Vista.

Now to give a brief usage of Run key.

When a new user logs on to a machine, all programs named in the HKLM\Software\Microsoft\Windows\CurrentVersion\Run key are executed. A program is named here (typically a .vbs script) which checks to see if a HKCU key exists (the "test key"), if it doesn't it creates all required HKCU keys for this user.

This technique can be used for our packages. The disadvantage is that it requires a program (or script file) per application requiring this. This could potentially result in a long list of programs (or scripts) to be executed when a user logs on, with consequent delay. It also requires the authoring of script files for each application requiring this.

Microsoft MVP [Setup-Deploy]

Login to vote
SH79's picture

Thanks Vijay...

Not entirely sure what you mean by 'UAC will interfere but it won't stop the process'. If it interferes then it has stopped the process hasn't it until a username and prompt are supplied.
Or do you mean 'UAC will see the repair but decide not to stop it as it is only writing to a user location'?

I wasn't really planning on executing a script to write the HKCU keys etc but to use the inbuilt msi repair, hence the use of msiexec /fu..
Ok - a vbscript could be used to first check for the need to repair and then go ahead and launch msiexec /fu if required.

My question was more about the treatment of the RUN key versus that of ActiveSetup.
Since the article i mentioned earlier ( geared towards the usage of the RUN key i was wondering if it is considered more of a threat to the OS hence why UAC might monitor it more closely than ActiveSetup.
There is no mention of ActiveSetup in that article so I presume that an exe prevented from running in the Run key will run fine in the ActiveSetup path.

I think testing is what's needed here.
If i get a chance to examine this I'll post back.

Thanks for you help.

Login to vote
trb48's picture

One thing that I have done a few times is actually load another users registry hive, then apply the settings in the users registry. Here is how you do it:

reg load HKLM\test "C:\Documents and Settings\Administrator\NTUSER.DAT"

Now, if you go into REGEDIT, you can see the users registry hive. You have to go to HKEY_LOCAL_MACHINE >>test to see the hive. All registry keys that you apply to that hive have to have their path changed. When you are all done, make sure you unload the hive. If you don't you will have problems.

Login to vote
Pascal KOTTE's picture

as usual... Juice to Connect migration impact

~Pascal @ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

Login to vote
EdT's picture


Looks pretty much the same as my original posting at:

Great to see it's getting around....;)

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Login to vote