Pages

Showing posts with label active setup. Show all posts
Showing posts with label active setup. Show all posts

Monday 29 August 2011

Active Setup Registry Keys

Following Registries are to be included in package to load User settings(either registries/files) so that by the time User
logs in his current user settings will be available on the machine.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode]]
"StubPath"="msiexec /fup {9A346205-EA92-4406-B1AB-50379DA3F057} /qn"
"Version"="1,0"

Difference between Run, Run Once, Active Setup

Active Setup:



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


Run:



The Run key is processed after every logon, either by the Explorer shell, if it is present, or by First Boot Agent (FBA), if a custom shell, Command shell, or Task Manager Shell is used. If FBA processes this key, it does so after every logon, not during first boot as it normally would. Typically, this flag is used to load Systray applications, launch services in executables, hide autostart applications, or hide background processes


Run Once:



The RunOnce key is processed only once, by FBA, after Plug and Play device enumeration and DLL registration processing have completed. The values of this registry key are deleted from the registry after it is processed, so that it will not run again. Typically, this flag is used when a reboot is required, such as for a DLL or OCX registration, or for cleaning up a setup or an uninstall.

Sunday 28 August 2011

What is Active Setup

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.

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 /fomus /qn


[HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{44CCA842-CC51-11CF-AAFA-00AA00B6015B}]
"Version"="1"
"StubPath"="Msiexec.exe /fpu {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.