Software Deployment

Hi gomtesh,
yes that's version info, i was after.
You can get the ISScript MSM here:
http://knowledge.macrovision.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q110580&sliceId=
Regards, Nick

It sounds to me like that prompt is coming from USD, in which case you'd be best off directing your query to Computer Associates (or whoever owns Unicentre this week...)

VBScab,

Thanks for your post. Yes the prompt is indeed from the USD. Infact when i removed custom actions pertaining to ISSCRIPT ( about 7 of them) , the USD promptly continues (without asking for the exe file). However my package breaks when I do so. Is there a way to include ISSCRIPT in my existing package? So that I can have custom actions removed and all can go home.

You *could* nest the ISScript MSI into your installation but this practise is now actively discouraged. See http://msdn2.microsoft.com/en-us/library/aa368010.aspx for details. You don't say which MSI authoring package you have but both the main players (Wise/Altiris and InstallShield) offer the means to bundle MSIs into a self-extracting EXE.

However, since you have a deployment mechanism, it would, it seems to me, be best to simply deploy it before your package, or set it as a dependency.

Now, the prompt from USD.... As I mentioned, your question about *that* would best be posed in a Unicentre forum. Having said that, it strikes me that it's expecting to be fed the name of an EXE so either go with the s/e EXE option or find out how to feed it MSIExec.EXE and the appropriate command-line switches.

VBScab,

Still stuck at this point. And yes I always wanted to have ISSCRIPT as a procedure dependency. I am working on removing the custom actions one by one and checking for an easier option. If anything stikes to somebody, do let me know.

Er, why are you removing the CAs if you plan to include ISScript somehow? That doesn't make sense.

You don't mention the product you're playing with but IS function calls in other MSIs I've come across do things like create IIS virtual directories, set serial numbers, register DLLs etc, etc. It may be that, having removed the CAs, the application will not work properly, if at all.

You mention that removing the ISScript custom actions breaks the installation.

My own approach in cases like this is to use a comparison tool such as Picture Taker.

Using such a tool, you would compare an installation using the vendor's original setup.exe with a second installation using just the MSI (with all the ISSCRIPT custom actions disabled / removed) - make sure a clean test machine is used for each installation.[:)]

The comparison tool should then be able show you what activities the vendor's ISScript CA's are performing.

It is then often possible to replicate whatever the CA's are doing using native MSI functionality (by way of a transform).


Spartacus

Do you have a link for Picture Taker, Graham? A Google threw up all manner of unrelated junk, even with quite a refined search.

VBScab,

Okay the CAs, I assume were written when the setup.exe was handling isscript.msi and my package ( which is teradata btw). Now that i do not need the setup.exe, hence the CAs are of no use (since i will manually put in isscript). Now i have two options,

1) To include isscript in my msi package and remove all the related CAs .
2) Remove the CAs and use both msis one after the other.
Do let me know if this is a wierd approach.

Spartacus,

Will use picture taker and try your solution. Thanks all!

VBScab,

I think you are right. It doesnt make any sense to remove the CAs. I think i am losing my mind. Still working on it, appreciate if you guys can come up with anything :(

Should have pointed out that PictureTaker is quite an old tool originally provided by Lannovation so you may struggle to find a download. It has since been superceded by Prism Deploy and the provinding company is now Newboundary (I think)

There is an evaluation copy of the Prism Pack available at http://www.newboundary.com/products/prismpack/download.htm

I only mentioned PictureTaker / Prism because I personally find it useful but basically any tool that can perform a simple before/after snapshot (i.e without "Smart" monitoring) and produce a report of the changes would do job for you.

Regards,

Spartacus

Hi gomtesh,
the easiest approach would be, to include the Merge Module of the required ISScript engine version into your MSI package.
Please tell us, which version this package requires and i will give you some instructions to do it.
But first you should definitely read this post from Kim, it is one of the real lifesavers you can find in depths of this board:
http://itninja.com/question/msi-corporate-standardiser6&mpage=1&key=&#19827

Hope, this gives you some progress.
Regards, Nick

Hi Gomtesh,

I think you have already decided to include ISScript as a pre-requisite or software dependency, then you need not make any changes to CAs. You can retain them and there should not be any problems except one in which the MSI looks for the setup.exe to be installed.

I agree with VBScab for not including ISScript as a nested msi as it is not regarded as a good practice. I suggest you can use Sparatcus's suggestion Picture Taker and check the files and registries that are installed by the Setup.exe compared with the ISScript + your native application.
And if you still find any problems during deployment then you must contact Unicenter guys.

I am not sure about the solution for including the Merge Modules for ISScript engine, may be because I have never used it. But would like to know more about it.

Let us know what solution fixes the problem.

Cheers[:)]

Thanks for the post guys,

Let me brief you on my current status.

First I removed all the CAs that were in any way related to ISscript, the package works fine and also the USD takes it in fine.
but but, when installing the package, it no longer asks for ISSCRIPT.MSI :)). Also let me tell you that my package is NCR Teradata and it has 10 MSI modules . All these modules require ISSCRIPT.

Now I used picture taker and found out that there is no difference with my package after doing this. (i.e I need to install isscript as usual and then all the modules. Then they work fine).

So i am pretty okay, but the package is not built in the right manner yet.

nheim,

The version of ISSCRIPT is 3.00.185, Now if i include the merge module, can i retain the CAs?

India_repackage.

I could not find any one particular CA that calls for setup.exe , hence had to remove all . Hope to hear more suggestions.

Thanks all for your replies. Appreciate it :)

Hi Gomtesh,

Sorry, but i am a bit confused. If you have installed the IsScript as the dependency for the application then I dont think you need to remove the CA's. But I must admit since that you are the best judge as you know the application.

** I have found that some applications built in IS have custom actions which require the Setup.exe to be installed (I dont recollect the CAs, in case i do I shall let you know abt them) But as I have said you will get a prompt, and since you dont get any, then you can ignore this comment of mine.

Cheers [:(]

India_repackage

Let me tell you my main concern.

I overrode the setup.exe (ISSCRIPTDRIVEN=1) and now can now install my MSI safely (with the CAs intact). But when deploying on the USD it asks me for the setup executable. Hence I need to know how to fool the USD.

So i removed the CAs, and the USD takes the package fine now. By the way , i am repackaging the application, hence not sure of most of package working per se.

folks,
i'm getting a litle bit confused... :-)
@ Ian + Rajit: Nesting of ISScript engine can't work at all, because it would start up way to late! What does work, is to include the merge module of the ISScript-version, the package needs. See the Howto, Kim wrote (link above).
@ Gomtesh: ISScript version 3.00.185 ??? Never heard about this one. When was it published?

This issue sounds like the well known DCOM permission issue. See:
http://itninja.com/question/blackberry-3.6-must-run-setup.exe300

Regards, Nick

ORIGINAL: nheim
@ Ian + Rajit: Nesting of ISScript engine can't work at all, because it would start up way to late! Hi, Nick. I don't recall suggesting that. In fact. post 4 actively discourages it, as I always do.

Given that the error only occurs when the CAs are present, there's not much we can do here, but certainly the DCOM permissioning thing is an easy, no-cost try-out. After that, as per post 2, I think the OP needs to give Computer Associates some grief.

Nick,

The version is indeed 3.00.185, but the MSI name is ISSCRIPT9. Its a 2003 release. Do/ Can I put in a newer version?

I am still stuck guys.

Hi gomtesh,
please log the install and make the logfiles available online.
Do it once with clicking through the GUI and once silent with the /qn switch.
It could be, that some sequences, which are authored only in the GUI are needed for a successful install.
Regards, Nick

Nick ,

Yes will do that. Do i paste the whole thing here? (kinda huge!)

Meanwhile if anyone could answer the 2 questions below,

1) What is ISSCRIPT doing? Why cant the stuff it is doing, be a part of the mother package?
2) What are the Custom Actions doing anyway?

Lastly, Now if one could remember, to gets things hurriedly, I removed all the CAs.When I used picture taker and compared the source and my new package, i.e the setup.exe that installs isscript and then teradata and my new package, i.e manually install isscript and then teradata (without CAs), the Entries are ditto.

So can I go ahead with this new found success of mine? ;)

Hi gomtesh,
use a free ftp-server to post the logs (like http://www.senduit.com/).
ISScript is the Installshield script engine. It is needed to run custom actions, written in Installshields own script language.
The custom actions will most likely check for some conditions on a target system, like check for the presence of certain SW, etc.
In general, they do stuff, for which no out of the box action exists in Windows Installer.

Like is wrote above, i would fire up the MSI in ORCA and merge the ISScript9 merge module into it and see what hapens.
That's not nesting, but merging the engine into the MSI package.

Regards, Nick

Nick,

Thanks. Will try to put in the merge module. By the way , where can i get the module? And oh, I checked the logs and it says ISSCRIPT ENGINE VERSION = 9.1.0.429. Is that the one you were looking for?

Thanks!

Nick,

Thankyou. I will try this and keep you posted. Thanks again.

Nick,

I get a message "ISSCRIPT missing" when i launch teradata (now with the MSM). Any idea , where this launch condition is coming from? I have been to hunt it down in vain. Thanks for all the help.

Hi gomtesh,
check the 'LaunchCondition' table.
Even better, look up the log file, there you will see, which action produces this error message.
Regards, Nick

My guess is that, even with the relevant Launch Condition edited/removed, you'll still get errors, because the MSM may not contain the files which have the called function(s) in. That's way we simply call InstallShield runtimes as dependencies when deploying. It's SO much simpler! :)

Nick ,

It worked!! I tried the other MSM Installshieldscriptengine.msm (with SP1) , and works like a charm . The custom actions and everything else intact. Now i need to see how the USD part goes. Thanks a zillion for the help!

Hi Ian,
because the MSM may not contain the files which have the called function(s) in.
Are you sure about this?
Aren't the MSM's 100% substitutes for the MSI's? ISScript.msi never has custom functions in it, because it is provided by installshield, IMHO!
Do you have experiences with this?
The biggest advantage, i see with the MSM solution, is that you not have to bother with an prerequisite, which has a crippled way of hanging itself into the system. Installshield had reasons, that they put together this MSM's, i think.
Regards, Nick

Nick,

The MSM completely substituted the MSI without me touching any CA or launch condition of any sort. So what you say should be true.

Nick,

A twist in the tale. The installation works fine with UI. But under silent installation /qb or /qn, it asks for the isscript. I am searching in the CAs (admin UI sequence) but with no luck. Any pointers? Thanks!

ORIGINAL: nheim
Hi Ian,
because the MSM may not contain the files which have the called function(s) in.
Are you sure about this? Nope!
ORIGINAL: nheim
Aren't the MSM's 100% substitutes for the MSI's? I guess they're meant to be...
ORIGINAL: nheim
Do you have experiences with this? Nope!
ORIGINAL: nheim
The biggest advantage, i see with the MSM solution, is that you not have to bother with an prerequisite, which has a crippled way of hanging itself into the system. Installshield had reasons, that they put together this MSM's, i think.True, one would hope. I was just saying that, if the OP has a deployment system, it might be easier to just deploy the IS MSI as a pre-requisite/dependency. End of problem. :)

Hi gomtesh,
ok, like i guessed in earlier post.
You need to watch out for ISScript related actions, early in the sequence, that are there in the 'InstallUISequence' table, but missing in the 'InstallExecuteSequence' table.
Like ever, the logfile is your best friend here.
Regards, Nick

Nick,

I am trying hard to hunt it down but everything seems to be in place. Also the normal installation happens fine in both UI and silent mode. Its the ADMIN (/a) installation in the silent mode that causes this. Below i have pasted the exact point where this happens. Hope you can find it.

DURING ADMIN INSTALLATION (ERROR)
Action ended 09:22:45: SystemFolder.21206420_6BA8_4CFB_A48C_C72A6BFE80C0. Return value 1.
Action start 09:22:45: ISMsiServerStartup.
MSI (s) (A4:94) [09:22:45:320]: Doing action: ISStartup
Action ended 09:22:45: ISMsiServerStartup. Return value 1.
MSI (s) (A4:A0) [09:22:45:330]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI10.tmp, Entrypoint: MsiServerStartup
MSI (s) (A4:A4) [09:22:45:330]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI11.tmp, Entrypoint: StartUp
MSI (s) (A4:A8) [09:22:45:340]: Generating random cookie.
MSI (s) (A4:A8) [09:22:45:360]: Created Custom Action Server with PID 3248 (0xCB0).
MSI (s) (A4:90) [09:22:45:480]: Running as a service.
MSI (s) (A4:E4) [09:22:45:490]: Hello, I'm your 32bit Impersonated custom action server.
Action start 09:22:45: ISStartup.
MSI (c) (78:C8) [09:22:45:971]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
1: The InstallScript engine is missing from this machine. If available, please run ISScript.msi, or contact your support personnel for further assistance.
MSI (s) (A4!C8) [09:24:36:500]: Product: Teradata SQL Assistant -- 1: The InstallScript engine is missing from this machine. If available, please run ISScript.msi, or contact your support personnel for further assistance.
1: ISStartUp Failure. OpenEvent, Error = 0x6
Action ended 09:24:36: ISMsiServerStartup. Return value 1603.

DURING NORMAL INSTALLATION
C:\WINDOWS\Installer\MSI7.tmp, Entrypoint: MsiServerStartup
MSI (s) (50:B4) [09:14:36:876]: Doing action: ISStartup
Action ended 09:14:36: ISMsiServerStartup. Return value 1.
MSI (s) (50:F4) [09:14:36:896]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI8.tmp, Entrypoint: StartUp
Action start 09:14:36: ISStartup.
1: The InstallScript engine version currently installed on this machine is adequate.
MSI (s) (50!F0) [09:14:37:347]: PROPERTY CHANGE: Adding ISStartupEvent property. Its value is 'E1437337'.
1: Event 'E1437337' is created

Nick,

Never mind. I got it solved.

The install UI/exec and admin UI/exec were using diferent actions after ISSTARTUP. I got the admin ui/exec tables to match the instal ui/exec action. Works fine now.

I really appreciate all the help that was provided. cheers!

Hi gomtesh,
glad to see, it worked out for you.
Keep MSI'ing. :-)
Regards, Nick