Software Deployment

As Bob has kindly added Deploy ISScript To Safely Bypass Checks and Including InstallScript Using MSM under Tips & Tricks I wanted to inform how easily it is to get rid of the ISScript.msi and setup.exe requirements for InstallShield based MSI with a summarized post.

Abstract
InstallScript based MSIs require the InstallShield Script Engine (ISScript.msi) to be pre-installed before the actual MSI can be launched to install the product. This will add the support for the InstallScript engine to communicate with the Windows Installer engine. By merging the InstallShield Scripting Engine merge module (InstallShieldScriptingEngine.msm) into the InstallScript based MSI the ISScript.msi is not required to be pre-installed. If this is a vendor MSI the preferred method would be to merge the InstallShield Scripting Engine merge module using a transform instead.


HOW-TO
Open the InstallScript based MSI using ORCA and verify that the InstallShield Scripting Engine merge module isn’t already included in the MSI. In such cases the InstallShield Scripting Engine is already handled by this merge module and does not have the ISScript pre-installation requirement. Go to the ModuleSignature table and locate any ModuleID that starts with “InstallShieldScriptingEngine.” and ends with a GUID based string where the hyphen character has been replaced with an underscore (ex. “InstallShieldScriptingEngine.D8FE90B3_C548_421A_89BB_E59CE07449A5”).
Select “New Transform” from the Transform menu to create a new transform which will be used during the merging of the MSM. If it’s more preferred to merge the MSM into the InstallScript based MSI skip this step. To merge the MSM into the transform (or the MSI) select “Merge Module” from the Tools menu or just hit Ctrl+M. Select the required version of the InstallShield Scripting Engine merge module (or enter the path into the Module field); the required merge module version is defined by the “ISSCRIPT_ENGINE_VERSION” property in the InstallScript based MSI. Enter the language ID in the Language field for which it should be opened with and select the TARGETDIR directory as the “Root Directory”. Select any feature from the Primary Feature drop-down list as the MSM doesn’t contain any components (only binary streams) therefore any feature will do. No “File Extraction” options should be selected as no components exist. To complete the merge just click OK. If any problems were encountered during the merge ORCA will display a list of any conflicts or errors. Merge Conflicts will occur if table rows exist in both the MSM and the MSI, in such case just accept the result and click the Accept.

Here follows some steps to remove the requirement for launching the installation without using setup.exe:
Add the property ISSETUPDRIVEN and give it a value of 1. This will fool the InstallScript based MSI that the installation was invoked by setup.exe, which in case of launching setup.exe the iDriver.exe would have done this. Remove the OnCheckSilentInstall custom action from the InstallExecuteSequence table to prevent the MSI from checking if a silent installation was performed without using Setup.exe. Remove the ISVerifyScriptingRuntime custom action from the InstallUISequence table to prevent the MSI from checking if the installation was launched using setup.exe during UI sequence.

Save the transform by selecting “Generate Transform” from the Transform menu and save the transform to a preferred location; or just save the MSI if no transform were created in earlier step.

Have in mind that by bypassing setup.exe the “wrapper” may pre-configure settings required for the installation to correctly install the product, so make sure to log setup.exe to investigate which requirements needed to be fulfilled before installing the product without setup.exe.


Summary of InstallShield InstallDriver DCOM Identity problem
ISScript.Msi or InstallShieldScriptingEngine.msm installs the InstallShield InstallDriver DCOM component. The DCOM component will be set to run as "The Interactive user" by default. In this case the DCOM component will not work if the logged in user has none-administrative rights resulting in installation failure. This will be stated in the MSI-LOG with the entry "MsiServerStartup failed. Abort installation". A workaround is to change the Identity of whom the application should run under. Run dcomcnfg.exe and expand the "Component Services\Computers\My Computer\DCOM Config". Find the "InstallShield InstallDriver", right-click and select Properties. Go to the Identity tab and change from "The interactive user" to "The launching User". This can also be done by removing the "RunAs" string entry under "HKCR\AppID\<GUID>". Changing the Identify must be done before the "MsiServerStartup" custom action is called which establishes the connection between the InstallScript engine and the Windows Installer engine.

Custom action to change any InstallShield InstallDriver DCOM Identity from "The interactive user" to "The launching User". The ca must be execute right before the ISMsiServerStartup action in InstallExecuteSequence.
CustomAction: SetISDCOMIdentity
Dim WMIService, WshShell, DComApps, DComApp
Set WMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set WshShell = CreateObject("WScript.Shell")
Set DComApps = WMIService.ExecQuery("Select * from Win32_DComApplicationSetting where Caption='InstallShield InstallDriver' and RunAsUser='Interactive User'")

For Each DComApp In DComApps
WshShell.RegDelete "HKEY_CLASSES_ROOT\AppID\" & DComApp.AppID & "\RunAs"
Next

Update:
Found a post from "kkaminsk" (Thanks!) about setting the DCOM Identity with "dcomperm.exe", which could be used in the custom action instead of using the above vbscript.
dcomperm.exe -runas {E4A51076-BCD3-11D4-AB7D-00B0D02332EB} "Launching User"
Dcomperm can be found in MSDN.

Hi Dave,
this is definitely the permission problem, i guessed in my earlier post.

Another limitation of GPO based user installs is not being able to script multiple MSI installs, or chain a pre-requisite MSI like you can in SMS.

Why shouldn't this be possible?
You can assign multiple packages to one GPO. They are installed in the same sequence as they are assigned to the GPO.

Regards, Nick

Hi gizmolala,
there are several possibilities for this. My prefered solution for this, is a wrapper MSI. With it, you do all the UI-stuff. Then you can call the prerequisite and the app with a CA or nest it. This depends on, how the these MSI's are built.
I do it e.g. with Quicktime 7. A wrapper, in there nested the ISScript engine and a call with a CA at the end to install the app. The wrapper and ISScript are removed from ARP. The app has a CA to remove the wrapper when it is uninstalled (ISScript can not be uninstalled).
Hope this example helps a bit.
Regards, Nick

Tnx a lot pal. the MSI i want to install first is ISScript engine and then install the main application. How am i suppose to go about the wrapper.

Giz

Instead of creating a wrapping include the correct version of the "InstallShieldScriptingEngine" merge module in a transform.

Tnx AngelID. That sound like a good idea. Will surely do that.

Hi AngelD,
this can't work at all! If you do that, the ISScriptEngine is called by the MSI which it is nested in long before it is actually installed!
See:
http://itninja.com/link/flexera-software---knowledge-base
http://itninja.com/question/follow-up-isscript.msi-question
http://community.installshield.com/showthread.php?t=154647

Regards, Nick


ORIGINAL: AngelD

Instead of creating a wrapping include the correct version of the "InstallShieldScriptingEngine" merge module in a transform.

nheim:

are you sure?
because the msm only contains:
_Streams/Binary Table
Name Data
_ISRES1033.dll {binary}
IDriver.exe {binary}
InstallISScript.D8FE90B1_C548_421A_89BB_E59CE07449A5 {binary}
IScript7.dll {binary}
ISRT.dll {binary}
IUser7.dll {binary}
objps7.dll {binary}


CustomAction Table
Action Type Source Target
EngineStartup.D8FE90B1_C548_421A_89BB_E59CE07449A5 257 InstallISScript.D8FE90B1_C548_421A_89BB_E59CE07449A5 EngineStartup

No nested what I can find.
(I've seen this being used by the BlackBerry installation)
Please enlighten me if I'm wrong ;)

Hi AngelD,
yes i'm quite shure about this. Take an MSI with a nested package and have a look at the logfile.

Exerpt from the Installer SDK Docu:
"A nested installation shares the same user interface and logging settings as the main installation.
Nested installation actions should be placed between the InstallInitialize action and InstallFinalize action of the main installation's action sequence. Upon rollback of the main installation, the installer will then rollback the nested installation as well. The use of deferred execution with nested installation actions is unnecessary because the installer combines rollback information from the nested and main installations. All changes are reversed upon a rollback installation."

In short: The actions from the nested app are worked into the MSI-Script and executed in a row with the actions of the main app.

Hope this clarifies the situation.

Regards, Nick


ORIGINAL: AngelD

nheim:

are you sure?
because the msm only contains:
_Streams/Binary Table
Name Data
_ISRES1033.dll {binary}
IDriver.exe {binary}
InstallISScript.D8FE90B1_C548_421A_89BB_E59CE07449A5 {binary}
IScript7.dll {binary}
ISRT.dll {binary}
IUser7.dll {binary}
objps7.dll {binary}


CustomAction Table
Action Type Source Target
EngineStartup.D8FE90B1_C548_421A_89BB_E59CE07449A5 257 InstallISScript.D8FE90B1_C548_421A_89BB_E59CE07449A5 EngineStartup

No nested what I can find.
(I've seen this being used by the BlackBerry installation)
Please enlighten me if I'm wrong ;)

Hey nheim,

what do you mean by nested package in this scenario?
There are no nested isscript.msi if that's what you mean, the msm only contains the files (binary) required for register and start the ISScript support.

Hi AngelD,
Sorry, i looked up your earlier post again and saw, you suggested the ISScript as MSM and not as a nested MSI.
But it doesn't change the main problem. I assume you want to add the IS-MSM with the transform to the app which requires it.
And this won't work either, because the MSI of the app makes the first call to ISScript at a very early stage and the engine isn't installed then at all.
With an MSM, the integration with the host MSI goes even further, than with a nested package. Therefore, in my opinion, it is not possible to avoid a multistage scenario, like i suggested with wrapper. If somebody finds a better way, please let me know immediately.
Regard, Nick

I understand your comments and it would be true the "EngineStartup" CustomAction wouldn't be executed in an early stage.

But the msm changes the sequence order in the InstallExecuteSequence table to execute the EngineStartup CA in sequence #2, this means that the engine is installed before the ISMsiServerStartup CustomAction executed from the msi which will have sequence #3.

Hope this will help you in determine if it will work or not ;)

Hi AngelD,
this sounds very promising to me! Of which ISScript version are we speaking here? And where could one get the MSM's?
Regards, Nick

hmm,

my posts was referring to the msm from the BlackBerry msm but when I look in the msm from Merge Modules (InstallShield repository) they do not look alike and doesn't seem to change the sequence order. So to be able to use the msm from the link you would have to modify these.

The msm from the BlackBerry MSI looks like:
_Tables Table
Name
_Validation
ActionText
Binary
Component
CustomAction
Directory
FeatureComponents
File
InstallExecuteSequence
InstallUISequence
ModuleComponents
ModuleSignature
Property
WiseMediaOptions


_Streams Table
Name Data
Binary.InstallISScript.D8FE90B3_C548_421A_89BB_E59CE07449A5 {binary}
MergeModule.CABinet {binary}
SummaryInformation {binary}

ActionText Table
Action Description Template
InstallISscriptFiles.D8FE90B3_C548_421A_89BB_E59CE07449A5 Extracting InstallShield Scripting Engine...
MoveISscript.D8FE90B3_C548_421A_89BB_E59CE07449A5 Configuiring InstallShield Scripting Engine...
RegisterISScript.D8FE90B3_C548_421A_89BB_E59CE07449A5 Registering InstallShield Scripting Engine...

Binary Table
Name Data
InstallISScript.D8FE90B3_C548_421A_89BB_E59CE07449A5 {binary}

CustomAction Table
Action Type Source Target
EngineStartup.D8FE90B3_C548_421A_89BB_E59CE07449A5 257 InstallISScript.D8FE90B3_C548_421A_89BB_E59CE07449A5 EngineStartup

Directory Table
Directory Directory_Parent DefaultDir
INSTALLDIR.D8FE90B3_C548_421A_89BB_E59CE07449A5 TARGETDIR .

InstallExecuteSequence Table
Action Condition Sequence
EngineStartup.D8FE90B3_C548_421A_89BB_E59CE07449A5 2


InstallUISequence Table
Action Condition Sequence
EngineStartup.D8FE90B3_C548_421A_89BB_E59CE07449A5 2

Property Table
Property Value
NewProperty1.D8FE90B3_C548_421A_89BB_E59CE07449A5 0

WiseMediaOptions Table
Option Value Type
DotNet Project 2 15
PathType 2 3

Well, I did some more digging into the InstallShieldScriptingEngine.msm and it seems it will work.

The ModuleInstallExecuteSequence table reorder the sequence for the EngineStartup and ISMsiServerStartup CA.
Taken from InstallShieldScriptingEngine.msm (10.x)
Action Sequence BaseAction After Condition
EngineStartup.4F635B62_07BF_4779_B74E_D80C29D508E3 -2147483648 ISMsiServerStartup 0
ISMsiServerStartup 1 -2147483648

The "After" column for the "EngineStartup.4F635B62_07BF_4779_B74E_D80C29D508E3" CustomAction defines "Action to come before BaseAction" (0) defined by the "BaseAction" column which in this case is "ISMsiServerStartup". When the merge module has been merged into the msi the EngineStartup action will be inserted right before the ISMsiServerStartup action making sure to installer the required ISScript support before the ISMsiServerStartup action establishes the connection between the InstallScript engine and the Windows Installer engine.

Just make sure the ISMsiServerStartup action has the same sequence order in the msm as in the msi.

Taken from the SDK "ModuleInstallExecuteSequence Table"
"If the sequence number in the merge module differs from that for the same action in the .msi file sequence table, the merge tool uses the sequence number from the .msi file."

Hi AngelD,
please tell us, where one can get the ISScriptEngine MSM's. Don't like to create wrappers if it's not necessary!
Thanks for all your info.
Regards, Nick

http://www.installshield.com/downloads/modules.asp?prod=ISX&lan=english&xmlUse=y

FYI, according to a support call I opened with Macrovision, InstallScript Scan fails to detect the latest release of QuickTime as an InstallScript driven package due to the fact that Apple used a third-party tool to create the self extracting executable.

I just added a new video to the AppDeploy Library on this subject, covering how to bypass the check by creating an MST that deletes the custom action which performs the setup.exe check, by passing the ISSETUPDRIVEN property and using InstallScript Scan. I touch briefly on this new MSM possibility as well. Check it out here: http://itninja.com/blog/view/appdeploy.com->-training-videos->-dealing-with-installscript-for-administrators

I've also posted a new PDF on the command line support provided by InstallShield setups (MSI and InstallScript) here: http://www.appdeploy.com/articles/InstallShield%20Setup%20Parameters.pdf

Thanks a lot AngelD, for this excellent Info!
Just a small addition for the people who don't use Installlshield (like me): There are only ISScript MSM's up to version 10 on the Installshield website: http://www.installshield.com/downloads/modules.asp?prod=ISX&lan=english&xmlUse=y
For version 11.5 MSM, you can download the evaluation of Flexnet Adminstudio 7.5
http://saturn.installshield.com/adminstudio/75/eval/package/flexnetadminstudio75.exe
Version 11 was available in the Adminstudio 7.0 Evaluation, but unfortunately, it has been removed from the IS website.
Regards, Nick

Good One AngelD, Rated your post

Hey nheim and all others ;)

Will see if I can manage to create a InstallShieldScriptingEngine merge module fromout the ISScript.msi and post the result.

Thanks for the rate guys

Gidday AngelD,

I believe your code will fix an issue I'm having with MapInfo 8.5 InstallShield situation.
When I run my installation as a standard user using SMS the InstallShield DCOM Identity setting is 'interactive user' which fails to process my PIDKEY. When identity changed to Launching user for the InstallShield InstallDriver my PIDKEY is accepted.
However, I've tried inserting the code into my msi as a custom action and it appears that when it is run, the custom action deletes the reference to interactive user and doesn't actually change the value to Launching user. Would you be able to clarify this for me please?

Thanks for the great thread,

Wayne

Hi WayneB,

By removing/deleting the registry entry the Identity of the DCOM component will be set to "The launching User".
Try this; install the ISScript.MSI, this will set the DCOM Identity to "The Interactive user". Then remove the registry entry and have a look at the Identity, this will have changed the Identity to "The launching User".

Use dcomcnfg.exe to check the Identity.

Gidday AngelD,

Yep, that worked when I ran the script manually, so now I've got to figure out why it doesn't change the dcom setting when I run the custom action in the msi.
Maybe because I pre-run the InstallShield1050.msi before MapInfo transform and it doesn't allow the setting to change; if there is a hook into it. I'll need to do some more testing.

I really appreciate this, this has been a quandary of mine for the last week. The PIDKEY value gets recognised as expected once the Identity value gets changed to the Launching User, which in this case is system; because I'm running the install through SMS.

Cheers
Wayne

Hi Wayne,

Don't know how you handle packages through SMS but If you install ISScript using the MSI I would create a transform for this and remove that registry for the Identity. That should be Registry601 for other then windows nt 4.0 and if you use windows nt 4.0 then remove Registry6010.
Also have a look in the MapInfo to verify that no custom action is setting the identity.

What parameters for the installation through SMS do you use?
If you use UI then add the custom action to InstallUISequence otherwise in the InstallExecuteSequence as you run the installation with the admin/system user.

hi AngelD,

I created the transform for the ISScript1050.msi and removed the offending keys. And thanks again, I checked the MapInfo 8.5 msi for any changes to the DCOM Identity in the CA's and there are checks for DCOM but no changes as far as I can see. I've left the CA in the MapInfo transform for the moment in the InstallExecuteSequence right before ISMsiServerStartup.

When deploying through SMS we run the ISScript1050 transform with /qb! first immediately followed by the MapInfo transform. The SMS installation runs with administrative rights (system context).

Thanks,

Crocs Rule (in remembrance of a legend Steve Irwin)

Cheers
Wayne

Don't know if you've got it to work yet but anyway I would use a Custom Action Type 6 (VBScript file stored in a Binary table stream.).

What packaging tool are you using, how are you adding the CA and what optional flag bits have you set to the Type column?

Gidday AngelD,

I finally got it working. I had the CA code embedded and this had truncatted to the 255 char colummn restriction. Now I'm calling the (CA) vb script from installation with a type 6. I've had to move the CA to the beginning of the InstallExecuteSequence (Sequence 1) in the MapInfo transform. We're using WPS 7.0.

Cheers
Wayne

Congratulations mate!

Thanks to you and all contributors, this was a sticky one. I've got a fresh appreciation of the ISScript engine.

I'll just tidy up my documentation and submit MapInfo 8.5 to the Package Knowledge base.

Cheers
Wayne

Hi,

Anyone know where to get a copy of installshieldscriptingengine.msm version 11?

You can email me direct if you like: grainger[AT]gmail[DOT]com

Cheers,
Richard.

maybe we should petition installshield to get rid of it altogether.

it seems an uneccessary evil to me.

Sorry to drag this thread up from the depths of time, but I think it's a fairly interesting discussion all the same.

I'm attempting to embed this isscriptingruntimeengine.msm into a vendor package, via orca...all works beautifully when I install it as admin.

Unfortunately my environment commands that I install this via Group Policy, which falls over at the first hurdle "1. Failed to install ISKernel Files" which I'm assuming is a permissions issue when launching DCOM etc..

I've tried the dcomperm.exe - runas {AppID} "Launching User" and also the VBscript AngelD added. (I'm actually running them manually as Admin rather than via the MSI.. I dont think it would make a difference though..

Anybody got any ideas? the previous packager recaptured the whole thing which is something I refuse to do point blank.

All help appreciated.

Cheers

Hi Dave,
which app are we talking about here?
Did the embedding of the ISscript.msm produce any error messages?
Are you sure, you have exact the same version of the merge module engine as it was used with the external one?
Regards, Nick

dm1:

I've done a few of these successfully now. Two things are essential:

1. You must use the exact version of the installshieldscriptingengine.msm expected by your MSI. I have the following versions:
7.x
8.x
9.0
9.01
10.01
10.5
10.x
11.0
11.5

2. You must use AngelDs custom action to change the InstallShield InstallDriver DCOM identity from "The interactive user" to "the launching user". This custom action must be executed just before the ISMsiServerStartup action in the InstallExecuteSequence (in other words you may need to slightly re-number actions in the InstallExecuteSequence).

Good luck!

Thank you Nick and Richard for your replies.

To answer your questions:

1. The application is IXOS Livelink Imaging 9.5.x. I had just received a couple of MSPs from the vendor that I needed to apply but as the previous packager couldn't get around the Isscript issue he recaptured everything. Which has left me needing to re-start the whole process, and patch the MSI, before trying to deal with the isscript issue.

2. merging the MSM only produces one error/warning referring to LaunchConditions.. I ignored it as it didn't seem relevant.

3. I am 99.9% sure that I have the correct MSM. I extracted the Isscript.msi and installed it separately and compared AppID GUIDs to the embedded msm installation. they are identical. They install the following AppID entries: [HKEY_CLASSES_ROOT\APPID\{1BB3D82F-9803-4d29-B232-1F2F14E52A2E}]
@="InstallShield InstallDriver"
and [HKEY_CLASSES_ROOT\APPID\{C2B96968-8E30-4BA4-A8F9-F40D09D1EA7E}]
@="InstallShield InstallDriver"


4. I added the CA and sequenced it as follows (Note I didnt use a Type 6 CA - Is this my problem?)

Custom Action Table:
Action:SetISDCOMIddentity
Type: 102
Source:<Blank>
Target:Dim WMIService, WshShell, DComApps, DComApp
Set WMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set WshShell = CreateObject("WScript.Shell")
Set DComApps = WMIService.ExecQuery("Select * from Win32_DComApplicationSetting where Caption='InstallShield InstallDriver' and RunAsUser='Interactive User'")
For Each DComApp In DComApps
WshShell.RegDelete "HKEY_CLASSES_ROOT\AppID\" & DComApp.AppID & "\RunAs"
Next

InstallExecuteSequence Table
SetISDCOMIddentity NOT Installed 5
EngineStartup.D8FE90B3_C548_421A_89BB_E59CE07449A5 6
ISMsiServerStartup 7


Any Ideas? Am I doomed to Group Policy Installation Failure? Anyone got one of these to install via Group Policy?

Thanks!

Hi Dave,
keep cool! No need to use big letters here :-)

First: Stop doing several things in parallel and solve the issues one by one.
This has not really to do with GPO install.
Be aware of the environment: GPO per machine install takes place under the system account.
To test if this is an issue, open a command line under the system account and start the installation from there.

A word to your custom action:
Are you aware, that carriage returns are not (officially) permitted in a inline VBS-CA? You should change all carriage returns/line feeds with a colon (:).
You should change your CA-type to "38", that means the return code has to be ok, otherwise the CA will stop the MSI.

And most important: Turn on logging and post the log file on a ftp server like senduit.
Be aware that the log files from GPO installs go to %windir%\temp.

Regards, Nick

3. I am 99.9% sure that I have the correct MSM...
To be 100% sure compare the File.Version column between the extracted Isscript.msi and the MSM to find out if you got the correct MSM.

4. ... (Note I didnt use a Type 6 CA - Is this my problem?)
Try a Custom Action Type 6 instead and see if that helps.

But as Nick suggested you will not find out without checking a verbose log.

ORIGINAL: nheim
Hi Dave,
keep cool! No need to use big letters here :-)
Sorry dude, didnt realise they'd come out so big!


First: Stop doing several things in parallel and solve the issues one by one.
This has not really to do with GPO install.
Be aware of the environment: GPO per machine install takes place under the system account.
To test if this is an issue, open a command line under the system account and start the installation from there.


I disagree. GPO Installations are exectued with elevated privileges for the logged on user. It's not executed via NT\SYSTEM which is what SMS does. I've deployed this through GPO for an Open User successfully, but it fails for the fully locked down accounts. Installing via the command line as admin always works! Beleive me, It's rare I come to the forum without trying lots of things first! :-)


A word to your custom action:
Are you aware, that carriage returns are not (officially) permitted in a inline VBS-CA? You should change all carriage returns/line feeds with a colon (:).
You should change your CA-type to "38", that means the return code has to be ok, otherwise the CA will stop the MSI.


I wasn't aware, nice tip.

I've tried various different CA Types to date, none of which have worked through GPO for a locked down user. Logging when installing as Admin returns a code of 1 which seems to work.

And most important: Turn on logging and post the log file on a ftp server like senduit.
Be aware that the log files from GPO installs go to %windir%\temp.


One of the More frustrating aspects in this scenario is my inability to log GPO Installs because our Infrastructure Architect won't allow it for some reason. I've tried the registry hack of adding this to no avail:
Hive: HKEY_LOCAL_MACHINE
Key: Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
Name: RunDiagnosticLoggingApplicationDeployment
Type: REG_DWORD
Value: 1

The Only part of the log that has looked suspect to me so far is the following chunk:
Action start 17:31:44: EngineStartup.D8FE90B3_C548_421A_89BB_E59CE07449A5.
1: EngineStartup, Last modification : 7/24/2002
1: Checking disk free space
1: Installing kernel files and script engine
1: Failed to create directory 'C:\Program Files\Common Files\InstallShield\Driver\8\Intel 32', return code is 0xb7
MSI (s) (AC!A4) [17:31:44:964]: Transforming table Binary.
1: Extracting _ISRES1033.dll to C:\DOCUME~1\DAMURP~1\LOCALS~1\Temp\{065B17B5-10E0-4EA7-9260-E37B98650331}
1: Trying to install C:\Program Files\Common Files\InstallShield\Driver\8\Intel 32\_ISRES1033.dll...
1: After file installation, return code = 0
1: regsvr32 /s "C:\PROGRA~1\COMMON~1\INSTAL~1\Driver\8\INTEL3~1\_ISRES~1.DLL"
1: Returning code is 0x4
MSI (s) (AC!A4) [17:31:45:089]: Transforming table Binary.
1: Extracting IDriver.exe to C:\DOCUME~1\DAMURP~1\LOCALS~1\Temp\{065B17B5-10E0-4EA7-9260-E37B98650331}
1: Trying to install C:\Program Files\Common Files\InstallShield\Driver\8\Intel 32\IDriver.exe...
1: After file installation, return code = 0
1: "C:\Program Files\Common Files\InstallShield\Driver\8\Intel 32\IDriver.exe" /RegServer
1: Returning code is 0x0
MSI (s) (AC!A4) [17:31:45:589]: Transforming table Binary.
1: Extracting IUser8.dll to C:\DOCUME~1\DAMURP~1\LOCALS~1\Temp\{065B17B5-10E0-4EA7-9260-E37B98650331}
1: Trying to install C:\Program Files\Common Files\InstallShield\Driver\8\Intel 32\IUser8.dll...
1: After file installation, return code = 0
1: regsvr32 /s "C:\PROGRA~1\COMMON~1\INSTAL~1\Driver\8\INTEL3~1\IUser8.dll"
1: Returning code is 0x0
MSI (s) (AC!A4) [17:31:45:729]: Transforming table Binary.
1: Extracting ISRT.dll to C:\DOCUME~1\DAMURP~1\LOCALS~1\Temp\{065B17B5-10E0-4EA7-9260-E37B98650331}
1: Trying to install C:\Program Files\Common Files\InstallShield\Driver\8\Intel 32\ISRT.dll...
1: After file installation, return code = 0
1: regsvr32 /s "C:\PROGRA~1\COMMON~1\INSTAL~1\Driver\8\INTEL3~1\ISRT.dll"
1: Returning code is 0x4
MSI (s) (AC!A4) [17:31:46:011]: Transforming table Binary.
1: Extracting objps8.dll to C:\DOCUME~1\DAMURP~1\LOCALS~1\Temp\{065B17B5-10E0-4EA7-9260-E37B98650331}
1: Trying to install C:\Program Files\Common Files\InstallShield\Driver\8\Intel 32\objps8.dll...
1: After file installation, return code = 0
1: regsvr32 /s "C:\PROGRA~1\COMMON~1\INSTAL~1\Driver\8\INTEL3~1\objps8.dll"
1: Returning code is 0x0
MSI (s) (AC!A4) [17:31:46:089]: Transforming table Binary.
1: Extracting IScript8.dll to C:\DOCUME~1\DAMURP~1\LOCALS~1\Temp\{065B17B5-10E0-4EA7-9260-E37B98650331}
1: Trying to install C:\Program Files\Common Files\InstallShield\Driver\8\Intel 32\IScript8.dll...
1: After file installation, return code = 0
1: regsvr32 /s "C:\PROGRA~1\COMMON~1\INSTAL~1\Driver\8\INTEL3~1\IScript8.dll"
1: Returning code is 0x0
MSI (s) (AC:38) [17:31:46:323]: Doing action: ISMsiServerStartup
Action ended 17:31:46: EngineStartup.D8FE90B3_C548_421A_89BB_E59CE07449A5. Return value 1.
But it still returns a value of 1 and continues OK, all files and folders seem to be created OK...

AngelD, I am now 100% sure i have the correct MSM.

Cheers Guys.

Hi Dave,
Sorry dude, didn't realize they'd come out so big!
There's a preview button between OK and Cancel down there... ;-)

I disagree. GPO Installations are executed with elevated privileges for the logged on user
This is only true for a per user installation. Are you sure, you need to install this SW per user? This needs a well designed MSI, with no CA's who try to make system changes outside of the Installer Script.

One of the More frustrating aspects in this scenario is my inability to log GPO Installs because our Infrastructure Architect won't allow it for some reason
You got a nice pal there. "Infrastructure Architect" and not allowing logging? On which planet does he live? :-(

There's almost no chance to solve this without logging!
You need to find the bombing action.

Have you tried to it the smart way: Just try to enable the logging policy. In the GPO under:
Computer Configuration - Administrative Templates - Windows Components - Windows Installer, turn on logging and enter voicewarmupx.
The log for a per user install would go to the users temp directory.

And move your new CA "SetISDCOMIddentity" right in front of the "ISMsiServerStartup" action (after EngineStartup).

Keep trying.

Regards, Nick

Hi Nick,

I'm persevering with this. Determined to get it working. Don't care how long it takes!

First off, our group policy installations are all user context, with elevated permissions. This allows our users to install applications from their local DFS point via Add/Remove Programs based on AD Security Groups. (All other larger applications, rollouts etc is handled by SMS - This Solution was designed for us by MS!)..

I want to persevere with installing it this way, because it will make's the upgrade of the existing application a piece of cake. GP simply uninstalls the old version automatically.

On the upside, I figured out how to enable the logging for each GP install. There's a KB article HERE. never had to resort to this previously, but it should prove useful with this particular environment.

Getting back to the Log: I've Run the WILogUtl (Note you can use this for MSI 3.1 Logs by following AAron's Tip Here) against the log to produce 4 errors:
1. 1: Failed to install ISKernel Files.
Make sure you have appropriate privileges on this machine.
MSI (c) (CC:D0) [10:29:10:641]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (s) (B8:DC) [10:29:29:287]: Note: 1: 33
Action ended 10:29:29: EngineStartup.D8FE90B3_C548_421A_89BB_E59CE07449A5. Return value 3.
2. MSI (s) (B8!54) [10:29:29:878]: Creating MSIHANDLE (16) of type 790531 for thread 3156
1: Shutting down the PRC server...
MSI (s) (B8!54) [10:29:29:878]: Closing MSIHANDLE (16) of type 790531 for thread 3156
MSI (s) (B8:50) [10:29:29:878]: Closing MSIHANDLE (14) of type 790542 for thread 3036
1: RPC runtime reported exception 0x6ba
Action ended 10:29:29: ISCleanUpFatalExit. Return value 3.
3. 1: Shutting down the PRC server...
MSI (s) (B8!54) [10:29:29:878]: Closing MSIHANDLE (16) of type 790531 for thread 3156
MSI (s) (B8:50) [10:29:29:878]: Closing MSIHANDLE (14) of type 790542 for thread 3036
1: RPC runtime reported exception 0x6ba
Action ended 10:29:29: ISCleanUpFatalExit. Return value 3.
Action ended 10:29:29: INSTALL. Return value 3.
4. MSI (s) (B8:DC) [10:29:30:009]: MainEngineThread is returning 1603
MSI (s) (B8:DC) [10:29:30:019]: Destroying RemoteAPI object.
MSI (s) (B8:E8) [10:29:30:019]: Custom Action Manager thread ending.
=== Logging stopped: 27/08/2008 10:29:29 ===
MSI (c) (CC:D0) [10:29:30:019]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (CC:D0) [10:29:30:029]: MainEngineThread is returning 1603

Obviously the Most significant of these is Error Number 1. I've added in another CA that runs DCOMPERM.exe as well as the AngelD VBS. The VBS Exits with Return Value 0 and the DCOMPERM CA with Return Value 1.
Is my GP Installation Doomed to failure?

Hi Dave,
i need the hole log file.
Please put it on a ftp service like senduit.
Regards, Nick

Hey! Another site in the world installing per-user via GP! I thought my current client was the only one!

Why not apply a transform to the InstallShield MSI and install that first? We have all the IS nonsense packaged up like this, where the relevant tregistry key is removed via the transform (thus obviating the need for possibly awkward scripts) and simply add the group name to whichever application requires it. We have their GPO links quite a way down the link order so they're applied before any apps.

BTW, Nick, there's no point in DM1 sending the whole log as things stand at the moment because we can see in the fragment we have that the ISCLeanUpFatalExit is returning '3', almost certainly because the DCOM identity hasn't changed.

Hi Ian,
BTW, Nick, there's no point in DM1 sending the whole log as things stand at the moment because we can see in the fragment we have that the ISCLeanUpFatalExit is returning '3', almost certainly because the DCOM identity hasn't changed.

I'am not so sure about this, because i see:
Failed to install ISKernel Files
IMHO, that results from permission issues, when the ISScript file are installed.
But we can tell that for sure only, if we can get a look on the hole log.

But the longer i think about it, embedding the engine can't work at all with per user installation, because the engine-files are copied outside of the script and this results in this error.
What should work, is to install the InstallScriptEngine as prerequisite in the GPO with its own MSI, like Ian suggested.
Regards, Nick

Nick/Ian,

Here's the full log for your viewing pleasure!

Creating the GPO package for Isscript works, but if I can get away without doing that I will. Another limitation of GPO based user installs is not being able to script multiple MSI installs, or chain a pre-requisite MSI like you can in SMS.

At least I know that I can get it to install in some eventuality.

Cheers

ORIGINAL: nheim
Hi Dave,
this is definitely the permission problem, i guessed in my earlier post.
Another limitation of GPO based user installs is not being able to script multiple MSI installs, or chain a pre-requisite MSI like you can in SMS.

Why shouldn't this be possible?
You can assign multiple packages to one GPO. They are installed in the same sequence as they are assigned to the GPO.
Regards, Nick


I know what you're saying, and you are correct to a point, but we don't assign applications in this environment - we publish them to users based on AD Groups. We only assign applications to Build OUs. Obviously in the situation where you use an OU such as Laptop Build OU to build a machine, then assigning the isscript msi before the dependant one will install in the correct order.

However in a per-user Group Policy install environment such as ours there is no way to group MSIs or sequence them.

I think to move this forward I'm just going to rename the ISScript MSI "IXOS Pre-Requisite" and communicate to users that they will have to install it prior to IXOS. Thankfully we are moving away from GP installs with SCCM in the coming months.

thanks for your troubleshooting help with this - I feel you are owed some "rep" points...

Hi Dave,
pragmatical approach. But then, i would change the package and product codes too. See:
http://www.appdeploy.com/messageboards/tm.asp?m=9841
Regards, Nick

I've had my fair share of experience with the annoying InstallShield Script Engine and all the aggravation it creates for us packagers. I'm particularly interested in addressing the IDriver DCom identity issue. I want to fix this once and for all in my environment, but I want to understand it a little better and determine best practice.

• First, I have to ask, why does InstallShield set the DCom identity to "Interactive User" to begin with? Clearly we have been running into problems with it for years now, but InstallShield continues to set it, so there must be a reason.
  
• What possible negative impact might it have if I change it to the Launching User? Is there any reason to change it back to "Interactive User"?
  
• What is the best way to change this setting across the board in my environment? That is, what do you think would be best practice? Should I transform each and every ISScript MSI? Should I use the described custom action in each affected package?
  
• Is there a chance that this DCom setting may be reverted back to "Interactive User" by packages besides ISScriptxxx.msi? If so, how would you recommend combating that?

Thanks, and sorry if I'm duplicating questions that have been previously asked.

- I don't think the latest flavours do, do they? I thought it was only v8 which contained that foo-bar...
- There is no negative impact, quite the reverse, in that it'll actually work! And no, no reason at all to change it back.
- The best way is to include the script engines into your builds. Failing that, yes, apply an MST to all IS engine-installing MSI.
- I've not seen that but, if you do encounter it, it's simply enough to spot and change in the application's MSI via a transform.

• I have confirmed cases with versions 7, 8, and 11.5 where I've had to change the DCOM identity to get them to install correctly.

[blockquote]I just checked all of the ISScript MSIs that I have (7, 8, 9, 10, 10.5, and 11.5) and the DCOM identity for IDriver is set to Interactive User by all of them. Judging from the conditional logic in each MSI from v8.0 and up, it looks like InstallShield "fixed" it for Windows NT (VersionNT = 400) only, but not the rest (NOT VersionNT = 400). *headsmack*[/blockquote]

• OK, I wasn't sure if InstallShield had some certain reason for setting it this way, or that there might be some reason to have it set to "Interactive User" in certain situations.
  
• Too late for the builds (the customer probably wouldn't go for that anyway; I've had a hard time convincing them to include runtimes and things that should be in the base build). Unfortunately, we also have users who perform manual installations (so much for a managed environment), so I can't completely standardize and control the distribution of ISScript. I can still transform all the supported ISScript packages, but I think I'll also have to do something per-package where this problem comes up.
  
• I agree, I'll have to address it if I ever encounter it and handle it in the transform.

Thanks.