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.
Photo

What Requires Admin. Privileges?


13 replies to this topic

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 25 March 2007 - 19:29

Is there an easy way to ascertain or a central information point that will tell me what tasks carried out during an install require Administrative privileges? Writing to HKLM, etc.

Any information, as always, APPRECIATED!


Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 26 March 2007 - 10:13

System administrators control this. Most objects (files, folders, registry keys, etc.) have ACLs that control its access, and administrators can change the access.

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 30 March 2007 - 21:24

Here's my current scenario and goals since inheriting my current employer's installation processes...

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.

sad.gif

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 31 March 2007 - 12:20

So the problem is that self repair fails while logged in as power user? Check the event log on the system to determine what component triggers the self repair. Once you know what component is involved you can determine if the self repair is needed or not.

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
* Etc...

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
* etc...
Regards
-Stein Åsmul

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 31 March 2007 - 18:59

No, the self repair runs, but our company wants to get away from this behavior. I think it is a matter of faulty initial design in that stuff is set to user locations.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 02 April 2007 - 04:31

If they want to get rid of self repair they need to ensure that their application can correctly initialize the data needed for each user in HKCU and the user profile. All applications should actually do this and installers should ideally only install per machine (excluding per user setups).

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.
Regards
-Stein Åsmul

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 02 April 2007 - 16:31

I've done a summary scan of our installation and here are some of the areas I feel there may be problems with regard to user access and possible self repair occurring....

in Windows\Profiles\Application Data\OurCompany\OurApp, there is an .ini file placed.

Registry items:
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.

Shortcuts:
Creating shortcuts in Windows\Profiles\Start Menu and Windows\Profiles\Desktop (all currently non-Advertise)

Files:
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!!

blink.gif

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 02 April 2007 - 19:42

OH, one more quick question...

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!

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 03 April 2007 - 22:27

The issue is not admin priviliges, but installing software for two or more users. You will experience the same issues (self-repair) if Admin1 installs the software and Admin2 starts to use it.

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.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 04 April 2007 - 00:52

It is generally difficult to get developers to realize that it is their responsibility to make an application work for multiple users - they seem to think it is a deployment concern - and it most definitely is not. Your manager will also have a hard time accepting it, but if they want no self repair the application has to be adapted to properly set up the user profile environment on launch. This involves both HKCU and the userprofile files. As stated above one way to do this is to have the application write "internal defaults" to HKCU and to copy files from a per machine location to a per user location on launch. If you go for the latter option you also need to think about issues such as roaming profiles and where you install files in the user profile. The Application Data folder is roaming and per user, the Local Settings\Application Data folder is NOT roaming but still per user. There is also the C:\Documents and Settings\All Users\Application Data folder which I believe is non roaming, and shared among all users (but without write access for regular users in most cases).

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).

Regards
-Stein Åsmul

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 10 April 2007 - 20:27

Thanks all for the info. What all have mentioned is basically what I've begun telling the folks here at my company. The way they built the installation will cause self-repair because that is how Windows Installer handles it.

What you've all given is useful information in helping to possibly correct the application and removing this stuff from the install.

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 10 April 2007 - 20:45

Also, if the appliction was changed to write Current User values or use/copy certain files, this 'stuff' would need to be cleaned up during uninstall.

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.

????

sad.gif

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 11 April 2007 - 00:42

Anything added to HKCU can generally be considered user data along the same lines as files in MyDocuments - and you wouldn't go and delete files from MyDocuments would you? As such it is generally perfectly legitimate to leave HKCU data alone on uninstall.

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
"StubPath"="%ProgramFiles%\Cleanup\MyScript.vbs"
* 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.
Regards
-Stein Åsmul

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 11 April 2007 - 00:44

Active Setup Template:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\MyScript]
"StubPath"="c:\Program Files\Cleanup\MyScript.cmd"

Attached Files


Edited by Glytzhkof, 11 April 2007 - 00:45.

Regards
-Stein Åsmul