Updater client permissions

Topics: Updater Application Block
Mar 13, 2006 at 7:24 PM
originally posted by: uanmi

we have found that the updates only work if the user on the client machine is a member of Administrators.
How do we get the auto updates to work for users not in the Administrators group please.
Is there an example?

regards, Mark
Apr 1, 2006 at 9:28 AM
originally posted by: enreynolds

This is a somewhat sticky subject that I have struggled with as well. I have found the following tidbits. (By the way I have a fully functional production application running.)
1)
The VS 2003 deployment project, which I assume most people use, by default, writes to the registry of the installed machine. The location of these registry entries is HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<GUID>. Note that there will be a seperate entry for each assembly that your App installs. These entries are NOT needed. I believe that you can modify the MSI file (with ORCA for example) to do away with this "feature", but that was to much VooDoo for me. I have been using Installer2Go to create my installers to get around this.
Explanation: Users and Power Users(next tidbit) by default, do not have priveleges to write to the registry under this registry key. If these keys exist, and you download a new version of the assembly, Windows trys to update the registry to reflect the version change. you could bypass this by not changing the assembly versions(!?!). Others have suggested changing permissions on these keys. Bad Idea: lowers security and requires touching all deployed machines. Better not to have those entries in the registry in the first place. I, of course found out about this problem after deployment. Rather than reinstall, I used a utility called 'Multi-Remote Registry Change v4' to merge a reg file deleting the offending entries remotely, with great success.

2)
Power users DO have modify permissions on the Program Files directory. In my envieronment our users require power user permissions for certain proprietary applications. This made the issue of application location a non-issue for me. XNicholas does have a good solution using CACLS.exe. This is still a security problem, but isolated to the application directory. You could also create the application directory in a user accessible location, but then you start to have more than one place to look for installed Apps. I guess this is more of a personal preference.

Good luck,
Eric Reynolds
Apr 1, 2006 at 6:15 PM
originally posted by: tipsterDC

Hey Mark, Eric,

We've encountered the same limitations to the UAB. There are several solutions as Eric noted, however, in our situation we found the best to grant permissions on the program files\app directory folder using CACLS.EXE. This was done to an existing msi using ORCA and extracted into a usable WiX file which is consumed by our continuous integration process (the MSI is reconstructed with each build).

Regarding the registry, we are applying a similar solution in the msi that uses REGINI.EXE to set permissions to the appropriate user group on the registry keys. This has turned out to be a bit more complicated for some reason, requiring a custom vbs script to be triggered by a custom action on the MSI. Thanks to Eric, I now have a better idea of the keys that are used and can tighten down the permissions we're setting on the registry.

It would be nice if the UAB was configurable to turn off the registry updates it makes during updates. The RegistryManager in the block helps the app to survive interruptions during an update by persisting updater tasks to the registry. For some, this isn't necessary, and would greatly simplify the permissions issue.

Eric also suggested installing the app outside of a restricted loc.; such as program files, windows, and system32. This is another idea we explored, but wasn't an option based on our clients baseline stds.

The whole thing is VooDoo... If you'd like I can post the details of how to instrament the msi using ORCA... initially provided by the Installer support team at MS.

Obviously, the easiest solution is to add all users to the local admin group :-)

Drew C.
Apr 8, 2006 at 12:57 AM
originally posted by: uanmi

yes, please if you can post any instructions on what to do. We are completely lost and this is hurting our customer.

A step by step guide would be useful for everyone, not just us I'm sure.
I appreciate your time.
regards
Mark