I'm a fairly newbie at MSI re-packaging so I was wondering if what I am about to say it a good/bad thing to do?

So I've downloaded the latest Acrobat Reader 7.05 and I want to create a MST (I also download Acrobat Tuner 7.0 to make my life a little easier)

I check this site out, which I have to say is easily the best website out there for information on MSI's in general!! I add some of the handy hints that people say to add to the MST to get rid of all the annoying (Yahoo toolbar!) addins that Adobe have added. I customize it a little further and then save my MST.

Ok so I run my MSI + MST and it works like a charm, I then log out and log in as another user. The most annoying thing is that the HKCU stuff hasn't been installed (makes sense I guess). Ok so this is what I did about. I went back into Tuner, exported the HKCU and then did a search/replace and changed every HKCU into HKLM. I then re-imported this back into the MST. Is that a good/bad thing to do??

The thing is that it works fine and I can't see any harm in it.

Any thoughts would be appreciated?

0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


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.

Answered 11/05/2005 by: MSIPackager
Third Degree Black Belt

Please log in to comment
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!

Answered 11/06/2005 by: cs_m_si
Senior Yellow Belt

Please log in to comment
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.

Answered 11/07/2005 by: Ilikebananas
Purple Belt

Please log in to comment
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}]
"StubPath"="msiexec /fup {AC76BA86-7AD7-1033-7B44-A70000000000}"

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

Answered 11/07/2005 by: rpfenninger
Second Degree Green Belt

Please log in to comment
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.
Answered 11/07/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment