I spent the better part of today trying to finalize an SPSS 12 installer that doesn't involve repackaging (because of how badly our SPSS 11 installation worked as a repackaged MSI). The installer runs great as long as someone is logged in. I tried thinking of all the differences between our department's boot script or active directory push installs running and a logged on user, and couldn't figure out why these in particular would fail (esp. since so many other, similar installations have been successful).

It looks like the answer has something to do with the conditions under which DCOM objects are launched (my terminology is bad here). DCOM is configurable such that certain applications can be launched as one of a few different types of user (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/security_3gjd.asp). Our machines are set to launch InstallShield InstallDriver applications as 'interactive user,' who does not exist pre-logon. However, I tried setting DCOM to use 'Launching User' for the InstallDriver and InstallDriver String Table, to no avail. I'm too ignorant about DCOM to know my way around it very well and to know what else to try.

It looks like InstallShield might actually reset the "installdriver" and "installdriver string table" user from "launching user" to "interactive user" when it runs, effectively overwriting the changes I've made in order to make the installer work.

SPSS' support is disappointing (support.spss.com):

"
Resolution number: 40099

Resolution Subject: Ensure that a member of the local Administrator's group is logged into each machine

Resolution Description:
This problem has been filed with SPSS Development and will be addressed in a later release of SPSS for Windows. In addition to the SYSTEM account, the installer requires a member of the local Administrators' group to be logged into each client at the time of installation. If the installation still fails, it's possible that the local system (or current account) does not have access to launch DCOM. Particularly if you are using Group Policy to deploy the MSI, this appears because it is the local system account that initiates action before any user is logged on. In doing so, Windows Installer launches the InstallScript DCOM engine as user "interactive user" and generates this failure. To resolve this, you may use DCOMCNFG.EXE to change the launch identity of "InstallShield InstallDriver" and "InstallShield InstallDriver String Table" to "Launching user". We apologize for any inconvenience this may have caused.
"

I've got 200 workstations on which I need to install SPSS, and I'm distressed that I can't install without repackaging. Does anyone have any suggestions?

Many thanks.
cdo-appdeploy@sociology.osu.edu
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
http://www.appdeploy.com/packages/detail.asp?id=281
Answered 06/18/2004 by: cdupuis
Third Degree Green Belt

Please log in to comment
0
http://www.appdeploy.com/packages/detail.asp?id=281

Yes. I posted the last entry on that page. The earlier posts do not help.

All signs point to a DCOM configuration "problem" whereby the InstallDriver and InstallDriver String Table objects are set to use the 'interactive user' rather than the 'launching user.' The process idriver.exe runs out of process and breaks. There are numerous suggestions on how to manually change the DCOM configuration on a machine useing dcomcnfg.exe, but manual manipulation of individual machines scales poorly.

I've tried doing registry dumps before and after the DCOM settings change so that I can isolate the relevant settings and merge them before running the installer, but this fails for a reason I can't discern.

Is there a way to script DCOM settings, or set them via Active Directory? So far I've found nothing on the topic (so I might create a new thread about this).

Thanks.
Answered 07/09/2004 by: colinodden
Senior Yellow Belt

Please log in to comment
0
A good thing to check is that you are only installing what parts of SPSS that you need. Don't just do a typical setup, do a custom setup, it may result in not installing some of those DCOM objecs at all.
Answered 07/09/2004 by: cdupuis
Third Degree Green Belt

Please log in to comment
0
Unfortunately, it's not that SPSS is trying to install DCOM objects. It's that InstallShield involves DCOM permissions (maybe the installer is trying to launch or utilize a DCOM server?).

http://itninja.com/question/what-is-pxe?6 describes the problem, but only suggests a manual solution.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=LOgtc.555%24jP3.277%40prv-forum2.provo.novell.com&rnum=2&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26q%3D%2522launching%2Buser%2522%2B%2522interactive%2Buser%2522%2Binstalldriver%26btnG%3DSearch looks like a reasonable answer given what I've seen so far, but I've run into another, stupider problem with InstallShield (no matter what version of ISScript I have installed on the machine, the installer complains that the version is too old). If I confirm a particular solution I'll be sure to post it.
Answered 07/09/2004 by: colinodden
Senior Yellow Belt

Please log in to comment
0
What version of SPSS are you using.
Answered 07/09/2004 by: cdupuis
Third Degree Green Belt

Please log in to comment
0
I'm trying to install version 12 for Windows on Windows 2000 SP4 machines. I'm testing on freshly-rebuilt machines with the OS installed by RIS. Everything should be dandy; MANY other InstallShield installations work pre-logon on these machines (Textpad, Acrobat Professional, Eudora Pro, etc.).

The error I get is "The InstallScript engine on this machine is older than the version required to run this setup. If available, please install the latest version of ISScript.msi, or contact your support personnel for further assistance."

SPSS has a downloadable ISSCript.msi that I've tried (ftp://ftp.spss.com/pub/spss/windows/isscript.msi). In another post they recommend getting it directly from InstallShield:

http://www.installengine.com/msiengine20/instmsiw.exe
http://www.installengine.com/isengine/isscript.msi

I've also tried downloading and installing the ISScript.msi updates from InstallShield for version 7,8, and 9, to no avail.
Answered 07/10/2004 by: colinodden
Senior Yellow Belt

Please log in to comment
0
Did you try and install the isscript.msi directly off the CD.
Answered 07/10/2004 by: cdupuis
Third Degree Green Belt

Please log in to comment
0
Did you try and install the isscript.msi directly off the CD.

I was certain that I had originally, but I tried it again a couple days ago and the installer worked. Thanks for recommending this. I don't understand why I got the ISScript errors I was getting, however.

-Colin
Answered 07/15/2004 by: colinodden
Senior Yellow Belt

Please log in to comment
0
ISScript.msi is customizable, so SPSS may have chosen to customize it to suit the needs of the SPSS installer.

Glad I could help.
Answered 07/15/2004 by: cdupuis
Third Degree Green Belt

Please log in to comment
0
Disregard this..They posted a new version of the isscript.msi that works without having to change the identity privileges of the installshield installdriver. It's at their website at ftp://ftp.spss.com/pub/spss/windows/isscript.msi

I had to revisit the site and I still needed to change the permissions. I swear it used to work.
Answered 10/26/2004 by: armstr26
Yellow Belt

Please log in to comment
0
For InstallShieldScript 7 I use:

dcomperm.exe -runas {E4A51076-BCD3-11D4-AB7D-00B0D02332EB} "Launching User"

Now if you are using a different engine I assume the GUID will be different. Dcomperm.exe can be found via MSDN.
Answered 10/26/2004 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity