We develop the msi package for our application using InstallShield.

The application, at run time, writes some keys to HKCU. We would like to remove those keys when uninstalling the application.

The tricky part is that multiple users might run the app which means that registry keys will be created under each users HKCU. Furthermore, uninstall can be performed by admin silently using some deployment utility. How would it be possible to remove the registry from each users hive?

Each user has a hive under HKEY_USERS\<SomeGUID>\Software. In theory it should be possible to remove the reg keys once you know the GUIDs. Is there any InstallShield smart way of doing this?

If not, the only option I can think off is to loop through the reg keys under HKEY_USERS, as always, in a custom action. It would be excellent if one has written a (C++) custom action for that already.

Thanks!
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
I would leave that to the client, as you can't control whether or not the application is installed per-machine or per-user. If the latter, your proposed uninstall action is going to remove every user's entries, something I like to describe as "sub-optimal".

In my experience, most clients couldn't care less about orphan HKCU entries...
Answered 11/05/2009 by: VBScab
Red Belt

Please log in to comment
0
As Ian said; leave them and let the customer handle those if they want.
Answered 11/05/2009 by: AngelD
Red Belt

Please log in to comment
0
Let me provide some more detail on this.

The install is always per-machine. Installer places the registry to HKLM only. Part of the application is a plug in to Internet Explorer which reads values from HKCU. And it is application responsibility to copy them over the HKCU.

After uninstalling the app, since the HKCU registry is left behind, the IE still shows a menu item. So somehow I have to remove the HKCU registry entries when uninstalling the app.

Any further ideas?

Thanks
Answered 11/05/2009 by: JoderCoder
Senior Yellow Belt

Please log in to comment
0
I missed the reference to "our" application so now the question is, why would an IE add-in write fundamental stuff such as menu additions to HKCU, when IE is, almost by definition, machine-based?

I'd be changing that but, expecting a negative response to that suggestion, then you have no choice but to:
- build a profile list
- double-check that against the list in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
- walk the profile list
- convert the SID to the user's log-in ID (hint: WMI, create user object, objUser.SID)
- if that profile exists, load its registry using Reg.EXE or similar.
- remove the keys
- unload.

Step 3 is necessary because only SIDs for the Administrator, LocalService, Network Service and the currently logged-in user are loaded at start-time.

And to answer your questionIs there any InstallShield smart way of doing this? No, nor is there in any MSI authoring tool I know. Have fun!
Answered 11/06/2009 by: VBScab
Red Belt

Please log in to comment
0
Ok, thanks.. Just noticed that Microsoft own application, Excel, has the same issue. They dont remove the IE menus when the application is removed which is pretty bad. But I'll do the same thing, just remove it from the HKCU of user who does the install.

As for add-in writing to HKCU, IE reads the context menus from HKCU. That's the design they have been using..
Answered 11/09/2009 by: JoderCoder
Senior Yellow Belt

Please log in to comment
0
A script to gather user directory names and modify the User.dat files with reg.exe should clean-up these types of issues.
Answered 11/11/2009 by: AutomateIT
Senior Yellow Belt

Please log in to comment
0
If it's actually critical that these keys get removed, I would consider writing a script (and spend a long time on it, for something like this it needs to be especially robust,) that would check for and remove the offending registry keys. Once you have that script rock solid and will run silently in every situation you can possibly think of, populate an activesetup action with your script as the target.

Then, the first time every user logs in after your activesetup item is configured, they'll run your (perfect, right?) script to remove the keys.

Without burning a whole lot of time on figuring out how to enumerate and access all user.dat registry hives while no user is logged in, this is how I would do it.
Answered 11/11/2009 by: Jsaylor
Second Degree Blue Belt

Please log in to comment
0
Answered 11/11/2009 by: AutomateIT
Senior Yellow Belt

Please log in to comment
0
I'm not entirely sure that linking a Wisescript to an Installshield user is going to really help matters ;)

EDIT: and to be productive. Tell me what happens when you run that script under the system context, and a user is currently logged in.
Answered 11/11/2009 by: Jsaylor
Second Degree Blue Belt

Please log in to comment
0
This is a partial script which has been proven for 6 years to work regardless of who is logged in and the context in which it is ran. Of course if an application which updates the registry upon exit it will undo a specific change. The intention here is to generate ideas and possibilities to address an issue similar to the one in question.
Answered 11/11/2009 by: AutomateIT
Senior Yellow Belt

Please log in to comment
0
The only reason I asked that question is to get you thinking about what the possible ramifications could be of trying to load a registry hive that's already in use.

The answer is that if you run reg.exe to load hives, but a user is currently logged in, that users' hive will not be loaded, and thus not modified. So unless you specifically force logouts, or to only run while there's no user logged in, then it's very likely that the primary user of a PC will not get the desired registry changes.
Answered 11/12/2009 by: Jsaylor
Second Degree Blue Belt

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