What Requires Admin. Privileges?
Posted 25 March 2007 - 19:29
Any information, as always, APPRECIATED!
Posted 26 March 2007 - 10:13
Posted 30 March 2007 - 21:24
Currently, they have users installing with Administrative rights, but the application is then run by a Power User. When the Power User initiates the app. Windows Installer self repairs and I'm guessing its writing/installing stuff to the user's profile and user area of the Registry. I hope to ascertain what exactly is lacking to cause the self repair upon further investigation.
Basically, what the company would like to have happen is to have this type of behavior cease, but I'm thinking this will take some major rework of the installation in some areas due to initial design flaws.
Any help, guidance, thoughts on how to proceed or where to start other than possibly using Process Monitor and examining the Event Viewer post self-healing would be more than helpful.
Posted 31 March 2007 - 12:20
Actions that typically fail during self repair if not correctly conditioned with the appropriate AdminUser or Privileged conditions:
* Self registration
* Service manipulation
* Anything writing to HKLM
Note that if the install is run with elevated rights it will be possible for a restricted user to perform tasks with temporary admin rights.
Also check whether the self repair is caused by faulty design. Here are some common causes of cyclic self-repair:
* keypath set to per user folder
* keypath set to temporary file
* keypath set to empty folder
Posted 31 March 2007 - 18:59
Posted 02 April 2007 - 04:31
The best design to accomplish this is to install userprofile files to a per machine location such as [INSTALLDIR]Userdata\*.* and then have the application copy this data to the userprofile on launch. The application can then be extended as needed with custom logic to overwrite some files and preserve others as needed. As to HKCU the application should have built-in defaults in the EXE or resource DLLs to ensure a default configuration is added on launch of the EXE.
Posted 02 April 2007 - 16:31
in Windows\Profiles\Application Data\OurCompany\OurApp, there is an .ini file placed.
We are writing some entries to HKLM\Software\ThirdPartyApp and HKLM\OurCompany\OurApp (InstallPath value for future reference).
We are writing some entries to HKCU\Software\ThirdPartyApp and HKCU\Software\OurCompany\OurApp.
Creating shortcuts in Windows\Profiles\Start Menu and Windows\Profiles\Desktop (all currently non-Advertise)
We're also placing two files in \My Documents\OurUtilityFolder.
Any further thoughts on corrections that can be made or pitfalls we may encounter is greatly, and I mean GREATLY appreciated!!
Posted 02 April 2007 - 19:42
In my scenario (Admin installs, Power User initiates, self repair occurs), when the Power User initiation of our application causes self-repair, should this process add another entry for our app. in Add/Remove Programs?
I'm guessing there's one for Admin install then one for the Power User.
I haven't verified this yet myself, but it is being reported by support.
As always, thanks!
Posted 03 April 2007 - 22:27
To overcome this installation, stop creating keys in the registry of the installing user (aka HKEY_CURRENT_USER), and stop installing files in the profile of the installing user (like My Documents etc.)
If the software absolutely requires these registry keys and files, learn to live with the auto-repair or stop supporting Windows NT/2000/XP/2003/Vista and higher - because these OSes support systems used by multiple accounts, and your software cannot deal with that.
Posted 04 April 2007 - 00:52
My recommendation would be to:
* Deploy only small files to the roaming user-specific Application Data folder (custom dictionaries, user preferences etc...). This folder will travel with the user if the user has a roaming profile.
* Deploy larger, user specific files to the Local Settings\Application Data folder. This folder will need to be set up once per computer even if the user has a roaming profile.
* Deploy read-only shared files to All Users\Application Data (your setup can safely install here without triggering self repair).
Posted 10 April 2007 - 20:27
What you've all given is useful information in helping to possibly correct the application and removing this stuff from the install.
Posted 10 April 2007 - 20:45
I guess I would have to search and remove certain reg keys, files, etc. via a utility to possibly run on uninstall. Or, we can place an uninstall shortcut, which removes any application initiated additions, file moves, etc. first before actually uninstalling the product installation.
Posted 11 April 2007 - 00:42
If you really need to clean up HKCU, you can do so using Microsoft's ActiveSetup feature.
Essentially what you do is:
* Copy a cleanup script of some kind to a per machine path such as %ProgramFiles%\Cleanup\MyScript.vbs or MyScript.cmd or whatever you choose.
* On UNINSTALL ONLY of the application, you write an entry to the registry to trigger Microsoft's ActiveSetup:
HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\MyScript
* The script %ProgramFiles%\Cleanup\MyScript.vbs will now run once per user on the machine in question and it can perform cleanup of HKCU.
* The cleanup script itself could also be removed by adding it via its own installer - but in general that's not worthwhile.
Posted 11 April 2007 - 00:44
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\MyScript]
Edited by Glytzhkof, 11 April 2007 - 00:45.