This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Writing Keys to HKEY_USERS/.DEFAULT?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Feb 03, 2011
09:22 AM
Writing Keys to HKEY_USERS/.DEFAULT?
Hi all,
I asked this question a while back somewhere and I believe there were some pitfalls, but I'm wondering....
Instead of writing user specific values to HKCU, why instead couldn't I write them to HKEY_USERS/.DEFAULT? That way, they would be available for non-installing users that log on and run our app. Windows Installer wouldn't kick off a repair if one of the keys previously written to HKCU was a component key. At least that is how I think it would work.
My goal would be to move away from having repair run for non-installing users. Are app needs some stuff in HKCU and we're hesitant to move them to HKLM with stricter security on more recent OSs.
When I got a reply last time (I think it was an old post in a Wise forum when we used that product.) it wasn't so much that there were pitfall mentioned, I don't think, but it wasn't a common practice. I think that was the jist of the reply, but it was way back.
Just wondering if anyone undertakes this practice.
Any information or tips would be greatly appreciated.
I asked this question a while back somewhere and I believe there were some pitfalls, but I'm wondering....
Instead of writing user specific values to HKCU, why instead couldn't I write them to HKEY_USERS/.DEFAULT? That way, they would be available for non-installing users that log on and run our app. Windows Installer wouldn't kick off a repair if one of the keys previously written to HKCU was a component key. At least that is how I think it would work.
My goal would be to move away from having repair run for non-installing users. Are app needs some stuff in HKCU and we're hesitant to move them to HKLM with stricter security on more recent OSs.
When I got a reply last time (I think it was an old post in a Wise forum when we used that product.) it wasn't so much that there were pitfall mentioned, I don't think, but it wasn't a common practice. I think that was the jist of the reply, but it was way back.
Just wondering if anyone undertakes this practice.
Any information or tips would be greatly appreciated.
(3) Replies
‎Feb 03, 2011
11:45 AM
That might not have the desired effect: http://blogs.msdn.com/b/oldnewthing/archive/2007/03/02/1786493.aspx.
Search these forums (or the world) for "ActiveSetup" for one approach to getting per-user keys created, though I don't know if it distinguishes between accounts that do and don't want the keys.
Search these forums (or the world) for "ActiveSetup" for one approach to getting per-user keys created, though I don't know if it distinguishes between accounts that do and don't want the keys.
‎Feb 03, 2011
12:56 PM
Thanks Robert. That reading was interesting, but I'm still confused. Is ActiveSetup just a way to side-step the visible repair when a User specific key path is missing. Is it meant to be the solution on if there is no advertised entry point.
My application is already launched by an Advertised Shortcut, so is it better just to stay with that? If I would go to ActiveSetup as a means of getting HKCU stuff, would I have to change the main shortcut back to a non-advertised shortcut.
Or, is this how it works...
User logs in, registry keys are checked, repair runs (with silent parameters if so desired) then, when the user actually launches the application, the HKCU key stuff would be in place. If this is the case, it wouldn't matter what kind of app. shortcut I use, correct? I would also wonder then if this would elongate the login process if a repair takes a while.
I also read that you could create an .exe to do the work and install that with your product. This could then be used by Active Setup. That might be quicker. I wonder though, what context would this .exe be running in at the time these two registry entries are compared and things are launced if needed.
In one of the posts regarding this I read that another option is to write a Custom Action to push user specific stuff to all user profiles/registry, etc.
I'd have to look for code to do that, but I wonder if that would work. I guess, if its possible, I could just run that in System Context.
My application is already launched by an Advertised Shortcut, so is it better just to stay with that? If I would go to ActiveSetup as a means of getting HKCU stuff, would I have to change the main shortcut back to a non-advertised shortcut.
Or, is this how it works...
User logs in, registry keys are checked, repair runs (with silent parameters if so desired) then, when the user actually launches the application, the HKCU key stuff would be in place. If this is the case, it wouldn't matter what kind of app. shortcut I use, correct? I would also wonder then if this would elongate the login process if a repair takes a while.
I also read that you could create an .exe to do the work and install that with your product. This could then be used by Active Setup. That might be quicker. I wonder though, what context would this .exe be running in at the time these two registry entries are compared and things are launced if needed.
In one of the posts regarding this I read that another option is to write a Custom Action to push user specific stuff to all user profiles/registry, etc.
I'd have to look for code to do that, but I wonder if that would work. I guess, if its possible, I could just run that in System Context.
‎Feb 03, 2011
03:05 PM
If you already have an advertised shortcut, I get the impression that ActiveSetup won't really add anything for your case. (I suppose you could add the ActiveSetup command to run regedit with a .reg file containing your default HKCU values.)
In any case, ActiveSetup kicks in on login, as opposed to the repair being triggered by an advertised shortcut. For that reason, the shortcut is a better way to go if you want the keys written only for users who launch your application...
In any case, ActiveSetup kicks in on login, as opposed to the repair being triggered by an advertised shortcut. For that reason, the shortcut is a better way to go if you want the keys written only for users who launch your application...
