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

Non Admin Install


3 replies to this topic

tsvare

tsvare
  • Members
  • 11 posts

Posted 01 October 2002 - 18:18

Hello,

For some unknown reason I was under the impression that IS 7.0 Developer allowed non admin installs.  Does IS 7.0 Developer allow non admin installs?

I've been messing around with publishing and ALLUSERS with no luck.

Thanks,
Tom

hambone

hambone
  • Members
  • 206 posts

Posted 02 October 2002 - 19:06

one of the other requirements is to set the elevated policies for both the user and machine...  after that the ALLUSERS=1 will set all managed apps to install elevated while leaving others as regular installs or the ALLUSERS=2 to make ALL INSTALLS elevated ( might not be what you want for a managed environment )...

tsvare

tsvare
  • Members
  • 11 posts

Posted 02 October 2002 - 21:23

I'm brand new to IS Developer 7.0 (msi).  I don't quite understand what you mean by 'set elevated policies'

Thanks,
Tom

hambone

hambone
  • Members
  • 206 posts

Posted 04 October 2002 - 15:51

there are two sets of policies, rules if you will, at the local machine that govern how the msi environment behaves.  

one set of policies applies to the system ( the machine policy ) and the other applies to each user ( the user policies ).  there are a myriad number of inter-dependencies between these two sets of policies but we can ignore most of that that for now and look only at the elevated install options...

typically policies are set using gpo at the server level and pushed down to the workstations to enforce compliance with corporate restrictions and other requirements.  it is however possible to set these policies independent of the gpo.

the machine policies are set under the registry key:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.  
i believe there are around sixteen ( 16 ) machine policies currently defined for the MSI v2.x engine.  one of these policies can be set to control the installation level of MSIs: the AllwaysInstallElevated policy.

the user policies are set under the registry key:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer.
here i believe there are five ( 5 ) user policies currently defined for the MSI v2.x engine.  as with the machine policy one of these policies can be set to control the installation level of MSIs: the AllwaysInstallElevated policy.

for an application to install with elevated privileges it is required that the machine policy is set AND the user policy is set ( for each user on the system that requires the application ).  this is
where it can get a bit tricky without gpo.  

only the current user account info. is loaded in the the HKEY_CURRENT_USER ( HKCU ) registry hive.  other users of the machine store their iinformation in, typically, files called NTUser.DAT in their profile sub-directories.  for all users of the system to have elevated privileges it is required that you apply the AllwaysInstallElevated policy to each of these ( can be performed by a ‘run-once’ type of approach where settings are loaded for each user at login time or a ‘load and go’ method where the installer sets this info. for each of the currently defined profiles and the default user for new logins ).

it is required that both the machine and user policies are set for this to be effective.

When combined with the installation property ALLUSERS, with a setting of 1 rather then 2,  it allows managed application installs to operate with limited administrative abilities.  This has the added benefit of limiting user installs, non-managed applications, to install using the current user’s security context.  

If the installation property ALLUSERS is given a setting of 2 rather then 1 then all installs to the system are performed with elevated privileges.  

Please note that when developing custom actions for a MSI it’s Type setting controls the security context of the custom action.

hope that helps a bit....