Remove registry keys from Users hive
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!
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
Answers (11)
Please log in to answer
Posted by:
anonymous_9363
13 years ago
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...
In my experience, most clients couldn't care less about orphan HKCU entries...
Posted by:
AngelD
13 years ago
As Ian said; leave them and let the customer handle those if they want.
Posted by:
JoderCoder
13 years ago
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
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
Posted by:
anonymous_9363
13 years ago
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 question
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 question
Is there any InstallShield smart way of doing this?No, nor is there in any MSI authoring tool I know. Have fun!
Posted by:
JoderCoder
13 years ago
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..
As for add-in writing to HKCU, IE reads the context menus from HKCU. That's the design they have been using..
Posted by:
AutomateIT
13 years ago
A script to gather user directory names and modify the User.dat files with reg.exe should clean-up these types of issues.
Posted by:
Jsaylor
13 years ago
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.
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.
Posted by:
Jsaylor
13 years ago
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.
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.
Posted by:
AutomateIT
13 years ago
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.
Posted by:
Jsaylor
13 years ago
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.
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.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.