Hi All

During manual MSI Installation, WriteRegistryValues Action writes the registry values in the registry. As far as I know, deferred execution Standard actions run in System context. But I observed, HKCU registry keys are getting written in Currently Logged on User (HKCU) instead of HKU\.Default (System account). The same is for files (user profiles).
Please explain me the phenomenon while writing registry values/user profiles in current user.
0 Comments   [ + ] Show Comments

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.

Answers

0
Google for 'Windows Installer self healing'
Answered 03/04/2012 by: VBScab
Red Belt

Please log in to comment
0
Hi raj-regul,

This is the default behaviour of Windows Installer.
All the profileinformation is written to the profile of the logged on user, this is why you normally get the installation progress bar when you first launch an application like Word with a user other than the one who installed it on the machine.
To counter this a lot of packagers trigger the self-healing part silently using the run/runonce key or the activesetup mechanism.

I advise you to read up on the subject and google for "Windows Installer self healing" to get all the technical information about it.
Answered 03/05/2012 by: Kazakh
Yellow Belt

Please log in to comment
0
To counter this a lot of packagers trigger the self-healing part silently using the run/runonce key or the activesetup mechanism

I have to disagree with this statement. To me Self-Healing is still the best choice. Only if for some reason it is not available do I resort to ActiveSetup. The Run/RunOnce keys are a (distant) third option for propagating user settings imo.

Of course I am only one packager, not a lot of em, so feel free to disagree :)

PJ
Answered 03/05/2012 by: pjgeutjens
Red Belt

Please log in to comment
0
pj,

That is why I said MOST packagers ;)

Everything depends on the requirements of the client.
Most of my clients don't like that repair window and want to get rid of it, so using activesetup is the standard choice with most of my customers.

Offcourse if you really want the native functionality, best is to use the advertised shortcuts.

btw, using activesetup does not mean you're not using the self-healing, basically you put the msiexec /fu... command inside it, which triggers the self-repair.
Answered 03/05/2012 by: Kazakh
Yellow Belt

Please log in to comment
0
Most of my clients don't like that repair windowusing activesetup does not mean you're not using the self-healing, basically you put the msiexec /fu... command inside it, which triggers the self-repair. Can you reconcile these two statements for us?
Answered 03/05/2012 by: VBScab
Red Belt

Please log in to comment
0
VBScab,

By using running the command MsiExec.exe /fu... /qn, a self-repair mechnisme is started without the user seeing the repair window. This keeps the native functionality of Windows Installer in place without bothering the user with extra progress bars etc...
Answered 03/05/2012 by: Kazakh
Yellow Belt

Please log in to comment
0
Bothering the user? What is the Active Setup non-modal dialog doing, then? I can't recall a single client I've worked for over the last decade that cared.

Anyway, horses for courses, I suppose...
Answered 03/05/2012 by: VBScab
Red Belt

Please log in to comment
0
Point taken, I should take care more of my wording...

In each case, everything is based on the requirements of the client.

Some don't care, some want the activesetup mechanisms, others want the run/runonce methods,...
Answered 03/05/2012 by: Kazakh
Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity