What is Active setup ?
I am confused , What are active Setups ? How do they work ? What is the logic behind there working .
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
aogilmor
18 years ago
Posted by:
pjgeutjens
14 years ago
How to run Active Setup twice for the same user?
you can augment the version value in the HKLM part of the Active Setup registry keys. This will cause all users to re-run the Active Setup command.
Another option is to delete a user's entry in HKCU for that Active Setup. That user will then execute the Active Setup command again
Posted by:
KentD
18 years ago
Posted by:
ColinBragg
17 years ago
To clarify: "needs registry keys in the HKCU hive and you have to support multiple profiles on the same PC". This isn't entirely correct because a self healing MSI should cover this. However sometimes but rarely an MSI cannot be made to self heal. So you can use Active setup so that your MSI self heals on log on. Although the default for Active setup is to run a user registry heal, it can be configured to repair files as well. If you really wanted to you can even use Active setup to run a completely different command altogether, it's not just restricted to MSI healing.
Posted by:
matrixtushar
17 years ago
if you are reading Active Setup, then also note the difference between entries in StubPath of ActiveSetup and entries under the Run keys and also the entries under the RunOnce keys.
If you need any clarification, do let me know. Will explain you
If you need any clarification, do let me know. Will explain you
Comments:
-
can you please clarify me on this....... - thulasi143 11 years ago
Posted by:
jaybee96
14 years ago
Active setup provides a solution when the aim is to deliver user based components when no advertised entry points exist in an MSI package.
Most packages will contain some kind on entry point; commonly an advertised shortcut. When launching this kind of shortcut Windows Installer will check the keypath of the component the shortcut belongs to and verifies that the component is installed. If it is found to be missing Windows Install will kick off a repair.
This provides a great solution for installing current user data when the package is not installed in the user context. It is also a very good reason why you should never mix machine and user data in the same feature.
So what do you do if there are no shortcuts to advertise? Active Setup will solve the problem.
An MSI package has been created to install an Outlook plug-in. This package installs both user and machine data. User preferences are stored as a combination of HKCU registry and a XML file written to %USERPROFILE%. As this application is a plug-in it does not contain any shortcuts. There are no other advertised entry points that might trigger a repair.
Further, this package is installed by the privileged account NTAUTHORITY\system. In this situation the user registry and XML file will be delivered to the Administrators profile and will never be installed for the user. This is when using active setup is appropriate.
Implementation
On logon the following registry keys are compared:
HKLM\Software\Microsoft\Active Setup\Installed Components\<UID>
HKCU\Software\Microsoft\Active Setup\Installed Components\<UID>
<UID> has to unique; it is good practise to use a GUID.
If the HKCU key is not found the contents of the string value StubPath is executed. The HKLM key is then copied to HKCU.
The executable in StubPath can be anything (a VBS script, a regsvr32.exe call, etc), but our aim, in this example, is to deliver missing current user data from a previously installed MSI. To do this we need to force the package to repair so Msiexec.exe will be used:
Msiexec.exe /fpu /qn
/f - Repair
/p - only if file is missing
/u - all required user-specific registry entries
If you choose to, the entire installation can be repaired:
Msiexec.exe /fauvs /qn
HKLM should look as follows:
[HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{44CCA842-CC51-11CF-AAFA-00AA00B6015B}]
"Version"="1"
"StubPath"="Msiexec.exe /fpus {44CCA842-CC51-11CF-AAFA-00AA00B6015B}"
Where a version is included; StubPath will only execute if the version of HKCU is less than the version of HKLM.
When a new user logs on Windows will find the HKCU active setup key missing, run Msiexec.exe with the repair arguments from StubPath and copy the HKLM key to HKCU. Next time this user logs in the repair won't run as the key already exists in HKCU.
Most packages will contain some kind on entry point; commonly an advertised shortcut. When launching this kind of shortcut Windows Installer will check the keypath of the component the shortcut belongs to and verifies that the component is installed. If it is found to be missing Windows Install will kick off a repair.
This provides a great solution for installing current user data when the package is not installed in the user context. It is also a very good reason why you should never mix machine and user data in the same feature.
So what do you do if there are no shortcuts to advertise? Active Setup will solve the problem.
An MSI package has been created to install an Outlook plug-in. This package installs both user and machine data. User preferences are stored as a combination of HKCU registry and a XML file written to %USERPROFILE%. As this application is a plug-in it does not contain any shortcuts. There are no other advertised entry points that might trigger a repair.
Further, this package is installed by the privileged account NTAUTHORITY\system. In this situation the user registry and XML file will be delivered to the Administrators profile and will never be installed for the user. This is when using active setup is appropriate.
Implementation
On logon the following registry keys are compared:
HKLM\Software\Microsoft\Active Setup\Installed Components\<UID>
HKCU\Software\Microsoft\Active Setup\Installed Components\<UID>
<UID> has to unique; it is good practise to use a GUID.
If the HKCU key is not found the contents of the string value StubPath is executed. The HKLM key is then copied to HKCU.
The executable in StubPath can be anything (a VBS script, a regsvr32.exe call, etc), but our aim, in this example, is to deliver missing current user data from a previously installed MSI. To do this we need to force the package to repair so Msiexec.exe will be used:
Msiexec.exe /fpu /qn
/f - Repair
/p - only if file is missing
/u - all required user-specific registry entries
If you choose to, the entire installation can be repaired:
Msiexec.exe /fauvs /qn
HKLM should look as follows:
[HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{44CCA842-CC51-11CF-AAFA-00AA00B6015B}]
"Version"="1"
"StubPath"="Msiexec.exe /fpus {44CCA842-CC51-11CF-AAFA-00AA00B6015B}"
Where a version is included; StubPath will only execute if the version of HKCU is less than the version of HKLM.
When a new user logs on Windows will find the HKCU active setup key missing, run Msiexec.exe with the repair arguments from StubPath and copy the HKLM key to HKCU. Next time this user logs in the repair won't run as the key already exists in HKCU.
Posted by:
thudo
14 years ago
What happens if you want to copy a file everytime a user logs in? ie. a file needs to be copied to each users C:\Document and Settings\<logged in User>\Application Data\<Client Software config location>each time a new user logs into Windows. Registry is handled up there but not file copying.
Update -- bah found out how to do it. Wasn't remotely hard to do. I just called my Stub file via the registry this way:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\<my_application>]
"StubPath"="C:\\Program Files\\<vendor_root_folder>\\<vendor_sub_folder>\\Stub.exe"
In my Stub.exe set up the variables to edit an ini file in %UserProfiles% based on the above StubPath. Works too well. Yeah essentially I needed to add then edit an INI file with hardcoded config details each time a new user logs in. I created an MST off a vendor MSI to add the default .ini needed in the default profile when the install first too place. Also added the registry info about so each new user would get the stub installed. Done!
Update -- bah found out how to do it. Wasn't remotely hard to do. I just called my Stub file via the registry this way:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\<my_application>]
"StubPath"="C:\\Program Files\\<vendor_root_folder>\\<vendor_sub_folder>\\Stub.exe"
In my Stub.exe set up the variables to edit an ini file in %UserProfiles% based on the above StubPath. Works too well. Yeah essentially I needed to add then edit an INI file with hardcoded config details each time a new user logs in. I created an MST off a vendor MSI to add the default .ini needed in the default profile when the install first too place. Also added the registry info about so each new user would get the stub installed. Done!
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.