none
Can not uninstall HKCU registry key in Terminal Server (MSI)

    Question

  • I have a msi component with HKCU reg key as its keypath.

    Installs fine on TerminalServer but when I uninstall the msi it leaves behind the HKCU reg key.

     

    I checked for the shadow key / area, there is one for it. It is removed when I uninstall the msi, but the HKCU stays.

    If I remove the shadow key before doing the uninstall still the HKCU stays there.

     

    Someone please explain me the mechanism here. Thank you much


    Thursday, May 26, 2011 2:05 PM

All replies

  • msiexec is usually executed under a service user whose HKCU maps to another hive. Besides, loading all users' registry hives in an Active Directory environment is going to cause serious permission and performance trouble. 

    You should not create per-user registry entries at the time of install. If you want to remove user settings, provide a reset settings feature in your program that runs on the user's desktop session.



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Thursday, May 26, 2011 6:08 PM
  • msiexec is usually executed under a service user whose HKCU maps to another hive. Besides, loading all users' registry hives in an Active Directory environment is going to cause serious permission and performance trouble. 

    You should not create per-user registry entries at the time of install. If you want to remove user settings, provide a reset settings feature in your program that runs on the user's desktop session.



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP

    The msi is run by the shell per double-click in a User session, and is elevated to System context (Local System) by msi server.

    I'm not loading all the user hives on the machine, where did you read that? That's what Active Setup or in Terminal Server case Shadow Key is for, every user gets it HKCU on logon. 

     

    But that doesn't answer my question, why the reg key is still there - the user that installs the msi does the uninstall again, so his HKCU should be removed (and is on Non-TerminalServices machines - that is default MSI behaviour)

     

    BTW Configuration should be done through the package not by the content. I can manipulate a lot of things with msi, no need to touch the application, removing registry keys is no problem I just want to understand why this happens

    Friday, May 27, 2011 12:42 PM
  • You will find more expert opinions on this matter by searching "HKCU" in a forum that covers your install software, for example, if you use Visual Studio to create your MSI, do a search in http://social.msdn.microsoft.com/Forums/en/winformssetup/threads.

    HKCU is an alias to HKEY_USERS/SID. The mapping changes depending on the current user of the winlogon session. There are usually multiple user sessions on the same computer, for example a console user would have a session running under a desktop user account, and services are running under session 0, but their current users may be LocalSystem, NETWORK SERVICE, etc. The Windows Installer service runs under LocalSystem.

    MSI is NOT an executable. The file type is associated with msiexec. The user context your MSI is executed depends on the install type. It would be the current user if you choose a "Just me" install, but since you mentioned elevation, you are doing a "All user" installation, and HKCU is now  HKEY_USERS/ElevatedUser-SID

    Per-user configuration is not supported for "All User" installation. From MSDN: Write per-user information to the registry when the application is run for the first time and not at installation time. If you must write per-user information to the registry at installation time, separate the per-user and per-machine information into different Windows Installer components. Author the package such that the installer does not attempt to validate and repair the components containing per-user information when the application is installed. 

    The second sentence means a "Just me" install, if you elevate msiexec in order to do a "All users" install, your install will fail to validate in any other user account since the keys included in the install would be missing in their HKCUs. That would trigger a repair (check your user's event log to see if this is triggered right now), and if the install media is not available (e.g. the IT department installed the app from a CD), your user would get a loud and clear "failed to repair" message box every time they launch your product. This would be effectively a "Just me" install, since other users would be annoyed by the message box to a point to call your customer support to fix this problem.

    Other side effect of including per-user configuration in a per-machine install would be problem like yours, registry entries are not removed because the uninstaller blindly apply operations on HKCU when HKCU is mapped to a different SID, or having to load a different user profile in order to remove HKCU settings.



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP

    Friday, May 27, 2011 5:31 PM