Installshield MSI und was wir daraus lernen...

(gefunden in einem anderen Forum... aber sicher auch hier interessant... Smile

)
---------------------------------------------------

Background:
At our company end users aren't local administrators on their desktops. This has been a issue when installing MSI's using installShield applications that seem to spawn processes that require local admin privledges.

On many InstallShield apps during deployment I get a dreaded NI pop-up window

Here is the section of the debug level log file from the NI Install that tells us whats up.
=====================================
Action start 14:46:58: ISStartup.
MSI (s) (08:3C): Creating MSIHANDLE (10) of type 790542 for thread 828
1: The InstallScript engine version currently installed on this machine is adequate.
1: Event 'E4658871' is created
1: GetInstallDriver, Can not find InstallDriver in ROT table, Return Code = 0x800401e3
1: {45DCEF83-9F6B-44E4-B361-7BC2C1152A55}
1: Extract supporting files
1: Failed to extract _IsUser.dll, Ignore it.
1: Ev1707240
Action ended 14:47:00: ISStartup. Return value 1.
=====================================

What I've learned from talking to more peoples than I want to.
InstallShield has a dcom application that is call the InstallShield Driver. This app has some interesting features. (Wait i am getting to it).

The Driver has a identity setting that control what user accounts processes are launched as. (This appears to sneak around NI's built in control of tossing item to the service account to handle permission issues).
Notice the default is "the interactive user"

So you ask where does that leave us.
We know now that InstallShield's driver (isscript.msi) installs dcom agent with a setting to tell InstallShield MSI's which account to use for actions being used by this agent.

If you've been following along and not fallen asleep yet you'll think.
What would happen if that identity tab was set to "the launching user"?
Its really a good question. If that is set to the launching user it seems to fix all issues and we no longer see this problem in our environment.

Now the fun part.
So if you go back and check out the 2nd screenshot you'll see what really makes InstallShield unfriendly (assuming you didn't already think of them this way). My screenshot shows 5 InstallShield Drivers. (trust me it gets better) They each of course have their own Identity setting (this is because installshield tells me there are 3 version of their engine, 7,8,9 and some of the versions have 2 drivers that are somehow different but look the same). So we need to set the identity tab on all of them to make sure we have it the way we want.

Here is where my personal distrust comes to play. InstallShield techs promised me i'd never see more than 5 but i don't trust them.
Spying the settings learned me the the current 5 (yes 5 was the max # i could get in both 2000 & xp to show up for the party)
HKEY_CLASSES_ROOT\AppID\{1BB3D82F-9803-4d29-B232-1F2F14E52A2E}
HKEY_CLASSES_ROOT\AppID\{9338AA50-B293-4CE9-B284-8A5E9E8FF901}
HKEY_CLASSES_ROOT\AppID\{A24328B5-E641-4C0F-873F-335473D32A2A}
HKEY_CLASSES_ROOT\AppID\{C2B96968-8E30-4BA4-A8F9-F40D09D1EA7E}
HKEY_CLASSES_ROOT\AppID\{E4A51076-BCD3-11D4-AB7D-00B0D02332EB}

The value 'RunAS' is set to Interactive user by default. To make it set itself to what we want (Launching User) you just delete the RunAs value which makes this atleast very easy to do.

... nope it gets more fun.

InstallShield decided to be lazy, if you ever re-install any of the versions of th IsScript.msi it decides to set for its verion the identity tab back to 'interactive user'
So if you have peoples who do manual installs they could ruin your glory

So here is my solution thanks to the much help of the Support peoples.
With much help of the Script peoples that wrote scriptomatic we got the following VBScript almost cut and paste from the tool. (just had to add a delete reg and get ride of pop up messages.
==============================
' Authors: Ryan Gray / Chris Kuhl
' Date: 2003-12-30
' Version 1.0
'
' This script enumerates the Dcom appID's for the InstallShield dcom apps
' Then taking that id deletes the run as property of the key to set the
' run as identity to run as launching user.
' This corrects several permissions issues experienced by NI installed MSI's
' using installshield technology.

Const HKEY_CLASSES_ROOT = &H80000000
On Error Resume Next
strComputer = "."
Set objReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_DCOMApplicationSetting",,4 Cool

For Each objItem in colItems
If objItem.Description <> "" Then
arrFind=Split(objItem.Description)
For i=0 To UBound(arrFind)
If lcase(arrFind(i))="installshield" then
'Wscript.Echo "Description: " & objItem.Description
'Wscript.Echo "AppID: " & objItem.Description

strKeyPath = "AppID\" & objItem.AppID
strEntryName = "RunAs"
strValue = ""
objReg.DeleteValue HKEY_CLASSES_ROOT,strKeyPath,strEntryName
End if
Next
End If
Next
==============================
We took this to an extereme and set this setting for all Dcom's that match "installshield" and set to "Launching user" with thisvb script.
However for those wanting to be more cautious you might only want to hit
InstallShield Driver.
Change the search line to:
If lcase(arrFind(i))="installshield InstallDriver"
will fix that part.

So usin that script we now have a way to set any Installshield Driver entry to the way we want

What we did to make a total solution was this.
We got copies of issscript.msi, isscript8.msi, isscript9.msi (see end on easy way to do this)
Made a project that installs all 3 with the /TS to make them service executed - machine releated.

then added the script call to then have the search and clean of the registry to set the 'launching user' setting.

This is our script.inc file for the project.
===============================
!Install Install Shield 7 Driver
MSIInstallProduct('.\extern$\ISScript.msi','DEBUG',MsiInstMach)

params:
EndProc/TS
!
!Install Install Shield 8 Driver
MSIInstallProduct('.\extern$\ISScript8.msi','DEBUG',MsiInstMach)

params:
EndProc/TS
!
!Install Install Shield 9 Driver
MSIInstallProduct('.\extern$\ISScript9.msi','DEBUG',MsiInstMach)

params:
EndProc/TS
!
!In house script to fix Idendity Tab
CallScript('.\extern$\FixRunAsInstallShieldDriverDcom.vbs')/TS
=================================

Then with this project we made it a component of all projects that require the installation of the isscript.msi file. When a vendor sends an app they almost always rename the isscriptX.msi to just isscript.msi so you aren't sure at first glance which version you need. Rather than mess with it we just install all 3 at once and then set the settings the way we want.

Last note is we set this component to always install even if installed on each of these projects so that in the event someone somehow, did somethig that would change the setting away from "Launching User" the script refires and puts everything back the way we want.

I think that covers it.

*** to get copies of the isscript.msi versions go download the evaluation version of the installShield Dev Studio 9
Install it, in C:\Program Files\InstallShield\DevStudio 9\Redist\Language Independent\i386 you'll find version 9
C:\Program Files\InstallShield\DevStudio 9\Redist\Language Independent\i386\Legacy you'll find folders for 7 and 8.

That should do it.

(meine Antwort darauf...)
---------------------------------------------------

Quote:

Ryan.Gray wrote:

On many InstallShield apps during deployment I get a dreaded NI pop-up window

Here is the section of the debug level log file from the NI Install that tells us whats up.
=====================================
Action start 14:46:58: ISStartup.
MSI (s) (08:3C): Creating MSIHANDLE (10) of type 790542 for thread 828
1: The InstallScript engine version currently installed on this machine is adequate.

every time you see this entry in the logfile ("Creating MSIHANDLE") msi spawn a new process and launches a custom action.

installshield is so dull (sorry;) that it check for its "ScriptBridge.dll" and, if not present on the machine, extracts the isscript.msi out of the binary table and tries to install it.

as we all know msi installation in netinstall run on elevated priviledges (setting the approriate policies hklm/hkcu shortly before installing).
what neither installshield nor netsupport keep in mind is, that while running at elevated priviledges, custom actions are still executed with the permissions the current user has... so installing a dll to system32 will fail inevitably... Sad

as you stated: the only workaround is to install isscript.msi in advance.

Quote:

*** to get copies of the isscript.msi versions go download the evaluation version of the installShield Dev Studio 9
Install it, in C:\Program Files\InstallShield\DevStudio 9\Redist\Language Independent\i386 you'll find version 9
C:\Program Files\InstallShield\DevStudio 9\Redist\Language Independent\i386\Legacy you'll find folders for 7 and 8.
That should do it.

be careful though. there are over 3 different versions of isscript.msi.
to be on the safe side, extract the one inside the msi package you like to install...:-/

I think I have the best solution for this. Please read my post on Appdeploy:
http://www.appdeploy.com/packages/detail.asp?id=725