I’ll just summarize what others mostly mentioned, specifying a bit, trying to make a “small link”.
You may need to pay attention to the Win10 ransomware protection feature below to see how this Windows change can affect the deployment of user profile files.
GENERAL APPROACHES
There are many ways to get files deployed for each user on a computer, but there are many shortcomings and problems with most approaches. Honestly, there are problems with all approaches, in one form or another.
The following is a list of some common deployment approaches, followed by a few cloud-based approaches. In the future, this discussion may become irrelevant, as the settings are completely cloud-based and synchronized on the fly, and deployment can completely switch from deployment to a separate machine to user-based deployment. We'll have to wait and see how it goes.
1: Template for each machine
- Set the configuration file to a location for each computer that is readable by all users, then copy the file from there and place it in the userprofile file when the application starts, using the application itself to copy once for each user.
- This is the recommended approach. You can even update your application using logic to force updates for each user if you need to use this approach: http://forum.installsite.net/index.php?showtopic=21552 .
- You will always work in the right user context when copying occurs, and you don’t need to worry about the complexities of impersonation, conditioning, and MSI consistency.
- A nice advantage of this approach is that it will work even if there is no installation source (MSI) during application startup.
2: Create file at startup - "Internal default settings"
- As Gillidack suggests, just create a configuration file at startup using the application’s default internal settings, and don’t install the file at all . Occurs once per user, since then you use the file that is there. Storing such a file in your installer means that you eliminate the risk that the installer accidentally overwrites it or removes it.
- The obvious question is: why do you need such a file at all - if you can create it from internal defaults? The answer, obviously, is that you might want to apply some specific values that are unique to the user environment after the file is created. However, can such settings be saved in the registry?
- You can set the appropriate user settings in the HKLM registry key via GENERAL PROPERTIES during installation (configured by the user on the command line or using conversion, see: How to better use MSI files to get information about this), and apply them to all users at startup applications - in other words, write them to HKCU. Or could you just save the read-only settings in HKLM and apply them to all users in your application? (non-user-configurable parameters - such as the name of a network server or similar).
- You can still use the method from the link above to force the existing configuration files to be updated at application startup by setting the HKLM flag in your configuration to notify that the deployment has “happened” since the last launch.
- Or, as indicated, use the registry instead to store the settings.
- How to read the embedded text resource file
3: MSI Self-Repair
- Put the configuration file in place for each user using MSI self-healing . This happens when you call an advertised entry point, such as an advertised shortcut, used to launch the application.
- Access to the installation source during repair is required. Be sure to cache your MSI file on the box.
- Self-healing may not work on terminal servers (disabled feature). Many years have passed since the last time I checked this. I'm not sure how the servers are configured out of the box these days.
- Unless otherwise specified, uninstallation can uninstall the configuration file for a user who is actually uninstalling, or, very importantly, this can happen during a major update (which is really uninstalling and reinstalling your product). In other words: set the component permanent (and never overwrite) - or your file may look overwritten during the update (but it really uninstalls and reinstalls).
- For the HKCU registry settings, it is not necessary to have an available installation source. See Stephen Krueger's explanation: http://www.msifaq.com/a/1011.htm . The procedure is the same as for starting the installation of userprofile files (but then the installation source is required). A related discussion is in case this is helpful .
- Although I did not check, I considered setting the path value to the registry key:
HKCU\Software\MyCompany\MyApplication\Version\HKCU_KeyPath = [ComputerName] to make the key path value a "moving target" so that self-healing works reliably when the user logs on to the new computer (although roaming profiles introduce existing HKCU settings). - As I said, it’s untested, as I have largely abandoned this approach - as it is less reliable to depend on every new update for Windows. Something strange changes every time, with unpredictable results.
- Although not 100% related, I can mention the new ransomware protection feature in Windows 10 as an example - it seems to cause periodic runtime errors for any MSI trying to write to user data folders. It remains to be seen how many problems will arise during deployment — although we still see erratic results — what happens when and if they enable this feature by default?
- And, as above, third-party security software also impedes deployment by blocking certain file system activity and isolating files marked for any reason (including false positives), which leads to self-healing, which can never be completed, but remains working in vain.
- So, in short , here are a few reasons why it is becoming more and more useful to avoid deploying user profile files through self-healing:
- Complications in the roaming profile .
- Anti-Ransomware Protection Function .
- Security software intervention (especially false malware).
- Limitations of the terminal server to self-healing .
- Data reset or problem removal options during a major update .
- Maybe you have the same feeling as mine: even more, and it will worsen.
- My two cents : talk to your manager immediately about the best data file management for your application and give up all attempts to be smart during deployment. Deployment for each machine file only with MSI - if possible.
- In the future, this preference may change as deployment technology changes, and installation is done only for the user (possibly).
- A more detailed description of the problem, written earlier: Why is it recommended to limit the deployment of files to a user profile or HKCU when using MSI?
- And the whole mess of talk about deployment issues in general : how do I avoid the common design flaws in my WiX / MSI deployment solution?
- Put the configuration file in place using Active Setup . This happens when a user logs on to the system (which then requires logging out and logging in, unless you make sure that the file is also installed in the current user profile during installation).
- In essence, this is a variant of approach 1. You must install the configuration file in a folder for each machine that is readable by all users.
- Then you register the task in the registry to run “something workable” once for each user. You can run something, for example, a batch file, an executable file, a script, or my preferred MSI recovery method, which will allow you to place the userprofile file in place (in this case, you do not need the file in the location for each machine, but you have access to the installation source when starting Active Setup).
- Be careful not to overwrite the configuration file installed during installation for the current user. Or, disable Active Setup startup for this user by writing the HKCU key that is written after running Active Setup for this user (see Link below).
- The procedure is described in my answer here: Updating the registry of each profile in Windows Server 2003 . All this is based on the HKLM key, which runs once for each user. Check out the related answer for details, and there are several external links that provide much more details.
- UPDATE : When installing on a terminal server, you put the server in "installation mode", and then the registry entries for each user are written to
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install and then written to each user HKCU bush when they are logged in. This may conflict with ActiveSetup - as far as I know. I have never had the opportunity to verify this. Packaging for a terminal server is usually performed by a special, specialized group of servers.
5: MsiProvideComponent
- Phil MsiProvideComponent is interesting, I never used it. I must.
CLOUDY-STYLE APPROACHES
Summary
I no longer like option 3 (Self-healing) and option 4 (Active tuning), although I have used them many times - and they work when everything is done correctly. However, they are not protected from problems with the roaming profile (files are not copied in place to all systems that the user logs into) and do not have access to the MSI installation source during recovery, which can cause deployment problems. During major updates with reset settings, frequent complications also arise, and self-healing fails on terminal servers. Self-repair may result in an error when installing in the user profile due to protection from ransomware or interference from security software. The command line specified in parameter 4 (Active Setup) may contain errors and destroy data (for example, you turn on the wrong flag for msiexec.exe recovery and force overwriting the settings file accidentally - this is often not detected until it becomes too large). late and the damage has already been done). And there are other problems that are avoiding me right now. Both approaches have similar but slightly different limitations.
I increasingly prefer cloud-based approaches to make local (and isolated) user settings files a thing of the past, but I rarely managed to deploy them that way. These cloud-based approaches may run into problems with the firewall / proxy server and network connectivity issues - and possibly with some other things that I don’t know about yet (now the developers will quarrel with DBO and not with deployment specialists, etc.) .d ... ;-)). Distributed computing has its own errors: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing . Also: in cloud-based approaches for applications, it might still be a good idea to allow settings to be backed up to disk, so is it obvious that some file management is still necessary - or are you just exporting a couple of database tables? Also: if you are installing a trial version of your application, you may want it to work without connecting to the network at all - in case the user is behind a very tight firewall. This is a very expensive mistake to prevent your user from testing the features of your application due to technical issues.
The great advantage of options 1 and 2 is that they will work even if the original installation media is not available when starting the recovery. This is especially important for deployment at home and in a small office, where deployment can happen rather randomly without centralized package sharing. You can work around this problem (missing the original MSI) by using caching methods to cache all MSI on the system during installation (available in Installshield, I did not check WiX or Advanced Installer).