One of the more common (and tricky) issues faced when installing an application in the enterprise is how to install user data. Typically, the application installer is run silently with no user interaction in the “system” context with administrative privileges. This method is commonly used so that the software can install in the background without disrupting the end users work. Fortunately, this method works for a majority of software deployments, because the installer does not need to install anything in the “user” context.
There are situations, however, when an application requires registry keys or some data files installed in the user’s profile prior to the applications first launch. One common post-installation method used for installing user data is called “Active Setup”; a full explanation of how to implement this method is beyond the scope of this post… and besides… there’s already been a blog post on this topic!
A major drawback of the Active Setup method is that any user logged on to the system when the silent installation occurred must log out of their profile and log back in. The reason is because the mechanism which initiates Active Setup compares a Local Machine registry keys to one in the User’s profile when the user logs on. A more convenient and functional method (and slicker, I must say) to install data to the user profile in the user context is by initiating a Windows Installer repair.
By design, Windows Installer initiates “self repair” or “self healing” when an entry point to the installed application is launched. Typically, the entry point is an “Advertised” shortcut. When the user clicks on the shortcut, Windows Installer will perform an integrity check to verify all the “key paths” of the installed application are present; if not present, the Windows Installer repair will install any missing component(s) and their key path. The key path of a component is typically a file or shortcut.
One method for installing Current User registry keys post install is to add a top level “Hidden Feature” (note: the feature doesn’t really have to be hidden, but we do this to ensure that whoever runs the install doesn’t have the option not to install it) to the install which contains all the HKCU keys. Mark the feature as “required” and make it the “Parent” feature to all other features in your MSI. Move all HKCU keys to the same component in the required feature. Finally, add an “advertised” to your application to facilitate the repair. After the application is installed (in the system context), when a user click on the advertised shortcut a self repair will occur to install the components with the missing key paths… IF the key path doesn’t exist.
Ya see…this blog post was partly inspired by a setup I encountered on a customer location which attempted to use this method for installing the required HKCU registry keys. When I tested the application, it was not behaving as expected. I looked into the .MSI that installed it and found that everything had been laid out according to the prescribed method detailed above… except… the component key path holding the HKCU keys was actually an HKLM registry key which already existed on my system! Thus, the self repair would never “kick off”. When attempting to initiate a controlled Windows Installer repair, you must ensure the component key path is truly unique, or the repair won’t happen.
I hope you enjoyed this little insight into Windows Installer and find this method to install user data helpful. This was just a high level overview; next week, I’ll follow up with a more detailed post on how to implement this functionality.