Software Deployment

since HKU\.Default is actually the users hive of the LocalSystem account, the keys won't be available to your normal users I'm afraid.

if they were there would be no use for Active Setup / Selfhealing mechanisms to propagate reg settings to users, since they'd already have them all.

PJ

What if the entries were written outside of the .Default key, would that still be a problem?

I always thought user specific stuff should be written to HKCU.

In summary, what would be the purpose(s) of writing stuff to HKEY_USERS?

Actually, HKU\.Default contains the registry information for when Windows loads and sits at the login prompt. E.g contains information, like the login wallpaper, background colour, numlock etc.....

The registry keys for the default user are stored in the file ntuser.dat within the profile (e.g. for XP it's "C:\Documents and Settings\Default User\ntuser.dat"). You would have to load this as a hive using regedit to add settings for the default user.

The registry keys for the Local System account are in the file "C:\Windows\system32\config\systemprofile\ntsuer.dat"

So by placing the keys under HKU\.Default, it shouldn't have any real effect on the system.

There isn't that many occasions where you'd want to write stuff to HKEY_USERS (in a package), you're better off writing to HKCU and using Active Setup to carry these over to all existing/new users.

Yeah, I've never written anything to HKU so this one threw me.

I'm not really sure how the application is working post install if it is trained to look in HKCU. Now, in my absence there may have been some big move to now look for user registry 'stuff' in HKU.

Is that safe to say that if an app usually looks in HKCU, it will be broken if installed with registry keys to HKU.

In asking why this was done, the initial answer was that when a Power User ran the app for the first time, self repair would run. I'm not sure what OS they were installing on or what user initially ran the install. This would be normal behavior if this was the first time this user ran the app following install if not the installing user.

UPDATE: The install was initially run by an Admin then the app was executed by a PU. This would initiate self-repair to place the user entries previously installed to HKCU. I'm not quite sure how extensive was on this, but the developer indicated that by placing the keys/values in HKU, self repair was no longer needed as the keys were now available to everyone. And, the application works. So they are saying that these keys are then available to everyone, which is in contradiction to this: "since HKU\.Default is actually the users hive of the LocalSystem account, the keys won't be available to your normal users I'm afraid. "

This really gives me an uneasy feeling about this whole move. It comes as a requirement from a potential big customer that there be no self repair for non-installing users initiating the app for the first time.


Thanks too for the quick responses!!

Is this package intended to be installed on a terminal server?

Term Serv - Not that I know of why?

Early on in testing this change, or maybe I should say re-testing, it appears that Windows Installer resolves looking in HKU even though a system search for launch condition is looking in HKCU. We have an install that writes install path to HKU now. We have another install that is dependent on the first being in place. This installs search is looking in HKCU, where the key doesn't exist on the target system, but it does in HKU. The install proceeds without issue.

That would be a good thing, I guess. Then I would only have to worry about custom action widgets that look to HKCU and change them to handle HKU as well.

Any thoughts on this are greatly appreciated.

I've been working with Windows Installer several years and I've never been as scared as I am right now. I don't know if I should move ahead with entries being written to HKU or change them back to HKCU!

t appears that Windows Installer resolves looking in HKU even though a system search for launch condition is looking in HKCUIt would do, if the installing user was local System.

We're currently working to revert this back to a state before the HKU changes.

Does anyone know a way to allow the self repair when needed, but hidden/silent? Is there a registry setting that could be tweaked to prevent the self repair dialogs from being seen?