Jump to content

This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.

Best practice: userprofile deployment

2 replies to this topic


  • Moderators
  • 1,447 posts

Posted 03 July 2003 - 21:24

Overall claim / problem: It seems to me that the whole Windows Installer technology is conceptually inadequate when it comes to handling proper installation and maintenance of user specific files. At least I think Microsoft could have done a better job making this important part of deployment easier and conceptually cleaner.
Just so it is clear: the problem is not the actual installation of userprofile files. This is pretty straight forward:

  • Install files to the userprofile folder hierarchy
  • Use a HKCU registry keypath for the component (this ensures that each user has a unique keypath set to the file - which is a requirement for Windows Installer).
  • Make sure the files are installed when you invoke the application shortcut OR invoked manually via an MSI api call from the application on startup.

However, it is after you deploy your files to the userprofile folders that the real fun begins. There are a lot of open questions. I will discuss userprofile deployment with myself below - this could be entertaining tongue.gif. The point is to make it easy for whoever has a better answer to point out where I am wrong:

Q1: When you install files to the user profile, each user must have access to the original installation image in order to copy all user-specific files to their profile directory. How do you make sure that the original installation image is available when these users invoke the product's shortcut (and self-repair begins)? If the image is not available the user will be asked to browse for the installation image in order to copy necessary files to the userprofile and if they don't have it, the whole install will fail

A1: To make deployment of user specific files work properly, you either have to cache the entire installer on the system, or have the user install from an adimistrative installation image on the network (shared network location). Alternatively you could install all userprofile files to the %PROGRAMFILES% hierarchy and then use the DuplicateFile table to deploy files to the user profile (this might also be the way to go to be able to patch user specific files).

Q2: Once files are deployed per user, how do you patch / update these files for all users?

A2: I see no easy way to have a patch apply to all userprofile files for all users. Two possible solutions would be to deploy these files with a separate "user specific" setup invoked by the application itself on startup (then you could install this MSI package to the %PROGRAMFILES% folder and deliver an updated package for this whole installer and install it again to patch userprofile files), or you could install all user-specific files to %PROGRAMFILES% and then rely on the DuplicateFile action to properly copy the file to the userprofile path.

Q3: How do I uninstall user-specific files from each user profile?

A3: It seems that the best practice here will be to leave all files installed to the userprofile as "permanent components". And then have a custom action in the uninstaller where the user is given the choice of deleting all userprofile files as a unit (the question then becomes how to invoke this custom action for all users - Maybe a custom EXE invoked by runonce would be better). An alternative is to parse all userprofile folders for the folder hierarchy in question and just delete all occurrences (a horrible solution if you ask me).

Q4: How does the file replace rules work for files installed as part of dynamic components? (Installshield specific) A component is said to always be installed / uninstalled as a unit. Does this mean it is impossible to install an update for a single file in a dynamically aquired component?

A4: It is unclear how Installshield's dynamical components affect patching and upgrades. Maybe the file hash table enables the upgrade install to only install files with "recognized" checksums and leave all other (user changed) files? My guess however, is that all dynamically deployed files always will be reinstalled.

Q5: If I would like to install only missing files, but not replace any existing files in the user profile, how can this be specified?

A5: This is related to question 4. I know that you can use the MSI API call MsiReinstallFeature and specify that it should only install missing files. Since this would have to be invoked per-user, the call must probably be done from the main application executable on startup. It is also unclear if this will actually version check each file in the dynamic component, or if it is only checking the keyfile for the component (if any).

Q6: I have a lot of "library" files with my application. These are files delivered by us that the user can change. Is there a way to prevent mixing our "vanilla files" from user changed files? The overall goal is to deploy these files to allow user customization and still make it possible to patch and update the main files.

A6: I have been thinking about deploying the application files we deliver to LocalAppDataFolder, and then have the application copy any changed files to the corresponding AppDataFolder. This way the files we install will not roam with the user (LocalAppDataFolder), and can in principle be patched (since no user specific changes should be made in this folder). The files in the AppDataFolder would roam with the user and hence provide a "transparent experience" for users who can use the same product on different computers and still have access to their customized files. The bad news is that this is all pretty complex to do, and requires changes in both installer and application. Conceptually it is not really clean either.


Edited by Glytzhkof, 04 July 2003 - 00:48.

-Stein Åsmul

Stefan Krueger

Stefan Krueger


  • Administrators
  • 13,269 posts

Posted 04 July 2003 - 07:43

First of all: this method of creating per-user registry entries or files using MSI's repair mechanism is only a workaround for the real problem. Actually your application should handle this, not the installer (as it would have done before MSI). What I mean is: if there are no user preference settings in registry, your application should use default settings, and create the per-user data as required. Similar for per-user files: you could install templates to a per-machine location (e.g. program files folder) and let your application copy them to the user profile if needed, instead of invoking a repair using MSI API.

Q1: Either use the method I mentioned above, or make sure the MSI source is available (install from a network share)

Q2: These are user data, so don't patch them. If a newer version of your application requires a different format or additional entries: let the application do the conversion upon startup (like InstallShield converts project files)

Q3: They are user data, so don't uninstall them.

Q4: You can add files to components (and they should be installed by the update). You can remove files from the components (you will need an entry in RemoveFile table to delete the orphaned files). Make sure you specify the older .msi file in the Patch Optimization panel of the Release Wizard. Otherwise InstallShield may change the file keys which will cause problems.

Q5: If the key file exists and doen't need to be repaired, no file in the component will be repaired. If the key file needs reinstall, the file versioning rules will be used to decide which of the other files in the component should be overwritten or not. To make sure each file will be checked put them in separate components and make them the key path of the component. (Dynamic links conflict with this obviously, so you have to make a decision)

Q6: I don't really understand what you are trying to do? You can't patch a file that has been edited by a user.


  • Moderators
  • 1,447 posts

Posted 06 July 2003 - 21:31

Stefan, thank you so much for your answers! This makes it possible for me to convince my boss that these issues are not really "installer issues", but part of a larger deployment issue.
-Stein Åsmul