Where I work, we have a very locked down desktop for our users. Users can not install anything, everything is pulled or pushed down through MS SMS. Our current desktop has version 6 and 7 of the InstallShield engine.
We are taking on an initiative to push out the latest ISScript drivers (8, 9 and 10) to our users in order to facilitate the deployment of other software.
We are a Wise shop and plan on creating a Wise script that will install each of the isscriptX.msi files.

Can anyone think of any caveats or issues we need to consider before we roll this out?

Thanks.
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
Not that I can think of. They are MSIs so just make sure you have the lastest ones. I think with the 9.x and 10.x engines some of the MSIs supercede older ones so trying installing everything that you want on this page and then find out which ones are still installed at the end of it because some engines might get upgraded by a newer x.y release.

http://consumer.installshield.com/kb.asp?id=q108322
Answered 05/18/2007 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
So far, it looks like 8, 9 and 10 don't step on 6 or 7 at all. It basically looks good. Of course, everything looks good until the QA people get their greasy little hands on it and start breaking it to pieces. :)

Any ideas on v10, 10.1 and 10.5? Do i need all three or just one?

Thanks
Answered 05/18/2007 by: gtimlin
Orange Belt

Please log in to comment
0
Should be just one or two but I forget which installers upgrade and which ones do not. That is why I suggest testing it out or waiting until someone with a better memory makes a more informative post.
Answered 05/18/2007 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
Hi there,

I would not recommend this tactic for dealing with isscript-based installations. Documentation as to why I say this is already on this messageboard, in plenty. nheim wrote a summary where some of this is explained.

Consider using merge modules for dealing with isscript instead. This requires a bit more knowledge about packaging but give you a lot less problems in the long run.

Edit: link
Answered 05/20/2007 by: jib
Purple Belt

Please log in to comment
0
Hi.
I have got alot of problems with different versions of Isscript engines when distributing applications with SMS 2003.
One or more of the early isscript set an CR\AppID\ regkey to RunAs = Interactive User (in my machine I found "{223D861E-5C27-4344-A263-0C046C2BE233}", "{DEF67AFC-20D3-4ED3-8DE2-7A14E1C72E28}" and "{E4A51076-BCD3-11D4-AB7D-00B0D02332EB}", I dont know what versions these belongs to).

The thing is that the above registry keys changes the account that installs the application from the SMS-user to the logged on user, and if they isn´t admins as you say (or as in my case) the following application wont install. Often you can get around this by adding an MST to your isscript msi that sets the "RunAs=" key to nothing.
One problem is that some of the isscript versions may ignore that you allready has installed the it and will overwrite the registry key... I dont know how to slove this with sms.... At one of my customer we had this problem with the application Rational ClearCase LT from IBM, we solved it with manual installation of the application as it was very few that used it.

M.N
Answered 05/21/2007 by: Mackan75
Orange Belt

Please log in to comment
0
Marcus,

Have a look at http://itninja.com/question/msi-corporate-standardiser6, I've posted a custom action vbscript that will change any InstallShield InstallDriver DCOM Identity from "The interactive user" to "The launching User".
Answered 05/21/2007 by: AngelD
Red Belt

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