Software Deployment

Hi Jonah,

No I wouldn't say that's good practice - you need to keep the registry stuff in the relevent sections to allow the settings to roam etc.

How are you installing the package? Presumably you are not advertising the application so set the installation to happen for all users rather than current user only - from command line it's msiexec /i appname.msi TRANSFORMS=appname.mst ALLUSERS=2

If you are trying to advertise then you may have problems doing it using vendor msi (especially Adobe products) and will probably take a lot of work to get the self repair working for current user stuff.

Cheers,
Rob.

Hi Johan,

Though it is not common practice, I used the same solution for Adobe Reader as you did: all customisations in HKLM instead of HKCU. You will not see many applications for which this will work!

We use machine-based installations, and rely on HKCU-repairs only if necessary. But our users just hate first time use repairs and often get confused by it. Therefore our manager loved this Adobe Reader solution. There was one setting that could not be set in HKLM, only in HKCU, and he decided to leave that setting out of the package. (HKCU\Software\Adobe\Acrobat Reader\7.0\Originals bDisplayedSplash=0)

Btw, the reason that your HKCU-repair did not work, is probably that your HKCU-keys were not in the same feature or in a parent feature as the "entry point". An entry point can be an advertised shortcut (For Adobe Reader 7 only the one in ProgramMenu is originally advertised, not the one on the desktop), a file extension, or COM registration.
The target of the advertised shortcut in the the ProgramMenuFolder is the root feature ReaderProgramFiles, so only the keypaths in this feature will be checked. The file extension *.pdf is not an entry point (only *.rmf, *.fdf, *xfdf, *.xdp and *.pdx), so a repair will not be triggered by double-clicking a pdf file.
I packaged Adobe Reader also for another organisation, and for them I managed to get self-repair of HKCU-settings working.

A lot of explanations, only to say that I think your solution is allright!

CS

Hi Johan,

There is no general good or bad about it. You generalize some settings a user can normaly configure himself. Wether or not this is bad depends on your environment...

Depending on the environment I am working in, when I encounter HKCU keys, I first try to get rid of them completely. If that doesn't work I try to move them to HKLM. After that I, use the techniques (often discussed on this forum) to minimize the impact of the repair.

A lot of applications don't have HKCU keys in their installation. Those that do, often need them, and also need them to be in HKCU. So the succesrate for skipping or moving them is not very high.

Ilikebananas

Hi Johan

We experienced the same effect after a different user logged in.
In our case it simply helped to add the followin registry keys to force a repair at login:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{AC76BA86-7AD7-1033-7B44-A70000000000}]
"Version"="7.0"
"StubPath"="msiexec /fup {AC76BA86-7AD7-1033-7B44-A70000000000}"

(Make sure that the GUID matches the one of your package).

Roland

That registry key is a rather extreme approach, and completely unnecessary if the package is made correctly. The package should automatically detect that the current user doesn't have the per-user data and automatically build it when the app is launched through an entry point.

To get the self repair of user data working properly, all user data (HKCU & Profile stuff) should be in components that do not contain any machine data. The keypath for these components are set to reg keys in HKCU. If they are missing, self-repair will put them there automatically.

If you really want things streamlined, create a new feature and move all the user data components into it. That makes the self-repair of the missing user components much faster because the entire application won't be repaired, only the missing user data components. BUT... the placement of this feature in relation to the feature where your entry point is located is critical. For this to work, the user data feature must be in sucessive steps above or below the entry point feature. If the user data feature is on a different branch and the tree must be traversed to get to it, the user data feature won't be checked when the entry point is launched.

If isolating user components into a separate feature sounds too complicated, then don't worry about it. All it does is significantly reduce the time it takes to self repair new users. If user components aren't isolated into a separate feature, the self-repair of user components will still work fine but will take more time to complete.