MSI installer for non admin user

Question

I created a msi package which will copy files and folder from production location to users machine and registers the required dll in local users machine.

Local users don't have admin rights on any machine now. but installer which i created registers some dll, here is the problem. Registeration logic fails when non admin users tries to run the installer. I got some feed back from my system admin to "We need to change the Installsheild permissions from executing as the 'interactive user' to executing as the 'Launching User'. this way when he MSI executes and calls the installscript service to start it will start up as the user who kicked off the installer, not as the logged on user (standard user) who doesn't have rights to install software. "

I dint really not able to proceed with this suggestion. Can some one help me .

Thanks, Sach

Solution 1

If I understand what you're asking, InstallShield 12 changed the InstallScript MSI architecture to avoid this problem; if you can upgrade and rebuild, this problem should just disappear.

If you cannot upgrade, you can search the Internet for terms like isscript.msi launching user to find suggestions on how to modify the DCOM service to run as the launching user. Removing the "Interactive User" value from the relevant AppId registry key isn't exactly supported, but lots of people have had success with it.

If these are third party installations over which you don't have control, Stack Overflow isn't the correct forum.

Solution 2

Several good answers here, but it seems they try to answer different questions. It is not entirely clear what the real problem is:

1: Michael Urman refers to a bug that can occur with Installshield setups whereby an Installscript custom action runs with interactive user rather than launching user and this can trigger permission problems. If you are using a new version of Installshield this should not be the issue. There are some older knowledge database articles for this: Q108324, Q108340

2: A setup that requires admin access to the computer can not be run as a standard user unless you enforce what is referred to as "elevated rights". In effect temporary write access to most of the system for the MSI whilst installing, but not genuine admin rights.

I am guessing that the issue you are really facing is the latter. In a larger company, elevated rights are generally enforced via its software distribution system. For example Microsoft's SCCM or SMS as it used to be called. There is, however, a more rudimentary way to get a setup to launch elevated, and the method is explained here: http://support.microsoft.com/kb/259459/EN-US - as indicated by Avik.

I didn't find a proper link for changing the DCOM settings, but here is one for a different product: http://msdn.microsoft.com/en-us/library/windows/desktop/ms630816(v=vs.85).aspx. The process is similar.

Solution 3

Why do you need installscript to register a Dll? There are a number of ways to do this, even if you just put the Dll in the MSI file's SelfReg table using whatever setup tool you are using. That's not even the best way, but it doesn't need installscript.

However, you cannot violate system security by having a limited user do an install that performs actions that limited users cannot do. A registration to HKLM will always require admin privilege. Group Policy can be used to roll out setups that require elevation to limited user's machines. If you want limited users to be able to install and use your app you need to redesign it so it doesn't need to create or modify restrictive areas of the system, as avik describes. That includes the ProgramFiles folder too.

Comments

[Patrick Hofman]

Possible duplicate of How to make a setup work for limited (non-admin) users